New Life Games Tech Forums

In this thread, I toyed with the idea of calculating payout % on the fly.

http://newlifegames.net/nlg/index.php?topic=13050.0 (http://newlifegames.net/nlg/index.php?topic=13050.0)

However, I ran into a few technical problems. First, I found out that the meter in and meter out signals sometimes run at the same time. This makes it difficult to monitor both signals at the same time. :25-  Next I found it difficult to convert the meter signals into something usable without making a bunch of mods to the MPU.  :47- So I put the project on the back burner.

Then one night while  :294-, it came to me. :79-  Why not just use the stored data? The coin in/out values are written to the EEPROM periodically. It may not always be up to date, but will be close enough to calculate % fairly accurately. Now what makes this relatively easy to do, is the EEPROM is a I2C chip (serial) and only requires a couple of wires. And multiple devices can access it as long as you ensure they don't try to access it at the same time. Since the EEPROM is written to between spins, I can do my reads while the reels are spinning (takes less than a second to do a read).

I put together a 'proof of concept' prototype that uses a S+ EEPROM and has two devices reading and writing to it and it works just fine. The next step is to find where in the EEPROM the data is stored.  :209- That should be easy enough though.

I know this is pretty much a useless project. :5- But I sometimes have more fun building stuff like this than playing the game.  :89-
And yes I do have way too much free time. :72-

Cool, looks like you and Bunker are made for each other! Keep up the good work, we need more of this. This is the fuel that keeps the industrial world moving forward.

 :3- :3-  Way to go Poppo  :244-  You always learn something new from projects like yours.  Sometimes the real fun is just seeing if you can do it, even if it doesn't prove to be very useful.  The knowledge you gain from this project may be helpful for your next one.   :259-

So true. And it was my EEPROM on the MPU project that really got me thinking about tryng this.

http://newlifegames.net/nlg/index.php?topic=10615.0 (http://newlifegames.net/nlg/index.php?topic=10615.0)

Interesting project. As long as you're at it, don't forget that for the S+:

Total coin in = coin in.
Total coin out = coin out + soft credit collect + jackpot pays.



When there are credits on the meter, the numbers won't be entirely correct. That's because credits obtained from bills but that have not yet been washed are not considered to be coin in or out yet; only coin dropped, and because coins won are not counted as coin out until either cashed or played: they are in limbo.

You can see this on the mech meters after inserting a bill (but the stored values act the same way). The coin drop will count the credits, but there will be no coin in registered. As you then play, there will be only coin in activity until the credits have been washed, after which each credit played will register as both a coin out and coin in, since technically, that's what the player has done: cashed out the credit and bet it.

If you cash out with some "bill" credits and some "won" credits, the coin out meter will only count the "won" credits. If you just change a bill, it will register in the coin drop when inserted, but no meters will change when you cash it out.

Right. I played around with the SAS meter readings a lot to see just what changes and when. What really wonks up the mechanical meters is when you have a lot of credits (i.e.put in a $10 bill) and start winning more than you started with (but lost the original $10). That is when both mechanical meters (coin in/coin out) count at the same time. Techically they count taking turns, but it happens so fast, it is difficult to get the timing right trying to use those signals.

I probably could have gleamed the % from SAS meter requests, but that would be too easy.  :72-

you no what would be cool is to find a way to make the machines hit certain number combinations through a computer........ that would be impossible to do though...... even though a ton of people think that the casinos can controll the machines hitting through your card......

Actually, you don't have to win more than you started with; you only have to wash the $10. You could start with those 40 credits and win, say, 30 along the way. When you've used up the first 40 credits and have 30 left, the meters will behave that way from then on, no matter what you've got, unless you put in another bill.

Also, keep in mind that the EEPROM is only updated once every 100 pulls. The good news is that you won't have any timing problems, but the bad news is that your data will only update once every 100 plays. :5-

Right. It's a trade off. And barring any huge wins between writes, the data should be fairly accurate. And the more it's played the smaller the discrepancy. I could lessen the discrepancy by using the progressive signal as the coin in counter (which I am already doing with my home-brew progressive).

Agreed. The next thing to consider it kit swaps. If you want to track each game, you'll have to be able to program starting values into your unit so that you can subtract them from the current totals. That may be more than you care to bother with.

If you bypass the RNG, then you don't really have a slot machine anymore.  :60-

If you want to change the odds of different payouts coming up, you just have to decipher the data chip, figure out how the security check works, figure out what symbols you wish to change and the subsequent change it will make to the payout percentage, hit frequency, etc., make the changes in the data, ... and ... and ... :25- :279- :30- :208- :208-

