MFME extraction, etc

[james-wallace-ghub]

A continuation of mamedev/mame#9632 (comment) , so we don't pollute the PR system any more.

[johnparker007]

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:

• implement relatively complete scraping for other required components for the MPU4 'classic' layouts, this is stuff like 'Frame' (original mfme2mame didn't have this, as they weren't in mfme at the time so we'll get some nice area borders in places), non-DX buttons etc...

• potentially implement the initial 'config' scraping system, and then do the MPU4 config page, could help with some games in the driver that weren't covered by the original MPU4 .tsv I provided (that contained the Chr lamp data, reel types, hopper types, etc)

• then from there, I will move onto rewriting a new version of the .xml generation (for internal MAME layouts, I'll deal with DX bitmap elements later). I'll try salvage what I can from the old mfme2mame codebase... but also change things to use the new Layout system improvements that didn't exist before - I see loops and whatnot now exist, so things like DMDs should be much less bloated (I have a memory that they were very large).

• generate a few test layouts and see how we're looking

• once that's all up to a good standard with the improvements (including fixing that issue where the labels were getting lost due to black ink on black background), I'll work on some batch processing system (including salvaging the reel text from the previously generated layouts, unfortunately I lost some work on the original, so I've lost a lot of reel image -> text lookup data), so I can regenerate all MPU4 layouts

• and later, generate more platforms, focusing on the ones that work/are being worked on (since this new mfme2mame runs on the final v20 version of MFME, all techs (e.g. Scorpion 5) can be brought over to MAME wrt layouts.

I'll post the odd update as I pass key milestones, now we have a forum for this :)

[cuavas]

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.

[johnparker007]

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.

[james-wallace-ghub]

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.
As for the debug views, they were handy for me when working out some of the reworkings for the unusual stake/prize combinations, but to be honest for most of it I fell back to the original lamp grid one I did eons ago. That could probably be improved though

[cuavas]

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.

[james-wallace-ghub]

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.

[johnparker007]

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

[cuavas]

The xscroll/yscroll elements are described here: https://docs.mamedev.org/techspecs/layout_files.html#views

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:

• Make an element representing each unrolled reel.
  • You can put whatever you want on it, but for internal layouts it will probably be text.
  • The transparent rectangles are just used to force the correct size when there’s empty space at the edges.
• When you instantiate the reel, add a yscroll element to control how a section of it is displayed.
  • Bind it to an output or I/O port in the same way you would for element state or bounds/colour animation.
  • The size attribute sets how much of the reel is visible as a proportion of the total ("1.0" would be the entire reel, "0.25" would be a quarter, etc.).
  • Use wrap="yes" for reels that spin indefinitely.
  • The difference between min and max is the range of state values in a complete revolution. If you’re using the reel stepper device (inherited from AGEMAME), this will always be 65,535.
  • If the reel component had reelreversed="1", make min greater than max; otherwise make max greater than min.
  • Set min to the state value when the top of the reel element is at the top of the visible window. This is slightly complicated by the fact that the values can’t be negative. You may need to add 65,536 to get the numbers in range.

With the sc2prem2.lay example:

• For reel0, reel1, reel2 and reel3:
  • Three of sixteen symbols are visible – height is set to 3/16 = "0.1875".
  • It has reelreversed="1", so min must be greater than max.
  • It had stateoffset="2730" which is a subtracted offset:
    • Subtract from 65,536 to get the state value that gives a neutral position: 62,806.
    • This is less than 65,535, so to ensure max isn’t negative, add 65,536, giving min="128342".
    • Subtract 65,535 from the min value to get max="62807" (note that it’s one state value away from the neutral position).
• For reel4:
  • One of 12 symbols is visible – height is set to 1/12 = "0.0833333".
  • It has reelreversed="0", so min must be less than max.
  • It had stateoffset="-1365" which is a subtracted offset:
    • You can subtract it from 65,536, giving 66,901, and then subtract 65,535 to normalise it giving 1,365, but for a negative stateoffset you can just take a shortcut by negating it to get a positive number.
    • Since max will be greater than min, there’s no issue with it becoming negative, so use min="1365".
    • Add 65,535 to the min value to get max="66900".

[johnparker007]

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

[stilett0]

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

[johnparker007]

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):
https://www.youtube.com/watch?v=Agl4L1Vvkfk

[cuavas]

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.

[johnparker007]

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

[johnparker007]

(@stilett0 sorry my reply to your comment has been partially redacted, so it is now incomplete)

[johnparker007]

@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:

[johnparker007]

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

[cuavas]

I did do something for this that constructed lamp-driven 7segs using rects for each of the segments for these MAME internal layouts, that code may be later mfme2mame code that was lost. I'll hold off on rewriting that approach if there's a plan to make the MAME 7seg component able to take 8 lamp numbers as parameters, that'll also look much nicer.

You know you can also use Lua script to do all sorts of stuff in layouts.

[cuavas]

I’d kind of prefer if people didn’t go too crazy with Unicode emoji in internal layouts:

• People still use MAME with BDF bitmap fonts like uismall.bdf – these usually only have a basic set of characters for the user’s language.
• MAME isn’t guaranteed to support automatic character substitution, so for example on Linux, if the user has selected a font that doesn’t contain emoji characters, they won’t see them at all.
• Emoji are drawn completely differently on different platforms, and inconsistency is bad. They also change for political reasons. Consider that popular operating system replaced the image for the “gun” emoji with a water pistol a few years ago.

[johnparker007]

You know you can also use Lua script to do all sorts of stuff in 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).

[johnparker007]

I’d kind of prefer if people didn’t go too crazy with Unicode emoji in internal layouts:

• People still use MAME with BDF bitmap fonts like uismall.bdf – these usually only have a basic set of characters for the user’s language.
• MAME isn’t guaranteed to support automatic character substitution, so for example on Linux, if the user has selected a font that doesn’t contain emoji characters, they won’t see them at all.
• Emoji are drawn completely differently on different platforms, and inconsistency is bad. They also change for political reasons. Consider that popular operating system replaced the image for the “gun” emoji with a water pistol a few years ago.

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:

<?xml version="1.0" encoding="iso-8859-1"?>
<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
	 viewBox="0 0 183.952 183.952" style="enable-background:new 0 0 183.952 183.952;" xml:space="preserve">
	<path d="M152.617,1.06c-1.386-1.386-3.839-1.386-5.225,0l-44.415,44.417c-1.443,1.443-1.443,3.781,0,5.225
				c14.404,14.408,14.404,37.848,0,52.254c-14.408,14.408-37.848,14.408-52.256,0c-1.386-1.386-3.839-1.386-5.225,0L1.082,147.372
				c-1.443,1.443-1.443,3.781,0,5.225c20.888,20.89,48.328,31.335,75.768,31.335s54.879-10.444,75.768-31.335
				C194.396,110.82,194.396,42.84,152.617,1.06z M147.392,147.372c-38.026,38.024-99.353,38.88-138.424,2.565l39.25-39.251
				c17.401,14.736,43.576,13.903,59.985-2.506c16.407-16.407,17.24-42.58,2.504-59.983l39.251-39.251
				C186.272,48.017,185.415,109.35,147.392,147.372z"/>
	<rect x="60.092" y="91.425" transform="matrix(0.7071 0.7071 -0.7071 0.7071 85.9429 -17.2437)" width="7.389" height="7.39"/>
	<rect x="75.768" y="91.424" transform="matrix(-0.7071 -0.7071 0.7071 -0.7071 68.3913 218.5671)" width="7.389" height="7.39"/>
	<rect x="73.155" y="78.362" transform="matrix(0.7071 0.7071 -0.7071 0.7071 80.5317 -30.3071)" width="7.389" height="7.39"/>
	<rect x="88.83" y="83.587" transform="matrix(0.7071 -0.7071 0.7071 0.7071 -34.6172 90.9896)" width="7.392" height="7.389"/>
	<rect x="94.057" y="57.46" transform="matrix(0.7071 0.7071 -0.7071 0.7071 71.8725 -51.2089)" width="7.389" height="7.389"/>
	<rect x="86.218" y="70.52" transform="matrix(0.7071 0.7071 -0.7071 0.7071 78.8143 -41.8405)" width="7.389" height="7.392"/>
	<rect x="99.282" y="73.136" transform="matrix(0.7071 0.7071 -0.7071 0.7071 84.4895 -50.3121)" width="7.389" height="7.392"/>
	<rect x="86.219" y="96.647" transform="matrix(-0.7071 -0.7071 0.7071 -0.7071 82.5395 234.8732)" width="7.389" height="7.39"/>
</svg>

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:

		<element ref="reel_background">
			<bounds x="0" y="200" width="200" height="400"/>
		</element>	
		<group ref="Reel 1 As Group Containing Element" state="0">
			<bounds x="0" y="200" width="200" height="400"/>
			<yscroll name="sreel1" size="0.15" wrap="yes" min="65536" max="0"/>
		</group>	
		
		<element ref="reel_background">
			<bounds x="300" y="200" width="200" height="400"/>
		</element>		
		<group ref="Reel 1 As Group" state="0">
			<bounds x="300" y="200" width="200" height="400"/>
			<yscroll name="sreel1" size="0.15" wrap="yes" min="65536" max="0"/>
		</group>	
		
		<element ref="reel_background">
			<bounds x="600" y="200" width="200" height="400"/>
		</element>		
		<element ref="Reel 1" state="0">
			<bounds x="600" y="200" width="200" height="400"/>
			<yscroll name="sreel1" size="0.15" wrap="yes" min="65536" max="0"/>
		</element>

Here's a functional test layout showing the above, I was testing on j6indy, but any fruit will do :)
default.zip

(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 :) )

[james-wallace-ghub]

There is a LUA script example for generating 7seg displays from lamp lines - I did it for Double Take (v4dbltak)
The problem is that it requires the running of -plugin layout on the command line, whereas the SVG solution works on the command line by default.
I don't know which approach is preferred in this case, and I guess with the nature of this we're probably pushing the layout setup beyond the original logical design. Any advice as to a preferred style is appreciated (in both our cases), as obviously we need to be consistant if automation is going to come in.

[cuavas]

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

Extending the built-in components is the road to hell. It’s better to keep them simple. We’re not going to complicate them.

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

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.

I found an example SVG melon from the net:

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.

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

You‘re not understanding what a group element actually does or how scrolling words.

• A group is expanded at the time a layout is instantiated. It no longer exists as a concept when the layout is being drawn.
• The individual elements within the group are drawn as individual textured quads. They aren’t drawn to an intermediate texture for the group. In fact, elements can exceed their containing group’s bounds and won’t even be clipped.
• As such, you can’t do bounds animation, colour animation, etc. on a group. It simply doesn’t make sense.
• The scrolling is implemented by setting the texture coordinates on the quad for an element so it can be accelerated by your GPU. Since a group is not a texture this isn’t going to work.

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.

[johnparker007]

Ok thanks for the info and feedback, I will stick with all text for the internal layouts, no SVG reel symbols.

[ghost]

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)
https://www.youtube.com/watch?v=UDzqMevLH9Q Deal or No Deal Deal Wheel (doesn't currently boot, although used to IIRC) 3 views into a reel, although always near top.

