December 22, 2018

The promice ROM emulator

I am using this now in 2018 to work on a historical project involving the MC6809 microprocessor. Prior to this I used it in 2012 to emulate code for the 6502 processor as part of my MacLAB reverse engineering. I have had the actual hardware since about 1991, and it is still working well. Probably the biggest reason this has not ended up a useless piece of electronics scrap is that it was supplied with source code for the software. It may once have run on MSDOS, then on Sun unix systems, and now runs fine on modern Linux machines. I am currently using it along with an inexpensive USB to serial converter.

Back around 1992, a company called "Grammar Engine Inc." produced a series of products, one of which was the "promice" ROM emulator. What this is is a little box with a serial cable on one side, and a cable you plug into a ROM socket on the other. Inside the box is some static RAM and a microcontroller. When you have some could you would otherwise burn into a ROM, you send it over the serial port, the microcontroller in the box loads your code into the "emulation RAM" and then makes it available via the cable (plugged into the ROM socket of a target system) so that the target system thinks it is an EPROM.

It works like a charm, and is almost a million times better than burning and erasing eproms. Once code is debugged, you do of course want to burn it into an eprom (or flash memory these days).

A particularly nice thing that this company did (they were nice all around) was to provide the source code for the program that runs on the host computer. The program is called "loadice" and is written in C. In 2012, I tracked down the files I had (the latest version was on a 3.5 inch floppy, which was still readable. I am wanting to run this program on a Linux system, and this has required some modifications and debugging.

I have it running and my unit identifies itself as:

 ID 0 uCVer:5.0b MemSize=131072 EmuSize=131072 FillChar=FF
So, my unit has 128K of emulation RAM, so it will emulate ROM's up to 27010 devices. It is also running version 5.0b of the promice firmware, which at this time is sort of academic.

Switches and Jumpers

There are a number of switches and jumpers on the unit, here is how they work:

The switches tell it what size ROM it is emulating. You set all of the switches for your size rom and smaller to "ON".

Then on the other side of the place you plug in the ribbon cable are a bunch of jumpers. The first 4 tell it where it should get power from. I usually install the "EXT" jumper and use the little 9 volt wall wart. You can let the promice get its power from the ROM socket (they say it only draws 120 mA). If you do, you set a jumper to "24" or "28" or "32" according to the number of pins in the device you are emulating.

A note on the wall-wart. The one I have is a 9 volt, 200 mA device, which seems barely adequate. Indeed the manual says that a 500 mA device should be supplied with the unit. The manual also says that the unit should draw less than 120 mA, which would lead one to believe that the 200 mA device I have (and who knows where it came from) is actually adequate. What makes me nervous is that the power LED on my unit blinks off and on. This could be a bad solder joint on that LED or some such. Stay tuned.

Important note: Be very sure you identify pin 1 on the socket and the cable and get it plugged in right. Getting this wrong will cause something to get damaged. You have been warned! There should be a red stripe on the pin 1 side of the cable, and if you are lucky a sticker on the plug that goes into the ROM socket that marks pin one. If you haven't figured out how to identify pin 1 on a chip or socket by now, you are probably in the wrong business. Here is a hot tip! Get a PC socket with 24 or 28 or 32 pins (as needed) and press it onto the plug, then plug that into the socket. This way when pins get bent someday (since you will plug this thing in and out fairly often) you can just get a new socket rather than having to repair the plug on the end of the cable. You will thank me someday for this advice.

There are 6 more jumpers which I never use (12 pins all told).

Actually, I lied - I have used the RST pin, which they provide a little clip for that you can attach to the reset line in your target system and allow the promice to reset your system after a new rom image is loaded. This is cool and very handy.

I would like someday to use the the WRT line (which allows you to bring a write strobe from your target system to the promice). The idea here is that you can set aside an area in your ROM image which is actually writeable RAM and communicate back with your host system. A cool idea, but will require some clever software support. I should look into it someday perhaps.

Downloading an image

You can feed this things hex files or binary images (which is nice). To feed it a hex file do this:
loadice myproject.hex
To feed it a binary image, do this:
loadice -i myproject.bin
Loadice looks for a file named "loadice.ini" in the current directory. This file contains options (which can also be specified on the command line). A typical file I have used, looks like this:
The equivalent command line would be:
loadice -h -w 8 -n 1 -r 27256
The "high" or -h option tell it that it can reply full speed, rather than throttling responses to something like 9000 baud. The "rom" or -r option tell it what kind of ROM you are emulating (you can say "27256" or "32k", your choice). The "number" or -n option tell it that you have only one unit connected (you can probably omit this if you aren't daisy-chaining multiple units). Likewise "word" or -w can probably be omitted if you have only one unit.

In fact, just now I used the following lines to successfully load a binary image into a 27256 prom socket:

loadice -h -n 1 -w 8 -r 27256 -i maclab.bin
loadice -h -w 8 -r 27256 -i maclab.bin
loadice -h -r 27256 -i maclab.bin
loadice -h -r 32k -i maclab.bin
So, clearly the "-n 1 -w 8" options are not required when using a single unit to emulate one ROM.

There is quite a bit more to the options. You can specify a different serial device (via "output" or -o) and baud rate (via "baud" or -b) among other things. There is also an interactive "dialog mode" that lets you do lots of interesting things, but which I have never bothered to get too familiar with.

Intel hex files and offsets

This is a headache and has been ever since we first got the unit. The unit views the ROM as starting at address 0. If you feed it an intel hex file that has proper addresses starting at say 0xF800 (as my present project does using a 2716 rom and a 6809), it will complain about "address out of range". Understanding how to offset the file addresses to the target addresses is a deep and muddy mystery. Everyone who has ever worked with one of these units has pulled their hair out over this. Whether to blame bad design or bad documentation or both is unclear.

One option is to convert the hex files to binary. These have no inherent address, so this will work in many cases. This requires software to do the hex to binary conversion (or a compiler that will emit binary files). This may yield a binary that pads unknown bytes with zeros, which is a mild nuisance and waste of time, particularly if the same files are one day used to burn actual EPROM devices.

However, we have the source code, so we can either figure out what options may achieve our purpose or make modifications so that this will work.

After an afternoon of studying the source code, here is what I learned. A line like this will do the job:

loadice loadice -r 2716 tom2.hex f800=0
The last argument indicates that address 0xf800 in the hex file should go to address 0 in the ROM image. Easy once you know the story. If you fire up the command line, you would type much the same syntax.
hex tom2.hex f800=0

Feedback? Questions? Drop me a line!

Tom's Computer Info /