MAME: Donated hardware for dumping

I got two PCB:s in the mail donated by Robert Quenet who is building emulator cabinets out of some old fruit machines.

Since I think the old fruit machines are worth preserving I dumped the roms and put up one page each to collect the information for later use.

The one at left was made 1993 by Fun Tech and based on a Z8400 processor and has 4 roms. While dumping one of the roms were sitting tight and the top broke off, either because the chip was old and had a crack or because I was a bit too eager. When I read out the content of the rom the reader told me a checksum that was different form what the label at the top said which worried me a bit, but soon later it has been verified that the rom was ok, only of the wrong size hence the checksum was wrong.

The one at the right was made around 1997/98 by Subsino and had only custom labels on the chips, however this brand is well known and there are drivers in MAME already which may fit the roms.

Just a day or so after I published the dumps I got the first results from Haze who had tinkered a bit with the Funtech roms and found that they fit well into one of two different drivers already in MAME too. He quickly produced the following screens from the roms:

 

Sooner or later these old fruit machine may be playable by people again without loosing loads of money and we all remember them from pubs and casinos end of the previous millennia!

Update: Early binary of the MAME emulation is here

MAME: Ironing out the address map from schematics

The other day I was very lucky, I got the schematics sent to me from Kron Ltd in Ukraine, for a thing I bought on the Ebay a year ago or so. The thing is a Kron K-180, a Z180 based terminal server from the mid 90:ies made up of east block TTL equivalent chips with Cyrillic characters! See my Kron180 page  for all the details.

When you got the schematics it can be quite easy to extract the address map. In this case we can see that the entire address space is divided into two parts by enabling the ROM when A15 is low and the RAM when it is high. We can also see that the A14 and A13 is not attached on the RAM chip since there is only 8Kb of RAM. This is how I present this to MAME:

The AM_REGION and AM_SHARE creates labels that I can use when loading the ROM and mapping the screen memory onto the emulated video device. The AM_MIRROR says that the A13 and A14 is not used when the range is selected hence it will be mirrored on the upper 24Kb om memory map. ADDRESS_UNMAP_HIGH simply says that unmapped areas are read as 0xFF.

The Zilog and other Intel like CPU:s also has an IO map, which Motorola like CPU.s doesn't. The IO map is selected when the special instructions IN and OUT are used and involves its own bus control signalling. Here the schematics are not as simple as for the RAM and ROM.

There are two decoder chips on the K-180 pcb that decides what device will be accessed and how, the first is the standard decoder chip 74138 and then there is a cascaded 74259 latch. They are hooked up like this:

74138

74259

As can be seen we now have all the address lines A0 to A7 defined. With a bit of tracing we can see that the Q0 output of the 138 is connected to the 259 at pin 14 which is active low. There is also A7 connected to pin 4 at the 138, active low. An interesting detail is that A3 is connected as data input to the 259 which means that there are different output level on O0-O7 accessing the 259 in IO range $00-$0F compared to $40-$4F and it is also locked until the next access.

The 138 is only active low during the access cycle itself. With all this information it is quite simple to trace the schematics and see what signals and devices are accessed for the Q1-Q7 outputs of the 138 and the O0-O7 output of the 74259.

Now, the Z180 has internal I/O registers between $0 and $3f which happens to overlap with the identified adress map, unless it is relocated. This can be done by setting the ICR register and by setting an IO access breakpoint at the ICR register in the MAME debugger we can easily verify that the internal registers are relocated to $80-$BF

74299

As a working assumption we model all accesses as writes just setting and pulse signals, except for 74299 which has an easily spotted parallel output that is connected to the data bus:

Then we can setup the complete IO map in our driver like this:









We handle the 259 latches as a single item since there are hidden data in the address. In order to debug this I declare stub functions in the K-180 board driver:

As can be seen there are special cases when accessing the 259 and also when reading from the 299. By setting a watch point in the MAME debugger we can verify that the assumptions are correct

Hmm, there are reads from offset $10 which is mapped to the AP5 line, interesting!

Checking out the schematics again we can see that AP5 is chip enable on another 74299 and that the writes to $F and $7 toggles the clock to the EEPROM. A not so wild guess is that the second 74299 is used to read out the EEPROM.

