8-Bit Reviver

An Arduino Mega2560 with DIP28 adapter to emulate 27C series eeprom up to 64KB.

Similar projects worth following
A low-cost eeprom emulator to allow for recovery of embedded systems where eeprom has failed. Useful in situations where CPU and ROM are not integrated - legacy embedded systems - allows for rapid changes and upload of new code without waiting for eeprom erase/burn cycle.

Having started my training in electronics with an 80C552 based development board, coupled with an eeprom emulator, the ability to modify and upload code was essentially as easy as it is with an Arduino these days.

Rather than having to erase and burn an eeprom with every change to the code, when you are just learning this can be very often! The eeprom emulator contained up to 64KB in SRAM and the compiled code was uploaded via the PC LPT port. There was a DIP28 socket on a flat-ribbon cable that replaced the eeprom and let the CPU believe it was addressing ordinary eeprom.

This project was born out of the idea of reviving my 80C552 without the expense of an eeprom emulator or eeprom programmer/eraser. My initial thoughts were to interface an Arduino Mega directly to the pins of the eeprom and by reading the address bus and performing a 2D array lookup in flash where the compiled .hex code was stored - provide the relevant data to the 80C552. 

This isn't going to work - mainly due to the fact that both the 80C552 and Mega are running at 16MHz - the latency introduced by the Mega - read address bus, lookup data byte, write databyte - will take an enormous amount of time compared with how long a direct read of an eeprom actually takes.

  • 1 × Arduino Mega2560
  • 1 × DIP-28 Socket
  • 1 × 74HCT573 Octal Latch
  • 1 × IDT 7007 Dual port 32Kx8 SRAM


    Bart van der Wee07/02/2014 at 03:41 0 comments

    Having decided that the direct-connected mega2560 will be too slow, I will change tack and utilise the above dual-port SRAM module. The Arduino Mega2560 will contain the .hex file within it's flash memory and at power-on will transfer this to the DP SRAM. There will be a flatribbon cable+dip28 socket to connect to the 80C552 board - or any similar embedded cpu that uses this is similar eeprom.

    The SRAM will be treated as ROM by the device being 'revived' - with some creative coding it could be possible to modify code on-the-fly via a serial console back into the Arduino Mega2560.

  • Initial Concept

    Bart van der Wee07/02/2014 at 02:51 0 comments

    My first thought was to have the Mega directly connected to the eeprom address/data/control lines. When it received an address it would then lookup the corresponding data byte in it's own flash memory and put it on the data bus.

    A closer look at the timing charts for both chips shows that this approach will be too slow even with highly optimised AVR assembly language routines - which I wasn't going to attempt I had hope to do everything from within the Arduino IDE!

View all 2 project logs

Enjoy this project?



Steve Day wrote 05/10/2018 at 23:43 point

Did anything emerge from this project?

I'm thinking it would be a good basis for another C64 cartridge (one that was a RAM based freezer). The AtMega would pre-program the RAM with the freezer tools via an SDcard (which used to be a process that was done manually using a floppy disk) and handle the parts that used to be done using TTL chips.

  Are you sure? yes | no

Bart van der Wee wrote 07/03/2023 at 07:55 point

Nothing came of it - timing becomes a problem due to the speed of actual eeprom vs emulated eeprom.

  Are you sure? yes | no

Radu Motisan wrote 10/08/2015 at 08:27 point

Thanks for following the #Portable environmental monitor , finalist in this year's hackadayPrize

  Are you sure? yes | no

raps500 wrote 01/25/2015 at 04:29 point

I was going down this path, an AVR as ROM, till I wrote down the program and discovered how slow it would be. It may not be a problem if the processor has some wait signal, but in many cases it would mean to hack the board. If you go with single-ported memory, most problems could be solved, except on the fly update (without reset). You would need some buffers between the processor and the SRAM, if the processor doesn't put the bus into Hi-Z during RESET, I think.

  Are you sure? yes | no

Bart van der Wee wrote 07/02/2014 at 02:02 point
Thanks Stian for your comments, have followed your suggestions after reading up the datasheets. Have requested a sample of some IDT7007 dual port 32Kx8 SRAM - will see what comes of that.

  Are you sure? yes | no

Bart van der Wee wrote 06/25/2014 at 21:04 point
@Stian that was my one concern - thank you for the information it will save me bundle of work learning AVR assembly :-) I had another idea that might get around this, just researching it at present, stay tuned.
@yo3ghm this is still very much on the drawing board, will post more details and pictures today.

  Are you sure? yes | no

Stian Soreng wrote 06/26/2014 at 11:20 point
Thanks, I'll follow this project to see what tricks you have up your sleeve :) Just a tip: My C64FC project (alsol on this site) was where I tried this at first, but I ended up "cheating" with a dual-port RAM chip instead. The on-board AVR simply programs the DPRAM on the fly, and the computer only sees the RAM as a ROM chip. Might be something to consider if you run out of options.

  Are you sure? yes | no

Bart van der Wee wrote 10/06/2014 at 02:49 point
Getting hold of DPRAM seems to be the problem these days. Will go down this track if I can find some.

  Are you sure? yes | no

Stian Soreng wrote 06/25/2014 at 12:50 point
Very interesting project! I'm curious whether you will be able to make the emulation fast enough to work on a real system. Source: I tried the same earlier with an ATmega128 @ 16MHz, couldn't get it to emulate fast enough on a 1MHz system (even with code written in 100% tight AVR assembly)

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates