From the Chess Computer to MAME
Intro
Since I started collaborating with the MAME development team, I have received many queries from Chess Computer fans about some aspect of the emulation process. This process is not always the same, as it depends on the type of computer, the data available, whether or not there is a similar computer already emulated, and so on.
In this article I will try to explain, with the help of graphic documentation, all the steps of the emulation process. To do so, I will take advantage of a small chess computer that I have recently worked on and that I think will be a good example due to its "relative" simplicity. It's the SciSys/Novag Super System III.
Let's start...
What is the purpose of emulation in MAME?
First of all I'll clarify something that often creates confusion: MAME originally stood for "Multiple Arcade Machine Emulator", but in 2015 it absorbed the sister project MESS (Multi Emulator Super System), so today MAME documents a wide variety of old computers, video game consoles and calculators, in addition to the Arcade video games that were its initial focus.
The aim of MAME is to preserve decades of software and hardware history, preventing it from being lost and forgotten. To do this, a copy of the software is made (a process called "dumping"), and the hardware is documented as well as how it works. The emulation (creation of a new driver) is then programmed, in order to check that the whole process has been carried out correctly. The MAME source code itself serves as documentation.
From here on, everything depends on the use you want to give to the emulation.
To learn more, I recommend visiting the official MAME website: www.mamedev.org
Preparation
Although it is desirable to have a working unit, this is not always possible. If it doesn't work, I usually repair it first, because it makes the subsequent work easier. But if this is not possible, you have to make the most of what you have! Sometimes, with the "dump" of the ROM and a few good pictures of both sides of the motherboard, the MAME development team is able to make an initial emulation, which can be further improved by adding more data at a later stage.
In the case we are dealing with here, a German friend sent me his Super System III to contribute to the MAME project.
After checking that it was working fine, I started to disassemble it completely to have access to all the elements:
ROMdumping
A "romdump" is the creation of a ROM (Read Only Memory) "image", which we store in a binary file. ROM is a type of non-volatile memory, i.e. the data it stores cannot be electronically modified after it is manufactured. There are some types such as EPROMs (Erasable programmable read-only memory) that can be erased and reprogrammed, but this is beyond the scope of this article.
In a chess computer, the ROM contains at least the program that allows it to run and play, but it may also contain the opening book, problems to analyse, famous games, etc. The ROM may be on one or more chips inside the computer, on an external cartridge, or split: one part inside (usually the main program and engine) and one part on a cartridge (usually the opening book).
In the Super System III we find two chips, located on the main board, of the Mask-ROM type (unlike the EPROM, here the data was programmed at the factory, and cannot be erased or modified).
To perform the romdump, we need to know the technical characteristics of these Mask-ROM chips. In this case it is not easy, because the printed information was "customised" by SciSys.
Let's see:
At the top we have the logo of the chip manufacturer: Synertek.
Then, after the logo, the date of manufacture: week 48 of 1979 on one chip, and week 11 of 1980 on the other.
In the middle line we have a reference that does not belong to Synertek, but to SciSys.
The same is true for the last line, which clearly identifies 'SS-3' (Super System III), 'HROM' (High memory address part) and 'LROM' (Low memory address part).
With this data we don't know the technical characteristics of the chips, but knowing the manufacturer (thanks to the logo), the year of manufacture, and the number of pins of the chip, we can get an idea of its real reference. Analysing the connections on the printed circuit board also helps.
In this case, I came to the conclusion that these were two 4 KB 'Synertek 2332' chips (the ROM has a total size of 8 KB). Being such old chips, which don't comply with the JEDEC standard, none of my commercial "ROM readers/programmers" could perform the "dump". So with the help of the technical specification sheet, I used a method that I have already successfully tried in similar situations: the use of a small ARM microcontroller (like the ones used in Arduino boards), which I can program at my discretion, to fulfil the specific reading procedure of this and other ROMs from the 70s.
The data is dumped into the 'flash memory' of the microcontroller, from there it is sent via serial communication (RS232) to a PC, where a first integrity check is performed by means of a hexadecimal editor.
This image is then written to a binary file, and so we have completed the romdump process. In this case resulting in two binary files of 4 KB each.
Reverse Engineering
I focused again on the motherboard, which contains the microprocessor, RAM, ROM and main digital circuits, making a netlist (list of nodes) necessary for the subsequent creation of the electronic schematic.
But on this computer there is a second board that contains the power supply, control switches and, most importantly in terms of emulation, the Display control circuits. With the exception of the power supply, the rest also has to be analysed to complete the netlist.
The keyboard should also be studied in order to make a detailed schematic of it.
And the LCD, from which each 'segment' has to be identified and documented.
The Display on this computer was quite a lot of work for me. First of all the disassembly without causing damage, as the protective cover was attached to the PCB, with the plastic melted at different points as a rivet.
On the other hand, the control chip (MD4332) is unknown to me and it doesn't control the entire LCD, but also uses 6 chips with 4 logic gates each.
Once the netlist has been completed, the electronic schematic can be drawn:
Finally, I reassemble the computer to be able to take some critical measurements with the Logic Analyser and the Oscilloscope, which are not always easy to deduce from the schematic, such as the different clock signals, sync signals, IRQ signal (normally used for Timing Control), etc. These signals are essential in order to achieve the most accurate emulation possible in MAME.
Making the MAME "driver"
All this data is provided to a programmer from the MAME development team, alias hap, with whom I have been collaborating for years. But there are many other programmers in the MAME development team, some of them specialised in Arcade, others in video game consoles, etc.
hap didn't have it easy, because it was necessary to interpret all this data, and convert it into a driver for MAME, which would be compiled in the next version of the software. The programming is done in C++ language.
In this case, the resulting driver has more than three hundred lines of code, but in addition hap had to emulate the MD4332 Display driver mentioned above, as it had not been used so far in MAME, and therefore was not integrated in its kernel.
After several days of work, all the code was written and MAME could be compiled to test the new emulation, with this result:
Using the "Super System III" emulation in MAME
At this point it is possible to play with the emulated computer as if it were the real computer, thanks to the integrated artwork.
But it doesn't end here. Thanks to the work of other people, like Franz Huber with his CB-Emu compilation, it is already possible to play with many emulated Chess Computers even from Arena Chess GUI! And the fabulous artworks by Luis Angel, Volodymyr, etc. allow to enjoy more realistic and 3D artworks. But all this is another whole article to write.