PE+ Emulator via MAME

(1/12) > >>

knagl:
Originally posted by Stolistic on 10/3/2007

I saw this topic mentioned before but didn't see any mention of someone actually doing it.

I own a PE+ Poker Machine Bar-Top model and decided to try and make it work under MAME.  See mamedev.org for an explaination of what MAME is and how it works.

I have been documenting my progress at the following address if you are interested in reading about it:

http://stolistic.blogspot.com/

My goal is to get my current machine's rom dumps to work in an emulator running on a PC.  It could end up being a cool tool to test your current game roms without actually inserting them into a motherboard.  If my project ends up working, it should support all PE+ chipset.  But I only have one at the moment to test with. Later I would probably expand to the superboard version to try some more roms.

Anyways, I be happy to hear any feedback you may have about such a project.

Thanks!

knagl:
Reply by rickhunter

That's great.  On all the IGT 8032 based machines in addition to the CMOS RAM there is also an eeprom that saves the machine's current state as well as accounting information, have you provisioned this on your code?


Reply by Stolistic

I didn't see any additional RAM chips on my motherboard.  I have attached a picture of it to show you, but I think its an older one that doesn't support what you mention.  Maybe you can verify my findings from the picture.  I believe I have all the major chips accounted for.




Reply by rickhunter

the eeprom is on the backplane.  It should be an 8 Pin 4K eeprom.


Reply by Stolistic

Sorry for my ignorance but by backplane do you mean on the back of the motherboard?  There are no chips on the backside, just the solder points.


Reply by Brianzz

the backplane is what the motherboard plugs into in the back or bottom of the machine


Reply by Ozzy III

Here is the dwg with location of eeprom U1  (see attached file)

cheers

Ozzy

knagl:
Reply by Stolistic

Thanks for pointing in the right direction.  I found the eeprom on my machine right where you said it is.  I'll have to see how that affects my code.  Does anyone know what kind of information is stored in the eeprom?  Does it correspond to any counts you can view when you are in Test or Operator mode?

Thanks in advance.

Also would anyone be interested if I persue a graphics editor?  I posted the idea in my blog very early on.
http://stolistic.blogspot.com/2007/09/graphics.html
I figured since there are a lot of older machines hitting the home market, people might enjoy customizing the card backs and other things...

Anyways, thanks again for the help!


Reply by Ozzy III

The S+ machine continually stores statistical data (soft meters, not hard meters) accumulated from game play in the cmos ram on the CPU board,  the S+ microprossesor transfers the data from the cmos to the eeprom on the mother pcb during the following occurences;

activation of the jackpot reset key

after a cold power up

upon leaving the self test mode

and or every 100 games played on the machine

cheers

Ozzy


