Mutton dressed as lamb (Part 1)

With the advent of faster FPGAs with sizeable quantities of RAM, it's becoming possible to breathe new life into old micro designs whose days would otherwise be numbered. Trusty workhorses of the last decade or two that are suffering from bit-rot and obsolescence may just be viable for another decade - with minimal engineering effort.

Consider this: an 8 bit micro-controller board has been running faithfully as far back as you can remember controlling a critical component of your assembly line. Trouble is, they've been slowly dying over the past few years and sources for seconds are drying up.

You've absolutely no need to update your machinery, so you face the prospect of a costly re-engineering exercise to re-create your controller boards - without those parts you can no longer buy.

Alternatively, there's a battered composite monitor and quirky keyboard jammed into the corner beside your PC monitor.

It gets used for about 30 seconds every week, but as it is the controller console, it's a must-have. It would be nice to give it the boot and replace it with a simple keyboard/monitor switch on your desk.

Enter the FPGA. Originally the domain of custom high-speed designs and/or ASIC prototypes, the cost and size of devices nowadays makes it possible to implement entire systems on a single device. And while that usually entails a vendor-supplied processor providing embedded software support for specialised high-performance logic, it also enables the (re-)implementation of legacy microprocessors and micro-controllers and acres of peripheral TTL logic.

If it ain't broke - don't fix it!

As any experienced hardware or software engineer will agree, very wise words indeed. Unfortunately, as your legacy hardware starts failing, it soon becomes time to bite the bullet.

You've exhausted your avenues of replacement and you're dreading the disruption that will inevitably occur if you introduce some new equipment into the equation.

Software is notoriously difficult to clone. And that's even if you have the assembler source code for it! The odds are against you being able to reproduce the exact behaviour - and this includes those 'features' that were introduced inadvertently by the programmer - and even if you did, you wouldn't be able to prove it!

Hardware (more specifically, a 20-year-old microprocessor design) is much more straightforward to clone. All the logic is laid out bare in off-the-shelf TTL chips.

There may be a few PALs or GALs doing the odd bit of decoding but there's not much guesswork involved in re-implementing an exact replica of such a design.

This article recounts my experiences in re-implementing a handful of microprocessor-controlled boards and while their application is hardly mission-critical, they do serve to illustrate the concepts.

The boards I have re-created entirely within an FPGA are a handful of classic arcade video games (along with a couple of 8 bit microcomputers) of the very early eighties.

These games generally occupied a few square feet of real estate, stacked sometimes as two or even three separate boards and connected by up to four ribbon-cables.

They housed one or more 8 bit microprocessors, such as the Z80 or the 6502, had small amounts of various RAM chips for video, sprites and main memory, and perhaps a dedicated sound chip or two. The rest of the logic was implemented in discrete TTL logic.

Reinventing the wheel

There are two approaches to the problem of a re-implementation; namely either a verbatim clone of the original schematics, or a functional equivalent whose interface to the processor is consistent with the original design. Each has its own advantages and disadvantages.

The former appears to be favoured among others who have re-created these classic arcade video games, though this may have more to do with the 'purist' nature of most enthusiasts. Indeed, given a schematic of the original circuit, this technique may well be the least-cost and perhaps least error-prone approach - at least when using an FPGA design tool that enables schematic entry.

And while sound engineering knowledge is obviously required to do the job, it could be argued that an intimate knowledge of every aspect of the circuit's operation may prove unnecessary.

Of course, this method requires that you have access to a (known to be correct) schematic diagram. It also precludes the use of more modern and perhaps more efficient and/or reliable designs.

But perhaps, most importantly, this approach foregoes (or at least limits) the opportunity to update the external interfaces and in the process add some new capability and/or consign some ancient peripheral to the scrap heap.

On the other hand, the latter approach does require some reverse-engineering effort in understanding the original design. While not strictly required, the schematic can greatly enhance this process.

I would argue that real-world examples that merit this treatment aren't likely to have much in the way of complex logic implemented in hardware; rather the complexity is in the microprocessor code and the electronics merely interfaces the processor I/O with the outside world.

A real-world example may be a PCBA that controls some assembly equipment. It interfaces to an ASCII (as opposed to PS/2) keyboard and dedicated LCD and sends status and alert information via a serial port to a printer or remote dumb terminal.

In the process of preserving the 'brains' of the controller, we can bring it into the modern world and save some floor space while we're at it. By adding a PS/2 keyboard interface and performing the necessary translations and emulating the LCD with a simple character set and VGA controller, this new board may co-exist with existing modern equipment by using a keyboard/monitor switch at the control station.

The old serial output brings up more interesting possibilities. We could embed a second CPU with a simple UDP stack and encapsulate the serial stream to a remote application anywhere on the plant's data network.

Without much more work we could convert status and alarm conditions to SNMP trap messages, or respond to simple SNMP status requests, and interface to an existing network management system. All while preserving the precise behaviour of the original software!

So back to my games...

I chose the latter approach for a number of reasons. Firstly, while the manufacturers published the schematics for a lot of the very early games, it didn't take long before bootleggers and unscrupulous operators put paid to that practice.

As luck would have it, an active project to document the workings of these games via software emulation contains pretty much all the information that is required.

Secondly, the original games interfaced to RGB monitors with low scan rates (~15 kHz) in various resolutions and rotations and custom control panels.

I wanted to have the option to be able to play these games on a standard VGA monitor in its normal orientation, and with a standard PC keyboard (or at least an arcade controller with a PS/2 interface). Composite video out would also be nice.

Thirdly, a lot of the circuitry on a video arcade PCB is concerned with generating the video display. As the MAME project illustrates, most games use variations on the tile-map-and-sprite theme. My idea was to create a customisable graphics core that could support any of these games with just a few tweaks to a couple of VHDL modules.