PE+/S+ Emulation via MAME

Wingboard Support

2009-01-08T16:20:00.000-08:00

Its been a while since I did any major updates to the peplus driver, but recently I decided to tackle a hardware add-on for the machine.

The add-on is called a "wingboard" or daughterboard. Its purpose is to attach to a superboard pcb where you would normally place the CMOS RAM and DATA chips.

By adding this board you are then able to add a special 5-in-1 game support. With the proper PROGRAM chip installed, the machine will read all 5 DATA chips and display a special Multi-Poker menu.

This board functions similar to the 2 chip (non-wingboard) set XMP00006, but allows the user to swap out different chip sets instead of using the fixed list in the 2 chip set.

The first challenge with making the wingboard work in MAME was discovering how the board functioned. The problem lies with the small PAL chip located on the board that controls the logic of banking to the proper DATA chips. After tracing the board by hand, I figured out a basic schematic and determined that the board switches DATA chips via a CMOS DATA write to the address 0x1FFF. The value written to this address is captured by the PAL chip and used to enable the output of the appropriate DATA chip on the address and data lines.

Once I understood how the wingboard worked, I added support to the peplus driver. Basically, I swap the internal superboard DATA region when address 0x1FFF is written.

Now that I had the game mostly working, I found that not all the graphics were painting correctly. This was due to the fact that the graphics chips are twice the size of any of the games I have added in the past. But I had to find what was triggering the machine to switch to the second half of the graphics chips and color proms. After some investigation, I found that there is a jumper on the superboard pcb (E16/E17) that controls the banking. This lead me to find that a bit on PORT3 is used to signal the machine to bank to the second half of the graphics.

So after a little more cleanup, all things appear to be working fine.

Lots of Slots

2008-06-11T18:10:00.000-07:00

I decided to revisit the PE+ driver specifically to find out why all the video slots did not accepts coins. I assumed the slots had some special code that maybe affected the coin-in timing, but after a lot of tracing, I couldn't find any differences. Eventually, I noticed that the last page of the operator screens was blank and the Spin button was lit. Pressing the Spin button didn't seem to do anything. Using some experience I learned from the S+ slot machine, I figured this screen was used to show the reel stops. Each time you press Spin you would see the next reel stop etc.

But the screen wasn't painting the reels and seemed to be stuck in a loop. After much tracing, I finally found that the Timer 1 interrupt at 0x001b stopped firing. Without this interrupt, the game would basically sit in an endless loop waiting for the timer bit to update.

It turns out that the split timer code in the i8051 core needed a small tweak. Once the code was fixed, the reel stops showed up in the operator screen, and the game started accepting coins.

Now that I could see the slot games play properly, I found that PS0716 was not "Quarter Mania", but rather "River Gambler".

With the video slots working, I added support for 5 new romsets to the driver:

(PS0014) Super Joker Slots

(PS0022) Red White & Blue Slots

(PS0043) Double Diamond Slots

(PS0045) Red White & Blue Slots

(PS0308) Double Jackpot Slots

S-Plus Slots

2008-01-27T11:32:00.001-08:00

I decided to mess around with another IGT machine called the "S-Plus (S+)". This machine is strictly a mechanical slot machine with no real video.

The hardware is similar to the PE+ machine but lacks video and contains optics for the reels.

There is a bunch of 7-segment display for some form of output, and interesting navigation procedures to view various operator values.

Once I got a skeleton driver working, I started to hookup the inputs and the 7-segment displays. After much work, I finally got the display to show the first error code. This is an error 61 or "Bad CMOS RAM". Sound familiar? It should, the PE+ generates this error the first time you boot the machine with empty RAM and empty EEPROM data. When I saw this error code come up, I knew I was on the right track.

The proper procedure to recover from this error is to open the door and press the Self-Test button. After doing that, the follow error code appears. This is an error 61-1 which represents "Game Data Reset". What needs to be done at this point is to close the door and turn the jackpot reset key.

Doing that produces the next error code, 65-3 which is "Game Options & Meters Not in the Most Current Format". This can be corrected with a Set Chip, or you can just turn the jackpot reset key and have it overwritten.

I chose to allow the machine to overwrite the values and turned the jackpot reset key. A new display appears with the "0" flashing as the CMOS data is reloaded. Now the next error code appears, 65-1 or "Bad EEPROM Data". Once again a error message I've seen on the PE+ machine. To resolve this you must open the door and press the self-test button.

Finally, the last screen appears which should be error free, however I get the following code, 41 which says "Reel 1 Tilt". This means the machine was unable to process the first reel properly.

So this is where I'm currently at today. From this screen I can go into all the operator self-test screens and play around with the machine settings and listen to the built-in sounds, but I get held up eventually trying to activate the reels.

Time to investigate the Reel Optics next. It should be an interesting challenge.

Hack Free

2008-01-21T14:46:00.000-08:00

I finally found the bug that was forcing me to add memory hacks to the driver in order for it to bypass the memory tests for each game.

The I8051 core library was basically firing the timers when they were sometimes not enabled. What this did was cause the timer interrupts to modify memory while the memory check subroutine was running. The memory check routine was writing specific values into memory and verifying that they read back the same value that was written. But with the timers updating memory at the same time, the memory check would not find the values it was expecting and therefore fail.

The fix should help slightly increase the responsiveness of the game code too. I believe the I8051 core has other areas to investigate, but this fix is a huge change for the driver.

With the fix in place, all memory hacks in the driver can be removed. This means any new clones that are added in the future should drop in nicely without any special memory modifications.

I will be submitting a new driver update in the near future with all the hacks removed.

Attack of the Clones

2008-01-18T14:19:00.000-08:00

Three new games to report on this update. The first game is Jokers Wild Poker. It plays much like other draw poker games, but includes a joker in the deck.

Next is Double Down Stud Poker. In this game you are dealt four cards and can decide to double your wager on the last card, or just play with your initial bet. After you bet or pass, the game reveals the last card and pays accordingly.

Finally is a payout percentage variation on Standard Draw Poker.

Multi-Poker

2008-01-15T10:22:00.000-08:00

Not a lot of new changes to report. I added support for a new superboard romset (pexmp006) entitled "Player's Edge Plus (XMP00006) Multi-Poker".

This romset uncovered a few memory locations in the DUART space that were not accounted for in the code, so I adjusted the driver accordingly. The changes are mostly for completeness at this point, since the driver does not currently support the DUART functionality (Network Slot Accounting System).

This particular game is really 5 games in one. It has a main menu that lets the user choose which of the five games they wish to play. Once in a specific game they can return to the main menu via the fifth Hold button.

This particular game has quite a few new screens in the operator mode. I have attached a sampling of pictures throughout this post.

Superboard Revisited

2008-01-06T10:50:00.001-08:00

Recently, I decided to look at a small bug that has been bugging me (no pun intended) with the superboard version of a few games. The bug appears after you setup a superboard game for the first time via the operator screens and exit MAME. The next time you load the same game you will get a "CALL ATTENDANT" or similar message. The sub-message after that will read "CMOS DATA". Basically, this means that there is data expected in the battery-backed RAM that does not match values found in the EEPROM. This functionality works fine in the non-superboard games, so there must be a portion of either RAM or EEPROM memory that is not being saved in the *.nv files.

I first confirmed the EEPROM portion of the NVRAM file and all appeared fine. So I started to dig around the CMOS portion. Earlier on I had determined that the superboard game data ROM intersperses its data in memory at 0x1000, 0x3000, 0x5000 etc.. up to 0xf000, in blocks of 0x1000. This was nearly correct. The mistake was, that 0x1000-0x1fff is actually extended RAM for the superboard games, not game data ROM memory.

So not only do superboards contain an extra data ROM chip, they also tend to use a larger RAM chip than the normal board sets (twice as large to be exact). With this notion in hand, I updated the driver accordingly and the bug was fixed.

The new changes should be reflected in the MAME source during a future update.

Testing on a PE+ Machine

2007-12-14T06:54:00.000-08:00

Here is a small update on the new game code I am writing for the PE+ platform.

I finally got around to burning the code on a chip and putting it in my real machine. The results were amazingly good. I was worried about the watchdog timer, but the code I put in place to support it works just fine.

I discovered some interesting details about the machine as I tried to enable certain features within my game.

The coin comparator turns on the coin-lockout feature by default. This means that any coins put into the machine are immediately rejected and come out in the little coin reject tray. I added code to turn off the coin-lockout and any coins inserted after that pass through the ABC optics and into the hopper. I have code in place to check for the proper ABC sequence and any coin-in timeouts before accepting the coin. These functions appear to be completely working.

Next was attempting to payout a coin from the hopper (the area that holds all the coins inside the machine). In order to successfully do this, you must enable both Hopper 1 and Hopper 2 outputs. This makes the hopper motor spin which in turn drives coins up a bar and out of the machine. At the end of the payout chute is a sensor that is triggered as the coin is leaving the machine. By creating code to enable the motor and count the number of coins passing through the sensor, I was able to acurately dispense any number of coins.

There is also support for testing when the hopper is empty, or a coin-out timeout condition occurs. And I added code to turn on the diverter when the hopper is full. This is just a simple gate that diverts coins into an overflow bucket when the hopper cannot hold anymore coins.

With this greater understanding of the hopper/payout process, I was able to fix a bug in the MAME driver that currently has issues with the hopper empty and coin-out timeout conditions. I will be submitting the fix for the next update.

Technically I believe I have most aspects of the machine covered that I will need to finish my game. There are some additional pieces I may add once the game is solid, but they are somewhat optional. This list of extra features would include:

EEPROM Support to backup the battery-backed RAM
Music Option (The game currently uses tones only)
Dollar Bill Validator support (I would need to buy one for testing)
Progressive Jackpot Feature (May need partial DUART support)
Card Animation
Attract Mode Animation (Blinking Play 5 Coins)
Double Up Feature
Soft Meters (Keeps track of coin counts etc)
Joker Feature (Optional but would reduce paytables)

There is plenty of testing and coding to do, but I believe my knowledge of the machine is growing and will allow me to further solidify the current MAME driver over time.

3 Card Poker Diversion

2007-11-29T17:33:00.000-08:00

Looks like my MAME adventure has changed course slightly for the time being. After learning so much about the PE+ hardware and emulating it, I decided to try my hand at creating a new romset for this platform from scratch!

The results so far are the many pictures posted here. I decided to create a game that is not currently found on this platform, and chose to go with a 3-card poker game.

The rules of the game are fairly straight-forward. You and the dealer are dealt 3 cards each and you must obtain a higher hand than the dealer. It is classic stud poker, where you don't discard and draw.

Besides the normal "ante" wager. You can place a bonus wager on the final value of your hand dealt. This "Pair Plus" wager pays even if you end up losing the hand. The bonus wager only pays if your hand is a pair or better. A paytable determines the payout for each of the bonus hands.

Once you receive your hand you can decide to either play or fold. If you play, you must place a second wager that matches your original ante. If you fold, you lose your ante wager, but can still receive your bonus payoff if you have a pair or better.

If you decide to play, the dealers cards are revealed and you are paid even money for your ante wager if you have a higher hand than the dealer. If the dealer hand qualifies (Queen high or better), your play wager also pays even money, otherwise its a push. If a tie occurs, you push both bets.

I'm developing the application using SDCC and compiling for the i8052 platform. Once compiled I convert the .HEX file to a .BIN file and test it under MAME. So far I have the video, inputs and sound mostly working. Its interesting to code from the other side of the platform. Things as simple as random number generators (which is done), etc. can be a pain to figure out, but once I am done, I will have a solid SDK for building other games.

I have been trying to create a game in the same style as IGT and therefore I have been adding support for the multiple operator screens that are used to setup the machine.

I will eventually burn the game onto a chip and test it in my real machine. But I want to make sure I have most of the bugs worked out first in MAME. Burning chips and disassembling the machine to pop in the chip takes too much time, but will need to be done sometime in the future to make sure I didn't miss something in the code (like the watchdog timer which the MAME driver ignores).

There is still plenty of code required to finish the game, but I am learning a lot about this machine as I go. And I currently have a lot of useful code for my PE+ SDK.

Superboard, Keno and Slots

2007-11-08T07:01:00.000-08:00

The PE+ machine has at least two varieties of motherboards. The basic board I have been emulating and the superboard version. The superboard has an additional socket on it for "game data". The superboard is backwards compatable with most or all of the non-superboard games (those that begin with PP or PS etc). The superboard specific games generally are in the format of XPnnnnnn or XSnnnnnn with game data roms in a format of XnnnnnnP or XnnnnnnS. (P for poker and S for Slots)

Internally, the super board maps the game data rom in all the external addresses the non-superboard had not used. After tracing the schematics, I determined the addresses are $1000, $3000, $5000, $7000, $9000, $B000, $D000 and $F000. So even though the game rom is stored on a 64k chip, only every other page actually can contain data. This essentually adds 32K of information to the superboard romsets.

With these changes added to the driver, I can now support the rather large list of superboard roms too. The slot pictured above is the Triple Triple Diamond Video Slot (XS000006) romset for the superboard. The slot driver uncovered some additional issues with video processing that I had not encountered before. Once I figured out the issue, the slot reels lined up nicely and the gameplay was correct.

Another romset now supported is the Deuces Wild Video Poker (XP000019). It is similar to many of the video poker romsets but has a few different graphics and gameplay with 2's being wild.

Lastly, I added support for a non-superboard version of Keno (KE1012). The romset I have has a bad dump of the CG files so there is some residue on the screen on some of the larger letters. The game uses a lightpen for input, so I had to add lightpen support, but it seems to be working just fine now.

At this point I am finding some small issues with the coin hopper timing when the machine tries to payout coins. I sometimes get a hopper empty or coin-out timeout message. It appears I will need to do something similar as the ABC optics for the coin-in mechanism, but not as complex. Some initial code appears to work on the non-superboard romsets.

EEPROM Support and Blackjack

2007-11-05T16:34:00.000-08:00

Since the last time I posted, I worked on adding I2C EEPROM support to the driver. Initially I spent a bunch of time creating the code I needed from a couple different sources I found in the MAME code base. Once I got the code working, I began to test the driver and things looked pretty good. A couple of days later, another MAME developer (smf) produced a much better library then the one I had cobbled together and helped me hook it into my driver and replace the I2C code I had already in place. The newer I2C driver worked great too and is now part of the MAME core.

Now that the I2C code is in the driver, a lot of hacks have been removed. The following is the sequence of events that take place when you load a game for the first time.

The first time in, the CMOS (battery-backed RAM) and the EEPROM will both be empty. You will get a "Call Attendant - CMOS Data" screen, and when you open the door and press the Self-Test button, it will attempt to load values from the EEPROM to the CMOS.
The next time you start the game, you will get a "Call Attendant - EEPROM Data" screen. When you open the door and press the Self-Test button, it will attempt to load the EEPROM with default data found in the game code.
At this point, both the CMOS and EEPROM contain some default values and you must enter operator mode to fill in any missing values such as denomination.
From that point on, all restarts of the game will react properly and the game will display.

I have found a few games that are having issues when using the 8052 specific Timer 2. These games do not let you proceed past step 1 as of yet. I'm thinking the I8051 driver in MAME may not be working for this scenario, or I am missing some other piece in my driver.

Finally, as you can see from the picture above, I have included in the driver support for a new fully working clone (PEBE0014) which is the IGT Blackjack program that also runs on the PE+ platform.

The ABC's of Coin Optics

2007-10-25T14:31:00.000-07:00

After a bunch of research and trial and error, I finally got the coin-in functionality to work.

This type of IGT machine uses an ABC coin optic detector translator. Basically what happens is the coin is dropped into the coin slot and passes through 3 different optics (A, B & C). As the coin passes through each optic, the optic's state changes from zero to one for a short period of time. This sequence is important to the game program and must be in the following order:
A->AB->ABC->BC->C

So first the A Optic is triggered, then the B Optic is triggered (while A is still active) and finally the C Optic is triggered (while A & B still active). From there the optics begin to shut off starting with A, then B, then C.

