Eprom Emulators - an alternative approach.

[electrosys]

There have been several posts on here recently concerning Eprom Emulators, and I'm always staggered at how complex these devices are for what they are required to do.

So here is an alternative solution for creating a similar useful, but far simpler bit of kit - one I used frequently throughout the 1980's.

The first device to make is a relocate-able ZIF socket - simply solder the ZIF socket of your choice on top of a header (aka 'component mounting board').
My preference has been to use Cambion headers which, being made from grp, are a far superior product to plastic. The ZIF socket can be now be inserted into the eprom socket of the target board. Life is already getting easier ...

For repeated 'tinkering' with firmware, instead of burning/erasing/re-burning EPROMs, use instead a parallel EEPROM or a battery-backed SRAM. If you've only got ordinary SRAM, it's not that hard to cobble together a back-up battery system for it.

Ok - so how to get the code into the EEPROM or SRAM ?
By far the easiest way is with the same EPROM Programmer you would have been using to burn your EPROMs - of course, with a suitable adapter (schematic attached).

What may not be clear from the diagram, is that this adapter is made from a 24-pin turned-pin socket soldered on top of a DIL-24 Cambion header, with pins 18 and 21 of the upper socket having been clipped away. There is enough room between them for the circuitry. I could post a photo if needed.

There are several variations on this basic idea - I have fitted a flying lead (a link or minature switch would be neater) to the upper pin 18 (/CE) so that the EEPROM/NVRAM can still be used whilst still remaining in the adapter (to save wear and tear on the pins).

Other possibilities of this 'turned-pin socket on top of a header' technique would be to make another module with just a switched /WE line and thus convert any form of NVRAM into a protected 'ROM', programmable only on switch selection (in a RAM socket, or in a ROM socket if /WR is available).


An alternative method of getting data into an EEPROM/NVRAM would be to use any micro board with a suitable spare RAM socket and the means to communicate with your host computer. If you plan on doing this often, it might be worth making a second 'relocate-able ZIF socket': be kind to your pins.

'best,
Colin

[Kat Manton]

Hi Colin,

Originally Posted by electrosys

Ok - so how to get the code into the EEPROM or SRAM ?
By far the easiest way is with the same EPROM Programmer you would have been using to burn your EPROMs - of course, with a suitable adapter (schematic attached).

And therein lies the problem. It takes minutes to get code into my programmer over a 19200-baud serial link.

Then I still have to transfer the programmed device from the programmer to the system I'm programming, power it up, test the code, power it down, transfer the device back to the programmer, wait several minutes to transfer new code...

With a parallel-port emulator, it takes less than a second to get code into the system. The system remains powered and the emulator holds the system reset line low while code is transferred into it.

I have one xterm open just for copying code to the emulator. Assuming the command is already in the command-history, 'up-arrow' then 'enter' and within a second, the system is running the new code.

This ability to test new code rapidly and easily encourages frequent testing after writing smaller chunks of code; that makes it quicker and easier to locate problems and ultimately speeds development.

(I suspect that my problem is that, having used EPROM emulators extensively for professional software development, I've got used to using them. Having used them, anything else is interminably slow and rather frustrating afterwards; not too good given I code for my own entertainment these days...)

Cheers, Kat