Afternoon, All.

After much googling and gnashing of teeth, I still haven't found information regarding what the first values inside a typical PIC .hex file are. I'm probably googling the wrong set of words, or something.

I've begun a PIC assembler project, and have already figured out the process of how the hexcode in the .hex file are created from the opcodes/etc.

for example:

;Project: Turning on a LED
;List P = 16F84
;#include <>

ORG 0 ;This is the start of memory for the program.
SetUp BSF 03,5 ;Go to Bank 1
CLRF 06 ;Make all port B output
MOVLW 01 ;Load W with 0000 0001
MOVWF 05 ;Make RA0 input
BCF 03,5 ;Go to Bank 0 - the program memory area.
CLRF 06 ;Blank the output

Main BTFSS 05,0 ;Test the input line on port A
GOTO Main2 ;Button not pressed
BSF 06,0 ;Button pressed. Turn on LED
GOTO Main ;Loop Main
Main2 BCF 06,0 ;Button not pressed. Turn off LED
GOTO Main ;Loop Main

END ;Tells assembler end of program

is assembled to this:


BSF 03,5 is in the file as 8316

I'd like to know of any pages/info anyone has on what the first "10000000" is/means. It changes slightly between .asm files. I'm assuming the first value has something to do with the size the code takes up in memory?

Any help would be appreciated.

Posted on 2003-05-01 09:08:07 by Scronty
Humm, I (unfortunately) never messed with eeprom programming, but I did play (briefly) with a 68k IDE that produced output in HEX format. I tried getting a .HEX -> binary converter going so I could load it into a 68k emulator, but... then I sorta forgot about the whole project.

Iirc, has a couple of specs on HEX formats - I think there was a little mismatch between what the 68k compiler output and what the docs said though, but that might just be my bad memory.
Posted on 2003-05-01 10:08:19 by f0dder
Hi, Scronty,

Check out this link:

Hope this clarifies it.
Posted on 2003-05-01 11:52:56 by VVV
Kool.. didnt know this... However i cant get the first line check sum to equal zero... (me shrugs)...