So I add another stub for reads at offset $10 and continue to go through the startup code as far as the code executes without crashing or misbahaving. When it does I need to go back and add real code to the stubs and reiterate the process until all devices in the IO map are identified.

Then the fun starts, stay tuned!

MAME: Saving old computers

When writing a MAME driver for an old computer it is more to it than one can think of.

You are seldom lucky enough to get full schematics or even access to real hardware. Sometimes all you get is a rom file from someone that worked on the system ages ago and some general idea. If you are lucky there are documents about the system on the internet somewhere like www.bitsavers.org. Sometimes you find a forum thread from someone who bought something on Ebay and posted some pictures asking people what kind of machine it was. The information mining and detective work is the first phase of the adventure. The less you find the more eager you'll get to find out what it was. At least that is how I am geared. :)

The next best thing after schematics are detailed pictures of the PCB:s involved which reveals the chips and how they are interconnected. However even with this at hand the PCB has components which hides the traces on one side and there might not be a picture of the bottom.

In this picture I have both bottom and top side of the PCB. The bottom part is mirrored so I can easily follow traces from top to bottom through the via holes without getting confused. Since I don't have the actual hardware at hand I can't use a volt meter to test which pins are connected, I need to see it on the image. I used Gimp to fill in the traces from the 74LS138 chip to be able to make an address map which is needed to write a MAME driver.

MAME also has a built in debugger which can be used to see where the rom code accesses things and then guess which of the chips it is, usually setup patterns from other drivers can be seen and verify the guess together with the visual trace on the PCB image.

It is actually great fun to figure out old designs from clues like this. In the end this specific work will be documented in the driver  and on my Candela page for others to find out.

MAME: Esselte 100 and serial support

The Esselte 100 has a rudimentary serial port that is available on the multi faceted I/O port labeled "Printer" where also the different measurement experiments are attached. In order to use the serial port in the emulator it has to be started with an emulated null modem cable attached to something.

In this example we will run it against a Telnet terminal. In order to get out of the emulated world and into the real world we attach it to a bit banger device which in turn needs to be attached to a socket server. These parts will translate the emulation time serial communication into a data stream through the socket server to the telnet terminal.

The null modem has built in support for the bitbanger and does the translation between stream data and the selected baudrate. This is how you set up MAME to work this way:

First you can check what devices is supported by a certain driver. The driver for Esselte 100 is called e100 and the option to use is called -listdevices:

The interesting information here is "RS232 Port" because it is a slot device which we can explore further with the -listslots option:

Here we can see that the RS232 port device called 'rs232' supports null modem. From not so well known sources we also know that the null modem support a bitbanger device which in turn accepts a socket address as argument like this:

This will start MAME as we want it to, The connection between the PIA pins and the rs232 device is defined in the emulation driver for the Esselte 100 and not something we can change from the command line. Once MAME is started you can open Putty.exe or you favorite Telnet terminal and connect it to the socket server using 127.0.0.1 (or the IP address of the machine running MAME if you are using a Telnet terminal on another machine) and port 4321 ( can be change to any port ).

Skip through the alerts at the beginning af the MAME session and at his point you will see two windows, one with Esselte 100 and one with the Telnet terminal:

The Esselte 100 starts in 7 bit, 1 start bit, 2 stop bits and 300 baud so we need to set up the null modem to talk to us at this speed through the internal menu system of MAME. This is enabled by pressing Scroll Lock and then TAB. Enter the "Machine Configuration" menu and change the settings accordingly:

Press TAB to exit the menu and select the Esselte 100 window. In order to use the serial port easy there is a terminal mode built in which takes the baud rate as argument:

Press some keys and there should be text in your Telnet terminal, the emulation has escaped into the real world!! :)

Not much more works at this point but this is a generic method how to connect emulated system with each other or to the outside world, enjoy!

MAME: Esselte 100 and other Didact designs

Now you can try how using a computer at the beginning of the 1980ies felt like. At the time they all suggested that you had to learn programming or at least use the prompt and usually they had a BASIC interpreter built in. Esselte 100 had only 12Kb of ROM to start with which was later upgraded to 16Kb. 