Game swaps should not be a problem since I have the EEPROM mounted on the MPUs. That works out great since it retains all of data including credits for each game. The % calculator would simply read the new game EEPROM and be good to go. Since each MPU (and kit) got a new EEPROM when I did the mod, they all started fresh and the data on them only applies to that game.

Of course things would be more complicated if I was using a 'standard' setup with just one EEPROM on the motherboard. It would pretty much require a clear every time a game kit swap took place. The other option is to use a socket on the motherboard and swap EEPROMs when changing game kits. That is what I originally was doing before I decided to just stick the EEPROM on the MPU. Even if I only had one MPU, it would be easier to swap the EEPROM that is located on the MPU than having to reach back in the machine to get to the motherboard.

I think it's a fantastic little mod Poppo!  :3-
How you figure out how which pins carry what signals by reading through the board schematics is great!  :131-
What's even more amazing is capturing the signals and re-routing them for your own usage! Awessome stuff !
It's way beyond what I know about IC board components and what they do! Nice!  :89-

Sweet. Your new project mates well with your EEPROM mod.

It had occurred to me that the only other issue that might come up would be using the device with both newer and older SP chips, but I think you'll be okay there.

When I swapped from an SP731 to an SP1271, the total coin in and out were unaffected, and as I recall, the JP and Soft CR weren't either, because all of those values were in the first "group" of data in the newer configuration (the older SP chips didn't separate the accounting data into groups.) Other data were lost because the structure and use of the rest of the space on the EEPROM was changed.

