johnparker007

Indeed, I messed around with a little coding experiment on it, the 2600 has a whopping 128 bytes (not kilobytes; bytes!) or RAM. You have to do it all with the playfield/object drawing hardware and beamracing - good results can be attained, but only if you play to its strengths, and design accordingly The Speccy on the other hand was a fairly versatile little beast for the price.

Ah yes, seems like the only workaround fix for MFME might be if your 3rd party audio drive software allows you to swap the L/R channels. Apparently that was more a thing in the past, not so much since Win 10 level drivers. Then you could temporarily swap the channels while playing an affected machine (but you'd need to remember to swap them back afterwards!). Just an unfortunate oversight I suspect, when Chris was unifying the 'Sound' and 'Speakers' settings into a single overall setting (missing an additional new 'Stereo (Swap)' option in the dropdown).

Regarding this are you saying there is a machine where it does output in stereo, but the L/R channels are flipped? And so you can tell in a sound test mode, if it says "Left" out of right speaker, then says "Right" out of left speaker? In that case, that sadly would be a bug, as he would have needed a fourth setting: Stereo (Swap).

Just to defend Chris's coding honour here It's not an overall a bug in his emulator, it's just a little counter-intuitive to understand the meaning of the setting! From my earlier comment regarding this here: So if you followed that explanation, which probably could be written more clearly haha You see that his work is correct, it's just that you are trying to tell MFME how the machine audio was originally coded and subsequently wired, not how you expect to hear it. Hope that makes sense

If you grab a newer PSU you'll have plenty of spare 5V/12V outputs after CPU/GPU/Mobo is supplied for exhaust fans etc - good luck with the build

I know you went for a new PC in the end, but I've done a few MAME cabs over the years, and mounting the motherboard bare on the side wall of the cab interior is a fine option - plenty of space then for heat to vent off too without noisy fans. On old arcade games that's exactly what they did, just had the JAMMA board mounted onto the plywood side of the cab. No real reason for a second casing - plus if you hang it/mount it on sliders, it's easy to detach for maintenance Just fighting the corner for PC motherboards naked in arcade cabs! I am revisiting my (landscape, video) MKII mame-converted cab at some point, and unless I get too tempted by the MistR with Jamma, I'll be mounting a newer I5 mobo in the cab with a firmware-flashed AMD for arcade frequencies (may sell the Mortal Kombat II board as I'm doing it if it still works, they seem to have crept up a bit in value)

Getting there with the smaller first UI change task, switching to native OS menus Out with the old ones: In with the new ones:

As above, MFME source is lost as the author has passed away (Chris Wren RIP). There is indeed slow but steady fruit machine emulation work happening with MAME, it is fully open source, the code is here: https://github.com/mamedev/mame I have started a project that will interact with MAME to allow designing/playing 2d/3d machines (fruit, but also any other machines), also open source, but very early stages and I'm not up to putting much time into it at present, though hoping that will improve in the future, code is here: https://github.com/johnparker007/Oasis Are you a coder?

Small tech update on this project... been getting small amounts of work done here and there with it, started to build a UI Form for the options for MFME Extraction, and decided it's still not a good enough foundation for the UI. All these cross-platform non-native UI solutions have issues, here the problems that are becoming clear are: - awful to design forms in, it's built off the old WinForms system. It isn't taking advantage of Unity's UI stuff at all. - it is crap for resolution-aware scaling, and people use there computers with 16:9, or 'Ultrawide'.. or even in Portrait etc. Plus a Form in 1080p would simply display at 1/4 the size on 4K, and dynamically sizing docked/undocked panes would also not scale the contents. These things are going to be very hard to back-implement down the road (since Unity UI has already solved some of this), so I'm setting the project up for having a perpetually crap UI, which isn't good when it has: - a Layout Editor (for designing 2d and 3d machine 'layouts' - a Machine Editor (for importing 3d models to build the 3d machine cabinets) - a Level Editor (for creating environments contains machines, such as arcades) That's 3x the pain, as they're all Editors requiring Editor-style UI... so for now at least, I'm planning to: - change the top bar menus to be OS menus (so this will be working in a nice usable way on Win / Mac / Linux) - change the window content to be based of a basic framework I found in an open source Unity Runtime level editor project. It's very basic and missing a lot of stuff, but, the bones are good from what I can see - and will allow for a much better end result, with far less pain when creating more UI stuff, as it's based around standard Unity runtime UI techniques So pausing on looking at MFME Extraction feature, and replacing the WinForms style UI with those two new UI approaches. I have worked around implementing as an MVVM pattern fortunately, as I thought I may end up doing something like this down the road - so the work so far (Emulation control, machine extract importing, layout rendering, emulation input) isn't intertwined with the code that renders the UI - it's all pretty much decoupled. So it'll take time, but as there's no spaghetti code, it should be relatively straightforward

Paul-Arnold has fixed the long-standing regression with meter error on boot on sc4 (and MPU5 not yet working): https://github.com/mamedev/mame/commit/4479bd973106b42b0cfecbd531101d532631ecb5

So does it work that whatever number it is on at the start, that is the number it times out on? I'm only vaguely familiar with the machine (used to pay it as a nipper) - are there other features on the board that allow a number reel timeout, and if so, do they also have the same behaviour? I'm reminded of Adders & Ladders (and probably Hyper Viper?) where when it gives you 'Even to continue' on the ?, that will also land on an even number when it's even at the start and left to timeout... however, I don't believe it can be used to actually exploit any emptying afaik.

I guess from my limited knowledge of how these exploits work, is; if you can get it so it's ready to get you near the £6 at the end of the feature trail, can you land on Pound A Round whilst on a 6+ often enough to gain an advantage (assuming that win doesn't count against feature board %age, so you can keep getting back onto that feature square). Followed this post, interested to see if any kind of advantage over standard percentage payout could be found, that'd be kinda wild (Reel Fruits won't be happy if there's a shiny new 2024 Andy Capp emptier haha, we'll have to write a custom patch for their ROM!). Edit: I think on JPM Indiana Jones, the value of the next move is already in RAM before the number reel spins from the user input (or you can patch it mid-move), if a similar thing is present on this machine, it could be a way to see if it's getting the £12 repeatedly without affecting percentage). Here's a @Chopaholic vid showing controlling the numbers moved on Indy, different tech, but might be an angle for testing some of this idea in the emulator:

Goddammit!

Googling: Andy Capp "Pound a round" The only result is this post, so if you found something, it doesn't seem to have been talked about on public forums before. Be crazy if it could be leveraged to find a new unpatched exploit in 2023

Improved rendering of segment displays (more readable now), add alpha duty voltage support (fade effects):

Little bonus vid of playing some Andy Capp now I have those two displays vaguely functional. The sound is too fast, that's actually my fault! I recommended an xtal freq be changed in MAME for all MPU4 (to fix audio speed on Adders and Ladders), I think it turns out that if there's a sound card with samples, the xtal should stay at original speed (Andy Capp sound was working correctly before my change - oops! ). Also wins count up very slowly, I think this is due to the program waiting for sample completion, but that is not coming through at the right time, so again a sound related bug. Anyway here's a little gameplay in the Layout Editor (even though that's not really its purpose! )

