EmuROM - An Open Hardware ROM emulator

Back in the nineties I spent a couple of years doing embedded system design, plus developing ISA and EISA cards. We had some cool tools for working on embedded machines, one of which was a ROM emulator. It was a plastic box with a ribbon cable hanging out one end, and a PC parallel port on the other. You could remove the ROM from a target system and plug it in, and load the ROM image into RAM inside the device under control of your PC. It made messing about with ROMs really straightforward.

Anyway, I'm messing about with ROMs now, and find the whole remove-erase-program-reinsert thing tedious, especially when my EPROM programmer only works on my old XP machine, which due to it's fragility isn't networked, which in turn means all my code has to be stuck on a USB stick to transfer to the programmer.

So I went looking online for ROM emulators. I found almost the perfect device, by John Tsiombikas. A straightforward board with a little Atmel microcontroller loading a RAM chip with data, which in turn is gated to the host machine using some tri-state buffers. Even better, John has released the whole lot under a Free Hardware and Free Software licence, allowing anyone to take his design work and play with it as they wish, as long as they in turn release their work under the same licence. And it's in KiCad!

Works for me! I took John's board and started by dropping support for 24 pin ROMs. If I ever need to emulate 2732's etc, I can aways do another board. As it's so tiny and I wanted to ensure good signal integrity on the host machine, I did away with the ribbon cable and mounted it via a 90 degree header and adapter board directly to the machine. I did a little work on the layout to reduce the size of the thing and neaten it up, including hiding the host tri-states under the RAM, which is socketed.

In any case, all the design files are on my google drive. I haven't yet updated the software, but am envisaging extending the firmware a bit so that no software is needed on the controlling PC aside from a simple terminal program, with EPROM code downloaded via X-modem, and perhaps even a simple monitor program. I do most of my work on a Mac, and like to use existing software (like serial-ii) as much as possible.

Here are the files.

Metcal MX500P soldering iron repair

I've been giving my soldering iron something of a flogging of late. It's a Metcal MX500P, one of the very finest irons ever to be made. It uses 13.56MHz RF to heat a teensy inductor right in the tip, with an incredibly ingenious temperature regulation system whereby a magnet in the tip, once it gets to temperature, hits it's Curie point and loses magnetism, changing the frequency the coil resonates at and thus making it get more or less hot with the applied 13.56 MHz. In any case, yesterday it simply stopped getting hot. I found an extremely good on-line analysis of the soldering iron here., and mention of dead driver transistors. in forums.

In any case, I opened it up and had a look, and there was a pretty obvious popped capacitor:

It's C4, a 330n 63V film cap that just does smoothing on a DC rail. Here it is after removal:

I replaced it with a 330n 100V one, and voila.

FreeBee Premium

This one is the logical progression of the FreeBee, just as the Premium (aka alpha) was the logical progression to the Microbee.

Indeed, the whole objective of the Freebee design is to get to this. I've had this idea of a massive simplification of the microbee video hardware in my head for literally decades, with the idea of wrapping the screen data back to the same RAM to get character data. This worked a treat with the Freebee. Now let's go nuts and access the sama overworked RAM no less than four times for each character. First we get the screen data, then attribute data, then colour data for a given character, then we use the screen and attribute data to look up the relevant character data on the fourth and last access.

It's a lot more complicated than Freebee. There's a whopping 57 ICs crammed into the main board. However like Freebee, it's a whole computer that doesn't need a coreboard to function. This makes debugging so much easier, as I don't have to muck about with coreboard extenders. It's got 32K of general purpose RAM alongside the 32K of Video RAM, plus 64K of EPROM, so it can load it's character data up and boot into standard Microbee 5.22e basic without adding any other boards. Of course it's totally compatible with Microbee coreboards, as well as SuperPAK and the Compact Flash coreboard.

To route all this extra complexity, I had to go to 4 layers. This makes it more expensive than Freebee, but not ridiculously so. Still done with gorgeous rounded tracks so it looks like it was done in tape.