Since those data you need to access remained unaffected through a rewrite of the EEPROM structure, appear to be at the physical start of the data on the EEPROM (though I'm not sure), and are in the same order in both the older and newer configurations, your percentage mod will probably work "out of the box" with both the old and new SP chips.

That is a good point. I have to verify that the memory locations for the coin in/out are the same across all SP chips. Once I find it in the first place. Luckily I have a head start on that. After I did my MPU mod and set everything up, I made a backup of the EEPROM data (all meters reset to zero). So now all I need to do is read the chip again and compare what has changed. I can use the SAS meter readings to help me determine which memory locations are the ones I need.

This sounds like the pachislo battle counter linked here: http://www.pachistat.com/

Yes, you had mentioned that in that other thread. However it has the same issue of not being able to count two things at the same time. In the case of the Pachislo, it is only at certain times, with the S+ it happens much more frequently.

Ok, this was pretty easy. But before I go any farther, I want to say that I do not believe that looking at or posting the EEPROM data is in violation of any copyrights etc. since the EEPROM was blank to begin with and what is stored in there is not code, but just the same data as can be read on the mechanical meters. If any mods feel this in on shaky ground, then let me know.

So I first compared my 'zeroed out' EEPROM with what it has stored now. All of the changes were in the first 150 bytes, so I focused on that. But nothing matched up to the SAS meter readings. This was to be expected since the EEPROM had not been written to for a while. So I played until it wrote the data. Then I read the EEPROM again and behold, there it is. The coin in and coin out are right at the very beginning. Better yet, they are in decimal form, but just byte swapped. So it should be easy to manipulate the data. I will now use this EEPROM data on my test unit to actually get it working. If all goes well, then it's just a matter of connecting a few wires to the machine.

That's interesting poppo!
Why the byte swap I don't understand.

On IGT's programming part - why make a code more confusing than it already is?   :5- :72-
Are you "reading" the socketed motherboard 24C04 eprom?

Don't forget soft credit collects and jackpots paid. :96-  I think you will find all of them near the beginning of the accounting data and in the same locations on both the old and new formats. Let me know, especially if I'm wrong. :71-

It's not unusual to write the date in reverse order. HOWEVER, I'm dead in the water.   :7- At first I thought that having the numbers in decimal format would make things really easy. I could have just taken those 4 bytes and done some simple math like this:
49 + (16 x 100) + (00 x 10,000) + (00 x 00,000) = 1649.  Pretty simple.

But it's had the opposite effect. See, all data in memory is always stored in hex format. So the decimal number 49 would be 31 hex. Now if the number 49 would have been stored as a hex number, there would be no problem because when I would read the hex 31 it would equal 49 decimal. Unfortunately, I have found no way for my microprocessor to look at that value and have it not interpret it as a hex number (and thus give me the wrong value to work with)  :277-

Bunker, as poppo pointed out, swapping bytes is quite common, as is using BCD.

Poppo, read each nibble separately and the number will always be the same in decimal:

4 = 0100
9 = 1001

0100 = 4d  *    10 =    40
1001 = 9d  *      1 =     9

1 = 0001
6 = 0110

0001 = 1d  * 1000 = 1000
0110 = 6d  *   100 =  600

0 = 0000
0 = 0000

0000 = 0d  * 100,000 =    0
0000 = 0d  *   10,000 =    0

0 = 0000
0 = 0000

0000 = 0d  * 10,000,000 =   0
0000 = 0d  *   1,000,000 =   0

                     __________
                            1,649 d


Or read each byte separately if you can't read each nibble (more work):

   nh --> nd
   In decimal: INT(n/16)*10 + n MOD 16.  (You want the truncated integer, not rounded.)

Then multiply the results of each byte conversion as appropriate (x100, x10,000, etc.)

Example:

 0x16 --> 22d.
 INT(22/16) *10 + 22 MOD 16 =16    *100 = 1600

 0x49 --> 73d.
 INT(73/16) *10 + 73 MOD 16 = 49   *1   = 49

 1600+49 = 1649

That is what I am doing.  But the problem is the byte is a hex number even though it is the decimal representation.

so looking at the bytes
49
16
00
00
in the right order they would be 00 00 16 49 decimal (which is what I want)
However in reality since they are actually hex values, they are decimal
73
22
00
00
which would be
00 00 22 73 (true decimal and totally wrong).

The Basic Atom I am using can not look at the byte and make it a decimal equivelent of the contents (i.e. make 49 hex = 49 decimal)

But I have a kludge workaround. I have to create a lookup table that will convert the numbers. For example

if byte = 73 then
fixedbyte = 49
endif

Since the byte hex 49 = decimal 73 when it reaches this part of the table, it will assign the correct decimal value to another variable. I can then do the math as I originally hoped.

Ok, now that might work. Let me look into it.

Reading each nibble is the way it's done.

I'm not sure I understand the issue about reading bytes? :103-  If you are holding the number as hex, then just perform hex or binary math on it. I figured that you were using decimal based arithmetic operations.

You didn't read what I posted. I gave you a simple formula to convert the hex value into the correct decimal number. Reread that part of my post. You're method of creating a lookup table is a very inefficient use of chip space.


<EDIT> Here it is again:


   nh --> nd  [In other words, 16 hex converts to 22 decimal. See example.]
   In decimal: INT(n/16)*10 + n MOD 16.  (You want the truncated integer, not rounded.)

Then multiply the results of each byte conversion as appropriate (x100, x10,000, etc.)

Example:

 0x16 --> 22d.
 INT(22/16) [ = 1. ]    *10 [ = 10 ]    + 22 MOD 16 [  = 6  ]  = 16   [ 10+6 ]     *100 = 1600

 0x49 --> 73d.
 INT(73/16)   = 4.    *10  [= 40 ]    + 73 MOD 16 [ = 9 ]    = 49   [40 + 9 ]     *1   = 49

 1600+49 = 1649

Ok, if you look at the hex dump above you well see that that you can 'read' the decimal coin in number 00001649 (in reverse). lets look at just the 49. That is the decimal number I need. But when I read that memory location, I will indeed get the number 49. However that is a hex value. And the equivalent decimal value is 73. So I can't do any math on the number because all the program sees is either 49 hex or 73 decimal. I need some code that lets it know that 49 IS already decimal. but there is no code to do that.

I'm playing around with using the nibbles, but not getting the results I expect (yet).

Yes there is!  Poppo, LOOK AT MY CODE.

Take the number 49. Convert it to 73 decimal. THEN do the math on 73 as indicated, and you will end up with 49 decimal.

 INT(73/16)   = 4.    *10  [= 40 ]    + 73 MOD 16 [ = 9 ]    = 49   [40 + 9 ]     *1   = 49


In decimal: INT(n/16)*10 + n MOD 16.  (You want the truncated integer, not rounded.)



<EDIT/ ADD> You do have to write the code to do the math. You can write it in assembly. It's a very simple and small routine that won't take much space. :89-

I'm not sure if the processor I am using has all of those math functions. Let me look into it.

I could have had the lookup table written by now.  :72-

Actually the nibble method seems to be working and takes less math.

byte.highnib * 10 + byte.lownib =49

It should. Modulo division is a basic component of computing. All numbers in computers are integers internally, so truncating the result of division that results in a decimal fraction also shouldn't be an issue.

You know, we both can up a head of steam. Putting everything aside, the simple and correct solution is to look at each nibble. Then you won't have to do anything except multiply each one by the correct power of 10. :200- :30-  :72- :72-

We're posting over each other.  :5- :97- :97- :97-

I agree completely. :89- That's how everyone does it. (according to Kinsey!)  :127- :208- :208-


<PS> Don't forget all those leading (trailing?)  00's. :71-  Basically, if you read each nibble of each four byte section from left to right, the multiplication goes:
x10, x1;    x1,000, x100;    x100,000, x10,000;  x10,000,000, x1,000,000

I'll admit that I am more of a 'hardware' guy. I don't usually have to do a lot of math functions in the programs I write.

When I was first doing the math for the % thing, I was having some problems because none of the examples I found worked. The problem is that there are different versions of the Atom chip and different compilers for them, And with each compiler revision they make some changes. So older code may not work.

Even accessing the EEPROM is done two different ways depending on which version of the compiler you use. On the older version, you could just do a read with a single I2CIN command. With the newer compiler version, you have to set the address doing a I2COUT first, and then do a I2CIN.  And I have 3 different Atom versions with 3 different compilers.  :5-

Thanks for getting me on the right path though.

Now you know why we HATE new versions of software for the sake of change.  :89-

Joey has to deal with the same types of problems every time the forum software gets an update. :277- 
Actually, upgrades to newer versions of software/firmware keep programmers employed, since tracking down broken code that wasn't broken yesterday takes lots of man-hours.  :133-

I spent several years at China Lake getting paid to migrate small departmental databases to a new format with an entirely new front end because the Navy had decided that the perfectly fine, fairly problem-free older program was to be disapproved for use on secure computers. It affected every part of every department on the base, and throughout the Navy, actually.

SF :31-

Well, after WAY too many hours and with help from Stat, I have the core coin in/out part done. I already have the % code written from earlier and just need to paste it all together. Of course with my luck, it won't actually work with the machine.  :47- But that's ok, I enjoy just doing something different.

Time for some serious  :294-

Looking good!  :3- :3- :3- :259-

Ok, so adding in the % caluclation routine was fairly simple and everything is now working (on the test unit)

Now the next step will be to see if it actually works while connected to the machine. Connection will be fairly easy and only needs 3 wires. However, I still have to add some code to make sure it does not try to read the EEPROM while the machine is reading/writing to it. I figure the easiest way to do this is to monitor the play max credits button lamp. As most know when the EEPROM is being written to, there is a delay before you can play again. During that time the lamp is off. So if I wait for the lamp to come on and then pause for a few seconds just to be on the safe side, it should guarantee that the machine is not doing a write. Plus since I don't need to be updating the display very often, I can have it on a slow loop (let's say once every 15 seconds or so).


