eprom burning question

If you have access to a Linux system you can do the combining with "dd" (one of many choices but it's straightforward).

One way to do this would be

dd if=/dev/zero of=combined.bin bs=1 count=8192 dd if=1st.bin of=combined.bin bs=1 seek=0 conv=notrunc dd if=2nd.bin of=combined.bin bs=1 seek=$((0x1000)) conv=notrunc dd if=3rd.bin of=combined.bin bs=1 seek=$((0x1800)) conv=notrunc

In plain language - create an 8k-byte file full of zeros, then copy each of the three separate images into it, seeking to the appropriate offset in the file first, and not truncating the file while copying.

Nice solution, I would only suggest editing the create function to make it a 8K file of "FF"s so you aren't trying to burn 00s - this will speed up the programming slightly. Afraid I don't know how, but I'm sure it is easy to look up...

John :-#)#

...

Use /dev/one instead of /dev/zero :)

It would *only* speed up programming if the hardware/software used optimizes things and skips/refuses to "program" locations that are 0xFF (the default blank chip state).

Otherwise, there's no speedup there.

Serious answer, if you don't have /dev/one available, change the first line to :-

cat /dev/zero | tr '\000' '\377' | dd of=combined.bin bs=1 count=8192

Omitting the "if=/dev/zero" takes input from stdin, and tr swaps

Nice work!

I wasn't really worried about the speed, more changing FFs to 00s seemed a bit pointless in the grand scheme of things, plus any unused space (FFs) in the EPROM could still be used if the OP needed something else in the future.

Or just erase and start over...which we've all done I'm sure!

John ;-#)#

Well, some programmers do optimise by "not-programming" 0xFF, which may not make much odds on a decent programmer. I added this step to the custom software for my EPROM programmer which talks over a 4800 baud RS232 serial link, where every byte matters! :)

Same for a "Rapid blank check" (check 1024 bytes spaced through the chip to check if they come up blank) for quick-sorting of blank vs programmed.

Yes, that's actually a good point -- I've used 27512 parts where I really needed only a 27128 (with two spare high address lines tied to jumpers to ground/pullup resistors) to allow four goes at programming the chip before having to chip-swap or erase!

Too many times :(

First we need to know what file types Mike is using. The proposed solution is OK for binary images, but actually in EPROM burning it is more common to have HEX files, which have lines containing an address, a number of bytes, and usually a checksum, all in ASCII HEX.

To combine those files, you would just need to cat them together.

If the OP is using osX I could recommend a little program I use quite a bit - burning EPROMs many times a week - called Synalyze It! Pro. Easy to merge files, do checksums of various levels of complexity and compare binaries.

Here is the free version:

And I do recommend buying the Pro. I know I don't use all the features...

John :-#)#