johnparker007

On this version of Arcade Sim, you only get the ambient sound on PCs that have fast enough CPU / disk drive to support the attract mode videos, sorry about that. So without a faster PC that can support running those attract mode videos, there is no ambient sound.

Are the other fruit machines fully playable, and it's just Andy Capp not working correctly? Usually it's the '0' (zero) key to insert a coin, 'Space' to press the Start button... or clicking on the coin slots/buttons works the same way.

This I am not sure about - do you perhaps have a joystick/gamepad plugged in with something resting on the joystick? Ok so unfortunately this old version of Arcade Sim triggers a false positive in the inbuilte WIndows Defender anti-virus software. There are instructions to work around it here: Sorry for the inconvenience, the new version of Arcade Sim uses a different emulation backend which doesn't cause these issues, but it's a long way from being ready yet, it will take at least a year or more, to develop all the software. And yes, for this original Arcade Sim you do need to download MFME v20 from this site, and then also run the Updater found in its folder (as MFME is not open source). Again, in the future release of Arcade Sim (as part of the new Oasis software), all these issues will be solved so it will simply run out of the box, with no additional emulator installs or antivirus problems. If you have more issues, please tag my username, as otherwise I don't always see these posts

Unfortunately the attract videos are quite demanding. In future there will be a simpler version that just uses cycling screenshots, but for now you'd probably be better disabling the videos from the settings menu. Linked in post above with steps that should get the fruit machines working properly.

This was the comment on that page that has the steps that should fix the issue (hopefully!)

Ooh nice machines I spy a Test Pilot next door.

I did plan to do something like that at some point, may end up being hybrid so it can use MAME's existing database of cheat locations at least, but perhaps Oasis RAM controller to manage the cheats, via the Oasis Lua library that we use currently to control inputs... one day

You could use MAME's debugger to search for larger/smaller values (without needing to know precisely what they are). So you'd guess at a value type (prob an 8 / 16 /32 bit int). Start a search on a clean RAM on that value type. Then feed money in the machine, and try to burn through credits while winning absolutely nothing. After every say 10 credits, you'd then go into the debugger, and search for values of the value type that increased since your last search. Keep repeating the process. At some point if it then sprees (something like Sunset Boulevard I guess does that)... then take a few wins, and then continue the debug searches, but for values that have decreased, and do that. Hopefully you will end up with 1 or just a few addresses that match the pattern. Then you could try poking them with values, so see if it can control how 'ready' the machine is... might be a bit more to it, but prob worth a shot if you are interested in doing this sort of thing! Also - the values may instead decrease as the machine becomes more ready, rather than increase. Have fun - there's a rough video here on how to do it in MAME, if you search 'mame debugger cheat' on youtube there's a few videos, some showing searching for floats as well, though the older machines like Smash & Grab probably worked in fixed point math: Also, you could probably also use MFME and Cheat Engine to achieve similar results.

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

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

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.

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

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