Now to take another look at this:

I understand the jackpots paid (I think) but I am not too sure about the 'soft credit collects'.  Using the SAS data, I have played around a lot with doing various things like add cashable credits, removing credits, cashing out, etc.. No matter what I do, the 'Total coin in meter' and Total coin out meter' (through SAS) have always been accurate and reflect coins actually played and coins actually won. Now I have not hit any jackpots yet with this, so I don't know if the SAS total coin out meter will reflect that or not. If not, I will have to wait until I hit one to see where the data is stored. Then I can just add that in.

So just what are the  'soft credit collects' and how do they come into play? All of the testing I've done shows that credits are properly accounted for in the total coin in and total coin out meters (SAS). If credits have not been played yet (i.e. you just stuck in a $10 bill and then cashed out) nothing is added. But if credits have been won, then the meters reflect that.

BTW, I did calulate in the leading zeros from the other two bytes. But since they equal zero right now, I still only have a 4 digit number. But it can go up to 99,999,999 (assuming the slot machine's software actually goes that high).

from testing i have done jp won meter( which is basically anything 1200 and up is not counted in the coin out meter) since it is handpay. and is reflected on the jp meter.

The only thing I am unsure of is - mechanical meters vs software meters. There are more software meters than mechanical ones, especially with newer SP chips that have more accounting features. So I don't know for sure if the software one (the one I am using) would reflect jackpots too. It's entirely possible that the 'Total coin out meter' (software one) actually does total everything won whether hand pay or not. Unfortunately, I can not force a jackpot.  :72-

I suppose I could change the hand-pay limits and see what happens to the total out when a hand-pay occurs.

And the verdict is.....

of course it works.  :71-

Ok, here is what I did. First I modified the code to wait until I pressed one of the buttons on the carrier board. This way I could control the reads until I was sure it worked, and would wory about monitoring the max bet lamp later.

It's not pretty, but because my EEPROM is mounted on the MPU, I drilled a small hole in the back of the tray to run the 3 wires out. After connecting everything and powering up the machine, I did a read. And thankfully I got the correct values (remember my test EEPROM was a copy of what was in the machine, so they better match).

Next I played 100 plays. During this time, pressed my read button a few times just to verify that the EEPROM had not updated and that it would not honk up the machine. After the expected write pause, I did another read and bingo, the values had updated.  :71- I did a SAS query to double check and everything matched. (SAS results pasted into second picture)

So as useless as this may be, at least it does work.

Ok, that took up a couple of days, now what?  :72-

After tucking everything away inside of the machine (including the display), I decided to just keep using the manual read button. Since I would have the door open anyway, all I have to do is press it to get an update.

Ok, this was interesting. I was attempting to see if I could do an initial read as soon as the machine is powering up. I waited a few seconds after applying power, pressed my read button and got nothing. And the machine promptly gave me a 65-0 (bad EEPROM) error. I figured I just triggered what I was trying to avoid (both the MPU and me accessing the EEPROM at the same time). I was not able to clear the 65-0 by powering down/up. BTW, there is nothing wrong with the EEPROM and subsequent presses of my button were able to read it just fine. Apparently what happens is if there is a problem reading the EEPROM (which the machine does at power up to compare to the CMOS), a flag gets set somewhere in the CMOS saying it's bad, and you are dead in the water. The machine probably looks for a blank EEPROM before resetting the error flag. So I just pulled the CMOS to get it to lose it's memory (and any set flag). After that, it got me back to the normal 61 (61_1) and all is well again, except I lost my credits as expected.

So apparently a 65_0 does not necessarily mean the EEPROM is bad, only that the MPU failed to read it. I suppose normally that would only happen if it is bad. But once that error flag is set, it stays set until either the EEPROM is replaced or the CMOS is pulled. Of course if the EEPROM really is bad, pulling the CMOS won't help, as the flag will just get set again.

You are doing things that not many of us (or any if that...lol) have tried...great stuff Poppo!
I really enjoy reading your "tinkering" projects!
It helps us all understand what is going on during different machine events!  :89-
Although it doesn't seem like much right now - it's very innovative
and will definitely come handy when deciphering other machine events.

I've always liked to tinker with things ever since I was a kid. Once I got an transistor radio for like my 10th birthday or something. I promptly opened it to to see what made it tick. First I looked at all of those cool variable inductors and started tweaking them, I found that you could make the station come in REALLY good. The only problem was that was then the ONLY station it would receive.  :25-  Next I got the brainy idea  :5- to see how many resistors I could cut out and still have it work. The answer was one.  :72-



This is my favorite challenge.  :79-

Here is a good example of how wildly the payout percentage can change until you have a lot of spins to average things out. Since this machine was recenlty cleared, all of the meters started at 0. On my first test, the % was 69%. Then after the next 100 pulls it went up to 76%. Then after the next 100 pulls it went back down to 66%. Of course, the more I play, the more stable the number will become. But I'm nowhere near the 97.13% of the SS3819 (yet).

Does this also blow holes in the theory that a freshly cleared machine pays out better?  :96-

BTW, here is where I mounted the display with a big button from another project mounted on top.

To wrap things up on this projects, I put together a small perf-board with a socket for the Atom chip and just enough pins for the signals I use. That way I don't have to waste one of my developement boards. I then mounted the board on the back of the MPU right by where my EEPROM mod is. I can put one of these perf-boards on all of my MPUs and then just swap the Atom chip (they are not exactly cheap). After I stuck a power jack on the board, I realized I could just get the +5v I need from the MPU.  :25- So that eliminated needing a wall wart.

And yes, before anyone says anything, I need a reminder on which way to turn the volume.  :96-

"Left is Louder" is the way my brain remembers it... :72-

But that requires actually remembering something.  :5-

The human brain retains visuals much better!!!>>>
Left is Louder !!!

Left is Louder !!!

Left is Louder !!!

You may never forget this again!!! :208- :97-


Left is Louder !!!

when turning anything its always the same as      righty tighty lefty loosey

not entirely true there my buddy...lol...
Try telling that to the guys that install the bolts for the public bathroom stall walls... :72-

Ok, I'll make a new label with that on it.  :96-

Lucy yelling...:>>>   "I give up Charlie Brown!!!"     :37-


( just kidding ya Poppo!  :)   )

