The ABC's of Coin Optics

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

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

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

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

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

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

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

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

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.