>>Given that $3FFF at the start of a program is essentially a do-nothing op
>>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.
>
>         Thats a good idea!  I'm just writing short test programs right now
> and this trick would save a great deal on erasing.  I'm not clear on why
> the HEX file is a benefit here unless you take advantage of its text
> nature and modify your hex code before running the programmer.  I should
> probably add a "Modify Data" feature to my programmer as this would be
> easy.

I use the .hex files because I understand them, I had code lying around from
another application, they're universal, and THEY WORK JUST FINE.  Perhaps a
.COD file would work better, but I can't see any "problem" with .HEX that it
would fix (for emulation, that would be a different story of course).

Personally, I'm waiting for the day when someone adds the following features
to compilers/assemblers:

[1] The ability to take information about starting address, etc. from a file
    that would be updated (by the burner) whenever a chip was burned, thereby
    automating the overburn process (perhaps it could use an old copy of the
    .HEX/.COD files to find out exactly what needed to be overburned and what
    routines could be left as-is.  The .COD could be *extremely* helpful for
    that.

[2] A "#strike"/"#endstrike" directive which would cause the compiler/assembler
    to emit NOPs instead of the struck code.  When striking out moderately long
    routines, it's a pain having to insert precisely the right number of NOPs
    to make everything else line up.  An automated directive could simplify
    this.

Anyone else like these ideas?