johnparker007

Maybe a little Romeo Knight for your playlist

Yeah, that of course is ideal I was just thinking, where you have people who have home collections, or places like the Mr P's arcades... or privately owned old seaside town arcades that might allow some scanning in exchange for cash... As it wouldn't involved taking photos in the arcade, which I can understand some arcades are against, so as to protect the privacy of their customers... it'd just be like a laptop/netbook, a hacked up flatbed scanner on a long USB, and perhaps some kind of powerbank setup. Then you could turn the machines off one at a time, and work your way around. I'm guessing the Miami Dice glasses you scanned turned out basically perfect then? So, evenly lit, no 'flash-burn' type artifacts, very high res? And in focus? As the scanner expects the sample to be at the distance of the scanner glass, but in practice it's a little further away due to the additional thickness of the fruit machine glass. Of course, with removing them, you also got to scan the mask on the back - this idea of the portable scanner would just be limited to scanning the front artwork, the masks would need manually building... In the vpinball community, they certainly struggle far less for decent source art these days... though there were also far fewer different pinball machines built, whereas fruit machines they just churned out, and they were also region-specific so I guess that is always gonna be the bottleneck on high quality art... too many machine variants to be able to get physical access to them all to do decent captures.

As per the title, was wondering if any experiments have been done with scanning machine glasses with ideally an A5 scanner (delidded). So you'd use a flatbed scanner like this: And delid (ideally it'd prob want to be an A5 scanner to fit flush inside smaller glass areas), with as small a bezel as possible on at least 2 of the four sides). Then it can be placed facedown on glass of machine (switched off) still installed in machine, and would in theory provide very high quality scans (that would need some skilled stitching to reassemble)... compared to unevenly lit photos. Or, maybe it wouldn't - perhaps reflections of the scanning light on the fruit machine glass would be an issue... I remember mucking about with A4 flatbed scanners in the 90s so there must be plenty of cheap old used ones out there, so perhaps a cheap experiment to hack one up. Then of course you'd need lots of fruit machines to scan though I've looked into the modern handheld ones that you manually move over the subject, they generally seem crap (distorted output as the tracking is inaccurate). A stitching of flatbed scans of an off machine seem like they could be perfectly stitched if care is taken when scanning wrt alignment etc. Edit: very brief look on eBay, A5 seems rare, used A4 seems as very cheap as expected (so no real loss if hacking it up goes wrong) - example of very cheap A4 used scanner that could work: 3 out of 4 sides have relatively small bezel... you'd still lose maybe 1cm on the edges, that'd need to be stitched in with photos I guess - maybe it's all a bit complicated - though if you had the cooperation of someone with a large collection of machines, you could end up with potentially very high quality source images (without having to do anything to the fruit machines, just scan the glass while still installed).

At some point this is a plan for an Arcade Sim 'cabinet mode' feature... as I'm already rendering them in 3d, I can map that to say an upper and lower monitor or whatever, so it would mean no need to manually edit layouts to make them 'cabinet friendly' etc. I'm sure it could drive out images to buttons... though I've millions of things to do before that would be a priority unfortunately. But it's all possible It's a shame it's so expensive to get a touchscreen 42" TV... that is something that would be good to help with the experience... small touchscreen monitors aren't too bad but large ones seem to be uncommon and expensive.

Looking good I suspect these aren't cheap, but one day I think these OLED push buttons would be great for a fruit machine cabinet if they are cheap enough in the future. So it would show the actual button decals for the machine currently being played (and black when not needed for current machine)... https://www.4most.co.uk/switches/lcd-oled-switches/oled-switches

MFME does this occasionally as internally it's mainly written in the old school C way (unmanaged aka unsafe code). Unless you are super careful when programming in this way, it's really easy to do stuff like 'trash memory' or 'corrupt pointers' etc, which results in these types of errors. There's nothing that can be done to fix this I'm afraid. In normal use, ie. when simply playing layouts, it happens very rarely (less allocs, more battle-tested code) - compared to editing layouts (which involves more allocating/deallocating memory/pointers etc), so it's not much of an issue for end users playing layouts

Bugger me, I do remember that! It was like a piezo-electric ignitor from a lighter, but then the stealth angle was attaching longer wires inside a coat sleeve! Not sure why we needed more than a single wire, thinking about it now - but yeah, so then if the arcade owner comes along, you've not got a clicker in your hand, I think we were doing something like having the wire attach to a metal button on the end of the sleeve? So then the coat would look totally innocent. Or maybe it was just the bare wire, which is somewhat suspicious anyway! I'd be better at making things like that now, I have tons more electronics skills than when I was 17, I only really knew about bits of computer programming back then...

https://www.gokkastenarchief.nl/online/?gokkast_kabinet=barcrest-87 This 'Barcrest 87' mentioned on Dutch site above might be an official name for some of those older Barcrests (they all look the same wooden outer cab on that page), if not, it can be adopted if no real name available. We're just trying to get to some sane cabinet categorisation, to put machines into, as the AS project grows Building cabs is on hold, as Spa has found more new official names in his flyers collection - so getting it organised. When we don't have an 'official' (ie. printed on flyers by the manufacturers) name, internal logical names are still good... but if there is the actual name available for a cabinet type that is nicer