The reason for such complexity is to prevent "coin stringing". Where someone attaches a coin to a string and tries to pull it back out of the slot. In this scenario, the optics would be triggered correctly on the way down, but would start to trigger again on the way up and screw up the sequence expected. Once the sequence is broken, the coin either produces a "Jam" error message or "Coin Sequence" error.

By adding code to the driver to simulate a correct sequence of the optics, I am now able to press a key to insert coins, and the game shows a coin in.

Door Closure

2007-10-23T16:58:00.000-07:00

Well I finally got the code mostly working for the door closure problems I was having. It seems the door optics like to pulse on and off when in a closed state. The game now starts with the door closed and I can press a key to simulate opening the door. However, I cannot yet get back to a closed door without restarting.

Still this is important, since it allows me to test the coin-in optics now. The machine tends to bypass the coin detection when the door is open, so having it closed now will help in debugging.

The door closure also allowed me to see for the first time the "attract mode" animation on the cards. As you can see in the picture, the face cards animate when the game is idle, assuming you have the option set to do so in the operator setup.

Time to figure out the coin-in sequence now. Its obviously an important feature to implement.

Minor Update

2007-10-18T14:49:00.000-07:00

Not much new to report today. I updated the driver to support a new romset, PP0188 - Standard Draw Poker. A screenshot of it is pictured here with the paytable option on. This rom also has an AutoHold feature, but was disabled. It has been suggested that depending on a casino's location and policies, that they will sometimes enable or disable this feature.

I had to apply the same code hacks as the PP0516 driver to make it work. But it does work as far as the others go.

I just updated my driver against the MAME .120 source and submitted it again. Hopefully the next revision will have some of the changes and bug fixes I made to the 8051 core.

Timers, Dip Switches and I/O

2007-10-16T05:43:00.000-07:00

Well, it looks like I figured out why I could play credits, see the card backs but then the deal-draw button would cause the game to hang. The game code was in an endless loop waiting for an interrupt to set a variable to allow it to continue.

I proceeded to trace why the interrupt wasn't firing and found out the code was using "split timer" mode for Timer 0. I start looking at the 8051 core code and find out that it was never implemented! So, the only thing to do is wait for someone else to do it, or add it myself. I went for the later. After adding the code to support split timers, I discovered the 8051 core had some more bugs in the way it determined what timer mode was to be used. This bug (mistake) was repeated in the serial transmit part of the code, so I fixed it there too.

After these changes my driver started to work a lot better. The timing still seemed a bit wrong so I went back to the 8051 core looking for other bugs. Upon searching I also found that there were several opcodes with the wrong cycle counts. I update the code for that too.

I'm thinking the 8051 core may still have other issues to be found, but I have progressed enough to play credits to the end game. In other words, I can bet credits, hold cards, draw cards and obtain a payout. In between I am able to double up when the option is enabled.

I found out my game supports an "Autohold" feature which is really nice. The only way to enable it is to set one byte in the program code and adjust the checksum, but I may end up doing that for my real machine.

A couple of other misc thing I did was to add support for I/O addresses and the dip switches are now working.

At this point, some open issues are:

Door Closure
Sensing Coin-In
EEPROM support
Timing

I expect there will be more 8051 core to look at to determine the timing issues. The other open issues are just a matter of time.

Layout with Lamps

2007-10-12T14:18:00.000-07:00

I've done a bunch of things since the last post. I mapped all the output devices to either lamps or output calls. With that I then created a layout file for displaying some of the lamps while playing. The little red square in the upper right corner is the change request light. Overall, these new lamps should help debug some areas a little better.

I found some problems with the way I did paged mode addressing to external ram. With those changes my memory model cleaned up considerably. All cmos data is now in one block #000-fff.

With the cmos memory now organized properly, I was able to load it on driver init with preset values. This let me populate the machine with things like max coins in, current denomination, background color, music choice, game type, drop door, bill acceptor, double up, animation, paytable and deal speed. I noticed I started getting the little "RESTART" and "GAME OVER" text on screen now. This is a good sign. That area of screen was not painting before, and usually tells the operator what has happened recently.

I was able to remove one code hack that was testing cmos memory but failing. That code now runs without errors.

