My new 'I have too much spare time' project

[StatFreak]

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.

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

[poppo]

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.

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

[StatFreak]

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

[poppo]

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

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. 

[poppo]

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

byte.highnib * 10 + byte.lownib =49

[StatFreak]

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. 

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.  

[StatFreak]

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

byte.highnib * 10 + byte.lownib =49

We're posting over each other. 

I agree completely. That's how everyone does it. (according to Kinsey!) 


<PS> Don't forget all those leading (trailing?)  00's.   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

[poppo]

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. 

Thanks for getting me on the right path though.

[StatFreak]

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

Joey has to deal with the same types of problems every time the forum software gets an update.  
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. 

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

[poppo]

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.  But that's ok, I enjoy just doing something different.

Time for some serious 

[StatFreak]

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.  But that's ok, I enjoy just doing something different.

Time for some serious 

Looking good! 

[poppo]

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:

Don't forget soft credit collects and jackpots paid.

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

[zarobhr]

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.

[poppo]

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.  

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

[poppo]

And the verdict is.....

of course it works.  

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

[poppo]

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.

[poppo]

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.

[stayouttadabunker]

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! 
Although it doesn't seem like much right now - it's very innovative
and will definitely come handy when deciphering other machine events.

[poppo]

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.    Next I got the brainy idea   to see how many resistors I could cut out and still have it work. The answer was one.  



This is my favorite challenge.  

[poppo]

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? 

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

[poppo]

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.  So that eliminated needing a wall wart.

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

[stayouttadabunker]

"Left is Louder" is the way my brain remembers it...

[poppo]

"Left is Louder" is the way my brain remembers it...

But that requires actually remembering something. 

[stayouttadabunker]

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

Left is Louder !!!

Left is Louder !!!

[stayouttadabunker]

You may never forget this again!!!


Left is Louder !!!