> 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.

        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.

>
> 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.
>

        I'm not yet into 16 bit parts.  I'm sure the day will come.

Thanks for the tips
Fred
fthompso@mail.win.org