[ghost]

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.

[johnparker007]

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.

[johnparker007]

@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
RESTART

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

[johnparker007]

@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:

[ghost]

hmm yeah, definitely not 2 then, I'll put it back to what it was

[james-wallace-ghub]

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.

[johnparker007]

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?

	  case 0x0F00:			// IC8
		pia6.write(addr & 3, x);
        if ( pia6.ca2_changed ) {
			decoder.write_A2( pia6.ca2);
            if ( MonitorActive )
              parent->do_io_sinks();
          if ( decoder.column == 0 )
              parent->do_lamp();
        }
		if ( pia6.orb_changed ) {  // Triacs
          sprintf(buffer, "Wrote %02x to Triacs", pia6.orb);
          DataWindow->AddMessage(AnsiString(buffer), 0xb0);
          if ( MonitorActive )
            parent->do_io_triacs();
          if ( Hopper_Type == 3 )
            duart.opto_drive(pia6.orb & 4, pia6.orb & 1, 0, 0);
          else if ( Hopper_Type == 5 )
            duart.opto_drive(pia6.orb & 4, pia6.orb & 1, pia6.orb & 4, pia6.orb & 2);
          triac.write(pia6.orb);
          if ( triac.changed )
            parent->do_triac();
        }
		if ( pia6.cb2_changed ) {
			display.write_clock(pia6.cb2,pia1.ca2);
          if ( display.display_changed || display.intensity_changed )
              parent->do_display();
            }
		break;

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