Not new coding dev, but man I swear the newer AI chat models are freakishly good! Just been brainstorming with ChatGPT-4o how to best tackle the future system for our Oasis online layout hosting/management - here's a snip from later in the convo where we're comparing Amazon S3 vs Backblaze: JP: Why did you recommend Backblaze over Amazon S3? ChatGPT: I recommended Backblaze B2 over Amazon S3 primarily because of cost-efficiency. Here's a detailed comparison to clarify why: 1. Pricing Backblaze B2 is one of the most affordable cloud storage services available: Storage: $0.005/GB per month, so 200GB would cost around $1/month. Download bandwidth: $0.01/GB, which would be about $1 per 100GB downloaded. Free uploads and free listing operations (like browsing your storage). Amazon S3, while widely used and feature-rich, has higher costs: Storage: $0.023/GB per month for standard storage, which makes 200GB cost about $4.60/month. Download bandwidth: $0.09/GB, which makes it roughly $9 per 100GB downloaded. Why Backblaze Wins: For 200GB of storage, Backblaze is significantly cheaper, costing $1/month compared to $4.60/month on Amazon S3, and its download bandwidth cost is far lower ($0.01 vs. $0.09 per GB). 2. Simplicity of Pricing Structure Backblaze B2 offers a more straightforward pricing model with fewer confusing tiers or added fees. You simply pay for storage and bandwidth. Amazon S3 has a more complex pricing model with different classes of storage (Standard, Infrequent Access, Glacier), which can make pricing less predictable and harder to manage for long-term projects, especially when download bandwidth is factored in. Why Backblaze Wins: If simplicity and predictability in cost management are important, Backblaze B2 makes things much easier to estimate. 3. Features & Usability Amazon S3 is known for its robust ecosystem and a broad array of features like versioning, replication, complex permission settings, and integrations with other AWS services. It’s incredibly powerful, but many of these features might be overkill for your use case. Backblaze B2, while more limited in some advanced features, offers the essentials for storing and serving large files. For hosting assets like PNGs, WAV files, and project data, it provides everything you need with an easy-to-use API, making it more lightweight and less overwhelming than AWS. Why Backblaze Wins: If you don’t need advanced cloud infrastructure features (e.g., machine learning integration, automated scaling, etc.), Backblaze provides a simpler experience, and for your project, it seems sufficient. 4. Performance and Reliability Amazon S3: It has a global network of data centers, meaning it offers better performance and redundancy for global users, with high uptime and excellent reliability. Backblaze B2: While Backblaze operates fewer data centers (mainly in the U.S.), its reliability and performance are generally strong, especially for non-critical, large-scale storage needs like your project. For an open-source project focused on collaboration, Backblaze should offer enough reliability unless your contributors are highly distributed globally and need faster, low-latency access. Why Backblaze Still Wins for You: Given the open-source nature of your project, where occasional latency may be acceptable, Backblaze provides reliable enough storage without the added cost of Amazon’s global performance features. Conclusion: Backblaze B2 is a far more cost-effective solution for your specific use case of hosting 200GB of data-heavy files (PNGs, WAVs, TTFs, etc.). It delivers simpler pricing and an adequate feature set without the complexities and higher cost of Amazon S3. Amazon S3 is more suited for projects that require advanced cloud services, distributed global access, or heavy integration with other cloud-based systems, which doesn’t seem necessary for your layout editor project. Given that you're focused on hosting large assets for a public project and keeping costs low, Backblaze B2 seems like the better fit. Let me know if you'd like more details on how to set it up!

Nice I just got my 4 year badge about a week ago!

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

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)

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

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

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

Cheers mate, you're making me blush now though!

Thanks man And yeah, multiplayer will be cool for those mystery machine states! I've just done a quick update video on the dev thread showing the bits I'm working on at the mo

Work has been continuing on the Layout Editor, but not had chance to do an update for a bit, so here's the latest, give @Mort something to check out Video shows editing text on a lamp, and also the new color picker I'm working on - quite a lot of progress really!

100% - the basics of this are already in place There is a program in the suite; MFME Tools. This is what can perform the 'extraction' of a layout from MFME (such as this classic I'm currently using for testing): Then the Layout Editor program (shown above) can import these 'extracted layouts'. So you end up with an Oasis layout, from an MFME layout. This will all be part of the suite that users install, so anyone will be able to do this process (and the Layout Editor will be able to call MfmeTools to do a one-click 'Extract & Import'. So I think that should solve the issue of having to make layouts from scratch. Additionally, even just for 2d, there will be various quality of life improvements that should make working on layouts less painful So a big one is a proper Undo history system, that will look something like this: So you can review the operations you've done and select different points in the timeline, or use the standard keyboard shortcuts, Ctrl+Z to Undo further and further back, Ctrl+Y to Redo. Also, with the new Inspector, I am planning to implement 'multi component editing'. This means that say you want to change all of the buttons to have say a blue background instead of red; you would select them all, then in the Inspector, change the background color to blue, and it will apply that to all of the selected buttons. And of course, this will ultimately allow for the full conversion of 2d layouts into 3d machines, like in Arcade Sim... also with 3d buttons, proper lighting/reflections etc. Those machines can then be placed in a custom arcade, and played in the new Arcade Sim. Plus shared, and played in multiplayer etc. So plenty of cool stuff to look forward to, but it will all take time to develop Oh also, no more waiting for booting up machines, even a Scorpion 5 will load in around 1 second, as we will be using save states, to restore the machine to the exact state it was last in when it was exited. And then of course multiplayer and VR... the list goes on... There's lots to do (literally years of work), but lots of new cool features planned. And of course this is all 100% open source this time from the get go https://github.com/johnparker007/Oasis/commits/main/