Smash & Grab 1st gen rom

[johnparker007]

Not sure if this is the right forum area for this so apologies, but apparently the infamous 'chris217' youtuber/machine collector has (on rewatching the video, his friend has) a very early ROM revision of Smash & Grab.  I wonder if we could tempt him, perhaps by clubbing in and sending over a ROM ripper/burner device, to rip those ROMs?

Or, do we already have those ROMs?  It seems to be doing something I've not seen the MFME build doing before.

Here's the video:

...and here's the pertinent comment, which makes me think these could be great ROMs to get:

@grahamnutt8958

What you have played there is the uber rare 1st version of  Smash & Grab. It got banned very quickly and very few of those (and ROM's) survived.

Gen 2 onwards only let you exchange the £3 win once.

I saw this just once and the lucky player rinsed it £10.50 banked in short order.

Your pal and #sulzerned will be able to confirm what I'm saying about 1st gen.
What a rare find!!!

Edited September 30, 2024 by johnparker007

[slotsmagic]

It's a tricky one. If you have an old / rare ROMset it's great to be able to dump the ROMs and have a known good backup you can recover from.

At the same time, would you want to risk losing your software by making a copy if you aren't sure what you were doing?

The risks aren't too bad, if you physically damage your original chip before / during dumping you'd probably be able to recover it to the point you can still dump it.

If you damage the data on the chip though - you are out of luck. You'd be able to source an alternative ROM dump (probably) but would lose the rare original.

Edited September 30, 2024 by slotsmagic

[thealteredemu]

I do believe we have the early roms for this.  I’m pretty sure I’ve seen it mentioned years back.

J

[johnparker007]

I wonder if it's one of these 7...

[logopolis]

I don't know anything about this game as it was a bit before my time of playing seriously. 

All those 7 sets are MPU4 roms which can't be for the machine pictured above. The MDM Smash 'n Grab is the machine with the cameras and the stop n step feature. Can't think what the Barcrest machine is off the top of my head.

[johnparker007]

9 hours ago, logopolis said:

I don't know anything about this game as it was a bit before my time of playing seriously. 

All those 7 sets are MPU4 roms which can't be for the machine pictured above. The MDM Smash 'n Grab is the machine with the cameras and the stop n step feature. Can't think what the Barcrest machine is off the top of my head.

Ah you're right on the MDM ones, I just tried one, they're for a more modern game that has a trail, random nudges and sampled music!

The 3x labelled:
SAG 3.4
SAG 1.0 (set 1)
SAG 1.0 (set 2)

Do play as the machine in the video, when booted and tested.

Looks to be more sets in the archive, seems to be a 32kb game...


(Edit: though it's just occurred to me that if these <32kb files sets were joined to make their full 32kb romset single file image, there may actually then be some duplicate 32kb full roms detectable in here).

Edited October 1, 2024 by johnparker007

[stevedude2]

We've got these ROMs - as I recall someone on the Mecca, might even have been @Player, bought a SAG on eBay and when he booted it up it was running on 1.0 software.

I've zipped my copy of the layout up and attached

Nudges banked from the gamble carry over from game-to-game (you don't get forced to Break or Take on the next spin - they go into the Pig instead of the nudge gamble ladder), and you can Trade/Exchange a £3 win repeatedly.

Enjoy

 

Barcrest - Smash & Grab DX (1.0 ROMs).zip

[johnparker007]

1 hour ago, stevedude2 said:

We've got these ROMs - as I recall someone on the Mecca, might even have been @Player, bought a SAG on eBay and when he booted it up it was running on 1.0 software.

I've zipped my copy of the layout up and attached

Nudges banked from the gamble carry over from game-to-game (you don't get forced to Break or Take on the next spin - they go into the Pig instead of the nudge gamble ladder), and you can Trade/Exchange a £3 win repeatedly.

Enjoy

 

Barcrest - Smash & Grab DX (1.0 ROMs).zip 3.96 MB · 1 download

Based on the filenames and dates, the ROMs in the layout appear to be the ones in the archive (time difference of exactly one hour)  

[Chopaholic]

1 hour ago, stevedude2 said:

We've got these ROMs - as I recall someone on the Mecca, might even have been @Player, bought a SAG on eBay and when he booted it up it was running on 1.0 software.

I've zipped my copy of the layout up and attached

Nudges banked from the gamble carry over from game-to-game (you don't get forced to Break or Take on the next spin - they go into the Pig instead of the nudge gamble ladder), and you can Trade/Exchange a £3 win repeatedly.

Enjoy

 

Barcrest - Smash & Grab DX (1.0 ROMs).zip 3.96 MB · 2 downloads

Ahh excellent! This is one I've always wanted to do a video on but couldn't quite remember the details of it and playing around with it in the emulator I couldn't get it to do anything special anyway. (I vaguely had in my head something about unlimited jackpot exchanges.) However with these ROMs it's a different proposition of course!

Obviously the machine can get out of it by just SMASHing the piggy bank nudges rather than GRABbing them, but in turns out that a cheeky plug (CTRL+R) simply reboots the machine back to the Smash & Grab opportunity and eventually it will GRAB rather than SMASH. (There's a comment on the video @johnparker007 linked to that makes this point, so it was a thing on the real machine.)

Cheers for the heads-up folks, this will make for a nice video I think. The machine was still to be found in arcades when I started playing in 1990 (most arcades had one in fact), but I didn't know about any shenanigans on it at the time  

[johnparker007]

5 hours ago, Chopaholic said:

turns out that a cheeky plug (CTRL+R) simply reboots the machine back to the Smash & Grab opportunity and eventually it will GRAB rather than SMASH. (There's a comment on the video @johnparker007 linked to that makes this point, so it was a thing on the real machine.)

I have just confirmed this on the 1.0 ROM, very satisfying!  Along with nudges going into the permanent piggy bank rather than the 1 credit 'temporary hold' of the later ROMs, you can keep getting/retrying £3 opportunities with a high/full nudge bank until it gives you the 'GRAB'.  I do really like this machine, it's a classic  

[Chopaholic]

Are there any clues on dates inside the ROMs @johnparker007? 

Going from the endlessly useful list from @jasonc , we can see that the £3 jackpot was running from early 1984 to early 1987, when it was increased to £4. Which would make this a pretty early MPU4 machine I believe. There's a £4 version of this machine called 'Grab The Bank'.

[johnparker007]

4 hours ago, Chopaholic said:

Are there any clues on dates inside the ROMs @johnparker007? 

Sadly no, there generally isn't in these MPU4 ROMs (though I have seen it once or twice).  I did a visual scan through the whole ROM, just the usual stuff; system messages/strings, alpha text, and the version you see on boot (SAG 1.0).

[Chopaholic]

5 minutes ago, johnparker007 said:

Sadly no, there generally isn't in these MPU4 ROMs (though I have seen it once or twice).  I did a visual scan through the whole ROM, just the usual stuff; system messages/strings, alpha text, and the version you see on boot (SAG 1.0).

No problem cheers for looking  I can get close enough with the known dates of jackpot revisions, but it's always interesting to get a little easter egg out of a ROM if it's available  

[johnparker007]

1 hour ago, Chopaholic said:

it's always interesting to get a little easter egg out of a ROM if it's available  

Well in this 1.0 ROM you have the almost 'standard' Barcrest message that I do like; NUDGE COCKUP



Charmingly British!

The other small block of strings that looks kinda interesting is; 


Which seems to hint at perhaps some engineer/test setting of 'generosity' that can go between:

MEGA-GENEROUS (MEGA GEN)
GENEROUS
CENTRE
MEAN
MEGA-MEAN (MEGAMEAN)

...which appear to be 5 settings/live variables or states - perhaps related to the Nudges, perhaps related to a Playtest setting.  There can sometimes be something simply in text that is 'secret' if you patiently go through the entire ROM  

Edited October 2, 2024 by johnparker007

[Jamie28J]

Absolutely love this version and I am pretty sure this is what my local arcade (Stardust at Hopton on Sea) had back in the day (parked next to a Top the Lot). Great memories.

[Mort]

5 hours ago, johnparker007 said:

MEGA-GENEROUS (MEGA GEN)
GENEROUS
CENTRE
MEAN
MEGA-MEAN (MEGAMEAN)

 

I guess these could be the various levels of the compensator(s) @johnparker007

Edited October 2, 2024 by Mort

[Mort]

Which reminds me, I am trying to find the various compensators in Club Bullion, in RAM.

I'd like to manipulate them in normal play, just out of interest, to see if you can get, and keep, a machine, in an ultimate play state.

It's something @Dougsta I recall has been asking me about over the years, but I don't have much luck in finding them.

The method I have tried to adopt, and it's an assumption, is that when you open the Back Door of a machine, and put it into Test/Free play mode, that I would expect the compensators to be raised high (with a command command in ASM to copy the existing ones elsewhere in RAM, so they can be put back when you put it back into normal mode). I then look out for them, and compare back to the machine going back into normal play mode (back door closed) but I have been driving myself insane in trying to find a pattern. I wish I could follow all the ASM commands natively, but it's nightmare to try and trace through them, at least for me!

For any proper Fruit Machine coders out there, do you know if this would be the case or am I wrong ?

Perhaps @edwardb can advise me ? I'd love to know.

Edited October 2, 2024 by Mort

[johnparker007]

1 hour ago, Mort said:

I guess these could be the various levels of the compensator(s) @johnparker007

Potentially, though I thought these machines could be set to discrete integer %ages between ~78% and 100%.  This looks to be a much less granular 1-5 scale... it's something maybe interesting, but I don't know what!

I'm not sure (from your above post) if Edward worked on Barcrest MPU4s so whatever code/logic/libraries etc could be significantly different between Barcrest MPU4s and other platforms/manufacturers.

In terms of hacking runtime compensator values, I'd imagine it's very likely possible, though potentially a ball ache (to pinpoint values/routines)!  So I guess you're saying, you'd want to take a Blue Moon (MPU4) or Indiana Jones (IMPACT) and then totally kill it with a big run of wins, but then hack some live values in RAM, and have it become 'ready' again, so you get more wins?

It'd be doable, regrettably I'll have to decline the challenge, since when I get spare FME dev time, I need to work on Oasis really!  But It would be doable I'm sure.  There'll likely be a function with a calculation somewhere (unless it uses a 'blackboard' approach to perform the calc less frequently and refer to it, to avoid running the calculation too much, to avoid stutters/delays)... so that'd be what you'd want to hack.


Edit: if you really wanted to go into this, one approach might be via 'pluggable' roms. 

I first learnt of these from @thealteredemu back in the day, I think it was early ROM revisions of a Monopoly machine.  So the machines where they use the 'count up' alpha animation when you get a win, and the trick was to score a Jackpot, then plug it (or click it) while the win animation counted up.  Machine would pay out on reboot due to battery backup, but it only processed the win from the overall running %age once the win anim had fully counted up.  So, on one of those machine ROMs, you at least know, that the code/function call that ultimately adjusts the payout %age is called precisely at the end of that anim. 

So, you could use a debugger trace or something to try figure out what's going on during that phase of execution.  It may be a standard function that adjusts the IN/OUT... or it could be that it calcs that revised %age to a blackboard.  If I had to guess, I suppose I'd think it might be the IN/OUT adjust, then perhaps a blackboard refresh.  And then for subsequent spins, I'd also expect the live value and/or blackboard to be adjusted.  As presumably it doesn't go on money inserted, but money 'played'.  So it might also take place at the start or end of each spin.  Not sure if that helps, but that's some initial rum-fuelled thoughts lol  

Final edit  :  while this may sound pessimistic, if you found a way to do this on say a Barcrest MPU4, you'd probably then be able to search for that same code 'signature' on other Barcrest MPU4 ROMs.  A lot of the code is simply copy/pasted between different games, for example the code that 'scrambles' the lights based on the Characteriser chip, it's just the exact same routine across a lot of the Barcrest MPU4 games (or variants of that code, again repeated).  They weren't writing the machine's code for specific common functions (i.e: lamp scrambling, compensator or in/out tracking) from first principles for each new MPU4, and I'd imagine that extends to other manufacturers/platforms.

Edited October 2, 2024 by johnparker007

[Mort]

Thanks @johnparker007, I understand all that you are saying here. Leave it with me!

[Mort]

Here is a great post, I get it out and paste it every so often, to remind us all how these things worked, it's from EdwardB

 

https://www.fruit-emu.com/forums/topic/53948-fruit-machines-inside-out-compensation/

Hi All
 
Decided to write a some articles about how real fruit machines work. In today's lesson, how fruit machines would control themselves, i.e. how decisions are made to pay a prize (or not).
 
BFG/Mazooma called them "compensators", Barcrest "stablisers", Ace/JPM "reflexes", Global "buckets" and 101 other permutations of the name. They all mean the same thing; essentially an amount of virtual money held in memory that the game uses to decide how much money we can give back to the player.
 
As I learned this stuff at the University of Mazooma, I called them "compensators", and that's what I'll use for this post.
 
How they work:
 
A game has a number of compensators, decided by the developer and/or mathematician responsible for the game.
 
Each game, we put the target % of the game into a compensator. So if the game is set to 80% payout, and you're on £1 a game, 80p goes into the compensator, and the other 20p is forgotten about.
 
A compensator is viewed from the player's perspective, that is, if the compensator is negative (hereafter referred to as -ve and positive as +ve) then the machine owes "the player" money - it has "underpaid". If the compensator is positive, the player owes the machine money - it has "overpaid".
 
As a side note, Barcrest worked the opposite way (from the machine's point of view - +ve being underpaid, -ve as overpaid).
 
We divide the compensator into "levels". The size of each level depends on various factors, again usually determined by the developer/maths person.
 
Let's see an example:
                                      |
          0------1------2------3------4------5------6 Compensator Level
                                      |
+2500  +1000  +500     0    -500   -1000  -2500
 
So Level 3 is our midpoint - the compensator has ZERO money in it. But that doesn't mean you won't win. Quite the opposite.
 
Now we play some games, we stick £10 in and we win nothing. Now our compensator is -£8 (we took 80% of our stake, remember, the other £2 has evaporated!), we are there now in level 4 (between -£5 and £10). 
 
But how do we decide if we're going to win? Easy. We use a chance table! 
 
Let's see those same levels, but this time we're going to assign a % chance of something happening:
 
£2 nudge win chance:
                                      |
          0------1------2------3------4------5------6 Compensator Level
                                      |
            1      3      8      15     35     60     80 (% chance of winning)
 
As you can see, the chance of getting a win (or maybe of getting the feature) is adjusted depending on the level of the compensator.
 
Chance tables controlled almost every aspect of the game; the likelihood of getting nudges (losing or otherwise), the likelihood of holds, features, even to the point of choosing which music to play (the more money we have, maybe we play a more "intense" bit of music?).
 
When a win is given, assuming the player collects the win, we remove that money - £2 in this case - from the compensator (after which is still in level 4, now) and carry on. If they didn't collect the win (gambled, and lost) then we don't do anything - the machine still needs to get rid of that money at some point. When a compensator is at zero, the machine should be bang on payout %.
 
The money in a compensator has no relevence to the physical amount of money present in a machine - so if the hopper is full or empty makes zero difference to how likely you are to win (or not). So those urban legends about "the machine is backing" (i.e. coins going to cashbox) and therefore due to payout are nonsense, but we all had a good laugh about it!
 
Most AWPs, certainly ones we did, had 1 main compensator for general gameplay, and 1 for big wins. We would then divide the 80% into the two compensators, maybe 80% of 80% (are you following?) to main, and 20% to reserve. Once reserve compen had reached our target value, transfer the whole lot to main comp (which then shoots up to level 6 - super generous!) and get rid of it. Maybe set a flag to say "big win time" and force a red mode or jackpot repeater.
 
Believe it or not, often, the more simple the game (lo-tech/Bar-X) the more compensators there were. From memory, some of our lo-techs had 20+ compensators, all receiving a small % of the stake each game, and then use to pay for things happening in the game (multiple streaks, hopper-emptying wins, etc).
 
Hope that's useful to some - let me know of any questions!
 
Oh I should have said - most games had a bell curve, that is, the game spent the majority of its life in levels 2, 3 and 4. Rarely getting to 0/1/5/6 as these were the extremities and only happened when someone was very lucky or you had someone forcing the machine to high levels.

Hi All
 
Answers to your questions:
 
ritdav: "That was really interesting.First question coming up.Emptiers were they mainly badly written code or were they always deliberate.Reading the above they would have to be beyond the compensators to work .What were the legendry ones and were people fired over them.If you can't talk too much about them thats fair enough."
 
Almost always mistakes. Never intentional apart from one guy at Ace who decide to try and make a few quid by putting an emptier in. He got caught in a pub, fired and prosecuted. I think he got 2 years for fraud. That was on an old SP-Ace club machine.
 
Were people fired - generally no, all software has bugs and fruit machines are no exception. The famous ones, like Donkey Kong, were just oversights (nudge debugging code left in by mistake).
We had an emptier on one of our games, where changing stake should have cancelled holds, but if you were quick enough you could hammer the holds and change stake at the same time. Oops!
Simple fix.
 
When you get a report of an emptier, all hell breaks loose. I did 18+ hr days just playing the game, trying to work out what was going on based on (generally useless) info from the site. You also pore over the code and look for anything awry.
 
Guitar: "An actual question for you though, where do you get the random values from on a machine with no RNG fitted?"
 
Good question! Believe it or not this was on JPM's standard interview question for software engineers. So we had a mixed prime congruential RNG but I suspect most people now use a mersenne-twister RNG. This was in the core libraries for games so we used that. But to answer your question; if for some obscure reason you had no RNG, then you write one, or you use inputs to generate random numbers, maybe timers of button presses, or system timers. I can't think of any library I've ever see that didn't have an RNG though. They're pretty fundamental to gambling!
 
evo1: "On an offtopic question when you played with tokens did the machine play on a different cycle/% cause again never really got any return on token play"
 
Yes, token payouts were typically in the 50% to 60% region. 
 
fuzion: "A lot of people I used to play with referred to compensators as pots, even a lo-tech game like Golden Game had quite a lot of separate pots to play around with."
 
Yes indeed - those lo-techs had about 20 compensators. My first ever bit of fruit machine code (aged 17!) was doing the attract mode for Golden Oldie. Attracts were written in a sub-language to make them quicker when writing lamp sequences (all done by hand...time consuming!). If you watch the "ripple" on the button lamps, you can see that I missed out the Start button further on in the sequence. That was also in every other Mazooma lo-tech - makes me laugh when I see them in a seaside arcade even now!
 
wizard: "I think a lot of the emptiers arose due to a "Free Win", my understanding of this is that a Free Win didn't update the compensators when it should have done, leaving the game in the same happy state."
 
Correct - the win wasn't removed from the comps, or in some cases the win was added to the bank, and then some visuals happen, before the win is removed from the comp. So, obviously if you switch the power off during those bank pay visuals, the win never got taken from the comp and hence a "free win". We never had this problem as the line of code that adds the money to the bank is always immediately after the win has been removed from the comps, and also we separated logic and visuals entirely. You'd be amazed the number of companies that didn't - and were always the ones with problems.
 
fruitman69: "Not really, anti force code normally will monitor certain variables, if forcing is detected then it would set a flag"
 
Actually, in my experience, what people termed anti-force code actually wasn't. It was anti-stats testing code! Manufacturers used to buy other manufacturers machines and play them, log every spin, and work out what the game was doing. I remember visiting Maygay in 1996 and seeing a Barcrest 10 out of 10 being stats played. So what everyone did, was monitor the last, say 200 coins to go in - if they were all £1 coins then you mangle how the game plays. Still hits % but plays differently. Obviously in a pub you'd get other coins inserted, so this would never happen.
 
wayne123: "Thanks for the info - love to read how the fruit machines have ripped people off - strange question but is it possible to look at an actual programme for a fruit machine ?"
 
Yes, I will be releasing the code for a game I wrote soon (when I can find the backups, probably in my attic!). It's a Hungarian AWP but still very similar to a UK game (dual lapper board, etc).
 
shaun2097: "also, a while back some red gaming fruit machines used to put the first £3 or £4 you inserted stright to the bottom cash box"
 
Correct! We spotted this whilst stats playing one in the office one day. We thought like you did - was just to suggest to the players the machine was "backing". Found no evidence of anything else.

Hi, not much I can add to what I said previously. We knew from site data a rough number of each coin type you'd expect for a busy pub, and so from that you can work out how many £1s vs 10p or 20p etc you'd expect in a given time frame.
What we did was simply not divert any money to the streak compensators until we'd see another non-£1 coin go in, so you'd never get a streak, and that's one of the main things you want to know - how often does it streak, and for how much?
We also mangled hold after losing nudges and other "cheats" to just make the game play poorly. We tracked how often this happened on site - and we got our numbers pretty spot on because it was very rare.
 
Everyone stuck the change from a pint in, so lots of 20p, 50p etc coins went in, so it never happened on site really.
 
I know Red Gaming did it too, we logged a machine for days on end with only £1 coins and it played like a proverbial. 
 
Hope that's useful.

[Mort]

11 hours ago, Chopaholic said:

Are there any clues on dates inside the ROMs @johnparker007? 

Going from the endlessly useful list from @jason, we can see that the £3 jackpot was running from early 1984 to early 1987, when it was increased to £4. Which would make this a pretty early MPU4 machine I believe. There's a £4 version of this machine called 'Grab The Bank'.

Hi Choppers, can you link me to the post for all this please ?

[johnparker007]

That was a very interesting read, thanks @edwardb and @Mort  

I'm not sure if this:


...means discrete levels (as opposed to algos with a fine-grained input); if it is discrete levels, then this from Smash & Grab makes a lot more sense:


(5 Barcrest 'stabiliser' levels).

Also, nice to read this:

ritdav: "That was really interesting.First question coming up.Emptiers were they mainly badly written code or were they always deliberate.Reading the above they would have to be beyond the compensators to work .What were the legendry ones and were people fired over them.If you can't talk too much about them thats fair enough."
 
Almost always mistakes. Never intentional apart from one guy at Ace who decide to try and make a few quid by putting an emptier in. He got caught in a pub, fired and prosecuted. I think he got 2 years for fraud. That was on an old SP-Ace club machine.

There are lots of theories about at least some of the bugs being intentional, it sounds like that was actually quite unusual, if coders who got tempted to the dark side were getting hit for fraud, by including some spicy code, and then caught directly using it.  However, I could still imagine that a coder might include a spicy 'believable' (but still exploitable) bug, if he had connection in the players scene (so they'd buy the bug, and he'd never actually use the bug himself in real life).  The old adage of 'don't get your hands dirty'.  So those ones would fly under the radar as innocent bugs... so there's still life in the theory yet!

Fascinating stuff  

Edited October 2, 2024 by johnparker007

[johnparker007]

Thinking outside of the box for a future Oasis feature, I guess you could have something like an 'enhanced stacktrace analyser'.  So then you could capture a stacktrace in Oasis (from the MAME backend)... and you could capture a start-> duration of spin sample, and then a duration of spin -> end of spin sample (on hotkeys/menu option).  It could then filter each trace by subroutine jumps (so it'd capture say all the JSR instructions with accompanying RETs back to the calling PC).  Then within Oasis, you could compare with a execution style diff tool, so that you could get a list of the unique function call addresses that were present at the duration/end of spin, that were not present at the start/duration of spin (as an example of what you could use this for).  That would be very useful in trying to do an analysis like we mentioned above, where you want to see which subroutines are unique to the end of spin (or end of win animation) - i.e: finding the calls that update the compensator on whichever tech.

MAME has a debugger, but it's command line based, and to be fair, much less user friendly that Chris's GUI debugger in MFME.  A hybrid could end up being more user friendly than either of those, with built in 'Datel Action Replay' style functionality, such as tracking incrementing/decrementing values (that could hook into MAME's existing debugger cheat functionality I guess (https://docs.mamedev.org/debugger/cheats.html), though it would probably be better to have Oasis roll its own integrated system, rather than a mish mash of Oasis native vs MAME native functions for execution analysis).

On some of these older techs like MPU4 they have so little RAM, it'd be like shooting fish in a barrel   ...compared to say a Commodore Amiga (where I first used a Datel Action Replay) where the writable address space is orders of magnitude larger than MPU4 (I'm assuming Impact and maybe even Sc4 is similar).

Interesting for future edits to MPU3 gamble blocks, compensator writes, and the like...

Edited October 2, 2024 by johnparker007

[Chopaholic]

1 hour ago, Mort said:

Hi Choppers, can you link me to the post for all this please ?

There's a whole video about it  

The thread over at Jackpotty is called 'Historic Jackpot Amounts' - Historic jackpot amounts? (jackpottyforums.co.uk)

The thread here at DIF is this one - 

 

And this is the specific post where @jasonc put us all out of our misery  

 

[Mort]

" BFG/Mazooma called them "compensators", Barcrest "stablisers", Ace/JPM "reflexes", Global "buckets" and 101 other permutations of the name. They all mean the same thing; essentially an amount of virtual money held in memory that the game uses to decide how much money we can give back to the player. "

@johnparker007 It's possible I could look at it from this angle, try to find where the 'virtual money' is stored in RAM, and then by raising this at any given point, it would have the impact of raising compensator and chance table(s).

It also makes me wonder on whether we sometimes screw up the compensation table values, by the way in which we use AutoPlay and force play to build up such huge drifts. Depending on the coding of the 'virtual money' it's possible we even break compensation tables entirely. Depending on quality of the coding it's possible you could end up completely adrift of the table itself, almost stuck in a limbo case of being in a poor or neutral position. All just theories of course, but makes you wonder. I guess in the case of some examples we have seen, the value just get's stuck in the various compensators to a really high level. Like in the case of Super Blackjack, when you needed then to take the value out over a long period of time, across different features to return to RTP.

As I have always said it would be amazing to see a  proper breakdown of source code, especially for a machine we all know. Even if it was a form of pseudo code, it would be good to see it. I'm still amazed nothing like this has ever come to light, especially with most of the manufacturers out of the business now.

Edited October 3, 2024 by Mort