Mort

Treasure Island Dizzy (Dizzy 2) on the C64 had a bug, meaning only 1 life lol! I think they found a bug related to the snorkel just before the game was to go into production, so they just believed it better to fix it to one life instead. It was tough, but when I beat it, it was a wonderful feeling! I think Fantasy World Dizzy (Dizzy 3) was my favourite. Wonderful times Dad, and I know what you mean about the pokes

Matt Gray is an excellent musician, he still releases stuff to this day : 6581 Records It made me think this about Codemasters, who were originally just the Darling brothers (Richard and David). Then you had the Dizzy games, coded by the Oliver twins. Released through Codemasters also (iirc). Then you had the Rowland brothers doing the 3 Creatures games on the C64 (I'm classing Mayhem in Monsterland as the third!). What a time it was to be a bedroom developer, and if you have a brother (or sister!) with the same interests, and talent!, then you had a winning formula. Shame how different things are these days.

I do remember these, but I spent all my virtual 10p's on Fruitbank, on the c64, here:

Hi Rick, welcome to the journey! I think many of us here with inquisitive minds have thought about these sorts of things and have tried to find answers over the years. Completely agree with all you say about disassembly. It's a huge amount of work, more than anyone can fully realise, and even then much of it will require some elements of guess work, and we will still not receive many of the answers we are looking for at the end of it (even if there could be an end of it!) For this, we need to look at help from the ex. real coders, by releasing the original source code, but even with this, most of us will not understand it anyway and then there are surely multiple libraries related to that source code, so we would need source code for those libraries as well, and the issue goes on. In my honest opinion, if we were going to see this, then we would have seen it, or at least some of it, by now. We have had everything in FME really except this. As for your query on meters, whether those be long-term or short-term, you have to think of them as just separate counters in the RAM. They most likely have no relation to how a game plays or what it owes etc. That information, in our compensated machines, is instead stored in the various game compensators that a machine has. It's a virtual money value, then linked to different compensator levels, ultimately then controlling the % likelihood of something happening. (e.g. a 4 symbol win spinning in, holds after nudges etc.) This post may provide you with some further insight: Enjoy the journey, but just don't drive yourself mad with this stuff!

It was fascinating to find out some of the history around the development of LN1, and 2. Mark Cale, who is the head of System 3, and main designer, built out the concept for the games originally, and wanted them in an Isometric style (pseudo 3D), which was a big thing for the C64 back in the day! Then around 1986 employed a team of Hungarians to develop it. They came up with an awesome piece of design but coded it in Forth, which is an older 1970s stack-oriented language. Whilst the concept was very much ahead of it's time, the speed of it was terrible. Each screen would take around 30 seconds to populate. It was a method which in the back end used a database of art components, and stacked them together, allowing a work around for the tight memory space of the 64KB address space (allowing many more screens per multi-load than would be possible otherwise). Eventually System 3, employed a coder, John Twiddy, who had a background in the C64 demo scene, and who also ported Ikari Warriors to the C64 for Elite. He took the concepts, and coded to the bare metal using 6502 assembly language, improving screen redraws down to around 2 seconds. I have so much respect for the coders back in the day that could do this. Ok, we have languages such as C, C++ now, but to code to the bare metal, requires such in-depth knowledge. It's common for many C64 and Amiga games actually to have been coded by people who cut their teeth in the Demo, Hacking, Cracking scene. It's awesome how, in life, it often comes down to one person with unique talents and intelligence to create or improve upon something, which then becomes a huge thing. Not forgetting the artist of course, I think that was Hugh Riley, who was also someone with special talent. It reminds me a bit of Wizard really, how a special intelligence and talent, can create brilliant things, which millions enjoy! Now I'm not saying FME reached millions, it's niche of course, but in the case of Last Ninja, it sold millions across the globe.

The Last Ninja Collection+Bonus Games on PS5,PS4,Switch, PC by System 3 — Kickstarter This is fully funded now, and closed, but I think late pledges are still possible. I pledged as soon as I saw it, but only just thought about posting about it on here. The Last Ninja 1 and 2, 3 I didn't care much for, I spent loads of time playing on the old bread bin (c64!). I recall in 1, the annoying pixel perfect jumps you had to do over the various lakes and swamps! Amazing music as well, Ben Daglish doing 1 and Matt Gray did 2. I backed a Kickstarter from Matt Gray a few years back, he re-composed much of his SID work, including Last Ninja 2. It's now hoped due to the success of this Kickstarter that we will see a HD remake of Last Ninja 1. Great stuff, such great memories! Also how could I forget IK+ as well, that's included! Loved that game and the original International Karate!. So many nice touches. I heard the coder, Archer Maclean, passed away a while ago. Real shame, the guy was coding genius, he did Jimmy White's Whirlwind Snooker as well

I recall the story about Donkey Kong and the unlimited nudges, was due to a works experience student at Maygay, who had the game for testing, with a portion of the debug code for testing things with unlimited nudges, and then the code base for that went back to the developers and got released official, with the oversight of not realising it was left in of course! I bet that was a stressful time for them!

I spent a lot of time on some machines mapping the RAM, to find locations of variables such as amount of nudges, position on ladder etc. One for way off in the future but it would be good to have some sort of cheat GUI on machines which we have mapped the RAM out for, so you can say add X nudges, X gold bars, at any time. I guess it would be just like the MAME cheat system. It does rely on a lot of hard work finding the locations, but as you say, some of the older techs, have so little RAM space, that it becomes fairly easy to watch it in real time and work it out! Certainly one which would be considered as a cherry on the top, and nice to have, but far from essential! I remember the Datel Action Replay, had a few of them for my C64, used to spend hours tinkering! Great times!

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

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

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.

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

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.

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

Nice post mate! I open MFME and play a random layout most days. It's a wonderful piece of community work spanning the last 24 years. It's very niche, many people I speak to about it just don't get it at all! It's great to have been part of the understanding people that do get it. For me it's always been about the memories, the places, people, and times it sends you back to. My memories are fading now, I'm getting on a bit!, but a dose of MFME always reminds me of those times and the people I shared them with.

Hiya @johnparker007 sorry I have been busy and not been able to reply properly until now. I think the MFME extract tools are essential and great to see you are building tools to do this. The ability to import into the 3d arcade is also amazing, as there are many machines/layouts I would love to see incorporated into the Arcade Sim. Also the Multiplayer aspect is important, I recall that Guitar built something similar into Amber, and it provided a great way for the community to share play states for machines, something which, of course, is really missing in MFME. Every time I come back to a layout it's as it was when I last played it, but it will be great to be coming to a session on a machine when I have know idea how it will play (although normally, it's very likely that @thealteredemu would have killed it!) Above all thanks for your openness and providing all the updates you do, it's great to see the work that goes into development. Looking forward to seeing the continued progress