Reply by knagl (hey, that's me!)

I find this stuff so cool.   :3-

I think it would be a blast to be able to do custom graphics on the card backs like on some of the old machines at the casinos -- heck, there could even be a market to sell that 'service' to people -- a custom card back design ("Tom's Casino" or whatever) burned on a chip for their PE+ home games.

I looked at the graphics on that page -- I've seen all of them except that "All Win" graphic.  Did that ever get used in a PE+ game?  I wonder what it would have been for.

Thanks for keeping us updated on this -- I find it very interesting.   :3-   :71-


Reply by Stolstic

Thanks Ozzy.  From my interpretation, you are saying the EEPROM is possibly an exact copy of the battery backup ROM on the motherboard.  But is updated only during certain cycles (probably to to save on the life of the EEPROM).  I know they have limited read/writes, like 1 million or so.

If the eeprom is an exact copy, I may be able to dump my chip to see what the battery backup rom should look like.  This would help having to disassemble the Set/Clear chip code.

I have a datasheet on the 24c04, looks like it uses a I2C bus for read/write....may have to play with it.


Reply by rickhunter

No, it's not a duplicate, it only stores certain accounting information as well as information regarding the chips installed on the mpu board, that's why if you swap MPU boards, you'll get a tilt as the eeprom has to be cleared and re-initialized with the new settings.  Also when the machine looses power, the eeprom keeps the state of the machine when it lost power, so say you were in the middle of  a dealt hand, when power is restored, it goes back to the same state.  Apparently there's some quick dump that happens when the machine does not detect power and might use some stored cap power in order to save the state.


Quote from: rickhunter

Quote from: Rep

Awesome work on the project so far! I was very into MAME in it's heyday and always wondered why no one tinkered with more poker and video slots (especially PE+'s as they're my fav  :89- ). Great work and keep us posted!  :71-


That's because the "official" mame devs exclude all gaming platforms from their development by choice and as a policy.  It's up others to take it into a different "branch" and allow for it.  Why don't you think that Mame is not in it's heyday anymore?  There's still a monthly release with intermediate releases in between.



Quote from: Rep

True Rick, I read they put some of the gambling stuff back in last I heard (not all though). Also to me a good bit of the old games are in and the focus turned to games I for lack of better terms couldn't give a crap about. They started adding more and more instead of getting the older games I was interested in working properly (many older games had and still have gameplay issues). I was just surprised no one really went this route before, there were and are many projects built off mame that people work on but I never read about poker machines really. VERY much looking forward to this project, sounding VERY good  :71-



Reply by Stolstic

A couple of people from the MAME dev team have given the "green light" on my driver.  They say that most gambling devices are acceptable now, but used to be unacceptable in the past.  I'll be submitting my driver to them soon so it may become part of the core.

Color prom question for you guys.  Could someone please tell me the value of the first byte in the CAP740 prom?  This value is generally the color black for most proms, so if you don't have that prom another would do, but I would prefer the 740.  I had to dump this by hand and want to make sure I have the bit values correct.  Your answer should hopefully be one of two values, either 0x00 or 0xFF.

Thanks for your help.


I've made a little bit of progress if anyone is interested:
http://stolistic.blogspot.com

I was wondering if my pp0516 code normally supports the "Autohold" feature and it was shut-off on my chip, or if it normally ships with the feature disabled.  When I bought my machine, the game code rom did not have a factory sticker on it and I suspect it could have been altered.

Thanks

knagl:
Reply by rickhunter

That's fantastic!!!

It is unlikely that your game prom was altered as the program does hash checks on all chips before the game starts up (security feature).  Some PE+ gamesets do not allow for auto-hold so it's been disabled.  Sometimes it's jurisdiction dependent, other times it's disabled to help the house out.


Stolistic

Thanks rickhunter.

I can see where the checksum could stop most people.  I stress the word "most", because I'm gonna change my chip to have the autohold and adjust the checksum accordingly. 
I know the source code intimately now, so that won't be a problem.

I also have a pp0188 chip with the same autohold "hidden".  I've run it in my emulator with the same success as the pp0516!


Jay

ok now that is cool.... I am assuming then you can burn this back out to a real eprom and play it in the PE+

I would be interested in changing the card faces and some of the pay tables. Are you into it enough that you are able to do graphic subsitution ?


Stolistic

jay:
I can definitely change the graphics and burn them back without the game prom caring about any checksum.  The paytables are stored in the game prom and affect the checksum, but I would just need to recalc the checksum before burning.  I can do both of these things right now without issue.  So in summary, you can change anything about the graphics and game proms burn them and put them back in a real machine.  The beauty of having an emulator is I can mess with the game chips and not blow-up my real machine in the process.  After prom changes are found to work in the emulator, they will work a real machine.

thedotster:
When finished the driver should support all PE+ roms, but the base driver would need to have the new roms and checksums added to it.  Not a difficult job, but there are like 50-100+ game roms that could be used, so the task just takes time to add them to the list of valid roms.  Personally, I only have 2 different program roms and am looking to buy more so I can verify they work in the driver.  As MAME is concerned, my driver is part of the core download now, and I will continue to pass updates to the developers so we have it in the public copy.  So if you have a MAME machine, you will be able to play the PE+ games in it.

There is no reason why I couldn't write my own game from scratch (including graphics) and make it work in a PE+ machine once the driver is complete.  You don't even have to have it be poker or such.  It could be the game of Tetris, and when you complete a row of cells it pays out a credit/coin!


I'm still having issues getting my emulator driver to recognize a coin-in scenario.  I read a little in this post:
http://newlifegames.net/techforum/index.php/topic,445.0.html

It appears that the optics go from A-Coin Started, AB-Coin in, ABC-???, BC-???,C-Security in one of the sketches.  I'm not sure if that is accurate of what to read from that.

I think the game code checks the state of the ABC optics individually from what I can trace, but not totally sure the proper sequence of events.  Right now when in the test inputs screen the default is ABC (all 1s).  When I simulate a coin-in with a keypress I have them go to ABC (all 0's), then back to ABC (all 1's).  I'm thinking there is more to this than just that.  Also if I hold the keypress from 1's to 0's for too long, the game does give a "Coin-Timeout" error on screen, which means it is seeing the states of the optics move from 1 to 0.

My guess is the sequence is a little more than I have done, and was wondering if anyone has any insight or ideas on it.

Thanks


Ricker

Hey hey,

Isn't the ABC optics a timing issue? Coin on a string, and/or coin accounting issues.

Richard


knagl

Yeah, as far as I know it is a timing issue.  In a real machine the optics are located in a line, and essentially see the coin rolling past as it goes down the chute.  A flip of the state of all three optics at the same time from "1" to "0" would not work.  Additionally, as you (Stolistic) posted, holding them down would result in a Coin-In Timeout as it would think that you're using a slug or a coin-on-a-string to try and fool the machine.  The good news here is that it is in fact seeing your virtual optics (as evidenced by the Coin-In Timeout), and I think it's just a matter of tinkering with the timing of the optics sequence to get it to work.

It would seem to me that the sequence would have to be along the lines of "A" gets tripped, then "B", then "C", with the previous ones turning off as the 'coin' 'rolls past'.  Perhaps is is as you posted in that the coin initially breaks the "A" beam, then covers both "A" and "B", then touches "C", as it rolls past and un-blocks "A" (leaving "B" and "C" blocked), then just "C", then none of them.  Does that make sense?  I have no idea on the exact timing of that sequence, although I susupect that some others here might.


CommTech

Your explanation sounds correct except that all three sensors would be blocked at one point then released one by one.  Also the "B" Optic is offset so that the off time of the "B" Sensor would be a few microseconds shorter than the "A" and "C" sensors as the coin drops through due to the curvature of the coin passing by.
So the sequence would be ... Detect A, Detect B, Detect C, release A, release B, release C.


Stolistic

Thanks for the input everyone.  I tried various combination and still no coin in.  I believe the pattern (A, AB, ABC, BC, C) seems to correct route.  I'm thinking there is something else going on (especially with the door sensor).  I know my real machine doesn't allow coins in when the door is open, and maybe the emulated code is doing the same thing.  It is possible that the coin detection process is valid now, but because the door is open the coin is ignored.

Any thoughts on my theory?

Thanks


CommTech

I believe you are correct. If the door sensor is open, the machine will not register credits.


Stolistic

I used the Input Test screen to verify my code.  When I slow the process way down, I see the Coin Detectors on the Input Screen pulse on/off in the sequence I mentioned before (A, AB, ABC, BC, C), at normal speed they just flicker briefly.  My guess is still the door optics or something related.  I was playing with the door logic and during one point was able to see the door open text disappear and the "reset/closure" text appears and the "Play 5 coins flash" etc.  Then after a secord or so it goes back to Door Open, then repeat.


Cactusjack

Not sure how your code is simulating a door optic closure but.....

I think in most IGT games, the door optics are actually Modulated.  So, even though in test, the phototransistor will respond to constant light (like from a flash light), it might be necessary to transfer the enable signal from the EMITTER to the input of the receiver (like is done when you install a jumper from one to the other).  This might be causing your temporary Door Closure and then when the machine figures out its not really closed, goes back to open again - just a theory?????

However, I can play my multigame PE+ by using a flashlight and still have the door open.  So, I don't know which of the S+ or PE+ software actually REQUIRE the modulated signal.

CJ


Stolistic

CactusJack:
I thought about your concept of using a flashlight to run the game with the door open.  I tried this on my real machine while in the Input Test screen the door open status flashed on/off repeatedly while the flashlight was in the stream.  So instead of a closed door being in a constant state of 0's, it is actually pulsing back and forth when it is closed.  So I update my driver to simulate that, and the door was detected as closed!

As soon as I interrupt the on/off state to a solid stream of 1's, the door open light and text appears.  Unfortunately, once the door is open, I can't seem to get it to close (by pulsing again) without restarting the application.  But at least I can now start with a closed door and open it.

The bad news is that my coin-in simulation of the ABC optics doesn't work when the door is closed.  Gonna need more research on that one.

Thanks for all the tips so far everyone!  At least I have a partial fix on the door.


Cactusjack

Well, the ABC optic closure IS timing specific.  In addition to the order that they are blocked and unblocked, they can only be block so fast or so slow.  I can't tell you the speed but it is obviously based on the gravity of the coin and the speed that the pathway allows it to fall.  Couldn't be too critical since there are a number of factors that might speed or slow it down.  But it does have some extreme limits to prevent "stringing" of a coin.  It could take a person a bit of trial and error to get the timing down but before that, it will go in to Coin in error and lock the machine up so they don't have a chance to learn.  Besides, the upstroke of doing the optics in reverse order will tilt it too.

Sounds like you are getting close.

CJ


Quote from: StatFreak

Stolistic,
Here are the calculations I came up with.  I measured the distance from the point on coin insert head where the bottom of the coin would rest before being dropped to the top of the optic board path. It was 5 inches. These figures are for a quarter which is very close to 1 inch in diameter.

I didn't tear apart my optic box so I wasn't exactly sure how far apart each sensor was. I calculated the travel time for 5mm. It's easy to adjust that using this table if the distance between the sensors is different. I used microseconds but of course that is easily adjusted as well.

Hope this is of some help. 

This is based on the formula:  tf = √ֿֿֿ(2d/g)

S+ Optic TimingFall from Coin entry head      LocationSpeed in Inches/Second   Speed in mm/second  Time in microseconds to move 5 mm (0.5 cm)5 inBottom of quarter enters optic  62.13586404002371578.25094661663168.0639966 inQuarter centered in optic68.06642872958741728.88728973152892.0335237 inTop of quarter exits optic73.52014581051921867.41170358722677.502765



Stolistic

Looks like I'lll be messing with the timing.  I'd almost like to get it to tilt from an invalid sequence like the coin on a string.  I'll try my standard A AB ABC BC C loop with some values going backwards.  At least then I know the system is paying attention to that.  I found out that the error message on screen can be "coin-in timeout" but can be two different conditions internally.  This is seen by the "Jams" and "Sequence Errors" counters separately.  "Jams" I can create right now.  "Sequence Errors" I have not been able to create.

StatFreak:
Thanks for the calcs, I'll need to do some conversion to clock cycles in the cpu, but that should get me close.  I know the cpu clock is a multiple of 3.6864 based on the crystal.

knagl:
Stolistic

I got the coin optics working!  New update on my blog:

http://stolistic.blogspot.com

Thanks your your help everyone!


Jay

Did you need to time the coin drop or was the sequence enough ?
I noted your blog had ABC in the middle while our earlier threads were all just 2 optic sequences.


Stolistic

The timing was less of an issue versus the proper sequence.  There was also some variable in memory that keeps track if you have a coin comparator attached, its the same variable that shows if you have a hopper attached (just a different bit position).  So most of my problem was that this variable didn't know there was a CC attached.  I normally didn't set this variable since I didn't want a hopper, so I never thought about going back to it for other devices attached.


At this point, I'm mostly down to EEPROM support and some timing issues.  I'm pretty sure the timing issues are in the 8051 core that someone else wrote, so its gonna be a bit harder to trace.  The eeprom code has been started, but there is a lot of learning to understand the I2C interface correctly.

As for my avitar (), I made it myself in Photoshop with graphics from the CG chips and custom animation.  If anyone wants something similar, let me know.


I'm just wrapping up the eeprom support and things are going nicely with it.  I can now read and write data to the eeprom using the i2c (two-wire) interface.

Here are some observations on how the machine reacts when both the eeprom and battery-backed ram are empty to start with:

1.  First time the machine boots up, you get a "Call Attendant - CMOS DATA" error.  Open the door and press Self-Test and the machine attempts to restore the cmos with eeprom data.

2.  You now get "Call Attendant - EEPROM DATA".  Open the door and press Self-Test and the machine loads the eeprom with default values stored in the game code.

3.  Both the cmos and eeprom are now loaded with some default values and you must go through the operator setup screen to fill in the final values such as denomination.

4.  Game resets and from there on, any power off/on will reload everything correctly.

Does this seem to match up with a real machine?  It totally makes sense to me why this process is required, since both ram and eeprom are empty to start with.  It also means you don't need the Set038 chip if both ram and eeprom are empty to start with.

I have some small pieces to wrap up and will post another blog entry after that.

Any insights to my findings would be interesting to here.


Jay

I can't say my machine has been ever truly "empty" but after a clear chip is used a Set Chip (set 038) is needed to set DBV denomination.
This is different than the denomination you set in the game. The setup you describe seems correct.


Stolistic

I was not aware there was a Clear chip and a Set chip.  I thought the Set chip did both.  I have a Set038, does that mean there is a Clear038?  I would be interested in looking at the code for a Clear chip if that is the case.


thedotster

Excuse ignorance again, but now you've done this, can you look at the programming code and either:

a) change the payout levels
b) answer the questions about how the cards are dealt, i.e. five dealt then keep shuffling until deal is pressed again, or five dealt and then five dealt on top so if you don't hold the card underneath is shown? I hope that makes sense.