[ghost]

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.

[james-wallace-ghub]

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.

[ghost]

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?

[johnparker007]

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
j6indy8.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?

[james-wallace-ghub]

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.

[johnparker007]

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.

[ghost]

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.

[johnparker007]

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)

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

[johnparker007]

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

[johnparker007]

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:
https://www.youtube.com/watch?v=b5jrlBJuy44

So for me I'm seeing:

1. boot MAME with m4addr
2. press R when booted, TOKEN REFILL error appears
3. exit MAME
4. delete NVRAM
5. boot MAME with m4addr
6. Observe TOKEN REFILL error still displays on boot

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.

[johnparker007]

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

[ghost]

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

[ghost]

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.

[johnparker007]

Ah ok cool, so long as it's logged as a known issue, that's all good :)

[johnparker007]

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

[johnparker007]

@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:
https://www.youtube.com/watch?v=fyggvqPJ-zI

0x00, 0x60, 0x40, 0x60, 0x20, 0x40, 0x40, 0x20 (MAME driver correct lamp chr values)
0x00, 0x60, 0x40, 0x20, 0x60, 0x00, 0x00, 0x64 (MFME layout incorrect 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.

[ghost]

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.

[johnparker007]

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

[ghost]

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.

[ghost]

expanding upon this...

If you look at the default debug layout in MAME it is arranged like this

0 8  16 24 32 40 48 56 64 72 80 88 96  104 112 120
1 9  17 25 33 41 49 57 65 73 81 89 97  105 113 121
2 10 18 26 34 42 50 58 66 74 82 90 98  106 114 122
3 11 19 27 35 43 51 59 67 75 83 91 99  107 115 123
4 12 20 28 36 44 52 60 68 76 84 92 100 108 116 124
5 13 21 29 37 45 53 61 69 77 85 93 101 109 117 125
6 14 22 30 38 46 54 62 70 78 86 94 102 110 118 126
7 15 23 31 39 47 55 63 71 79 87 95 103 111 119 127

each of those 8 rows is controlled by a different value in the table

so in the case of the adders and ladders table
0x00 affects the lamps on the first row
0x60 2nd row
0x40 3rd row
0x60 4th row
0x20 5th row
0x40 6th row
0x40 7th row
0x20 8th row

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)