Little bit hacked in for now, doesn't look great but it's working - it's a new 16 segment alpha renderer for the Layout Editor. Each individual segment is driven individually (the AS version worked via 'fonts'), so should somewhat futureproof for non-fruit machines from MAME in future... haven't done the variable brightness effect yet:

Those instructions from @SomeRandomGuy's example above are showing where the disassembling is wrong, that's why they look odd. Once the word is set to define bytes, everything is opcode aligned again and the cp a, pop af are gone.

Good to see you around man! Yeah damn I forgot about opcode alignment issues, with data peppered through the rom - good examples you posted So no one-click perfect solution unfortunately... And yeah feeling a bit better at the mo ta, so back to some light dabbling with FME dev! Next thing to sort out is these alpha displays...

I've not actually used SkoolKit ever, just one that sprang to mind - as I mentioned above there could be better ones. If I remember I'll have a look when I next am doing some FME stuff... Something like this might also be good or better: https://github.com/toptensoftware/yazd though you'd have to build it yourself. Not sure if more user friendly options out there. You want the disassembler, to generate a text file from the non-blank parts of the rom (or NOP the blank areas) containing the assembly code ('LD A, 0' etc). Then an (ideally matching) assembler, that can take that text file containing the assembly, and build it back to an identical binary file again. Once you've got that workflow sorted, you are good to go with commenting, changing subroutine/data addresses to labels etc

Yeah if you can get it looking more like: LD A,0 etc... rather than raw hex, and then be able to 'recompile' it again... i.e: more like simply translate directly back to a file that you can put back in the rom, and it is exactly the same. If you get to that point, then you can start adding comments to the code: LD A,0 ; reset nudge count to zero etc... and things get a little less crazy. Then, when you have absolute addresses for jumps and calls, like: CALL $ABCD etc... you can put labels at the point that compiles to $ABCD, so it'd read more like: CALL ResetNudges ...and the reset nudge routine would look more like: ResetNudges: LD A,0 RET etc. You don't have to do this of course But if you really want to own that code, and potentially rewrite large chunks of the machine, that's the way to start going about full reverse-engineering it. It's a super manual process though, I've only done a teeny little bit of that really - I end up handcompiling the hex! There may be other good Z80 disassemblers/assemblers around, that SkoolKit is not necessarily the best one, just one I remembered. Good luck