Finally, I created a child driver for the rom set "Set038" that I was testing with earlier. This new driver is called "peset038", but still contained in the same file "peplus.c".

I am still having trouble debugging the door sensors, and I believe I will need to tackle the eeprom soon. There are still areas of game code that need hacks removed, and they relate to the eeprom.

More Progress

2007-10-09T20:47:00.001-07:00

After a few game code hacks to bypass error codes, I was able to get the game to produce a "Out of Service" screen. From this screen I could get into the operator mode and setup all the game settings for denomination, sound, double-up etc. Basically, all operator mode screens became available.

After going through that setup I was able to get the normal game screen to appear with it showing cards from the last hand. With that screen I pressed "Play Credit" and it deducted credits and displayed 5 card backs like the picture shown here. I also re-ran the test with the "Max Credits" button and it peeled off 5 credits in a row like it should. I setup the ram to have 20,000 credits to start with in order to play.

Unfortunately, the "Deal-Spin-Start" button did not reveal the cards in my hand to allow me to press the Hold buttons. My theory at this point is the door sensors are still not 100%. I think they may pulse on/off instead of stay in a constant state. Either way, this is a major milestone.

Obviously I need to go back and find out what I need to do to remove the game code hacks, but being able to get this deep into the game is really helping document memory locations.

Set and Clear

2007-10-06T13:48:00.000-07:00

Well I finally dumped and disassembled the Set038 chip that is used to setup a PE+ machine that has had a battery replaced or just a bad data image.

This fairly simple program is also used to setup a denomination and choose if you have a bill acceptor attached.

I've been using this program to better understand what goes into the battery-backed ram and how the cmos is accessed.

After a lot of investigation in the code, I found that the cmos is attached to address #9000 using an I2C bus as a communication mechanism. It appears that #9000 is a write only address to affect (wc, scl and sda). Further analysis seems to point to #8000 bit 7 as the read bit for data and acks. The #8000 address is normally used for Output Bank A, but bit 7 is not documented in the operator screen as being used.

Based on schematics, and a visual look-over, I have a X2404P cmos which can hold 512 bytes (4K-bits) of information.

I found some code that tests the integrity of the cmos etc and commented it out in order to see what would happen. The screen above is the result. I am able to fully run the Set038 chip program in the emulator and simulate saving data to battery-backed ram. The program fails if I don't comment out the block of code that tests the device. Tracing this particular dump has really helped me understand the inner workings of the cmos communication.

My next step is to make it work without commenting out the section of code that verifies the cmos etc. This will require driver changes to simulate a 24c04 eeprom.

Call Attendant

2007-10-02T22:28:00.000-07:00

Now that things are mostly working I decided I wanted to see if I can figure out how to get a coin into the machine so I can play.

At this point the system comes up with a single screen that just says "CALL ATTENDANT". If I open the door and press the "Self Test" button. The screen to the right is shown. It appears there is some missing data in my external RAM.

The RAM is usually kept via a battery attached to the motherboard. If you replace the battery or pull the RAM chip, you will lose all the contents inside. This is where the coin counts and settings are stored. I have been playing with those values for a while, but now may be at a point where I need to see what a valid RAM looks like.

I will be dumping a "Set and Clear" ROM that is used in real life to fix such an issue. I will need to disassemble that source of that and figure out what it is doing in order to make my RAM match what a real machine would have.

Background Color

2007-10-01T21:19:00.000-07:00

The screen that lets you change the background color wasn't working before. It would let you select and change red, green and blue values, but it never refreshed the screen.

I found that the code writes to location #6000 whenever the value changes. With a change to my driver to update the internal palettes whenever #6000 is updated, I was able to make it work!

I don't have code to load the palettes upon startup with a predefined value yet, but I know the background is saved in memory for when you power off the machine. This is something I will have to add later. For right now, it will boot up with the default background in the color prom.

Current Game Display Part II

2007-09-29T20:08:00.000-07:00

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

2007-09-27T20:02:00.000-07:00

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

2007-09-26T19:58:00.000-07:00

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

2007-09-24T18:42:00.000-07:00

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

2007-09-23T21:37:00.000-07:00

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.