0  8  16 24  32  40  48  56  64 72 80 88  96  104 112  120 
to
64 72 80 88  96  104 112 120 0  8  16 24  32  40   48  56

which is a XOR of 64 (xor any value with 64) to get new lamp value

a value of 0x20 swaps like so

0  8  16 24  32 40 48 56  64 72  80  88   96 104 112 120
to
32 40 48 56  0  8  16 24  96 104 112 120  64 72  80  88

which is a XOR of 32 (xor any value with 32) to get new lamp value

a value of 0x10 swaps like so

0  8   16 24 32 40  48 56  64 72  80 88   96  104  112 120
to
16 24  0  8  48 56  32 40  80 88  64 72   112 120  96  104

which is a XOR of 16 (xor any value with 16) to get new lamp value

and a value of 0x08 swaps like so

0   8   16  24  32  40  48  56  64  72  80   88   96   104  112  120
to
8   0   24  16  40  32  56  48  72  64  88   80   104  96   120  112

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.

[johnparker007]

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

[johnparker007]

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:

https://www.youtube.com/watch?v=65ocbbkgXsc

[johnparker007]

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:
https://www.youtube.com/watch?v=b43YbFdpRI4

MPU4 Sunset Boulevard with boxed symbols:
https://www.youtube.com/watch?v=nMu7ksHJVe0
(this one will need several layouts, to account for I think 4 different Chr chips used through the different ROM versions, should be able to automate it into the new MPU4 lamp remapper)

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):
https://www.youtube.com/watch?v=qjWvvXH5eYk

