johnparker007

Hiya @captainhaddock Thanks for those high res images! ...I'm just wondering, as I've seen your name on a lot of layouts over my years of tinkering with FME projects involving the layout collection... do you have a collection of images in decent quality like the ones above, for other machines? The reason I'm asking, is that if so, I'm wondering if I could be cheeky, and perhaps ask if those could be shared onto the 'Community Drive'. It's a public google drive (so anyone can view/download the files to work on new high res layouts) I have setup, and given various scene members admin access to: [ Community Drive ] The drive: http://tinyurl.com/yckze665 (link above copied from my forum signature) We've generally been putting high quality art assets on there, for future layout resources (I may revise that at some point, so each machine also has a 'low quality' subfolder, since sometimes some useful information can be gleaned from having more photos even if blurry etc). No worries if not, but I thought I'd best check! If you do, me or one of the other drive admins can put them in the relevant folders in the 'Archive' area... or also, I'd be happy to add you to the list of Admins, so then you have full write access (we can sort that out over DM), if you'd prefer that. Thanks for your many layouts over the years

I've done the upscale and placed it in an 'AI Upscaled' subdirectory on the drive. Direct link to the file is here (upscaled from my higher quality original image), this should be pretty much good enough for a 4K layout now (some small text may need a touch up), as the source image was good enough quality https://drive.google.com/file/d/1Jz2BgGk80sb0753ADKswi4Oe5qrTsUW4/view?usp=drive_link

I have just added a slightly higher quality version of this image to the Community Drive: https://drive.google.com/file/d/1k7N4dVX4kzNhI9zolZkq69D7oLNJA7Iw/view?usp=drive_link Looks like a good candidate for AI upscaling, would recommend a 4x using Upscayl Photo Ultramixed Balanced. May need to retype some of the smallest text, good luck

I've just heard about this device: They are LCD rather than OLED unfortunately... but if one were to build a 'tiny cab' this thing could be on the bottom, and contain the button images for the game you have loaded. And with a bit of software you could perhaps even hook up the rom-controlled 'flashing' effect, maybe by having an dark off image and a bright on image for each button. Cost is £145 for this 15 button unit, and it's a very popular and well reviewed product: https://www.amazon.co.uk/Elgato-Controller-15-macro-keys-trigger-software-like-OBS/dp/B09738CV2G/ From watching this video here, looks like it takes 180x180 image files - so I guess that is also the resolution of each button. Wondering if I want one of these for my desk anyway for the day job, looks like a pretty neat gadget! https://www.youtube.com/watch?v=nrWRzYYC1rE

Well that is certainly a novel approach! So a bit like those console streaming services. If several people want to play at the same time (on different layouts), that could get hairy, as you'd need to be running and streaming out 3x MFME windows. You can pretty much simulate how it might be, by using something like TeamViewer or Chrome remote desktop, and then you could run MFME on your PC desktop - however! You will see much better results if both the host and client are on the same network (i.e: your house). As then it won't go out onto the internet and will all be done over your house ethernet/Wifi, giving a false sense of performance. You could kinda simulate real world conditions by playing it on your phone over 4/5G perhaps.

Well this was just some very broad pointers, for if someone did want to do this system (I won't due to the time cost, as I'll be doing a system in Oasis that will work 'somewhat' differently to this (much less janky and much less straightforward to cheat! ). At the basic level, if it's working on an 'honour' system, so say everybody uses their Dif forum username as their username for the Windows-side app... then if a machine stays 'checked out' for a week or so, a message could be sent thru Dif to ask them to do check the file back in. And on the Windows app side, you'd have a button to check in the machine you currently have checked out (so it wouldn't matter if communication was lost at some point during play, they only need to be connected at the point when the click to check the machine back in again). Need to be online: Browse and check out an available machine from the list via the Windows app Don't need to be online: Play the checked out machine, launching it from the Windows app Need to be online: Check in (aka 'submit') the machine again

That is correct. The author Chris Wren sadly died, and so the source code is lost. Yes that's right. There is something on the Oasis repo that would probably be useful for this, as it's also used by MfmeTools to control Mfme for extracting the layout, and not polluting the real Mfme data in the Windows Registry. It's part of the dll injection that Arcade Sim uses - it does cause false positives with virus detection software though! The code's probably a mess, as it was a bit of a whirlwind developing all the technology to make Arcade Sim work, so I wasn't doing my tidiest work Oasis code is better, honest lol You prob do something like have a server running, or ideally set it up on an Amazon instance. That could manage the database of ram saves, who currently has a machine 'checked out' from the collection of machines (i.e: they are playing it). It could provide a web interface purely for viewing the data. It could then also provide some JSON IO stuff (something simple with plaintext GET/POST to start), that's how the Windows-side app would check out/submit RAM saves to the online database. The Windows app would display a list of the machines in the database, and whether they are currently being played by another user, or available to check out. When a machine is checked out by a user thru the app, it downloads the save, and prob fires MFME up under the DLL control, using its own copy of the layout. Then at some point the user can choose to submit this machine back to the server, making it available for others to play. You could also add some basic tracking of the meters, ensuring the layouts specifically set up for this system have them set correctly, I think it's in the .gam file where the accumulated values are recorded. So you could then give users a balance or 'high score' of how much they made/lost. This would all be extremely easy for someone to cheat on if they were so inclined btw! Editing gam file In/out totals, exiting MFME without saving the ram if they do poorly, plus other ways to cheat, hacking credits into RAM with something like cheat engine. It'd also all be highly janky, but that's a way it could be implemented in theory, if you chose to develop it

The way I plan to implement this will be that the user will be running the emulator (in this case MAME) in their own machine, not in the cloud. So for the 'arcade' version, the simplified version of how it will work is: when you walk up to a machine to play it (that doesn't have someone else currently playing it), the latest uploaded save state will be downloaded from the server, and the emulator will start up with that save state. User plays, money goes in, money pays out etc... then they exiting playing the machine, and the machine's current state is uploaded to the server as the new latest state, ready for the next user. If you get close to another player who is playing a machine (specifically in terms of the fruit machines), there will be a stream of the lamp/segment/dot matrix data, in a highly compressed lossless format. So then it'll be like how the fruit machines do their attract modes in the current Arcade Sim when you are walking around - it's just a somewhat compressed data stream, that flashes the various lamps etc. Unsure what direction to take wrt. streaming the emulated audio yet, will get into that when I actually come to implement this stuff ... though button clicks, coin payout, meter clicks etc will also play back perfectly as again it can be wrapped in the highly compressed codec as mere trigger bytes. So you'll be able to wander around and watch people actually play the machines next to you... In terms of doing something for MFME, I couldn't get into that myself, since I need to use my free FME dev time to work on Oasis... but someone could knock something up that would work like how Amber did it, so simply uploading the RAM save when the user finishes playing locally, and then the next user downloads that RAM save, and boots up the machine...

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

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!