Emulating ROM with a one-chip ARM

[BigEd]

This project is for a multicart for a Vectrex, a 1.5MHz 6809 system, but the principle is surely applicable to any 8-bit system which runs at modest speed. The ARM chip reads the address bus and drives the databus using its general purpose I/Os. The ROM contents to emulate can be uploaded via USB to the ARM.

http://spritesmods.com/?art=veccart&page=2

It's a 100MHz ARM chip in this case - we've got a thread full of ARM dev boards including an inexpensive one that's 168MHz.

First design:


Actual build:


(via Hackaday)

[Mike Naberezny]

There are still commercial EPROM emulators available, but most of them seem to target the automotive market and tend to be expensive. An low-cost EPROM emulator with USB like the one presented here is a great idea.

I bought my EPROM emulator, the "DPROM 2" from Applied Data Systems, around 2002. I got it on eBay for next to nothing, back when they were somewhat common there. The device itself was made in the early 1990's. Inside, it has a PIC microcontroller and SRAM that is battery-backed. I have replaced the battery twice. It has an RS-232 interface and receives data in Intel Hex format.

In the years that I've owned it, I've made a variety of adapters for it, like the one pictured below. The target system uses two 2716s but the adapter makes it look like one 2732 for the emulator. I've used the emulator on every 6502 SBC that I've made along with various other systems.

The computer I use these days doesn't have an RS-232 port so I use an FTDI US232R-100. It takes about ten seconds to upload a 8K image (2764) into the emulator. Going from a burn/erase cycle of 5+ minutes down to 10 seconds really changed the development experience for me. I also used to have a small pile of EPROMs that I would cycle though so I wouldn't have to wait for the erase, but it was still inconvenient to have to swap the chips. I'm hooked on the emulator and don't think I could go back.

How are the rest of you programming the ROM on your machines? Are you still burning EPROMs, using a ROM emulator, or something else?

[BigEd]

Mike Naberezny wrote:

I bought my EPROM emulator, the "DPROM 2" from Applied Data Systems, around 2002. I got it on eBay for next to nothing...
How are the rest of you programming the ROM on your machines? Are you still burning EPROMs, using a ROM emulator, or something else?

That's a nice little box! I know richarde has built a box a bit like this - without the battery backing, and loaded using I2C, and with no onboard micro. It's called Rombo. I see I've mentioned it a couple of times before, and as it happens, in threads about ROM emulation:
USB-connected ROM emulation?
ROM emulator

[BigDumbDinosaur]

Mike Naberezny wrote:

How are the rest of you programming the ROM on your machines? Are you still burning EPROMs, using a ROM emulator, or something else?

I continue to do it the old-fashioned way: 27C256 EPROMs (55ns parts), an EPROM burner, and my "state-of-the-art" EPROM eraser I hacked together some 27 years ago. The unit on which I am testing the code gets a ZIF socket plugged into the EPROM socket for quick and painless chip swaps. It takes about 10 seconds to burn and verify an EPROM and less than a minute to swap a fresh EPROM. Fifteen minutes are required in the eraser, which can erase 20 EPROMs at a time.

"State-of-the-Art" EPROM Eraser

ZIF Socket in EPROM Socket

[GARTHWILSON]

Mike Naberezny wrote:

How are the rest of you programming the ROM on your machines? Are you still burning EPROMs, using a ROM emulator, or something else?

I haven't used my EPROM programmer in years except to refresh EPROMs. But if I had to develop something to be used with an EPROM, I would still use the programmer. When I was doing that, I'd keep the eraser going most of the time, and another EPROM was ready to come out every time I needed one. ZIF sockets made it easy. I test routines on the workbench computer now though with its onboard Forth assembler for its interactiveness, so things can be proven before going to EPROM. The last time I did a lot of EPROM work was probably when I was developing my '816 (actually '802) Forth.

[DerTrueForce]

Mike Naberezny wrote:

How are the rest of you programming the ROM on your machines? Are you still burning EPROMs, using a ROM emulator, or something else?

I'm using a Minipro TL866A programmer and EEPROMs, and I can blast a 32KB image in something less than five seconds. I've never actually timed it.

I use multiple ROMs so I can keep things seperate. One of them is my DUART test program, and one's my VIA test program.

[Aslak3]

Mike Naberezny wrote:

How are the rest of you programming the ROM on your machines? Are you still burning EPROMs, using a ROM emulator, or something else?

I bootstrapped my machine using a home-made programmer for 28C256 EEPROMs. This programmer uses an AVR and some 8 bit counters to form the address bus.

Now I can reprogram the EEPROM in-place the programmer is rarely used.

[Mike Naberezny]

