Current Game Display Part II

As you can see I got the current game display showing cards!

The problem was actually quite big. Up to this point the screens I had been viewing only used graphic characters found in the roms at locations between 0x00 and 0xFF. The card graphics are located beyond the 8-bit boundary of 0xFF and needed a 16-bit address in order to find them.

I found that the Port 1 actually stores the upper address I needed. It also stores the palette number. Up to this point, the palette had alway been zero, but once I got the value from P1 I had all I needed to display characters in higher addresses.

Another problem is the 8052 driver didn't seem to have a way for me to fetch the value of P1, so I had to add a new function to allow me access to internal ram values. Yet another change to the 8052 core that I will need to go back and document.

Current Game Display

I finally figured out how to advance to the next screen. It seems the "Current Denomination" and "Maximum Coins" need to be populated before you can go on. It has to do with showing coin counts for each grouping like "with 1 coin in", "with 2 coins in" etc.

Now that I made it to the current game display I figured I would see some cards on screen. Either the current game data values are corrupt (since I don't have any game history), or I am looking up the wrong graphic characters.

Machine Counts

Well now that the inputs and door sensors are working, I thought I would look at the machine counts screens.

It seems that I will need to map the memory locations for each of the amounts, but most appear to have zeros in them.

The values are stored in a 4 byte BCD format and support values from 0 to 99999999.

I can't seem to get past a certain screen and advance to the current game display screen. I need to figure out what is blocking me from going forward.

Sound of Music

Well, the music now works! At first the speed was really slow, so I had to finally determine the speed of the 80c32 CPU and the Sound chip.

It turns out that the cpu is exactly 7.3728 MHz or (2 x 3.6864) and the sound chip is 1.6666 MHz or (20.000/12). These values line up nicely with the crystals found on the motherboard (3.6864 and 20.000).

I found there are 5 tones and 9 songs. The 9th song is not played during operator mode, but is used I think when paying out credits or coins. Its just a song where the notes keep getting higher and higher. This seems to match how the payout process works.

Sound

After tracing the game code, I found that the sound chip is accessed via external ram at #4000. Specifically, #4000 is the control port, and #4004 is the write port.



I setup the driver to map to these and navigate to the output test screen and fire off the sound test. It works! I hear a 'ping' sound just like my original hardware. Its not exact, but I'm sure its due to the improper frequency I setup for the cpu.



I know that I can mess with the sound settings in operator mode in a page further down, so I advance the pages but cannot get to the sound screen. There is probably a variable in memory that needs to be set in order to let it know that that page is available.

Outputs

I fought with the inputs for a long while trying to get it to advance to the next page (outputs), but it kept resetting every time I pressed the "Self Test" button.

I finally narrowed it down to the door sensors. There are two sensors to deal with, the upper door and lower door. It seems the door wasn't open or something and the code just resets itself.

Now that I can get to the next page, I can mess with the outputs. Since I won't be using any outputs for now, I just tried triggering the sound effects button. Nothing happened. Looks like sound is next!

Inputs

I had to hack the game code to jump to the operator mode. The only way to normally get to this screen is to open the door and press the "Self Test" button. Since I don't have inputs yet, I force the code to jump there.

This allows me to see what happens when messing with the inputs via the keyboard.

After a lot of digging I found that the Inputs seem to address external ram at #A000. There is also inputs at #8000.

After fuzzing around with the values, I found that the #A000 region is split into 2 banks. The high nibble stores 8 inputs and the low nibble the other 8. This covers banks B and C.

The #8000 region seems to handle the bank A but since these are not buttons, they need to be treated differently. This area is gonna need help eventually. But for now I have all 3 banks working but not the dip switches.

In Living Color

Horray! The colors are perfect. I had to figure out how the bitplane stuff is setup in the driver properly and now you can see its working great!

The colors match my real hardware exactly, except for the background color. I know you can change the background color when in operator mode, so my guess is this is the default color that ships with the color prom.

Now that I have a working visual, I need to figure out how to get inputs to work.

Better Video

As you can see I figured out the issue with the video. Looks like the transparent addressing mode automatically advances the cursor to the right (basically incrementing the current address after displaying).

Once I added the code to do this, things cleared up considerably. I still need to mess with the color palette, but that shouldn't be a problem.

I see something!

Its not pretty, but there is definitely structure there. I can tell where the "Open Door" text and "COINS IN" text are. And the colors are all bad.

Looks like I need to review the documentation on the video processor and see if there is something I missed.

8052 core

Well after looking at the source code to the 8052 core, I found there is no way to currently do what I need to do when dealing with "paged mode" addressing. I need Port 2 (P2) to be the high byte of the address when reading external ram, and it appears the 8052 driver has a place for a callback function but was commented out and doesn't appear to work anyways.



I had to hack the 8052 driver to include P2 as the upper byte when accessing external RAM. I will have to revisit the cpu driver later and include a way to make the callback work. For now I just hard-coded what I need. I'm desperate to see some output soon!

Accessing Memory

I'm finding that the game code addresses some external memory using "paged mode". Basically, Port2 (P2) holds the High Byte address while an 8-bit register like R0 holds the Low Byte of the address. This allows for a 16-bit pseudo-address by combining P2 and R0.

Whenever graphics are addressed in the game code, they seem to be using a value of 0x20 for P2. Which tells me they are addressing a range of 0x2000 to 0x20FF.

I found that in other drivers using the CRC6845, they generally look at 2 memory locations to get it to work. One for the registers and another for the address. I found some video code that places values at 0x2080, 0x2081 and 0x2083. One too many addresses, but I can tell that the 0x2083 value always holds the address to the graphics character in it. Since its using "Transparent Mode Addressing", I'm gonna need all three.

Video Processor

I think I have resolved the issues with the memory and started to try and find out how the video is handled in the game code. After a ton of research I find out the video system appears to be using a special method called "Transparent Mode Addressing". The MAME driver for the CRTC6845 doesn't seem to be coded to handle this yet. I'm gonna try to go without the driver and hack my own implementation for now. I'd really like to see some kind of visuals show up on screen. If I get anything to show up I will go back and see about adding the features to the CRTC6845 driver at a later date.



My first challenge is to find out where in memory the video is updated. The game code is getting more and more commented, but there is some areas that are unexplored. Time to flesh out the game code some more.

Driver problems

Well, this driver is not gonna be a slam-dunk in any means. There is a lot to learn about how MAME drivers work. I found a few games that use 8051/8052 cpus and others with AY-8912 sound and others with SY6545 type video processors. With that I cobbled together a basic driver that displays a startup screen!

I didn't confirm the proper cpu speeds but can do that once things start to partially work. I just used values other people did so the timing is somewhat correct. I noticed 2 different crystals on the motherboard, one marked 20.000 and the other marked 3.684. They probably correspond to the cpu and sound chips but could also be used in the timing of the serial port (which I think is used to relay progressive jackpot information).

Well the driver doesn't work past the title page. It bombs out a lot with memory violations. I'm gonna need to figure out a lot more on how memory is divided in the cpu.

Starting a MAME driver

I think I have enough information on hand to at least being a basic MAME driver. I know the processor is a 8052 equivalent (which there is a CPU emulator for in MAME). Looking at my motherboard I also see a AY-3-8912 sound generator, and a 6545 video processor. I have game code, graphics and color prom dumps. At this point I would love to see what I can get up and running in MAME.



I downloaded the MAME source code and setup my development environment. I then compiled it and tried one of the free roms (Robby) found on the MAME website. At this point my system is ready to go.

More Game Code

The game code has some data embedded in it for processing strings such as "COINS IN", or "ROYAL FLUSH". Using the offsets I discovered in the graphics files, I was able to come up with a chart of letters that correspond to data found in the game. With this information I then added comments to the source code wherever I found a string being used.



The more strings I find, the more the code starts to document itself. I am finding the same subroutines being called after loading the strings, which makes me think its routines for painting to the screen. Time to dig around in the code.

Game Code

The processor on the my PE+ board is an Intel 80c32. It pre-dates the 8051/8052, which is a more common version of the chip.

I used a program called DIS8051 to disassemble the game code and it appears to be unprotected. I found that strange for a system that is used for gambling, but was quite happy to see it!

Time to dig into the code and see if I can start mapping interesting things. I'm using 8052.com as a reference site. They have a ton of information on this processor. Once I get comfortable with the code, I will begin creating a driver in MAME.

Graphics

Well I've figured out how the graphics are stored on the CG chips. Basically, they are using 4 bit planes to represent the colors, meaning this is a 256 color system.

I wrote a little C++ program to open the graphic roms and organize them a little better on screen so I could see them grouped properly. The colors are guessed at this point and I know there are 16 palettes to be used, so I just picked common colors and used 1 palette for this. Thats why the spades and clubs are red. The palette gets switched when the game is displaying cards.

I'm considering making this a real graphics editor sometime. It would be nice to change the card backs and animation pictures, etc. and burn new chips to put in my real machine. But for now I won't be adding any other features to this viewer.

And so it begins!

I've been kicking around the idea of making a MAME port for the IGT PE+ Poker machines for a long time. I know the hardware shares many similarities with arcade machines, and the MAME team has developed quite a few libraries for CPUs etc.

I personally own an IGT PE+ Poker Bar Top model show here.

My first step was to dump the roms in order to view the them in a binary format.

This was a fairly straight forward process using my trusty USB programmer. I ended up dumping 5 chips this way. The game program (pp0516) in my case, and the 4 CG chips for the character graphics (MRO, MRG, MRB, and MRX). The color prom (CAP 740) is a special little bugger that I could not dump by normal methods. I ended up resorting to putting it on a breadboard and reading the 256 bytes by hand with a bunch of LEDs. This took a while, but is accurate.

So now its time to look at the binaries and see what I can find.