My new 'I have too much spare time' project

[poppo]

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

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.   Next I found it difficult to convert the meter signals into something usable without making a bunch of mods to the MPU.  So I put the project on the back burner.

Then one night while  , it came to me.   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.  That should be easy enough though.

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

[reho33]

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.

[Tilt]

   Way to go Poppo    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.  

[poppo]

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. 

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

[StatFreak]

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.

[poppo]

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.  

[staz]

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......

[StatFreak]

...
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.
...

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.

[poppo]

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.

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).

[StatFreak]

...
And barring any huge wins between writes, the data should be fairly accurate. And the more it's played the smaller the discrepancy.
...

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.

[StatFreak]

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......

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

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 ...

[poppo]

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.

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.

[stayouttadabunker]

I think it's a fantastic little mod Poppo! 
How you figure out how which pins carry what signals by reading through the board schematics is great! 
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! 

[StatFreak]

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.

[poppo]

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.

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.

[reho33]

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

[poppo]

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.

Different Pachislo machines turn on the Big Bonus signal at different times. Sometimes it is before the initial payout of 15, sometimes after and sometimes in the middle. In order to combat this we set the payout to 15 and wait until the first spin to start counting a Big Bonus payout. The good news is that some machines will not allow you to start your first spin until after all the initial 15 tokens have been accounted for, the bad news is that some machines will allow you to start your first BB round spin while it is still sending the token out signal to the PachiSTAT. If you start your first spin before the signals for the 15 tokens have been sent then the Big Bonus Counter will be off.

[poppo]

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.

[stayouttadabunker]

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?   
Are you "reading" the socketed motherboard 24C04 eprom?

[StatFreak]

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.

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.

Don't forget soft credit collects and jackpots paid.   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.

[poppo]

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?  

It's not unusual to write the date in reverse order. HOWEVER, I'm dead in the water.   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)  

[StatFreak]

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

[poppo]

Poppo, read each byte separately.

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.

[poppo]

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

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

[StatFreak]

Reading each nibble is the way it's done.

I'm not sure I understand the issue about reading bytes?   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.