December 22, 2018

Using the promice ROM emulator

This assumes you have the unit all hooked up, cables straightened out, a proper power supply and so forth. All of this is covered elsewhere. This section discusses using the software once everything is up and running.

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: 
high
rom=27256
number=1
word=8
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 / tom@mmto.org