[ghost]

this one will need several layouts, to account for I think 4 different Chr chips used through the different ROM versions, should be able to automate it into the new MPU4 lamp remapper)
The end result (once the game has descrambled the lamps using the table) should be the same regardless of CHR, if it isn't that suggests there might be an issue with one or more of the tables, or some of them were for a physically different machine. (For Red Alert that is clearly the case, m4ra__n is clearly not the same physical machine as m4ra, the former having a display for every lamp position / symbol rather than just the reels?

[johnparker007]

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

SunsetBoulevard.zip

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

[ghost]

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
m4sunset is a 'BSB 0.4' set
m4sunsetd is a 'SBU 2.0' set

m4sunsete is BS__ 1.1
m4sunsetk is SB__ 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)
and m4sunsete (BS__ 1.1) is the same as m4sunset (BSB 0.4)

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.

[johnparker007]

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)
m4sunsetc - Lamps & Buttons matching m4sunsetd (5p play)
m4sunsetd - (20p play) - this is the ROM set of the reference MFME layout)
m4sunsete - Lamps & Buttons not matching m4sunsetd (2p play)
m4sunsetk - Lamps & Buttons matching m4sunsetd (2p play)

If m4sunsetk (SB 1.1) is the same lamp setup as m4sunsetd (SBU 2.0)
and m4sunsete (BS_ 1.1) is the same as m4sunset (BSB 0.4) 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?)

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

[ghost]

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

[johnparker007]

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! :)

[johnparker007]

I'm just checking in :)

I've been continuing to work on this, a lot on the extraction side first to check how feasible it is, and now have all ~3k layouts selected, 'pre scraped', and can scrape around 150 per day... so all looking good so far (though a later phase is encoding all the reel symbols)... anyway, one snag now that I'm generating some initial test layouts is that a lot of them do not start due to:

Fatal error: render_texture::get_scaled: Too many live texture instances!

Would it be possible for the number of allowed 'live texture instances' to be say doubled please? :) With the improved lamp rendering and some more complex layouts this is triggering a lot, and is kinda blocking progress.

Worst case scenario if this current maximum texture instance value is not arbitrary, and cannot be doubled, I could go back to the old solid color rectangle lamps, I do much prefer the new ones though.

[johnparker007]

Re the above - to be clear it's not a problem having a lot of lamps, it's just a problem when the lamps are not sharing a bunch of common dimensions, e.g: here's a new one that has plenty of lamps, but doesn't crash MAME at launch as a lot of the lamps share common dimensions.

So I'll keep chipping away, but I'm kinda stuck if we can't increase the 'live texture instances' to say double, as otherwise MAME fails to launch a lot of the layouts with:

Fatal error: render_texture::get_scaled: Too many live texture instances!