BigEd wrote:

I see I've mentioned it a couple of times before, and as it happens, in threads about ROM emulation:
USB-connected ROM emulation?
ROM emulator

Thanks for the links, I missed those threads the first time around. In the second thread, yzoer mentions that he needs to manually reset the processor after uploading new code to his emulator. I need to do this with the DPROM 2 as well. I've seen some commercial EPROM emulators that have a clip for /RES. The emulator will hold the processor in reset while the code is being updated and then release it automatically. That feature would be really handy.

DerTrueForce wrote:

I'm using a Minipro TL866A programmer and EEPROMs, and I can blast a 32KB image in something less than five seconds. I've never actually timed it.

I just bought one of those last week for when I need to burn a real EPROM. I've been using a parallel port programmer for many years. I only have one computer left with a parallel port. It's a hassle to drag that out just to burn an EPROM, and it has some issues I'd just rather not deal with anymore, so I've finally moved to a USB programmer.

[sjgray]

I do occasional EPROMS for my ColourPET project. I have a MCUMall GQ-4X programmer (USB), and a real eraser. I test my code using the VICE emulator and only write EPROMS when the code is stable. I have about 10 eproms I rotate as needed and keep 5 or so BLANK so I can write any time, and then bulk erase a batch when I need.

I'd love to have a small USB eprom emulator. The ones on ebay (ostrich brand) seem to be about $170 these days. Too much for me. If someone can make one for <$50 that would be really cool.

Steve

[Rob Finch]

For what I’ve worked on lately, ROMs are simulated in a simulator or emulator running on a PC workstation with the whole project being simulated.

I hard code the ROM contents as hexadecimal in Verilog code, then download the ROM with the rest of the project code in a bitstream that configures an FPGA. The download uses a USB cable that connects to the FPGA board. There is also an option in the toolset to program the bitstream into a spi EEPROM that can be used to boot the FPGA board.

In the past when I’ve used EPROMs I used a PC ISA based board that connected with a custom parallel interface cable to an EPROM programmer. It would program anything from a 2716 to 27c512. I had to keep an old 386 machine around for years as it was the only PC that could contain the EPROM programmer board. I just got rid of the programmer and PC last year. I still have an eraser and a number of eproms just waiting for projects.

I’ve been contemplating replacing the EPROM programmer as I think I won’t have a use for it in the future. I haven’t programmed an EPROM for a couple of years.

[Alarm Siren]

Mike Naberezny wrote:

How are the rest of you programming the ROM on your machines? Are you still burning EPROMs, using a ROM emulator, or something else?

I built a custom ROM Programmer for my project, built around an Arduino Due. It can write to 28BV64 EEPROM chips, either a single one on its own (left socket) or using the "cartridge" connector (bottom middle). Source files can be plain binary or motorola S-Record, and are obtained from an SD Card you plug into the back with your files on. Because it grabs the files off SD card, it is platform indepedent. It can also erase chips or dump the contents of a chip to the SD Card.

[Tor]

I'm using an old serial EPROM programmer that I got for free (from work, obsoleted. Got a UV eraser too). It can be used with just a terminal, something I've used to copy & patch an existing (E)PROM.
Edit/update: A ROM emulator is something I have considered for some time.

[BillO]

I have mostly used a process similar to what Garth describes. I get out 5 or so EPROMS and keep the eraser going while I test and debug. Lately, though I have favored EEPROMS. I've not found them so expensive though. The last lot of them I bought in June from an eBay vendor 'jk_parts'. I bought 10 SST27SF256-70 EEPROMS for $9.00. 90 cents each is not what I call overly expensive.

[Oneironaut]

Cool to see another uC becomes ROM project.
I did this as well using an Atmega324 to directly become ROM in a VIC-20.

A tight assembly loop reads 2 ports as address, and then does a lookup from program memory to dump the byte out of another port. I had to use a 74HCT245 to do two jobs; translate from TTL to CMOS, and offer OE.

Response time of the fake ROM was around 200ns.
It can be reflashed in an instant, and does not require a wonky expensive programmer.

Brad

[Chromatix]

For the project I'm currently planning, an EEPROM is called for, along with a bootstrap debugger module for when the EEPROM hasn't yet been flashed (or requires emergency recovery). I should be able to load bulk code over a UART from a Raspberry Pi, so only a basic loader has to be toggled in on the bootstrap.

The main impediment to building the bootstrap module is actually a shortage of binary-to-hex 7-segment drivers - BCD decoders are still available, but the hex ones have inexplicably been discontinued. I may need to settle for 16-way demultiplexers and a less friendly display, so as to avoid relying on a GAL for that purpose.