johnparker007

Mpu Mecca is definitely still running, may be worth giving another try, checking Spam folder etc. https://www.fruitemu.co.uk/ib/

Yeah I don't know what the solution is with MAME currently, it's all kinds of tech that's being impacted (in terms of people don't want to work on them with MAME currently as it is, and these are highly skilled emulation people, who you definitely do want working on this stuff), fruit machines is just a small part of it... going to keep to the sidelines for now!

Kind of yeah. A whole emulation project is iffy as it's a massive undertaking - but if someone wanted to say get all of sc4/5/6 fruit machines working, they might make a 'fork' of MAME, to say ScorpionMAME. Then do all the work in there, free from code reviews. But ideally you'd want someone to then merge that work back to MAME. It doesn't need to all start splintering out like that into these dedicated mini-projects, as there'll be loads of duplication of work, bugfixes not making it across the forked projects... it's really not ideal longterm. Retroarch doesn't really do any emulation development, it's just a 'wrapper' that encapsulates existing emulation projects into its 'core' format. A lot of devs in the emulation community hate it, though I can see it's utility, it does overstep sometimes with building cores where permission is not granted etc.

Yes and no... there are most cases where Cuavas is correct, and the code is not 'up to the MAME coding standards' (the basics are here: https://wiki.mamedev.org/index.php/MAME_Coding_Conventions). But - lots of people who enjoy reverse-engineering stuff, building emulation - don't enjoy being tied to rigid coding standards. So they just don't bother working on MAME... and I've seen this happen in real time the other week with Paul, he just hates all the coding standard stuff. I'm not sure what the solution is - one way might be to keep Cuavas, but then have an army of people who enjoy converting code from its current form to one that meets coding standards... I dunno, without Cuavas things get messier again, and the codebase is huge and precise, perhaps more than any other codebase that has ever existed. I can't think of an equivalent project.

I've not seen that, though I may scout it out, but I did just read through the github thread from @Johnnyafc and I'm not surprised by what I found. It is not as simple as it appears; on the one hand, it does appear that Cuavas is a bad guy stopping emulation coders doing their thing. But on the other hand, MAME has grown into the most complex emulation project in human history by an order of magnitude. It emulates such an insane amount of hardware, and ties it all together. In the past, emulation devs were allowed to do their thing, and while that worked ok when it was just video games, however once the scale massively jumped, with fruit machines, home PCs, main frames, synthesizer keyboards, calculators, word proessors, door bells etc etc etc, the list goes on to emcompass anything that can be emulated... it became a real nightmare codebase. And Cuavas, love him or hate him, is a very intelligent coder with the aptitude to be able to deal with that complexity and try to organise it in some fashion. But! I also totally see the other side of it - just the other day Paul (who's been looking at some sc4/5/6 stuff), was saying he doesn't do much, because he hates the insanely strict code reviews. He doesn't mind doing the reverse engineering (which is the hard bit), but hates trying to then fold his work into MAME's monolithic codebase, so doesn't actually bother. David alludes to this on the end of his github post: "You're driving people away, making the project look bad, unapproachable. MAME is getting a reputation as very gatekeepery, and elitist, looking down on anybody who has a slightly lesser understanding or different set of skills." I have to agree. Not sure if it would be different with someone else at the helm... or if it is just that MAME has grown so large as to be a very slow moving frustrating project. In David's case he was just partway through writing a disassembler, and committing a WIP from what I can see. From Cuavas's perspective he is saying, get it to a state where it passes the strict MAME coding guidelines before committing (mainly; using official MAME assembler syntax, some other bits, plus the infy loop is just an oversight). I can see both sides of this to be honest. I'm not sure if there might be a branch in the future 'casual MAME', that would have more relaxed coding rules, the people who are into the rigid code standard stuff could import work from that branch into the core MAME branch... though that it introduces its own issues. Can definitely agree that is does discourage a lot of emulation coders from even bothering, since they know they then have to deal with the iron fist of the Cuavas code reviews! But, Cuavas does loads of work, and the code reviews generally are all valid criticisms, compared to the coding standards and methodologies of what should be merged into the root codebase. I've posted that here, but I'm staying well out of it over there! Edit: I just read though some of David's twitter, and I saw: It also appears that HE is allowed to go through an iterative process of how the disassembler represents things, through a series of live checkins, as he understands it, but when I want to do that, not allowed Unless he's finally realising that yes, that iterative process matters So there may be some level of double-standards here that I wasn't aware of, i.e: Cuavas may not be following his own rules when he is working on something in MAME, or making up arbitrary ones to suit what he is doing at the time... not a simple situation this... I can really see both sides, as it's putting a lot of people off even working on the project

First CL is just housekeeping, second one is good though - finally get MAME sc4/sc5 on the dot alphas, they've previously been running in 14/16 segment alpha back compatibility mode

I've played 4 out of those 5 games on the 2600, alkl except Vanguard (I've got one with a flashcart, and dabbled), also enjoy the 2600 version of Centipede - the graphics may be simplified but it is super playable on a CRT with zero input lag Speccy - obvs awesome And yeah it was faster than C64 for vector games which was always nice, since the c64 had better sound and sprites and no colour clash and full screen hardware scrolling, which is a lot of advantages. It did cost more though, amazing what the Speccy could do for the pricetag at the time

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