Re: *.COD file format why I want it
John Payson email (remove spam text)
> I do this. Before Walter sent me the file format, I had to scan
> for a long series of 0000s then switch to a mode to scan for variable
> names. Now that I have the format, I can do this with greater elegance.
> The symbols that I scan for are
> #ChipID: - marks the address of special chip ID address
> #LastLine: - marks the end of the program (so I only burn the locations
> actually containing code.
While simulation, etc. might benefit from #LastLine, I think it's better to
look at the hex file to see what locations need burning. For the 14-bit
parts, I find it easy to simply fill my buffer with $FFFF [not a valid code]
and then use one of four modes when processing those addresses:
 Don't blank-check that address; simply ignore it.
 Blank-check it and require it to be blank.
 Unconditionally program a zero there.
 Blank-check it; if blank or zero, leave alone; otherwise burn all zeroes.
Given that $3FFF at the start of a program is essentially a do-nothing opcode,
using option #4 makes overburning (i.e. using excess code-space in the chip
to hold multiple versions of the code without having to erase) much easier.
For example, if my program is 512 bytes or less and I'm programming a 16C622
(2K), then I burn my first program at address zero. If that doesn't work, I
modify my code, change the start address to $200, and burn again (same chip,
no erase). Then $400, then $600. If I'm using interrupts, things get a
little bit harder (but not too much): on the first burn, $000 is a jump to
start of code, $004 is a jump to start of interrupt, and the rest of the code
starts at address $008. On the second burn, $001, $005, and $208. Etc.
For the 16-bit parts, the $FFFF-as-flag-value technique doesn't work (though
CALL $1FFF is an unlikely instruction, $FFFF could be part of a data table).
Consequently, I had to make my hex-loader take note of the last byte loaded,
but this wasn't too hard (actually, I may subdivide memory into 16-byte chunks
and make the loader set the flag for every chunk that's used. If any code
has gaps in the middle this should speed up programming a bit). Has anyone
else used techniques like this in burners? I've found them to be quite help-
ful at times.
In reply to: <Pine.GSO.3.96.970810103707.3019A-100000@winc0> from "Fred Thompson" at Aug 10, 97 10:51:48 am
See also: www.piclist.com/techref/microchip/devices.htm?key=pic
You must be a member of the
piclist mailing list
(not only a www.piclist.com member) to post to the