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

[1] Don't blank-check that address; simply ignore it.

[2] Blank-check it and require it to be blank.

[3] Unconditionally program a zero there.

[4] 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.