I've added the ability to run the CPU off either 6.75 or 13.5 MHz in turbo mode, so (hopefully) with the right CPU this'll be the fastest bee on the block. In order to make that work with the glacial speed of the 6545 though, I've had to add a pile of wait states on I/O access.

The need for a 74LS open collector part to scan the keyboard always annoyed me, so I've used a bog-basic CMOS '138 instead, and added some diodes so it can't source current.

The PIO and tape circuitry is totally unchanged from Freebee.

There's not a lot to say about the coreboard connectors. Note there's no sensing of ROMSEL from the coreboard - the boot code needs to figure out where to jump after finishing the boot routines. It's always 8000h except for the annoying 56K CP/M coreboard.

Here's the core of the design - the video memory. One 62256, one data bus transceiver, several sources of address (CPU, CRTC, screen+attribute)... The key is wrapping around to get the character data sorted out.

There's some glue to make the screen sequencing work, and to allow CPU access. As with Freebee, CPU access is denied until the screen is in retrace. As with Freebee, there's no stinkin' PLDs.

On a whim I added a sound chip. This was never really supported on the Microbee hardware, and can simply be left off the board.

Finally the CPU and memory. Much the same as Freebee. The machine boots in boot mode, and the character font is copied into character RAM before the boot ROM pages itself out of existance. There's some jumpers to enable mainboard RAM and mainboard ROM above 8000h, in case you're running without a coreboard.

Here's a pic showing build of the prototype. It went together quite nicely.

And first boot. There was a stuff-up necessitating a bodge wire where the video output latch was not enabled. Additionally composite output (shown on the left-hand monitor) is inverted. Nothing that can't be fixed with more bodge wires! My mind is totally blown that my video sequencing scheme worked first try.

I wrote a quick test program in basic to sequence through colours. This shows that the keyboard works (albeit using tweezers to short contacts for many keyswitches where I'm waiting on parts), it shows that the colour circuitry works, and by running inverse at the bottom is shows the PCG RAM works. So that pretty-much validates the whole video memory design.

Next step is to try loading a game from tape. Emu Joust won't cut it, as it's monochrome. Gotta be Kilopede.

After inverting the pixel data for composite output and playing with the resistors for composite video (I ended up with 330Ω for pixel data and 680Ω for intensity) I get a nice clear separation between normal and intensity on in composite:

There's a stuff-up on the prototype where i didn't connect the LV register to the video logic. This had the effect of disabling PCG over 2K. Connecting them up then caused basic 5.22e to display garbage, as the register isn't cleared on reset. I fixed that in the boot ROM, then connected a SuperPAK with 5.29e basic, which has support for premium graphics via hires2. Finally I ran the demo program from the premium basic manual:

The result is a rather cool display using all 16K of PCG. It's a premium bee!

It was agreed on MSPP that the definitive Premium test would be to run Quix-2.com. This required getting a Compact Flash coreboard running (thanks Brad!), and transferring the program from my mac using Telcom (and Serial-ii on the mac side), thus validating that my serial port works. Then we get to display a cool screensaver.

Meanwhile, the production version is pretty-much ready - just gotta do some QA. I've done a bit of placement optimisation - moving the power switch, adding a teeny speaker on the board, shrinking the big power cap...

Irritatingly, it looks like the Fremium board doesn't get on with super-fast video RAM any better than the standard FreeBee. This is with a 71256A25 - 25nsec cache RAM...

After a bit of poking and prodding, I found the culprit. /VWR was generated from /VF000 and /WR, but the address lines for the video ram are also dependent on /VF000, and they go through several gates before percolating to the actual RAM. The result of this is that the address lines don't settle until around 10ns after /VWR is asserted. With very fast video RAM this is enough time to occasionally latch data to the wrong address, with the result above.

The fix isn't as straightforward as just running the /VWR line through a couple of gates to slow it down, as this will just move the problem to the other end of the write cycle. Instead we use a flip-flop to delay the falling edge of /VWR by one dot clock (74ns), and use VF000 to deassert the /VWR line straight away (using an asynch set input to the flip-flop). The result is clean writes with fast 25ns video RAM, as well as our slow 85ns stuff.

And here are the design files.