Thanks to some dedicated people at elektronikforumet.com, a swedish forum for electronic enthusiasts, I got hold of schematics and ROM:s so I could start my Didact project. Esselte 100 is a Didact design and here is how you can run it in MAME on a 64 bit Windows 7 computer:

1) First download the MAME Didact beta package here: Didact beta MAME 177

2) Extract it somewhere

3) From the command shell type: .\didact64d.exe e100 -window

Just press enter on the informational messages that pops up and you should now have a prompt!

From here you can explore the wonders of BASIC.

To use the cassette you first need to enable the pop up menu system in MAME by pressing Scroll lock. It will toggle the menu system so you can turn it off later by pressing Scroll lock again. Once the pop up menu system is enabled you get the main menu up by pressing TAB

Select the File Manager and then the cassette option to open the file dialog

In the file dialog navigate into the demos folder and select a BASIC demo. Once a wav file is selected the "cassette" is loaded an ready to be used.

To load the demo from the cassette issue a 'LOAD' command at the Esselte 100 prompt. The Esselte 100 will ask you if you are ready and of course you are, press 'Y'. To start the loaded cassette press F2 and a counter will appear showing you where on the tape you are.

Under 'Tape Control' in the main menu there are additional actions that you can take in order to navigate the tape in case you have several saved assets at the same cassette or want to create a new one. More on the latter below.

While loading the cassette the Esselte 100 displays what it loads and when done it will clear the screen and sit at the prompt awaiting commands. Now you can look at the code by issuing a 'LIST' command and of course run it by issuing a 'RUN' command:

Saving your own BASIC program is similar but you need to prepare a cassette first. This is done by selecting [create] in the file dialog shown above, use file name of your choosing and append a .wav suffix, because MAME will actually generate a wav file.

In the 'Tape control' menu there is 'record' option and once you have pressed it a wav file is being written to file so quickly exit to the Esselte 100 prompt and issue a 'SAVE' command. Shortly, well 300 baud can take a while, you precious work has been saved! :) Press F2

If you write a nice Esselte 100 demo and want to share it, let me know and I can add it to the distribution. If you sit on original Esselte 100 cassettes, dump them to WAV files through the microphone input on your computer and then try to load them into the emulator as described. I am very interested to know how that works, it is not yet tested. You can also contact me and I can do it for you.

History of Didact

Didact Laromedelsproduktion was started in Linkoping in Sweden by Anders Andersson, Arne Kullbjer and Lars Bjorklund.  They constructed a series of microcomputers for educational purposes such as "Mikrodator 6802", Modulab, Esselte 100 and the  Candela computer for the Swedish schools to educate the students in assembly programming and BASIC for electro mechanical applications such as stepper motors, simple process control, buttons and LED:s. Didact designs were marketed by Esselte Studium to the Swedish schools. The Candela computer was designed to be the big breakthough and developed by Candela Data AB, "a Didact Company". The Candela system was based around a main unit that could run OS-9 or Flex and a terminal unit that had a propietary software including CDBASIC. The Candela system lost the battle of the swedish schools to the Compis computer by TeleNova which was based on CP/M initially.  Later both lost to IBM PC as we know. Candela Data continued to sell their system to the swedish industry without major successes despite great innovation and sprit.

MAME serial support Part II

I have previously submitted a driver for the Zilog SCC, Serial Communication Controller, to MAME, improving it while working on different board drivers needing it. While one would want everything to be emulated correctly from start it crucial to find some legacy code to test the feature at hand. Unless you do the effort is not useful anyway.

Usually a board initiates the SCC and start sending characters through it to an unknown device at the other end. The device on the other end will eventually send something back and the firmware will respond to it. Quite simple ehh!?

The way this is done can differ a lot though and if a feature used is not emulated or previously tested it is important that the board writer get useful messages using the logerror(). I usually start with that, creating logerrors for everything that doesn't work, so when a new software is tested there are printouts saying that this feature is not implemented. Then it is Time to call Saul.

[ The logerrors are seen in the debugger log window. The debugger is enabled by the -debug command line switch from where you start the board driver with F5, but first you want to open the log window by Ctl-L. ]