so are you a installer of bathroom stall walls ? :200- or just spending to much of your free time hanging out in public bathrooms  :279-

Speaking of mnemonics, you should hear the one I memorized to remember the circle of fifths (music). I can't repeat it in public, and what made it immediately memorable for me was that a pretty girl told it to me.

Of course, there's dozens of G rated ones that are completely forgettable uninteresting.  :96- I'm sure I learned one of them as a kid, but I can't remember it anymore. :97- :97- :97-

lol...I have to use the public bathroom here at work...  :40-

So I get time to look at the funny looking reverse bolts while waiting for the "movement" to happen.... :208-
It's amazing how you can make your fingers look separated too by crossing your eyes and staring at the floor.
What the heck were we talking about here anyways?
 :72- :72- :72-

Oh..."I have too much spare time..."  well, sitting in a public restroom and staring at bolts certainly fits this thread title...lol

Since it's a slow night on the forum, here is what I have been working on with this project. First, I changed to a different LCD (larger and back-lit). I mounted the LCD on the inside of the door as seen in the first picture.

As I am locating the data in the EEPROM, I'm adding it to the display. Each press of the button will cycle to a new 'page'. Yeah, a lot of this can be gleamed by using the reset key and accounting mode, but this is not as cryptic. And I might as well make use of the hardware. The second picture shows the 3 screens I have completed so far.