Usually less talk in the manuals about the cabinet, compared to the flyers, from what I've seen so far (perhaps because the games are somewhat cabinet agnostic?). I've been going Spa's findings from going through his flyers, and then regoing over more myself, trying to make a more organised version of the Cabinets sheet in the database, making some progress (though they slightly changed dimensions, even in the same lines of cabs) I think it's the Trad' / Trad Cab? There is one that is also a 'flat top' in this style and era, that has a slightly taller coinmech, still embedded in the glass - still meeting the top and right corner of glass edge, I think that is the 'Slimline'. And then there is the other very similar flattop cabinet of Club Tropicana, and that is the Highline. (Taller, and Coin mesh doesn't meet top side of glass, only right side). (Can't find flyer right now:

Just got back and watched your video, awesome overview of the new video game stuff and the project in general - thanks for making it! One plan is to get a few static screens per video game that they'll cycle through (along with the sounds as you hear it now) when attract videos are turned off, so users with weaker systems can still have a fairly immersive experience... and also some other optimisations are planned that should bring down the CPU & GPU load a little. Also in the future, I may be doing something so it can stream textures from the hard drive (like how Grand Theft Auto 5 does it)... so then there'll be less demand for VRAM (and general system RAM), so hopefully will be able to keep it accessible for most people, even with limited RAM/CPU (so it would load a very high resolution copy of a game marquee, fruit machine reel etc only as the user gets close enough to it to be able to see the detail).

Try: Menu > Design > Edit Mode then Menu > Configuration then change Audio setting from Stereo to Mono Right: Then close window and play machine and see if you have sounds. If you do it means your PC speakers are only playing the left channel for some reason (unrelated to MFME) - you can check this on a website such as https://www.audiocheck.net/audiotests_stereo.php

Been checking out a couple more of his while doing my work - here's one where he's using his usual beeper engine for the pads etc, but is using the 128k AY chip for some amazingly realistic (for a Speccy) snares - never heard that approach before! Doesn't use the 128k AY chip for any tones - just the snare instrument.... Admittedly 128k only, but those snares sound lit ...and as a bonus, at the end it jives into a remix of the Chronos music above, but with the awesome layered AY snares... this guy is a bit of a legend, thanks for the heads up!

I've seen the various more modern zx beep trackers (no stranger to tracking myself, spent many an hour on the Amiga noodling away!) ... this one is a little more basic I think (it is from '87 before there hardly was a 'scene'!), but the actual song is also really cool Pads work very well in this one... to write one this good, this early - guy had serious skills!

Good point about the dynamic difficulty man - I don't remember actually playing Apidya much myself (I had a copy for my Amiga) - it was just a wow fest on the gfx/audio, I was always particularly intrigued by the additional sound channels. Back in those days, it was more a case of 'git gud' - it was hot on the heels of the Speccy and C64, and they had some shocking difficulty issues on games!

Great music from Chris Heulsbeck on this one, gets more then the standard 4x Amiga sound channels using his custom audio engine

It's a really novel idea using the casino cab, instead of standard jamma type

Oooh F-Zero GX - I sunk quite a few hours into that, along with the various Wipeout games XG3 is also a nice little futuristic racer on the GC (better gfx than the PS2 version iirc).

On the MPU4 I've seen some routines that really seemed to jump about more than is necessary - I'm not a machine code pro, but it certainly felt like it had been intentionally obfuscated to some extent! Although thinking about it, he could've been referring to the 'dummy signatures' - on some ROMs (can't remember which right now), they have a bunch of copies of the old style sig that don't do anything, meanwhile using an alternative - might've been Blue Moon...can't check right now

Which machine has the poor play please? And how easy (and quickly via a playthrough from a cleared RAM) can this be replicated? If this can be gotten down to a reliable STR (steps to reproduce) This is longterm, as I have to wrap up the basic version of MPU3 patching and get back to Arcade Sim tasks, but if that behaviour does not repro in MFME, using an unpatched ROM, then that would suggest that 'perfect' patching is ultimately possible (hopefully via stealth patches that fix checksum in junk bytes etc). I'm already aware of some test machines with good STR (using a unstealth patched ROM), but more would always be welcomed! So then these STR can be used to objectively verify (or not as the case may be!) whether the stealth patch ROMs work correctly, initially on emulation, and then on real machines. It's a fun corner of the scene, that still needs work - and we can hopefully save lots of machines from the tip, be it via PIC chip type replacements, or stealth patched ROMs... these Chr chips are going to keep dying/getting lost...

I had another thought so if this: the other way is to patch the rom and put up with the poor play the machine gives were the inescapable fact due to these extra values you seen when you probe the Chr out of circuit, that would mean that all the long term percentages would be wrong in MFME when people play machines that don't have emptiers/exploits, or leave them on autoplay for a long time. If it held true that the simplified model that MFME/MAME use to provide the expected values to the ROM code were erroneous and causing poor play, then it'd be easily seen and repeatable, with massive 'drift' from the expected payout percentage. If this is actually repeatable, so there's an MPU3/4 machine, that when run in MFME on autoplay for say 1 day, has a very large drift from the expected payout %age, I'd like to know about it, as it could be a way into improving the emulation accuracy! As far as I'm aware though, these big drifts from expected payout %age don't occur... which would seem to mean that the 'hidden' tables you are detecting via probing don't make it into the wider running codespace. My theory is (currently) that weird behaviour like this is down to these patching techniques (that I'm also using)... and could be remedied with stealthier patches, to be investigated when I next get chance to work on this after another chunk of Arcade Sim work. We'll get there in the end!