Thursday, October 25, 2007
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:
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.
Tuesday, October 23, 2007
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.
Thursday, October 18, 2007
Tuesday, October 16, 2007
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
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.
Friday, October 12, 2007
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.
Tuesday, October 9, 2007
Saturday, October 6, 2007
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.
Tuesday, October 2, 2007
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.