On a side note, these are awesome LCDs.They are 2x20 back-lit. They are serial (standard or TTL) or I2C driven. Lots of options for I/O etc. There is a guy selling them new for $15 each on e-bay. I picked up a bunch since serial back-lit LCDs tend to normally run about $40+.

That's very, very nice Poppo!
Are you going to try and stick it in the player tracking display area with a button to flip through the pages?
I think that would be pretty neat too?

I had though about that, but do we really want people playing to know the machine is only paying 69% or the win to loss ratio (I still need to calculate that).  :47-


I need to double check, but it seems that it is actually doing a write every 99 pulls vice every 100. Also, I have not figured out why there is a total of 349 games played in the EEPROM if it is  writing every 99 or 100 pulls.  :103- Something caused it to write sooner. Maybe when a SET chip is used?? The number of games played stored in the EEPROM 'should' always be a multiple of 99 or 100.

Here are some known memory locations for the EEPROM on the PE+ platform.  I'm thinking the S+ may share a lot of similar locations.  Let me know if they line up!

00   Game Type
01   Coins In
02   Coins In
03   Coins In
04   Coins In
05   Coins Out
06   Coins Out
07   Coins Out
08   Coins Out
09   Drop
0A   Drop
0B   Drop
0C   Drop
0D   Cancelled Credits
0E   Cancelled Credits
0F   Cancelled Credits
10   Cancelled Credits
11   Jackpots
12   Jackpots
13   Jackpots
14   Jackpots
15   Total Games Played
16   Total Games Played
17   Total Games Played
18   Total Games Played
19   
1A
1B
1C
1D
1E
1F
20
21
22
23
24
25
26
27
28
29   Current Denomination
2A   Bill Acceptor
2B   Bill Validator Totals - $1 Bills
2C   Bill Validator Totals - $1 Bills
2D   Bill Validator Totals - $1 Bills
2E   Bill Validator Totals - $1 Bills
2F   Bill Validator Totals - $2 Bills
30   Bill Validator Totals - $2 Bills
31   Bill Validator Totals - $2 Bills
32   Bill Validator Totals - $2 Bills
33   Bill Validator Totals - $5 Bills
34   Bill Validator Totals - $5 Bills
35   Bill Validator Totals - $5 Bills
36   Bill Validator Totals - $5 Bills
37   Bill Validator Totals - $10 Bills
38   Bill Validator Totals - $10 Bills
39   Bill Validator Totals - $10 Bills
3A   Bill Validator Totals - $10 Bills
3B   Bill Validator Totals - $20 Bills
3C   Bill Validator Totals - $20 Bills
3D   Bill Validator Totals - $20 Bills
3E   Bill Validator Totals - $20 Bills
3F   Bill Validator Totals - $50 Bills
40   Bill Validator Totals - $50 Bills
41   Bill Validator Totals - $50 Bills
42   Bill Validator Totals - $50 Bills
43   Bill Validator Totals - $100 Bills
44   Bill Validator Totals - $100 Bills
45   Bill Validator Totals - $100 Bills
46   Bill Validator Totals - $100 Bills
47   Bill Validator Totals - Total Bills Accepted
48   Bill Validator Totals - Total Bills Accepted
49   Bill Validator Totals - Total Bills Accepted
4A   Bill Validator Totals - Total Bills Accepted
4B   Bill Validator Totals - Total Dollar Amount from Bills
4C   Bill Validator Totals - Total Dollar Amount from Bills
4D   Bill Validator Totals - Total Dollar Amount from Bills
4E   Bill Validator Totals - Total Dollar Amount from Bills
4F   Bill Validator Totals - Total Coins or Credits Dispensed
50   Bill Validator Totals - Total Coins or Credits Dispensed
51   Bill Validator Totals - Total Coins or Credits Dispensed
52   Bill Validator Totals - Total Coins or Credits Dispensed
53   Physical Coins In
54   Physical Coins In
55   Physical Coins In
56   Physical Coins In
57   Physical Coins Out
58   Physical Coins Out
59   Physical Coins Out
5A   Physical Coins Out
5B   Max Payout Low Byte
5C   Max Payout High Byte
5D   Hopper Size Low Byte
5E   Hopper Size High Byte
5F   Maximum Coins In
60   Maximum Coins In (BCD High)
61   Maximum Coins In (BCD Low)
62   Tones/Music
63   Background Color
64   0x04=ABC Detector Attached, 0x08=Hopper Attached
65   Credit Type, 0=Credit, 1=Player Initiated
66   Autobet
67   Deal Speed
68   Paytable
69   Animation
6A   Double Up
6B   SAS Mini System Address
6C   Autohold
6D   Drop Door
6E   Total Wins
6F   Total Wins
70   Total Wins
71   Total Wins
72   Losses
73   Losses
74   Losses
75   Losses
76   Credits Bet
77   Credits Bet
78   Credits Bet
79   Credits Bet
7A   Credits Won
7B   Credits Won
7C   Credits Won
7D   Credits Won
7E   Credits Paid
7F   Credits Paid
80   Credits Paid
81   Credits Paid
82
83   Progressive Level 1 (0x00=No, 0xff=Yes)
84   Progressive Level 2
85   Progressive Level 3
86   Progressive Level 4
87   Progressive Level 5
88
89   Communication Type
8A
8B   Bill Credit Limit Low Byte
8C   Bill Credit Limit High Byte
8D   Bill Acceptor