It might be a hybrid of this format.. (since PIC's are definitely not intel based ;) )
Posted on 2003-05-01 16:24:02 by NaN
Afternoon, VVV.

Thank you very much.

It just shows you how great this messageboard is as a valuable resource of tech knowledge.

After a whole day of searching the Net, and perusing large numbers of pages, I post this question and go to sleep. First thing this morning, my headache has been cleared.

Thanks again.

Afternoon, Nan.

Thanks for the heads-up on the checksum problem.
Because of that, I decided to do a few checks/tests to see how you'd go about it.

After a few goes, I found this out:


The above ^ is this first line from a valid .hex file ( EXPT1.hex from the file, which is downloadable from here: .
According to the info on the page VVV supplied, we know that the last byte is the checksum. Remembering how to do byte-to-hex conversion, we know that the 'AB' on the end is the checksum.
Also: that it is a checksum which, if added to the sum of all the bytes, will equal 00h (ignoring any overflow).

So the first byte we begin adding from is '10h' (the number immediately after the ':').
Thus, we have:

10h + 00h + 00h + 00h +
83h + 16h + 86h + 01h +
01h + 30h + 85h + 00h +
83h + 12h + 86h + 01h +
05h + 1Ch + 0Ah + 28h

which equals 355h
Since we're only concerned with byte-sized values, we drop the '3' and just use the '55'.

The last two characters are a checksum (sum of all bytes + checksum = 00).

sum of all bytes + checksum = 00
55h + ??h = 00h
00h - 55h = checksum
checksum = ABh (<- just want the last byte. If we use a dword-sized register for the calculations, then we ignore the fact that we actually get a negative value)

Next step is to figure out which way to do the parsing and generation of the hex. There are many methods, and I'd like to decide upon a method that is easily modified for additional chips (I only have 16f84 PICs+info at this stage).

Posted on 2003-05-01 17:56:45 by Scronty
Thanks for the verification of my dyslexia. I was adding BAh + 355. (Doh!) ;)

BTW: What is your end purpose in all this. You want to design your own programmer? Or hex assembler?

Posted on 2003-05-01 23:12:47 by NaN
Afternoon, Nan.

BTW: What is your end purpose in all this. You want to design your own programmer? Or hex assembler?

Both.:grin: :alright:

I've spent the first few days of this week trying to find out how to output to the parallel (printer) port on my XP machine. Going through quite a few of the available premade drivers from the Net, none of them seemed to work until I discovered that I can't even "type myfile.txt > LPT1" via the command prompt on XP:mad: .

So instead of trying to see if any of this stuff worked by outputing a single character to the printer, I soldered an LED+resister to a 25 pin socket. plugged it in, and made two proggys: one outputed a 'A", the other a 'B'. The LED was wired to the lowest data bit, which should be a 1 for 'A' and 0 for 'B'.
It friggin' well worked.

This was using Winio driver/dll/lib.

It was only after I got it working, that I saw that bit7 has uploaded a PIC writer (4PIC) which uses Winio as well ( grrrr. I'm sure I can hear "fate" laughing at me).

So the next step was to decide on how to implement an assembler (.asm to .hex). I'll still build a programmer into it, however I need to put the horse infront of the cart first;). I've downloaded the PIC16F84 data pages for all of the instructions and figured out how to read them (pretty straightforward). The only thing which was missing was to understand what the data in a .hex file actually was (the first 4 bytes, and the last checksum byte).

Posted on 2003-05-01 23:50:04 by Scronty

You want to design your own programmer? Or hex assembler?

if i got a chance, i will build one without a desktop computer need. so, both is build with own design :grin:
Posted on 2003-05-02 06:50:54 by dion
Afternoon, dion.

if i got a chance, i will build one without a desktop computer need. so, both is build with own design

That's a nice sentiment, and I agree with the idea.

However... the assembler needs a file with asm code. It assembles it into an ASCCI hex file.
A programmer takes the ASCII hex file and programs the PIC.

Even though you could cut the middle step out, and go from asm file to programming the PIC, you would still need to be able to get the asm code to the program.

A standalone piece of hardware wouldn't be able to do this...

hang about...

You're not talking about building hardware which has two huge friggin' buttons ("0", "1") are you?:grin:

Posted on 2003-05-02 07:47:02 by Scronty
I guess you havent seen this then (written by vom-bonjour)...
Posted on 2003-05-02 16:51:10 by NaN
Afternoon, Nan.

That's pretty damn scary :grin: .

Posted on 2003-05-02 20:04:15 by Scronty
My only complaint about the WinIO .dll (or AsmIO) is that there is not any interupt ability to it... If i can't get interupts to work between my hardware and ring3 software, i dont care for it.

Im currently looking into USB as it appears to be a simpler solution that dealing with the parallel port (from a software point of view)..

Posted on 2003-05-02 21:48:19 by NaN
sorry being too arrogant, Scronty :grin:

but what i mean is i was dreaming someday i will build one mini computer with a big LCD, a computer's keyboard, and a FDD. so, i will happy to type something in and save it to the disk. i had learn how to interface FDD, so i just need a time to do it :grin:

i do this because i had each time i type something, i had to tired my eyes to see monitors, and fire up my really slow computer, just to *typing* something :tongue:
Posted on 2003-05-03 07:05:37 by dion
Afternoon, dion.

sorry being too arrogant, Scronty:grin:

No need to be sorry. Also: you weren't sounding arrogant:tongue: . The sentence you gave made you sound ignorant (and around here, on'y I'm supposed to be that:grin: ).

Your idea for a programmer project is quite good, and might be an idea to pursue in this Electronics forum. I'd get involved myself, however I'm still a couple of months away until I'm in a situation to start on it.

Posted on 2003-05-03 07:14:55 by Scronty