Category: MAME

Note: This post is a summary of my posts to this thread on the Bannister forums.

The PSI Ψ 98 is an early 80s micro computer manufactured by Kontron. It was mainly used for industrial controlling or science lab computer. Recently, rfka01 posted pictures, ROM images and disk images of his unit to the Bannister MAME forum. It’s specs are roughly:

There is some documentation available and all major components are already emulated by MAME, so it shouldn’t be too hard to add.

The first step is to load the ROMs into the correct memory address, then make sure that it can access it’s RAM. This is a bit more involved here because of the memory management, but luckily there is a good enough description in the manual. So, after making sure that writes to the memory mapper ports map memory into the correct locations we let the CPU run a bit more. It’s easy to see which I/O ports it accesses, because MAME logs reads and writes to unmapped addresses. Among the writes, we see it writing data to the 6845 and also to video memory ports. The video memory on this system isn’t mapped into the main memory map, but instead accessed via the I/O ports. After hooking those writes up, we can already see in the debugger the first screen it wants to display! So, next step: Get something displayed on the emulated screen. The 6845 drawing routine itself is nothing special and similar to other systems, so it can be implemented quickly, which results in:

That’s all it does for now. But, by looking into the log again, we see lots of accesses to floppy controller ports, which basically means that it already tries to boot from floppy (even though we haven’t hooked up a lof the Z80 support chips).

After a bit more work and hooking the µPD765 up:

Looking quite promising! CP/M complains here that it can’t load the SETCRT program. After a bit of investigation we see that it tries to load it using DMA, which wasn’t hooked up fully. Fixing this, we get this result (also added support for inverted characters here):

Sure would be nice if we could actually enter something now! The PSI supports two kinds of keyboards: A serially connected one or a parallel one (they actually use the same connector). Since the system expects ASCII codes we can just use the generic ASCII keyboard MAME offers for now and attach it to the relevant I/O ports:

With the keyboard hooked up, we can now get into the debugger stored in boot ROM by pressing Ctrl-K:

The command MT 6000 1000 I’ve entered starts a memory test. As you can see it fails here, pointing to issues with the way we implemented our system memory. There is also a disk test that you can start with the command J 1800:

Since we now have a nice test case, the memory mapping can be fixed for good which results in KOS booting fully now:

The login is “*” (which means it points to the default working directory).

It works quite nicely at this point, however any access to the second drive results in the system hanging. In the debugger we can see that it’s running in a tight loop, waiting for a value in memory to change. This means it’s waiting for an interrupt routine that changes this value to continue. The last command executed by the µPD765 is RECALIBRATE. This command issues an interrupt when it finishes, and indeed we see this interrupt happening. So, what’s going on here? The interrupt simply happens too fast, before the system has a chance to setup it’s waiting loop. Looking at the floppy disk controller code we can see that RECALIBRATE is supposed to seek to track 0, then issue the interrupt. In MAME, a freshly inserted disk always starts with the head at track 0, so the command finishes instantly. Easy fix then, just add a small delay before the command completes and issues the interrupt. This makes it possible to access the utilities disk in drive 2 and run commands from there.

One of the programs on this disk is a BASIC demo called “MAGIC”. It runs in the graphics mode, so that’s perfect for implementing it:

Playing around with the system, I’ve noticed that the disk format command didn’t work. A hang just like the problem we fixed earlier. And indeed, adding a small delay after a SEEK command when the disk is already at the correct track fixes it too:

Some things left to add: Printing over the centronics port. Load MAME like this:

This attaches the null modem to serial port a, and connects it to port 1234 on the local computer. Start PuTTY now and tell it to connect to localhost:1234 with connection type “raw”. Let the emulated system boot now, open the TAB menu and configure the RS-232 port to 2 stop bits. Then enter the following commands:

IODC $PSIA=ACTIVE

(load serial port a driver)

IODC I-5=$PSIA

(attach this driver to input channel 5)

IODC O-5=$PSIA

(attach this driver to output channel 5)

PT

(start simple terminal program)

At this point you should be able to see any entered keys in the PuTTY window, as well see everything typed into PuTTY in the emulated system. Here are some screenshots:

Pasting ASCII art:

So, what’s left? A major point is SASI (it wants the Adaptec ACB-4000 controller). For this, we need to emulate the custom DMA circuit which sadly isn’t described anywhere. The keyboard is currently HLE’ed and not emulated, but we do have a dump of the keyboard controller. It would also be nice to add an ECB card slot system and some cards (memory, I/O, etc.).

Initially I just wanted to do some quick clean ups to the ambush driver. However, while searching for references to the game, I noticed that we had two dumps of bootlegs running on “extended Ambush hardware”: Mario Bros. and Donkey Kong 3. They were already added to MAME, however they lived in the mario driver, likely because the graphics system shares some similarities. mariobl was marked working, but dkong3abl had bad graphics, and various bits were missing.

So, I decided to do a bit more refactoring to the ambush driver first, to make it easier to move the bootlegs to the correct driver. This involved changing the driver to make use of our tilemap rendering system for the background and foreground character graphics and documenting the layout of the attribute RAM and sprite RAM.

After making sure the existing games still work as they should, I added both bootlegs to the driver. With the ROMs mapped to their correct place, the games ran fine, however had messed up graphics. This was expected of course, since the bootleggers did some major rework to the graphics section of the ambush PCB.

The basic graphics decode is the same as ambush (only difference is that the mario bootleg uses sprites with 3 bits per pixel instead of 2), however the tile lookup is handled slightly differently, and the sprite RAM layout is completely different. One interesting fact is that the original dkong3 uses a PROM to lookup the color of the background tiles, but since there is no place for this on the Ambush PCB, the bootleggers moved the PROM contents to one of the game code ROMs, and then copy this data on startup to the ambush board attribute RAM area.

Unfortunately the color PROM of the two bootlegs wasn’t dumped, so the driver uses the original game PROMs for the palette for the two games.

The mario bootleg doesn’t seem to have any graphic or gameplay differences (in fact, even the test mode is still intact and they even updated it to correctly checksum the 3 bootleg ROMs), but the sound now uses two AY8910s (the original Ambush uses AY8912s).

The dkong3 bootleg removes the Nintendo copyright, but otherwise seems to be identical in graphics and gameplay like mario (there are palette differences, but since we don’t use the correct color PROM it might not be specific to the bootleg), and also uses two AY8910s now.

You can try both bootlegs starting with the upcoming next release of MAME. The driver names are “mariobl” and “dkong3abl”.