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!