If someone could let me know please if it's ok to make this change in MAME source, as I got 4 months of work stuck on this one MAME bug :) I could sync the code and find and fix the issue by doubling the max live texture instances value when I can find it, if that's acceptable? Ta guys :)

[galibert]

1fff4b0fc660131c13ee6fe5180b666d3c083e8b

Multiplied by 5, hoepfully it will be enough.

[johnparker007]

Thanks very much @galibert - that's perfect :)

I'm sure 5x will be more than enough - I could usually get them working by commenting out around a third of the lamps. Great stuff :)

[james-wallace-ghub]

On that same note, this should get rid of the hopper issues, in that I write directly to the DUART when I need to now. Someone should really check that what I'm doing to ticket.cpp is OK though, it's connecting the output state to a device line, but whether that's the best way IDK mamedev/mame#10404

…

On Wed, 12 Oct 2022, 11:00 John Parker, ***@***.***> wrote: Thanks very much @galibert <https://github.com/galibert> - that's perfect :) I'm sure 5x will be more than enough - I could usually get them working by commenting out around a third of the lamps. Great stuff :) — Reply to this email directly, view it on GitHub <#2 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACFVXMFNWVSDI6O6W6WSTIDWC2DZ3ANCNFSM5YM4BE2A> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[james-wallace-ghub]

OK, that's in now, so in theory we should be able to identify more DUART stuff. While I've been looking at Maygay M1 and related, it looks like we are going to need the analog beep circuit for MSM6376 after all, it's used a lot to supplement the regular samples as a sine wave generator. Since I can look into that without impacting on other stuff, I will, and then I'll try to take M1A/B to pieces as that address setup makes no sense that everything seems to be armed by 'reads' rather than writes, unless there's some very complex latching I/O going on.

[altharic]

I took the liberty of asking about Bell Fruit Flat Chassis at the Mecca someone posted a pic of one of the boards

https://www.fruitemu.co.uk/ib/topic/25725-bell-fruit-flat-chassis/#comment-374855

[Paul-Arnold]

That brings back memories, I remember repairing those. The triacs which drove the payslides had 240V on their tabs, dangerous times!

I don't recall the other electronic tech he posted though.

[johnparker007]

Hey @james-wallace-ghub and @mamehaze :)

I'd been ill so away from the scene for a while. I have been back to slowly plugging away on some FME-related stuff though :) It's not ready yet, but I thought a preview would be good. So the new project is a suite of programs (Oasis suite) to allow others to work on this stuff that I was doing all manually/with coding before.

So there is a split out tool in progress, that takes care of extracting layouts from MFME to an open JSON structure with accompanying BMP images:

...in conjunction with that I'm working on a Layout Editor:

...and this will have the MAME .lay builder ported/upgraded into it.

So the layout is firstly Extracted from MFME, then Imported into Layout Editor, and then can be Exported to MAME .lay format. The Layout Editor will also allow for creating layouts from scratch, so will be generally useful for MAME internal layouts outside of just fruit machine layouts.

It also runs MAME as a child process and can render the emulation/send input to MAME (via Lua), so this will be helpful if creating new layouts to test lamps/buttons etc:
https://www.youtube.com/watch?v=Eg1Txr5Eiis

All a work in progress for now, but thought it was worth an update :) Sorry I abandoned the last big attempt at this - but lots of that work is finding its way into this new work, so not a complete write off! And this way, it won't actually need specifically me, others will be able to help, with labelling reel text symbols etc (some people have indicated they'll be down to help with that sort of stuff from over on Dif forum.

The repo is here, and I'll update again once we're at the stage of outputting MAME .lay files, as I'm prioritising that over all the 3d stuff it will do later.

https://github.com/johnparker007/Oasis

[james-wallace-ghub]

It does feel to me that the lay creation is the stumbling block here, so something cleaner than the existing setup is a good move.

I think trying to find a good route to do this is something that has been beyond me, so I'm keen to see where this goes.