Thanks @johnparker007. I think I say for all the FME community how thankful that someone with your genius, because you are a genius, and I understand some of the struggles you have from time to time, that you continue to look into innovation in the FME scene. I find it hard to see positives (it's in my nature!) going forward as so much has been done, and the people who care about these machines get older and start to care less of course. I want to thank you for pushing past all that, and hope you can find the interest going forward. I do worry though that some of that enthusiasm time has past us by, and during those golden periods, we saw creativity shine, in part through the addictive personalities many of us have. I hope you can find a way to make it easy to build upon existing layout work, because I fear the interest to do layouts from scratch is faded. It's just due to the time line of it all. Please keep going though, without you, I do feel this scene is lost to any innovation.

The 7-seg glow alone! Love it! I'm sure Wizard would have built this sort of effect in natively eventually. This sort of effect is subjective though of course, so maybe not something you can emulate 1:1. It's just the way I see the machine in my memory, and adds that extra bit of immersion. I know you have discussed this for Oasis @johnparker007 and of course you had it, and DOF, in Arcade Sim. The key is to be able to control it on a per layout basis, something, sadly, I cannot work out how to do with this form of injection. Classic layouts look fucking awful though lol! But again, simply press B (or another key input of your choice) to turn it off.

I'm over the moon with these bloom settings, It might just be me of course! And of course the way it looks will depend on your individual screen settings, but I really think it works well on @Tommy c 's excellent Big Banker DX. The bloom looks bloody awful on some layouts, and perfection on others (at least to me!). In my mind, this DX layout, suits it really perfectly YMMV! Big Banker (JPM).rar

Yep and remember 'Sort by Caption' is your friend to get the list into an A-Z order. Whilst the legacy gallery is fairly up to date, you would also need to look at the normal downloads area for newer releases which Geddy has not renamed yet.

Haha! I have been hoping you would notice JP. I use Arcade Sim backgrounds for all my playable DXs now. I often 'visit' the arcade on a photo shoot run, grab lots of different backgrounds, some with DOF, and also toggling the lights with 'R'. I hope you don't mind, it makes the machines (those which are not in Arcade Sim natively of course) more immersive back in normal MFME. I have the newer carpet for most of the machines now!