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!