When writing the board driver for the MVME-147 I had problems getting the keyboard on the terminal to produce input. The funny thing was that the output worked just fine. Hmmm... I had to dive into the core code to understand how this was possible. The core feature that allows us to connect a serial device to a terminal as previously explored is mainly kept in src/emu/diserial.cpp

I had recently added support for SCC:s internal baud rate generator by adding a timer. It worked in the board driver for hk68v10 board but for MVME147 it failed. I pretty soon figured out that the serial timing was not working since I sometimes got a character through but sometimes the system got it wrong by just a bit or so.

I had to investigate it of course and I found several weaknesses of my first implementation in relation to how diserial works and can do for you. Here is my post on the MAMEdev forum summarizing it like this:

"I found the bugs finally, it was due to that it is not possible to use diserial the way I did with local baudrate timer in the SCC device. I got it nearly to work one way as can be seen above but when sending keypresses the other way there was problems. The SCC device wasn't producing exactly the right baud rate but nearly enough to being able to send characters from the board to the terminal, but in the opposite direction there was not start bit detection and there was no mid bit alignment in the SCC device. Even after adding that it turned out that I didn't get the final transmitt_complete because it also had no stop bit detection... So I relized I was reimplementing diserial in the SCC device and after I relized that it took me just 20 minutes to implement the baudrate timer using the diserial setrate() functions. So that part is now rock solid compared to how it was and the MVME-147 driver was submitted a few days ago with a working 147-Bug> terminal."

So to not reinvent the wheel you need to recognize a wheel...

Serial ports in MAME part I

Serial port emulation is a much more intriguing subject than you probably think. I am writing on a number of pages exploring different aspects of the support for serial ports in MAME. The first one is describing what a typical addition of a serial port to a board driver looks like and you can check it out here: serial-port-in-mame.html

Adding the serial port is the easy part, as a board writer you often just find a board that has a similar feature to what your board has and copy the apropriate lines to your driver. However, unless you know how it works the driver will probably not work properly or to the full extent.

In the other end of the RS232 cable there is another device, normally a terminal or a printer but it can be anything. MAME has some default devices that behaves like that class of devices normally behaves.

A MAME top level board driver describes a system rather than a board so the name board driver is somewhat misleading. In MAME you start the board driver and give it configuration options to activate one of many preconfigured devices compiled into MAME that is pre configured to work with that particular driver. For instance there can be a default serial terminal device configured, in which case a terminal window just pops up and starts working without any extra parameters:

./mame fccpu1 -window

There are options that I have not yet explored to connect MAME to a real terminal, this has another set of host related problems that I intend to look at later.

MAME the virtual retro system archive

For some time now I have hacked bits and pieces of code for the MAME project. It started out as I needed a convinient way of debugging code I hacked for a retro machine and MAME quickly appeared on my radar as the best versatile vehicle to host my ideas. In fact when I started the part I was interested in was called MESS but this project has now converged back into the MAME project event though the core MESS devteam seems to lurk around in one forum and the hardcore arcade people more in another. The boundaries are not strict and over time noone will remember the distinction.

My growing interest in MAME was not the gaming part itself but the opportunity to run old code in emulated hardware. The "old code" resides on harddisks tapes and floppy disks of various sizes in my garage. I also realized that I could recreate old systems I once worked with back in the CRT era when people still had to write clean good code just because to fit it into the precious ROM/RAM. Moore's law killed that reason and the code nowadays are huge, complex and with endless layers of abstractions that blocks the horizon. The MAME source code is no different which I soon learnt the hard way.

The cool thing with MAME is that it prepared to emulate things at an arbitrary level of detail, only limited by, that's right, Moore's law! The things that are most demanding to emulate are the analog parts of old computers but MAME also emulates analog circuitry such as the famous Pong game from 1972

Compare with the MAME emulation done in 2015

MAME bases the emulation on the hardware design rather then trying to mimic the behavior and appearance. For obvious reasons there are trade offs where emulation meets the real world and the user from 2015 interacts with the creation from 1972.

In the end MAME, or one of its forks, might be the only way to run your old software, unless another project catches up which seems unlikelly. So that may save the day when it comes to hardware but the really big problem is "bit rot". This is when the bits are fading away from the original storage media and why it is important to dump the information before it vanishes. But that is a huge subject for later.