MAMEdev
MFME extraction, etc #2
Replies: 44 comments 123 replies
|
Thanks for this, and apologies @cuavas, @james-wallace-ghub - I was thinking we need something for general MAME fruit machine discussion, this is perfect :) As an update - I am fully committed to the 'flakey but already working' approach on my MFME layout/config extractor again now (to much risk/work/complexity in the FML decoding approach). I spent last night doing the majority of the remaining Lamp component base info (thus far I've been just extracting enough to drive the Arcade Sim 'DX' machines, as it was all still in the experimental phase). Plan is:
I'll post the odd update as I pass key milestones, now we have a forum for this :) |
|
As you’ve probably noticed, I’ve been slowly converting layouts to use loops to generate and place the numeric lamp/button labels in the debug views. It saves thousands of lines in the layout files, and makes a checked out source tree a bit smaller. I have about 200 left to do for my current round. It’s fairly automated with vim scripting, but I still check the changes, so it’s boring work. As you guys are already no doubt aware, the reel components in layouts (inherited from AGEMAME) have been deprecated. They were problematic in multiple ways. They performed incredibly poorly (you could see the slowdown when the reels do their initial spin on start), they generate insane numbers of textures, and you’re limited to using fixed-size bitmap tiles. Being able to show a window on any element is more flexible (it can cater to things other than reels), and it performs a whole lot better. I migrated a couple of layouts to eliminate deprecated reel elements, but it’s going to be quite a while before they’re all done. There are some other people interested in helping out with it, but I’ve been putting off describing the process because I wanted to get the rest of the debug view cleanup done first. |
|
Sorry I've been a bit busy so am still just on the first step in my plan above (implement complete scraping for MFME components). I migrated a couple of layouts to eliminate deprecated reel elements If you could let me know the name of one of these layouts for reference of how to do the new style of reels please, for when I get to writing the XML generation code that would be great (I checked a few layouts from different platforms, but they all still have the old 'reel' components). I'm a little wary now though, as I don't want to generate new layouts overwriting what's already been worked on by others after my original commits! Also I did lose the original work on the old codebase that generated those 'debug views', I wasn't sure if they were still desired, they seemed like they might handy back when I working on this stuff before. I could look at writing that again (using the new compact loops) if they're still handy for developing the emulation side. I guess best plan is I'll just generate layouts for the fruit machine platforms that didn't get done last time; MPU4(a load of MPU4 did actually get done, but didn't end up in the MAME codebase)... and then there are other platforms that weren't available before; Scorpion 5, Proconn spring to mind, other new ones. |
|
I would use the loops anywhere you can. I know if it's automated that stuff doesn't matter as much, but if people are going to be making their own layouts in the 'DX' style, they might as well have the best practice examples in the codebase to work from, to the point that I'm probably going to pull down the old AGEMAME ones for Dr Who as they're not particularly fit for purpose any more. |
|
I do rather like the debug views – they’re handy for seeing what’s being tickled, or doing comparisons when you refactor something. It would be nice if the buttons were hooked up rather than all being TODO, though. The lamp matrix grid technically contains the same information, but it’s in an incomprehensible form. |
|
I guess it's just because I'm deep in them that they make vague sense to me. If the debug views work for others then I'm fine with them. To some extent I wonder whether the base view should be more along those lines for things like, say, the MPU4 Test Unit ROMs where essentially they hook up to a box full of test lights, reels etc. |
|
I'll bear in mind once the 'classic' layouts stuff is working, that a per-tech per-game debug view would be welcome :) Just had a look to remind myself:
I think the colours on the lamp matrix showed what was referenced (tickled) ; green for lamps, yellow for lamps that are also buttons... dark blue might be reel lamps... unfortunately the original code I did to make these 'debug layouts' is lost, but I can maybe find further visual improvements when I make them again. I think the lower right 8x8 matrix is showing the buttons, where yellow ones are referenced, and they may also light up (sc4 is broken now so unsure). And off course as cuavas says, these were intended to be hooked up so they would be 'clickable', sounds like I didn't finish that part on the first attempt back around 2015. Also as James says, it would be better perhaps if the shared base layout for a platform like MPU4 etc, was then based of a more generic version of one of the debug layouts above. So it wouldn't have the shading to show what is referenced, but still more useful that the current ones, especially once the input matrix is set up for clickable. Still real life stuff going on at the mo, but when I do get time to work on emu dev, I'm now fully on this new MAME layout generation rewrite (using the other Arcade Sim project to drive most of it) - so please bear with me :) |
|
The Here’s an example of a new, relatively simple layout using scroll windows to implement reels: https://github.com/mamedev/mame/blob/445293464e4aa99320493f1a93d8caeff72a1a68/src/mame/layout/j_lc.lay This commit converts reel components for one layout: mamedev/mame@24a5f43 Essentially:
With the
|
|
Thanks very much for the examples of new reels and the detailed explanation, this all looks nice and straightforward and should be fine to build into the new 'mfme2mame' xml generator :) |
|
@johnparker007 I saw you mentioned about your doing screen scraping/remote control of MFME. Just FYI that you do not need to do this with MAME (any more), @npwoods (Bletch) has a good example of how to remote control a MAME interface with Lua over at https://github.com/npwoods/bletchmame . Most (all?) MAME frontends have yet to catch up. |
|
I did see this before when looking at ways to use MAME with Unity... I'll have to actually have a proper look into it! I did roll my own Lua control thing for sending input to a non-focused MAME window behind the Unity full screen window, here's an old video of that in action, running a JPM Impact fruit machine (Lua to send input, window-scraping a 'data layout to get lamp/Vfd states): |
|
Please don’t discuss or link to libretro/Retroarch here. It’s a parasitic project with an incredibly toxic leader. Their behaviour has directly lead to emulation projects being abandoned (DuckStation, Reicast) or going closed source (ReDream). The so-called MAME2003+ project is one of the biggest steps backwards for emulation. They’re also happy to violate the terms of the GPL. |
|
Ah ok, sorry I didn't realise all this, ta for the heads up. Sounds like more reasons to investigate the BletchMAME approach if that is an 'approved' approach for MAME under Unity, see if they solved the debounce issue I was seeing with Lua input control - I was probably doing it wrong, it was just a first attempt :) |
|
(@stilett0 sorry my reply to your comment has been partially redacted, so it is now incomplete) |
|
@davidhaywood just to let you know I've finally got some free time again, so I've now finished up the first stage of scraping the components (used in the test MPU4 Adders & Ladders MFME layout). This gives me graphical assets along with a large human-readable json file containing a dump of all the extracted data: CLASSICClassicAddersAndLadders(Barcrest).zip So now I'll move onto implementing a new version of the MAME .lay xml builder. I might be able to salvage some stuff from the old one written in C, but I may just start from scratch, and do it cleaner... Once I've got it generating something I'll post another update with a MAME screenshot :) I may be doing some improvements, I'm considering putting a white border around clickable buttons, something like this mockup on the £1 button, so they are visually different to lamps: |
|
I've got the first working output - just basic lamps, some issue to fix :) So this is porting and rewriting the old mfme2mame code that wasn't lost, into Arcade Simulator codebase, just focussing on what's needed to make the 'internal' non-graphical layouts for now, and potentially remaking those debug views. I will keep chipping away, and post another screenshot once I've got more components in and bugs fixed... |
You know you can also use Lua script to do all sorts of stuff in layouts. |
|
I’d kind of prefer if people didn’t go too crazy with Unicode emoji in internal layouts:
|
I did see that mentioned in the now expanded layout docs on skimming through them again recently - using Lua to do fancier stuff (last time I read these docs was back in 2016!). The reason I suggested we might want to expand the < led7seg > was that it's a common use case, in that I remember having to make the < rect > workaround back in the day. Here's an example from the existing layouts with 6 of these lamp-driven 7segs (literally the first MPS-platform machine I loaded up to check for this, Add A Note): Also I see: Layout scripting requires the layout plugin to be enabled. ...so I'll stick with the original workaround approach for the moment (and perhaps improve the appearance), as using Lua in the layout isn't going to work (for the typical user). |
Ah ok I see - right, I will ditch the unicode fruit symbols idea, thanks for the heads up :) Having had a taste of seeing those colored fruit symbols instead of the old text, they do look so much better (and clearer when playing)... though I'm concerned that if I made 'SVG fruit art', that would impose too much bloat on the layouts? I guess there'd be something like 4-12 unique symbols on average per layout, that's a very rough guess (some machines like this one pictured below have a lots of fruits, some just have 3-4 like melon/7/bar). I found an example SVG melon from the net: I've had a play with the < group > stuff, and it seems like there's a bug/omitted functionality - in that the < yscroll > tag doesn't work when referencing groups, which I believe are needed to reuse elements (such as the SVG reel symbols). The View Element still renders, but it doesn't decrease the window visibility, and so no scrolling takes place when linked to an sreel. E.g:
So in the View section, the first two of these (referencing groups) appear to ignore the yscroll, only the third works, which is not referencing a group: Here's a functional test layout showing the above, I was testing on j6indy, but any fruit will do :) (of course the SVG reels could be made to work by copy/pasting lots of duplicate copies of repeated SVG data into the element instead of using groups, but that would add insane amounts of bloat :) ) |
|
There is a LUA script example for generating 7seg displays from lamp lines - I did it for Double Take (v4dbltak) |
Extending the built-in components is the road to hell. It’s better to keep them simple. We’re not going to complicate them.
It’s one setting to change to turn on a plugin – you can get there from the main menu pretty easily. You’d be shocked how many “typical users” turn on the high score, autofire and input macro plugins straight away. I really don’t want to pander to users who can’t flip a setting in a menu.
Why are people so obsessed with using transforms to rotate things by 45° when the SVG code would be more readable using plain paths? I really don’t understand this.
You‘re not understanding what a group element actually does or how scrolling words.
But I think you’re trying to jam too much stuff into the internal layouts. Consider that in an external layout, you can supply SVG, PNG, JPEG or BMP files for reel graphics. If you want to de-duplicate the symbols in an external layout, you can just draw the same images in multiple elements (remember an element can contain multiple components). For internal layouts it‘s probably better to just use text for the reel symbols so people know what they are. |
|
Ok thanks for the info and feedback, I will stick with all text for the internal layouts, no SVG reel symbols. |
|
Yeah, that sounds best to me. Maybe a generic set of symbols that can be referenced would be fine for some cases, but text is fine. We will eventually need things like rotatable elements, as for some of the ones using 'wheels' it's fundamental to how they play (overlaying a spinning wheel so that only certain game specific parts of the wheel are visible through them, eg 2/3/4 points on the wheel) In that case text might be a bit awkward, as typically the symbols used are ones that have to look fine flipped / rotated so that they make sense wherever they're in view; text doesn't work so well there. For cases like that maybe a generic set of symbols (not font / unicode based) would come in handy, but we can't even rotate textures / groups etc. right now (Vas is aware of this already, and I believe it's on his TODO list) At the moment some of these cases are faked simply putting extra copies of the reels in the view at different positions, but that doesn't really reflect that they're a single rotating wheel. https://www.youtube.com/watch?v=Fjy2kQhslOM&t=210s JPM Big 50 (we currently use a duplicate of the reel in the view) |
|
btw, if any games ONLY have 'deluxe' MFME layouts, it might still be handy to be able to convert what's there, even if it just ends up being a bunch of generic tags we have to turn back into real text to get something useful - at the very least we get something with lamps in reasonable positions for further tweaking though. |
|
I have a note to look at doing something like that with the DX layouts that have no classic, when all the classics are rebuilt. I'll do full extracts at that stage, so I can probably get reasonable colours set up for those lamps too, by analysing the image data and perhaps then mapping to a limited palette. when confidence is high. |
|
@davidhaywood Making a bit more headway with this new .lay builder :) I'm expecting the .lay files to be about 33-50% of their original size with the new approaches using groups and params (plus going to write a custom xml writer, so I can do clearer human-like formatting of various parts, which will also shave off a bunch of wasted returns+tabs). One of the next things I'm planning to look at that wasn't present in the original one is to detect how many rows of text is rendered in MFME, as it would rely on its own text wrapping rather than having 'hard returns' in a lot of layouts. So then in the generated .lay it would render as: FEATURE instead of all being squashed up on the same line like it is currently (that plus the MAME font I have forced to very small right now, this is still all WIP) - should hopefully make the layouts a bit more legible when it's done (although my line breaks may not perfectly match MFME for something like XXX Y ZZZ). |
|
@davidhaywood @james-wallace-ghub Hey guys :) I've been following the conversation you were having on mamedev/mame#10015 ... re: "the layout now specifies if the 7seg is inverted. I guess this makes sense, if they used different component types which inverted the signal or something. kinda feels like we're missing a level of abstraction somewhere, but as it's mostly guesswork based on behavior, it should be ok for now." I'm sure you already know, but just in case - in MFME, the emulator appears to be able to detect/model this without any additional game-specific configuration (i.e. within layout, as that also has a lot of per-game hardware settings, much like MAME's per-game drivers). Here's a screenshot showing the layout properties page for an LED on Andy's Big Time, plus the overall hardware config page... no option anywhere to manually invert 7 seg displays:
Apologies if this is superfluous information :) It does suggest though that it's (somehow) possible to have these work at the emulation level, without a per game manual adjustment. Easier said than done of course :) But it does appear to be derivable. I have been continuing to work on the layout builder, another (very rough) WIP screenshot: |
|
hmm yeah, definitely not 2 then, I'll put it back to what it was |
|
I don't suppose anyone has a photo of any of the hopper drive boards? I'm still trying to work through this stuff, and while there are things I can impute from debug analysis and a bit of program checking, there's some things that make no sense. |
|
I do not... however, is the hopper board easy to get access to, and/or remove, in order to take a photograph of it? There's a couple of machine owner people on MPU Mecca site I could ask nicely, to see if they'd could take some 'usable' quality photos if that would help? Also, this is probably not relevant, or perhaps too janky to be of use, but I see lots of MPU4 vaguely related hopper code on the old leaked copy of MFME source code, addresses and hopper commands and the like. Could anything useful be gleaned from this stuff? If so I have a VDI with it building/running in, or can zip up the source... though I'm sure you guys already referenced this for some of the MAME stuff way back when (during 'the troubles'). |
|
the MFME way of doing it is basically 'everything in-line' and the same style hacks being used here, rather than everything going through the right channels. Sometimes I'm kinda amazed that software worked at all. |
|
That hopper code... I did look at it and the problem is that everything is based on that one central timer - strictly speaking the DUART emulation there isn't a DUART at all, just a structure for hanging the inputs off. And that means on the hardware level, it just plain ignores stuff we would want to do. I need to go back into the ticket dispenser/hopper code and write some output handlers for it that might help a little, but hopefully there's enough there now to at least sort some of this out. |
|
fwiw, looking at the layouts we already have the one for 'Alphabet' is mostly correct, but it looks like that game doesn't use a standard '3 lamps per reel' setup. I'm guessing the layout generator assumed reel lamps were always a standard mapping? |
|
My plan is to also regenerate all the existing layouts with the new generator, not just missing ones - and checking for errors/differences between the new ones and the old ones as I go (so I don't nuke any actual layout content change work that has been done since my initial commits) - so all these original layouts should be replaced when I'm done, with the new improved ones. I do have a concern when there's often just a single number or two changed, for instance: j6indy6.lay (Layouts for Indiana Jones with the £6 jackpot and the £8 jackpot). I think that's going to cause insane bloat if I could come up with a way to generate those with minimal manual work. Some machines would end up with 3x nearly identical layouts, or even more (£4.80 / £6 / £8 / £10 variants of a single machine etc). Would it be better to stick to one layout per game for now, accepting the Jackpot decals wont match all the ROM variants/DIP configs, until it's possible to do something like a 'base class' version of a layout (or view)? Then one approach could be that the child .lay has something to show it extends the parent layout (<include "j6indy/lay/> for example), and then does something like override named element/groups etc? So it could override a named element that it a text element showing "£6", with "£8" etc. Another way could be to extend Views, so just override specific group/element refs from the base View there, so one .lay would have parent View for £6, and tiny child Views for £8/£10. There's probably a better way to do this, just throwing out a couple of ideas. Just a thought for future anyway, I read above there's a big TODO list somewhere for the layout system :) So for now, I'm thinking just one .lay per game, if that sounds sensible? |
|
Ultimately, that's where I wanted to go, different stake/prize combos in the same file, or at least some sort of import feature so it wasn't mass duplication, but that was way out of my range to bring in. |
|
If/when such an import feature is ever made, I will update the fruit layout generator, and in theory can simply click one button and it'll regenerate all the fruit machine layouts with the required changes/improvements. It'd also be nice so all the layouts can also share a common header for generic svg elements like the reel lamp effect, rounded corner images, that kind of thing (rather than redefining the same common svgs in every layout). I'm keeping this all properly backed up this time round as part of Arcade Sim, so I should be ready to rebuild everything as and when things change with the Artwork system. |
|
The layout format is sadly rather inflexible, it would be nice to have a concept of fragments and variables that could replace strings based on layout selection, but it isn't possible AFAIK, so copy paste is the only way to go for now. I'd rather see options available for every game that reflect the possible configurations of that set (so for ones that get the stake/jackpot from the keys, that will mean multiple layout views in each layout) One of the things that I find sad with MFME is that they only focused on a single set for each game, and really didn't care about the others. I'd rather MAME avoids falling into that trap, and instead ensures all different versions are available with appropriate internal art at least. |
Ok - well I'll initially do straight converts to start us off once I get to that stage (still a couple of weeks of stuff to do yet I reckon, before moving onto other machine layouts). We'll have to work out how best to do this... as it'd be good for the generator to be able to generate them all, so I'll configure for each base layout which text strings represent changeable stakes and what those values are, or something like that. I'm aiming to keep it so that the layouts don't need manual changes after generation, so then if I think of new improvements etc I can regenerate and the diffs to source should just be those improvements. Once it diverges it's going to mean I can't continue to refactor/optimise/improve the layouts as the additional manual diffs will make it really painful... |
|
Testing layout stuff with Adders & Ladders, I got this 'TOKEN REFILL' error message: At that point, the start button flashes and the machine is unresponsive. I suspect it's down to the tubes being emulated correctly, and so the machine sees the token tube as empty, after enough has been paid out. I believe in MFME, the tubes are 'hacked' so they always return that they are full, so this message doesn't appear after extended play. I'm not sure what the plan for this is with MAME..? Currently it's realistic, but does also break everything when a tube becomes empty :) |
|
Ok, pressing 'R' does being up the TOKEN REFILL error. I'm a little confused but even if I delete the NVRAM, it still 'remembers' and shows the TOKEN REFILL error. That must somehow be saved elsewhere - very odd, or very simple and I'm missing something, I am knackered :) Video showing repro on my machine: So for me I'm seeing:
I'm not sure how it's doing this lol :) Edit: Ah apologies - ignore all that, when pressing R that is saved m4addr.cfg. So probably I simply inadvertently pressed R when playtesting the layout, and that caused this. |
|
I had that save state mapped to the 'R' key on my keyboard. That is also the key to toggle the Refill switch. So upon loading a save state with the R key, it also processes the same R keypress as an input to the machine. When toggling the Refill switch while it's on the Feature Restart / Respin skillstop (which is where that save state directly begins), the machine isn't monitoring it. So once you land on Respin, the code kicks in and checks it, and the error is displayed. So it's not a bug with the emulation :) (though potentially a bug in MAME, perhaps it shouldn't process the keypress entered into the UI to load the save state, as also a machine input, until the next key down). |
|
yeah, pressing R will then expect some other sequence where you refill the machine. I'm not sure what that sequence is (probably some other sensor?) one of the reasons I'd like the layouts to all be mouse driven with clickable artwork is that it minimizes the chance of accidentally hitting one of the admin keys |
|
and yeah MAME UI keys falling through to the emulation is a big issue with a lot of systems, it causes problems on some computers when trying to change discs too. |
|
Ah ok cool, so long as it's logged as a known issue, that's all good :) |
|
Just checking in - I'm still on the layout builder, taking longer than anticipated, as is often the way with these things :) Finally got the 'soft return' word wrap stuff working, so now the text is better distributed on the lamps/buttons/labels etc where the layout relies on that (for instance in this test Adders & Ladders). Just put in 'frames' which gives some outlines for areas on layouts that have them. I'm probably still a few weeks away from scaling up to more MPU4 layouts, bear with me... |
|
@davidhaywood I'm moving to a new layout with different reel symbols, so I can develop something for parsing reel symbols from text files/earlier versions of the .lay files. This was always going to be an issue - so was just wondering; how did you go about unscrambling the lamps themselves to make your test Classic Adders & Ladders MPU4 layout work correctly (once you'd given it the correct 8x lamp column Chr values)? Was it just a case of careful trial and error per lamp, or did you figure out any kind of magic way to determine the old lamp number -> new lamp number mappings? MPU4 Graffiti layout, showing incorrect lamps: 0x00, 0x60, 0x40, 0x60, 0x20, 0x40, 0x40, 0x20 (MAME driver correct lamp chr values) I'm guessing it was just working each lamp out manually, but thought I'd best check! :) - in which case, I guess I'd initially just generate them with these wrong lamps where they occur, perhaps someone can be tempted into working them all out in the source MFME layouts, so I can then rebuild them for MAME. |
|
The lamp descrambles were done manually, yes. Since a lot of games share characterizers, there was a lot of cross-referencing done too, eg. the "tri98" style ones are basically trusted, so if another game used a different chr but also had sets using tri98, the scramble was done to match a known working decode. There are a handful of games where I'm not 100% confident as there was nothing to cross-reference with, but even in those cases I'd say I was 95% sure based on lamp use. |
|
It's great work all the Chr 8x lamp value derivation you did :) I can confirm that the Classic Adders & Ladders 8x lamp chr values are correct, as I've used them in a real machine (through making a patched ROM so the real machine can run without the Chr chip, instead retrieving its 8x decode values from a new routine added to an empty area of the ROM). I have also had verification that Blue Moon 8x lamp values from your work are correct on real hardware. (Both Classic Adders & Ladders and Blue Moon were games where the MFME layout had incorrect 8x lamp values, so my initial ROM patches had lamp issue on real hardware, until you figured out the 8x lamp decodes from the protection patterns). But, when you had done them for Classic Adders & Ladders, you must have then had an additional step where you worked out the lamp numbers to actually make the layout work correctly with the fixed 8x lamp values. So I will need to do that step, or find some patient MFME folks to do that step, for each of the affected layouts - otherwise those new MPU4 layouts I provide will in some cases initially have the lamps scrambled (due to the MFME layout being built with incorrect 8x lamp chr values). I'm guessing that's still preferable to no layout though, so I'll just carry on for now, and they can be dealt with at some later stage... at least the other platforms don't engage in the lamp scrambling, so it'll just be some MPU4 layouts that have the issue :) |
|
well for Classic Adders and Ladders, yes, I went over the layout and manually fixed the lamp values. Basically each scramble value acts as a 'xor' on each row. I knew what the old layout expected, and was previously being provided, and I knew the difference in the values in my lamp values compared to the old ones. From there I created a table of what the 'old' lamp number in the layout was, vs. what it should be. I search+replaced each of the lamp values that would need changing, so "lamp64" was renamed "lampxxxx68" for example. After doing all the renames I then removed the 'xxxx' part. basically if you want to hand-fix the layouts to work you need to know the (incorrect) CHR lamp table values MFME used and the (correct) CHR lamp table MAME uses. I guess it would be cleaner if this could be built into the conversion process, but for Classic AL it was done by hand. |
|
expanding upon this... If you look at the default debug layout in MAME it is arranged like this each of those 8 rows is controlled by a different value in the table so in the case of the adders and ladders table despite some of the lamp tables having more bits set (I assume these were read from hardware or something) the game code only uses 4 bits in each byte for swapping the lamp data a value of 0x40 swaps like so (using the first row as an example) which is a XOR of 64 (xor any value with 64) to get new lamp value a value of 0x20 swaps like so which is a XOR of 32 (xor any value with 32) to get new lamp value a value of 0x10 swaps like so which is a XOR of 16 (xor any value with 16) to get new lamp value and a value of 0x08 swaps like so which is a XOR of 8 (xor any value with 8) to get new lamp value combinations of bits combine the XOR values, so 0x48 would be 64 + 8, a xor of 72 as I said, other bits can be ignored, so if 0x04, 0x02, 0x01 or 0x80 are set in the table they appear to have no effect on the lamp scramble (unless they're used for extended lamps, but I'm not seeing that, as I said, I assume in cases where those are set it's because the table was read from hardware, and those bits are set but not used by the lamp scramble) so basically, to convert from incorrect MFME lamping to correct MAME lamping work you need to use the above information to remove the incorrect MFME scramble from the lamp numbers in the layout, and replace it with the correct arrangement, so that when the game writes the descrambled data (as it's the CPU reading the table, and doing the descramble) the correct lamps are triggered. I did notice some MFME layouts were trying to do all the lamp descrambling in the layout, rather than having a correct table for the CPU to use. That approach actually falls apart completely in cases where games only go through the lamp scramble function for SOME lamps, and write others directly. (a few do that for clear effects) If you're still in doubt, just list the ones I need to manually fix when you convert them. |
|
Ah wow that is great news - that it can be automated with the data I have available here :) Thanks for this detailed explanation of the process and the XORs - I do indeed plan on building this into the Layout Builder as an optional stage, since it can be fully automated - really a relief, as I'm not sure people would be queueing up over on the MFME forums to do this by hand, since from their perspective the existing layouts 'work' (even though not properly, as you say for hardcoded clear effects etc - I certainly saw some subtle lamp issues with the original Adders that were fixed once I manually remade it with the correct 8x lamp values from your MAME characteriser code). |
|
Thanks again for the help with the remapping process :) I've got some finishing up to do, but it looks like it's all working ok - MPU4 Graffiti after the automated lamp remapping applied: |
|
Just checking in with another update :) The work is going slowly due to lack of time (the noisy neighbours on both sides of my terraced house have got the better of me, so now I'm balancing full time job + building false interior walls both sides of house to block the noise, so FME dev is getting a smaller slice of time than is ideal), but still progressing... Been doing work on more reel symbol layers, and also got JPM input/reel alignment working, here's a couple more test layouts: MPU4 Graffiti with fruit symbols/overlays: MPU4 Sunset Boulevard with boxed symbols: JPM Impact Big Bucks - some symbols have a red background stripe layer, buttons/coins/reels working (minor issue with hold 2/3 lamps to figure out): |
|
|
|
Ah well, in this example I noticed with Sunset Boulevard - I've just double-checked and and also some of the actual button inputs are also different... so I think it would need to be treated as two separate layouts - I've attached (these are bloated non-optimised debug layouts, not ready for the codebase!) Once you get holds on m4sunset you'll notice the Hi button flashes, and acts as a hold button, while Hold1 does not flash or function as a hold button... on m4sunsetd all works correctly (both the layouts in the zip above are the same layout just named differently for quick testing). Perhaps it was housed in a different cabinet or something... |
|
probably different cabinet types then. there were also sets market as Sunset Boulevard that turned out to be oki type, eg. m4sunseta (although could just be another game mislabeled, there was plenty of that) anyway m4sunsete is BS__ 1.1 (the oki types are B25 1.2 fwiw) Maybe BSx sets and SBx sets are different cabinet types, maybe SBx is some kind of showcase? maybe they're just different games? If m4sunsetk (SB 1.1) is the same lamp setup as m4sunsetd (SBU 2.0) then we probably have 2 cabinet types. (or the game was popular enough to be rebuilt from scratch and reissued as a new machine without moving to a new platform?) the bootleg m4sunsetc is OSB 0.2 in this case, which is a different code again, but being a bootleg could be a hacked code. There are other machines where we've seen 'new', 'super' or 'mk II' versions, which would have clearly had different artwork, and maybe extra cases, so could be one of those cases. |
|
I've done a quick test :) So I've only generated a single layout, as I only have 1 single source MFME Classic layout (which uses the m4sunsetd roms). Using that layout with those other romset you listed: m4sunset - Lamps & Buttons not matching m4sunsetd (2p play) If m4sunsetk (SB 1.1) is the same lamp setup as m4sunsetd (SBU 2.0) These lamp setups do match the above statement. Note that the button mappings are also different (so the Hi button flashes instead of Hold 3, and to actually hold reel 3, I need to click the Hi button). It's like you mentioned before though - often in MFME land, the most fun to play ROM version is the one on the highest stake with lowest jackpot, as you get a lot more action in the same number of spins... and so a 20p play Sunset Boulevard MFME layout exists, but not a 5p or 2p, as they're a grind to play. So these at some point would need fixing up (by making a copy of the m4sunsetd MFME layout, fixing buttons +lamps to work with the 'other' type of rom, then building a second Sunset Boulevard MAME layout from that. Gah, there's a lot more to this even when I've got it generating the optimised layouts from the source MFME layouts then! Ah well, I'll keep chipping away as I get bits of free time... :) |
|
glad to see you're still chipping away, my progress has kinda stalled until the branch gets merged in, but I'm sure we'll get there in the end |
|
I was originally going to use the existing workflow I have for Arcade Sim as that's how I've been working on the extracting of these layouts... but it's just not scalable... each of the folders here pretty much represents the number of 'base' machine layouts (ignoring custom stake/prize variants) needed for MAME (as this time round going to make those initial playable 'textless' layouts too where only a DX is available). ~3,000 really is a lot to configure :) Though some of the hardware platforms aren't set up in MAME yet... so some of that 3,000 will come later. I'm making a bunch more tooling and helpers to try automate/speed up the overall process to something more feasible. I'll still be able to focus on platforms we need first once this is built (Initially MPU4, then JPM SRU, MPU1, and the potentially upcoming 'BLACKBOX')... but it'll take a while to build this stuff. But overall I'm certain it'll save me a ton of time, as I really want to get all fruit machines in MAME with a 'new style' layout. Will there be any issue with ultimately having the ~3,000 .lay files in the MAME source? After optimisation (not yet done) I believe the individual layouts will be 50% of the size of the original MFME2MAME layouts I did, maybe even smaller... but there will be a lot more layouts, as I'll be filling in gaps with the initial 'textless DX conversions'... but it'd be good to know before I embark on this quest! :) |
|
Adding a few zeroes to the end does nothing, adding a bunch of them prevents the layout from loading - pretty sure it's in the size. |
I tried that and it fails for me even if I had only one 00 |
|
It doesn't look like its the size. |
|
I think this time I figured it out for some of the files: program mfme_decoder;
{$APPTYPE CONSOLE}
{$R *.res}
uses
System.SysUtils, System.Classes, EasyCompression;
const
levelValue: array [0 .. 9] of TECLCompressionLevel = (eclNone, zlibFastest,
zlibNormal, zlibMax, bzipFastest, bzipNormal, bzipMax, ppmFastest,
ppmNormal, ppmMax);
var
fs: TECLFileStream;
inputFile, outputFile: string;
last4Bytes: Cardinal;
passwordInt: Integer;
const
XOR_CONST = $00C59A00;
{$R-}
{$Q-}
function mixer(a1, a2: Integer): Integer;
var
i: Integer;
x, v4: Cardinal;
addr: Cardinal;
begin
Result := a2;
addr := Cardinal(a1);
for i := 0 to 99 do
begin
x := addr xor Cardinal(Result);
v4 := (x shr 24) or (x shl 24) or (x and $00FFFF00);
Result := (v4 shl 3) or (v4 shr 29);
end;
end;
begin
try
if ParamCount < 1 then
begin
Writeln('Usage: mfme_decoder <inputfile>');
Exit;
end;
inputFile := ParamStr(1);
outputFile := ChangeFileExt(inputFile, '_decoded.dat');
var
fsIn := TFileStream.Create(inputFile, fmOpenRead or fmShareDenyNone);
try
fsIn.Seek(-4, soFromEnd);
fsIn.ReadBuffer(last4Bytes, 4);
finally
fsIn.Free;
end;
Writeln('Bytes: ', last4Bytes);
passwordInt := mixer(XOR_CONST, Integer(last4Bytes));
var
passwordStr := LowerCase(IntToHex(passwordInt));
Writeln('Password: ', passwordStr);
try
fs := TECLFileStream.Create(inputFile, fmOpenRead, passwordStr);
fs.SaveToFile(outputFile);
Writeln('File decoded to: ', outputFile);
finally
fs.Free;
end;
except
on E: Exception do
begin
Writeln(E.ClassName, ': ', E.Message);
Writeln('Trying alt password');
fs := TECLFileStream.Create(inputFile, fmOpenRead, 'b67de657');
fs.SaveToFile(outputFile);
Writeln('File decoded to: ', outputFile);
end;
end;
end.The last 4 bytes are the password but run through a XOR mixer 100 times. |
|
Nice work :) I do kinda of bear some responsibility for this, as Chris changed his save format directly after my original 'mfme2mame' project! So I'm guessing the alt password (b67de657) is just a placeholder, pending further investigation... impressive stuff. |
|
I created my own fml file and it seemed fairly structured and semi-meaningful but other fmls looked completely different but I eventually found some similarities. The images are stored as bitmap files with a control header before them. Easiest way to find them is look for the font name, "Tahoma" was used on the fml I looked at. Sometimes you get some extra 'tags' between the images, no idea what they do. Somewhere in all that is the number of "on" images as you can have images which aren't allocated to a lamp so aren't in the 12*4 table. That's all I've got |
|
Nice work, that's some impressive progress! :) |
|
Had some time while waiting for other stuff to happen. Need to keep editing the layout and changing flags one at a time and see what changes to workout what all the bits actually do so it won't be a quick job. |
|
It's deffo a good start, with lamps being the most common component :) Hopefully @stonedDiscord can make use of it in his quest! I did look into this a bit back, but since I already had my clunky-but-functional solution kinda working, I just carried on down that route, and now have all the component scraping mostly done I think (and then import them into the layout editor)... though if there was a way to reliably import from any version of an MFME .fml, that would be loads cleaner :) |
|
Also @stonedDiscord - if you do decide to do a deep dive and decode all the possible MFME components from the various versions of .fml, here is the relatively comprehensive structure data for each of the components, may be of use setting up your own - good luck :) |
|
For now I'm most interested in the element positions, this alone would make manual layout creation much easier. So parsing the fml to get parameters 01-04 is what I'm going for right now. |
|
Experimented a bit more with this and with a simple pattern search, with a bit of value validation, it's fairly easy to find the first resource block and then walk through the rest of the file. Question - for reels there is a height parameter which specifies how much of the reel band is displayed, does anyone know what units this is in ? It's not pixels or steps so I've no idea what it is. I've tried to get the library compiling in a c++ app but failed :( The demos work fine but they're gui. As soon as I try and include the lib in a console app it fails at link time with something like system.classes.obj :( |
|
Cool to see more progress! :) Regarding the reel 'Height' parameter - it's not so straightforward to try get a 1:1 match with the layout, as MFME is doing a faux perspective on the rendered reel band image, in just the vertical axis. In these diagrams, you can see the height of the '7' symbol is taller in the middle position, but the height is shortened near the top/bottom of the rendered reel band section: 
|
|
Prob not much use, but I dug out my 'fudge' I'm currently using for the 2d side of my recent layout editor project, to get a vaguely correct scale (that's then applied to the texture). It's super crude as I'm just rendering the bands in the 2d view 'flat', with no faux perspective (as the purpose of the editor is to make the 3d machines, where the reel band texture is mapped onto a cylinder model like an actual reel). Might do as a placeholder for your project though, since MAME also renders its reels 'flat'. |
|
Thanks for the info. I'm not going to dig much further into the format, I was having a look for someone who uses MFME as a layout editor/creator. Are there any timescales on your latest editor and/or the rendering software ? |
|
I've had a lot on with life/work/other obligations - so not had any time/energy left to work on the Layout Editor component of my project for a couple of months (it's all on github for others to contribute, but it's so very niche, I think it'll end up being just me lol). So it currently has an extractor component, that extracts layouts the clunky way. I've not written (or ported one of my 2x existing) MAME .lay 'exporters' to it yet, so that needs doing. I've not actually written the 'editing tools' side (to allow to create/move/resize components in a clean intuitive manner), so it just runs on imported MFME layouts. So that'd need designing and developing. With the MAME pure text layouts, another issue you run into, is that the reel symbols need to be manually 'transcribed' in some way... I did a couple of approaches to this (my most recent reels look a little fancier than just a text string), but it's still a ton of manual work to type them in. Got the flu right as I started my xmas break of course, hopefully I'll get chance to do a bit of work on it over Xmas. From my end I was working on the 3d aspects - but making the editing tools, and certainly the MAME .lay exporter aren't that much work, if I go for the 'non fancy' MAME layout style, that doesn't do svg shading etc. So I could look at that for a bit instead :) Fancy style with SVG shading and other enhancements vs original style: 
|
|
I've had a quick look at how MFME draw lamps and I'm a little confused. For normal lamps you take the ON image and apply the mask so it looks like it's lit by a lamp then draw it on the background taking note of transparency and rotation etc. All fairly simple. I'm not sure what's supposed to happen when the BLEND box is ticked. There are some lamps with this ticked where the ON image contains the lit part but also contains unlit background. These images have no transparency. If you apply the mask the unlit background part of the image becomes too dark when drawn on the background. Does anyone know how this is supposed to work ? Similarly, laps with LED and RGB ticked also behave in a way I haven't yet figured out. |
|
MFME has a basic form of transparency - not quite like indexed color transparency, instead a RGB color value can be set as the transparent color per image. It's set in MFME to corner pixel/custom pixel/cleared from a context menu (1). You can open the image in MFME's internal graphics editor, and see the current RGB value that is set as transparent for the current image (2): 
They are then rendered using MFME's 'software' renderer (ie. it's not using shaders etc, the pixels are generated in c++ code) - the precise way they blend I never went into great detail on, I just made an approximation in the original Arcade Simulator using standard alpha blending - but that came out pretty similar (this isn't my long term plan for lighting fruit machine artwork, so it was good enough for placeholder). The purpose of it within MFME is for something like that Indiana Jones logo, where the effect of multiple independent (usu. ROM controlled) bulbs behind glass - it allows the 'lit' pixels to combine. LED and RGB, I'm going from memory here, but depending on the tech, some LEDs are simple mapped to a lamp 'index'...though on some techs it is done differently... for RGB, that is specific - I did look into it ages ago, but the general idea is that an RGB LED can be driven. I think for RGB leds, then the colors are then set up arbitrarily in the numbered 'on' images, image 0 = red, image 1 = cyan, image 2 = green etc... to match however Chris mapped his reverse engineered LED model of the machine's output. And then the original artist who created the DX layout would put a red image in image 0, cyan image in image 1 etc. Sorry if this is a bit scant on details, I'm in bed with the flu - but hopefully that gives some insight into those MFME features :) Edit: to add - then for these 'Blend' lamps, the mask image sets the effective alpha of the non-transparent pixels (though again, I can't remember if my shader hardware based simple alpha blending perfectly matched whatever Chris's internal software renderer did, it was close enough though). |
|
Ah I might have over-explained, having re-read your initial message: There are some lamps with this ticked where the ON image contains the lit part but also contains unlit background. These images have no transparency. If you apply the mask the unlit background part of the image becomes too dark when drawn on the background. I suspect these may simply be marked as Blend lamps by mistake, by a rookie layout creator? As if there are no transparent pixels (as MFME defines them), then no blend will take place, so the result will just be a more CPU intensive draw with the same appearance as a 'non-Blend' lamp. |
|
Sorry to hear you've the flu, hope you recover soon. Thanks for your replies. |
|
Hi guys, Can I ask about the implementation of a few things within MAME... Specific Inputs - Coin Mechs, Door Switches, Note Acceptors, Percent / Stake / Prize keys. Not just in terms of layout building but also in terms of the internal emulation. Are there shared modules / components that I can hook in to, or do I just use external inputs / outputs and leave it to the layout devs to work it out? I also note that the lamps are using a persistence value, I was thinking of creating a Lamp Matrix module / device / component that would handle filament simulation. The HW devs can then just add a lamp matrix (or multiple if needed), select the data / strobe sizes, and the colours / brightness /real persistence will be handled via the emulation. |
|
Just tagging @james-wallace-ghub re: above (also @mamehaze - not sure if this a new account now... ) :) |
|
Just wondering if it's possible to decode the fml files without using the easycompression library ? There appears to be some sort of header to the fml but apart from the obvious I'm stuck :( Edit: I was expecting the header to specify the length of compressed data, so file length-header length, and also the decompressed data length but I see neither :( Not really a problem, I can just call the decoder program first. |
|
I don't know about doing it without the lib - however just a heads up, another guy has also been working on decoding that fml format (apart from the easy compression lib stuff). He's got like 90% of the components decoded including all fields/dropdowns/images/overlay images I believe. I'll send him a link to your comment, as you guys may be working on the same stuff :) Wrt to the compression/encryption stuff, in Mfme it is using this proprietary solution I think: https://www.componentace.com/compression_delphi_component_streaming_compression_easy_compression_library.htm |
|
@Paul-Arnold @johnparker007 @stonedDiscord Other guy here :) As John says. I have been working on an FML decoder, obviously the first hurdle is decryption which was already solved in an earlier thread. Only problem is that you need to use that proprietary library. So in my converter, I tolerate that for now and invoke the command line to decrypt (with the solution from @stonedDiscord , which to clarify, does work for every file, just that many fall back to a default 4 byte sequence as opposed to last 4 file bytes) before we decode. No file I have tried has failed to decode with this. I have been making such great progress on FML decoding and nearly have a full component decoder working. A variety of tools (some vibe coded stuff like a layout binary diff utility that makes tag identification a lot easier) I have figured out how to walk the file and extract all of the data for each component. On a component by component basis, decoding fields for each. A full suite of smoke tests etc. it will be open source when done but still needs a little longer to cook. I'm willing to chat with you about any details you want to know on that front. On the topic of AACS. I wanted to look further into this. But a basic search of that term reveals that this is the type of encryption used in BlueRay disks. There are a few open source projects that can handle this kind of decryption out of the box. Obviously they need a key, therin lies the challenge. Now this is really a best guess but a Google for "AACS key length" reveals that Now we know that the last 4 bytes of the file (or a static known 4 byte sequence for older encrypted files) contribute in some way to the key. As this is what we pass to the library. So my guess is that we need to figure out the "proprietary" 8 byte sequence to append to the 4 byte sequence. Maybe time to get Ghidra out? Maybe look for an area of code where the last 4 bytes of the file are being handled? Follow what is being done to the memory of before some call, there are 16 nicely aligned bytes that may prove helpful :) Maybe that would leave you with some kind of unencrypted compressed data that can then be fed into a standard decompression algorithm. Not 100% sure of this approach but I think it's worth a poke. |
|
Thanks for your reply. I originally looked into the fml format to help someone working on a project which needed a list of objects and their positions, sizes and rotation. That part, including saving the images was quite straight forward and I didn't progress it much further. I'd not worked out any of the tick boxes, dropdown menus or anything else. I picked it up again more recently as things seemed to have gone quiet on this thread and although I've made some progress I'm no where near to what you've achieved. As there's no point in re-inventing the wheel I think I'll drop the format investigation and see if I can get anywhere with the decryption side. My understanding was the library accepts a variable length string as a password and although mfme uses a 4 byte value converted to ascii I'm not so sure it's as straight forward as needing another 8 bytes. I've not done reversal of pc software before so might be a slow process. If I get anywhere I'll post on here. I look forward to seeing your decoder when released. |
|
Is it a “library” in the sense of a DLL? If it is, you can detour the entry point to the function of interest and see what MFME is passing as the password. If you’re lucky, MFME’s key schedule might be in the calling function itself. |
|
@Paul-Arnold @johnparker007 @stonedDiscord Just to let you know. I've figured out how to decrypt and decompress without the library (sorry to take the task but by the time I had read your reply I had already invested loads of time.) I have C# code with tests, it works with every fml I have thrown at it so far. Figured out using Deepseek V4 Pro using OpenCode as a harness, took a few days to find the right approach. Bottom line is...It's now a solved problem and I will be integrating it into my codebase, just need a little time to do it. My C# implementation covers the use of a fallback password as well (as seen in the @stonedDiscord implementation) FML Decoder — How It WorksPipeline OverviewNo external binary, no emulation, no capstone. Dependencies: Step 1: Parse FML HeaderRead two 32-bit little-endian integers from fixed offsets:
The first 144 bytes (0–143) are the header. The payload starts at offset 144. Step 2: Derive Password via MixerThe last 4 bytes of the FML file encode the password. The Mixer AlgorithmPseudocode: Where Verified Passwords
Step 3: Derive AES Key — RIPEMD-128The password is used as raw 8-byte ASCII input to standard RIPEMD-128. RIPEMD-128 AlgorithmRIPEMD-128 is a 128-bit cryptographic hash function. It takes an arbitrary-length
Compression Function Constants
f-Functions
Round Operation (per round j)Both left and right lines execute the same pattern with different tables: Each round feeds Feed-Forward (Final Combination)After all 64 left and 64 right rounds, the new hash state is: Verified Key Outputs
Step 4: Derive IVThe AES key encrypts a block of 16 Step 5: Custom Decryption (ECL Mode)The ciphertext from offset 144 (length StateFull Blocks (16-byte aligned)For each 16-byte ciphertext block: This is not standard CBC. Key difference: CBC XORs the previous ciphertext Partial Block (if csize % 16 != 0)For trailing bytes (<16), encrypt Important: Uses Step 6: DecompressThe decrypted output is a raw zlib stream (deflate, no header wrapper for The output is a Delphi binary format (DFM/resource stream) with a consistent File Layout SummaryFML File Structure
DAT Output FormatDecompressed output is a Delphi binary stream with a |
|
Awesome - native FML importing just got a whole lot cleaner :) |
|
Amazing work, brilliant. I'll try and understand what you've found later but I've a couple of really dumb questions :) Using cashcrusader.fml (£100 Dx version), file is 0X96D56e = 9885038 bytes So, the compressed length is 266464 and decrypts to 524288 ? but using the released mfme decoder the file decompresses to 29578180 I'm obviously being really stupid :) |
|
Actually I posted before fixing a bug @johnparker007 did some QA over discord for me and he found this very bug Easy fix, there are multiple 512kb blocks per file and they are chained together into a stream. The decoder now accounts for that. We tested it. My initial set of samples was very small. I can't blame the AI for thinking "job done" when it was not made aware of larger files. Yes, I think this Dsize stuff is stale in light of this. |
|
Corrected info here: File FormatSingle-chunk files (smaller .fml)Multi-chunk files (larger .fml)Larger Each chunk header (16 bytes): All chunks use the same password-derived AES key and IV. Each chunk is |
|
Here is the fun bit you have been waiting for :) It's reasonably clean but remember it is vibe coded and I have not given it a super fine review. Usage |
|
So if we walk the structure, we would see that the encrypted data ends at EOF instead of EOF - 4, meaning we have a legacy file... Makes sense to validate if this is the case. |
Works exactly as you said, updated the project to match this. Added warnings if CRC verification fails for a block. |
Just put handling for this into the code, works like a treat. The legacy files don't have those 4 bytes on the end and we can detect it. Nice find! |
|
Library to decode MFME FML is now published under MIT license and is here Also has a bonus feature where it can 'write back' a 'dat' file as an FML and have MFME load it. |
|
Just created a release and have binaries that work for Linux, Mac and Windows. So already a tangible benefit over the current stuff. Should work as a 'drop in' replacement for the @stonedDiscord program wherever folks are using it. https://github.com/paul-maidment/fml-decryptor/releases/tag/v1.0.0 |
|
Any chance we cab get @cuavas to comment on common components for fruit games? I appreciate the old reels etc were slow, but it would be really useful to have some proper common component support for lamps, reels, alpha's etc. Internally at the emulation level and externally at the artwork level. |
|
There's 2 parts to each component. The internal emulation. i.e. the driver code. That's why I am asking how it should be done rather than just doing it however I can make it work. |
Well the layout I ended up looking at as an example still had them in. It came up as deprecated when I ran it, so I thought I'd ask how to do it properly. I got pointed to this thread and told it was best to ask you. All you needed to say was that it had already been explained somewhere. I'm trying to fix things and get more techs running, no need to be snippy about it. Equally what about other components; reels, meters, coin mechs, coin hoppers, alpha displays, 7 seg displays, solenoids (coin tubes), percent keys, stake / prize keys, dot matrix displays, coin hoppers, SEC meters, etc... All common components that you will find on most fruit machine techs. I'm just asking how you want it done / how its already done, so that the techs I am fixing and the changes are accepted. I already have 1 new tech completed on the emulation side, and another that has a lot of fixes so it runs properly as per the schematics / data sheets. I've also completed some TODO's on sound hardware / CPU cores / peripheral stuff. I'm just trying to make life easier for both of us. |
On the emulation side I agree, on the artwork side they are all pretty similar, either 14 segment, 16 segment and with / without a dot and comma. Then there's the dot matrix variants. This is why I am trying to work out the correct way of doing things. There's a certain amount of hardware abstraction that happens at some point between the emulation and the artwork / layout. |
|
I'd love to see a more universal solution to this as I've been wondering quite a lot about how to handle "reels" that are disc shaped: |
|
Disc Reels, Horizontal Reels, Flapper Reels (like the rotating letters used on old railway station signage where there was a 'flap' with each letter of the alphabet on it and it rotated round until the required letter was displayed). Then there's the lamping of the reels as well. |
|
Hello — hoping to tap the MFME knowledge in this thread, apologies as it's a tangent from layouts. I've been writing a Bell-Fruit Scorpion 5 hardware emulation for my own machines. Personal project, nothing distributed, and not an attempt at a rival to MFME. The board side works: MCF5206E ColdFire, YMZ280B, the alpha display, the SEC meters, the I2C devices. The CPU is verified instruction by instruction against a reference trace for 400 million instructions, and Deal or No Deal: The Golden Game boots properly — initialises, reads the sound ROM header, puts its startup text up. Then it stops with The exchange it wants is on I2C address 0x09, every boot:
Those 16 bytes are identical whatever the device answers (tried 00, ff, 5a), so it's a fixed challenge — meaning a single captured reply would satisfy it permanently, rather than needing the algorithm. Two questions if anyone knows:
I notice sc5 in MAME is still "this system is not emulated", so I assume this is the reason. |
|
Not sure why you're seeing it as fixed but it's definitely not a fixed challenge. |
Uh oh!
There was an error while loading. Please reload this page.
A continuation of mamedev/mame#9632 (comment) , so we don't pollute the PR system any more.
All reactions