Paul


Brianzz

I can answer the 2nd question. When you press deal 10 cards are selected. I've seen some techs do last game recalls that show all 10 cards


knagl

Quote from: thedotster

Excuse ignorance again, but now you've done this, can you look at the programming code and either:

a) change the payout levels
b) answer the questions about how the cards are dealt, i.e. five dealt then keep shuffling until deal is pressed again, or five dealt and then five dealt on top so if you don't hold the card underneath is shown? I hope that makes sense.


This should answer your first question:

Quote from: Stolistic

The paytables are stored in the game prom and affect the checksum, but I would just need to recalc the checksum before burning.  I can do both of these things right now without issue.


...and Brianzz is correct.  The PE+ platform selects ten cards at once and displays the first five.  The next five are waiting to be used if requested.  They are not "hidden" behind the first five, but rather are sitting in queue waiting to be used.  For example, let's say, for simplicity, that the game has selected A, 2, 3, 4, 5, 6, 7, 8, 9, 10 as the ten cards (in that order).  You'd be dealt a straight (A, 2, 3, 4, 5).  If you chose to throw away any one card (no matter which card), it would be replaced with the 6.

For example, you throw away the 2 and the 4.  You'd end up with A, 6, 3, 7, 5.

Incidentally, no matter whether the cards are hidden behind the first five (some older machines), or ten selected at once (PE+ method), or five and continue to shuffle (the Game King method), the odds of the game remains the same.

Navigation

[0] Message Index

[#] Next page