Coin in and out match up, but that's about it.  But I have not dissected the whole thing yet.

Poppo, cancelled credits are the same as "soft credits collect," and to answer your earlier question, they represent credits cleared off of the machine with the JP key when the credits exceed the hopper limit. That's why I told you to add them, along with the JP total, to the coin out figure when calculating the total coin out figure to be used in your payback percentage calculation.

Neither the "cancelled" credits nor the jackpots paid are included in the coin out total meter.


I'm only speaking of the data – not their location on the chip.

I'll have to wait until I hit something large enough to trigger a hand pay to find out where the data is stored.

You're not thinking out of the box.

First, for the cancelled credits (which really only applies to the later SP chips like SP1271), set the hopper limit to 0 and the credit limit to 9999. Then WIN some credits (remember that inserted bill credits won't count) and cash out. That will cause a hand pay lockup. Turn the key to clear. Then look in the bookkeeping menu and the EEPROM for the value.


Second, set the JP lockup limit to something low, like 10, and play until you hit the jackpot – which won't take long. Follow the above procedure.


Problem solved.

Something else I am not sure of, is if a hand pay will cause an immediate EEPROM write. Otherwise I have to wait until it does one or the data won't be there yet.

Something else I am not sure of yet is if the newer SPs like the SP1271 store the data in the same place. I have been using a SP1048 and SP873 for testing (which so far are the same). The newer ones may be different and might match Stolistic's list. I like using the SP1048 because it supports the different bonus sounds for games like my Spin Till You Win.

One of the side benefits of all of this is I did a clear (to reset all of the meters) and set up everything the way I wanted to. Then I saved the EEPROM data. Now if I ever want to start over, I can just put the data back and not have to mess with any self test settings, SET chips etc. Of course that was part of the reason for the EEPROM on the MPU mod that started all of this. Just pop in a MPU and you are right where you were before switching games. Credits and all intact. No remembering menus or getting bent pins from swapping chips etc.

Don't forget that the data on the CMOS and in the EEPROM are compared, so if you write changes to the EEPROM, but not the CMOS, you'll still have to clear tilt codes. I'm not sure if the program will take data from the EEPROM and move it to the CMOS, but I suspect not. It's probably a one-way street from the CMOS to the EEPROM, which means that any tilt code clears will overwrite your new EEPROM data with the existing CMOS data.

I have already done it several times. You will get a 61 because the data does not match. But all is well after clearing that.  Clearing a 61 appears to re-copy the EEPROM data back to CMOS. After all a 61 is 'bad CMOS RAM'.

Interesting. :79- I learned something new. :89-

It also makes sense from a security standpoint. You would always want the EEPROM to take 'priority' if a MPU is swapped (i.e. data does not match). You would not want your 1 cent denomination MPU overwriting your $1 denomination machine's EEPROM.

After thinking about it for a moment, it made more sense to me, too. When we've had data errors in the past, changing or clearing the CMOS by removing it would often clear the error, which means that the computer had to have written the EEPROM data to the CMOS.  :25-

When the EEPROM data gets corrupted, that's probably when a full clear is required to fix the problem.

That might be the exception the the rule. When I got the 65_0 by reading the EEPROM at the wrong time, nothing would clear the error  (short of pulling the CMOS) even though there was nothing wrong with the EEPROM. BUT if I would have put a blank EEPROM in I believe the CMOS would have written the data back. But only if the EEPROM is blank. Maybe some day I will test that theory by causing a 65_0 and then butting a blank EEPROM in and see what happens.

Had some free time and added the last bit of data that I wanted to be able to see.

I don't recall whether or not you ever mentioned what game you have installed?

The only type of game that would have a hit ratio like that would be a 5-line or the 9-line TD. A 3-line might, for a small sample. :128-
Most cm games have hit frequencies between 1 in 5 and 1 in 8, with the most common being between 1 in 6 and 1 in 7.


It's interesting that the data you chose to calculate is the same data I calculate and summarize at the bottom of my spreadsheets. :71-

This is in a 5 line Gold Mountain with a SS3819.

Keep in mind this is still a short term sample. I simply used the reciprical of games won divided by games lost. In this case I have 276 won and 379 lost. Thus there has been one hit (not necesarly a win of more than wagered) in every 1.37 spins (truncated to 2 decimal places)

My 3 coin Spin Till You Win SS4198 has an even smaller sample so far. It has 57 games won and 231 lost. According to my calculations it is at a hit ratio of 1 in 4.05.

Is the hit ratio "games lost / games won" ?? 379/276 = 1.37
Shouldn't it be "total games / games won" ?  (276+379)/276 = 2.37

Correct Uniman. :89-




<ADD> The second hit ratio should be 1 in 5.05  (231+57)/57

Poppo:
However, one doesn't need to add the wins and losses. There is a separate bookkeeping value for total games played. The correct procedure would be to change the code to read the total games played and games lost values. (In other words, substitute a loookup of the Total Games Played value for your lookup of "Games lost" and leave the math function in the code alone.

Side note: You could cheat and just add 1 to your current calculated value*, but it's not the right way to do things. The NGC would never approve. :96-
*since total games = games lost + games won; your current value is games won/games lost; and games lost/games lost always = 1

Yep, you are right.  :89- It's easy enough to fix since I already have grabbed the total games played value for use on page 1 of the display. All I need to do is change the one line in my code.  Thanks  for pointing it out. :259-

Good think I stuck my Atoms in ZIF sockets.  :96-

Note: I always grabbed the actual total games value from the EEPROM instead of just adding won + lost  so that I could verify I was getting the right values. I suppose I could eliminate that one read if I needed to, but I'm not running low on program space or anything.

That's cool, your project is really turning out nice!    :89-

Thanks.  I think I am about done with this phase.

The Atom chip I am using has serial I/O (on any pins). Now I already have SAS working and can do EFT transfers to the machine from a PC. If I had a better understanding of the EFT commands, I could send some credits right from the machine (using the Atom) without the need for a PC. But from what I have seen, the EFT is not just a simple command of 'add $20'. Instead there is validation with an initial command, then a reply (that is different each time) and then another command to complete the transaction.

If I could get that working, I could add a card reader, and while not a true funds transfer, have a swipe of the card add $20 (or whatever I set it up for).

Of course after I started thinking about that aspect, I realized I could be getting the same data I am getting from the EEPROM by using SAS commands (using the Atom) and have the data in real time. The commands for meter reads are simple and the machine just sends a reply to the request. But that would tie up the serial port on the machine for SAS.

I've even been thinking of some sort of S+ 'TITO' using something like a memory stick. Pop it in, cash out (info gets written to the memory stick), go to the other machine, pop it in and add the credits.  :5-

Did I mention I have too much spare time?  :72-

That's an awesome idea actually...
It would save live casinos millions of dollars in ticket stock and the machines wouldn't need printers...lol
You'd be a multi-millionaire!  :96-

MIMO _{patent pending}

 :72-

You need a partner?  :200- :96-

Poppo

Have been looking into doing something similar. On the S+ have you managed to do an actual EFT or only a legacy bonus (Andy's app does these ok to the PE+ and also SAtest ut cant seem to get a EFT transaction done)
You could write that info to a smartcard - may be more practical and easier to interface to the atom than a USB device.

Ian

EFT with SAS Test.

I doubt I will pursue 'MIMO'.  :96-  But the Atom does serial (RS232) very well and easily. So whatever device, whether it be a memory stick or a smart card, would be easiest to implement if it had serial I/O. On my robotics project, I had a serial based SD card reader. It worked very well and was fairly easy to read and write from with the Atom. But deciphering the EFT validation seems like more trouble than it's worth.