JPM SRU fruit machine improvements #9632

SomeRandomGuyIdk · 2022-04-26T19:29:12Z

Many improvements to the JPM SRU fruit machine driver to bring it out of skeleton state. Four games are now playable,
albeit with very barebones layouts. There are some games from the skeleton which I haven't looked at yet that I'll
deal with later. I've also found ROMs for a few more games, those are to be added soon.

Changes:

Many changes to the JPM SRU driver, 4 games now playable
SRU audio circuit netlist, not yet perfect
Very simple layouts for the games with proper symbols on the reels, also changed jpmsru.lay
Added JPM SRU reels to steppers.cpp
Created machine/genfruit.cpp, a common class with mechanical sound samples for fruit machines (same idea as genpin.cpp)

cuavas · 2022-04-26T19:45:23Z

src/mame/audio/nl_jpmsru.cpp

@@ -0,0 +1,64 @@
+// license:BSD-3-Clause


Is there any reason to be using a BSD license on a netlist? The facts (i.e. the actual list of parts and connections) are not eligible for copyright protection, the only actual creative work is the formatting, hence we usually just use CC0 for netlists to avoid annoyances.

Whoops, that was copy-pasted without paying much attention. Some netlists have BSD on them, must have taken it from one. Fixed.

cuavas · 2022-04-26T19:46:43Z

src/mame/includes/jpmsru.h

+	required_device<netlist_mame_logic_input_device> m_audio_in1;
+	required_device<netlist_mame_logic_input_device> m_audio_in2;
+	required_device<netlist_mame_logic_input_device> m_audio_in3;
+	required_device<netlist_mame_logic_input_device> m_audio_in4;
+	required_device<netlist_mame_logic_input_device> m_audio_in5;
+	required_device<netlist_mame_logic_input_device> m_audio_in6;


Can you use a required_device_array for this?

cuavas · 2022-04-26T19:49:00Z

src/mame/includes/jpmsru.h

+	jpmsru_state(const machine_config &mconfig, device_type type, const char *tag)
+		: genfruit_class(mconfig, type, tag),
+			m_maincpu(*this, "maincpu"),
+			m_inputs(*this, "IN%u", 0U),
+			m_reel(*this, "reel%u", 0U),
+			m_lamp(*this, "lamp%u", 0U),
+			m_digits(*this, "digit%u", 0U),
+			m_audio_in1(*this, "nl_audio:in1"),
+			m_audio_in2(*this, "nl_audio:in2"),
+			m_audio_in3(*this, "nl_audio:in3"),
+			m_audio_in4(*this, "nl_audio:in4"),
+			m_audio_in5(*this, "nl_audio:in5"),
+			m_audio_in6(*this, "nl_audio:in6"),
+			m_nvram(*this, "nvram", 0x80, ENDIANNESS_BIG),
+			m_dips(*this, "DIP%u", 0U)
+	{ }


Pick a style and stick with it, either

c(...) : m1(...), m2(...), m3(...), ...

or

c(...) : m1(...) , m2(...) , m3(...) ...

Not some combination of the two.

cuavas · 2022-04-26T19:50:54Z

src/mame/includes/jpmsru.h

+// license:BSD-3-Clause
+// copyright-holders:SomeRandomGuyIdk
+/**********************************************************************
+
+    JPM Stepper Reel Unit
+
+**********************************************************************/
+#ifndef MAME_INCLUDES_JPMSRU_H
+#define MAME_INCLUDES_JPMSRU_H


Why are you adding a header for this class? Is it really likely that there will be other driver classes derived from it?

cuavas · 2022-04-26T19:54:50Z

src/mame/drivers/jpmsru.cpp

+	int reel = (offset & 0xC) >> 2;
+	int bit = offset & 0x3;


Please be consistent with hex literal case – lowercase is used most of the time in MAME. Also, you can make variables that shouldn’t be changed const.

cuavas · 2022-04-26T19:57:40Z

src/mame/drivers/jpmsru.cpp

+	PORT_BIT( 0x01, IP_ACTIVE_HIGH, IPT_BUTTON2 ) PORT_NAME("Hold 1")
+	PORT_BIT( 0x02, IP_ACTIVE_HIGH, IPT_BUTTON3 ) PORT_NAME("Hold 2")
+	PORT_BIT( 0x04, IP_ACTIVE_HIGH, IPT_BUTTON4 ) PORT_NAME("Hold 3")


There are dedicated slot and poker input types for these kinds of things.

cuavas · 2022-04-26T20:00:43Z

src/mame/layout/j_dud.lay

+		<element name="lamp1" ref="matrixlamp" state="0">
+			<bounds x="8" y="0" width="7" height="7"/>
+		</element>
+		<element name="lamp2" ref="matrixlamp" state="0">
+			<bounds x="16" y="0" width="7" height="7"/>
+		</element>


You should really use repeating elements when you have a lot of things – it’s unmanageable like this.

cuavas · 2022-04-26T20:01:49Z

src/mame/layout/j_dud.lay

+	<element name="Reel 1" defstate="0">
+		<reel reelreversed="1" stateoffset="6540" numsymbolsvisible="5" symbollist="Watermelon,Pear,Bell,Cherry,Bell,Pear,Cherry,Bell,Pear,Orange,Bell,Grapes,Cherry,Pear,Cherry,Orange,Pear,Bell,Plum,JPM">
+			<color red="0.0" green="0.0" blue="0.0" />
+		</reel>
+	</element>


Reel components are deprecated and will be removed in the future. Please draw the text strings onto a texture and use a scroll window.

cuavas · 2022-04-26T20:04:43Z

src/mame/machine/genfruit.h

+// license:BSD-3-Clause
+// copyright-holders:SomeRandomGuyIdk
+#ifndef GENFRUIT_H_
+#define GENFRUIT_H_
+
+#include "sound/samples.h"
+
+#define SAMPLE_METER 0
+#define SAMPLE_PAYOUT 1
+
+const char *const genfruit_sample_names[] =
+{
+	"*genfruit",
+	"meter",
+	"payout",
+	nullptr   /* end of array */
+};


Fake samples for events really isn’t the direction we want to go in. Please don’t start doing this for fruit machines.

Are samples very frowned upon? MFME has them, plus IMO they make the experience a bit more authentic. Also for
machines this old, in some cases payout sounds are the only feedback about winning something. Just something I'd like to keep.

ghost · 2022-04-27T17:02:36Z

Thank you for looking at these, always good to get people with a better understanding of how they all worked on board :-)

ghost · 2022-05-07T19:09:06Z

Personally I think this is where we should bend a little, it will help with acceptance of these in MAME and build some momentum. AFAIK we have samples in some other similar cases

…

On Sat, 7 May 2022, 20:02 SomeRandomGuyIdk, ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In src/mame/machine/genfruit.h <#9632 (comment)>: > +// license:BSD-3-Clause +// copyright-holders:SomeRandomGuyIdk +#ifndef GENFRUIT_H_ +#define GENFRUIT_H_ + +#include "sound/samples.h" + +#define SAMPLE_METER 0 +#define SAMPLE_PAYOUT 1 + +const char *const genfruit_sample_names[] = +{ + "*genfruit", + "meter", + "payout", + nullptr /* end of array */ +}; Are samples very frowned upon? MFME has them, plus IMO they make the experience a bit more authentic. Also for machines this old, in some cases payout sounds are the only feedback about winning something. Just something I'd like to keep. — Reply to this email directly, view it on GitHub <#9632 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AG2MR3VVX7MDB43A2SFP4VLVI2445ANCNFSM5UM3PSKQ> . You are receiving this because you commented.Message ID: ***@***.***>

einstein95 · 2022-05-07T20:41:53Z

My 2 cents is that samples like these are similar, if not identical, to the floppy noises, being noises generated by mechanical parts attached to the machine.

MooglyGuy · 2022-05-08T12:25:22Z

I tend to agree, and the justification that @SomeRandomGuyIdk mentioned is the same justification for floppy-noise samples remaining in: In some cases, particularly older and slower systems, those audio cues can be your only clue that the system is actually doing something.

cuavas · 2022-05-08T19:44:10Z

I think at some point we probably need better abstractions for hoppers, etc. There are a lot of things that use them, e.g. all the medal mahjong games. In general the approach used so far is to just make the game work, and not do anything that would make it too easy to hook up to a real payout mechanism to avoid even entertaining the possibility of people using MAME on location in redemption machines.

I still don’t like the idea of having a “generic fruit machine” base class, because it’s a large class of machines with very little in common. It also becomes problematic when you have a platform that’s used for multiple purposes, like the mahjong platforms that are used for video strip mahjong as well as medal mahjong.

cuavas · 2022-05-08T19:32:19Z

src/mame/drivers/jpmsru.cpp

+	void out_disp_w(offs_t offset, uint8_t data);
+	void out_payout_cash_w(offs_t offset, uint8_t data);
+	void out_payout_token_w(offs_t offset, uint8_t data);
+	template<unsigned meter> void out_meter_w(offs_t offset, uint8_t data);


Please use LlamaCase for template parameter names to make it clearer that they’re semantically different to function parameters.

cuavas · 2022-05-08T19:44:52Z

src/mame/machine/genfruit.h

+#ifndef GENFRUIT_H_
+#define GENFRUIT_H_


This doesn’t follow the format for include guards.

cuavas · 2022-05-08T19:45:43Z

src/mame/machine/genfruit.h

+#define SAMPLE_METER 0
+#define SAMPLE_PAYOUT 1
+
+const char *const genfruit_sample_names[] =


You shouldn’t be using preprocessor macros when it isn’t absolutely necessary, and you shouldn’t be putting things in the global namespace unnecessarily.

cuavas · 2022-05-08T19:47:33Z

src/mame/drivers/jpmsru.cpp

 #include "cpu/tms9900/tms9980a.h"
+#include "machine/timer.h"
+#include "machine/steppers.h"
+#include "machine/genfruit.h"
+#include "machine/nvram.h"
+#include "video/awpvid.h"
+#include "machine/netlist.h"
+#include "netlist/nl_setup.h"
+#include "speaker.h"
+#include "audio/nl_jpmsru.h"


These should be grouped with stuff from src/mame, src/devices and src/emu, and src/lib separated. We order the groups most-dependent to least-dependent to help catch cases of headers not including other headers that they should.

cuavas · 2022-05-08T19:49:36Z

The CI builds are failing with a link error:

/usr/bin/ld: ../../../../linux_clang/bin/x64/Release/mame_mame/libjpm.a(jpmsru.o): in function `jpmsru_state::jpmsru_3k(machine_config&)':
jpmsru.cpp:(.text+0x1990): undefined reference to `genfruit_class::genfruit_audio(machine_config&)'
/usr/bin/ld: jpmsru.cpp:(.text+0x19f5): undefined reference to `netlist_jpmsru(netlist::nlparse_t&)'

This seems to be directly related to this PR, not an unrelated bad commit.

ghost · 2022-05-09T11:01:38Z

I still don’t like the idea of having a “generic fruit machine” base class

Yeah, I'm inclined to agree. Over the years I've spend quite a lot of time untangling such things, and we ended up with a lot of cases where there were base classes for very simple functionality that really belonged in a device, or was less code just in the drivers.

I can't really think of many good uses for 'base classes' across multiple drivers, more often than not that functionality is better placed a device that can be shared.

The fruit machine samples could be handled in such a way, a device, rather than a base class.

The general consensus seems to be that such samples are a good idea, but maybe implementing them should be deferred to a separate PR, so that the functionality fixes can go in first.

SomeRandomGuyIdk · 2022-05-09T20:51:00Z

Yup, something like a fruit_samples_device seems like a way better idea. I just based this off of what some of the pinballs are doing, which I guess is quite outdated. Hopefully the build works now.

cuavas · 2022-05-10T14:01:11Z

It seems to build now anyway. Move the sound samples into a device of some kind, and then we should be able to merge this.

cuavas · 2022-05-14T21:05:24Z

scripts/src/machine.lua

+---------------------------------------------------
+--
+--@src/devices/machine/fruitsamples.h,MACHINES["FRUITSAMPLES"] = true
+---------------------------------------------------
+
+if (MACHINES["FRUITSAMPLES"]~=null) then
+	files {
+		MAME_DIR .. "src/devices/machine/fruitsamples.cpp",
+		MAME_DIR .. "src/devices/machine/fruitsamples.h",
+	}
+end
+


Please put this thing in src/mame/audio instead.

cuavas · 2022-05-14T21:06:49Z

src/devices/machine/fruitsamples.cpp

+void fruit_samples_device::play(uint8_t index)
+{
+	if(index < SAMPLE_END) m_samples->start(fruit_sample_channels[index], index);
+}


Better to assert that the sample number is valid or throw a fatal error for out-of-range samples – it’s a programming error if that happens. Also, this file is missing the ending newline.

cuavas · 2022-05-14T21:07:33Z

src/devices/machine/fruitsamples.h

+
+#include "sound/samples.h"
+
+#include "speaker.h"


Does this need to be in the header? It increases dependencies.

cuavas · 2022-05-14T21:08:39Z

src/devices/machine/fruitsamples.h

+	const char *fruit_sample_names[SAMPLE_END + 2] =
+	{
+		"*fruitsamples",
+		"payout",
+		"meter",
+		nullptr   /* end of array */
+	};
+	const uint8_t fruit_sample_channels[SAMPLE_END] =
+	{
+		0,
+		1
+	};


Please don’t put definitions for this stuff in the header – it increases fragility and slows down compilation of dependent code. Also, you have an array of non-const pointers which you shouldn’t.

cuavas · 2022-05-14T21:09:14Z

src/devices/machine/fruitsamples.h

+
+DECLARE_DEVICE_TYPE(FRUIT_SAMPLES, fruit_samples_device)
+
+#endif // MAME_MACHINE_FRUITSAMPLES_H


This is missing the ending newline, and the #include guard name will have to change when it moves.

SomeRandomGuyIdk · 2022-05-14T22:21:48Z

Alright, fixes are in, that was quick. Also I found a bug: scroll windows don't render properly using BGFX. They look fine with everything else.

cuavas · 2022-05-16T18:47:38Z

Also I found a bug: scroll windows don't render properly using BGFX. They look fine with everything else.

Do you have any clue as to what triggers it? Is it just not implementing the texture wrap flag? For sc2prem, one of the reels appears OK, but the other three don’t. What’s special about the one that “works”?

MooglyGuy · 2022-05-16T20:25:07Z

I wonder if a minimum test case could be constructed using a skeleton driver and an external layout. I'd be interested in knowing more about the issue so I can debug it.

cuavas · 2022-05-16T20:26:03Z

I wonder if a minimum test case could be constructed using a skeleton driver and an external layout. I'd be interested in knowing more about the issue so I can debug it.

I’ll hook you up with a simple demo at some point.

cuavas · 2022-05-17T01:56:30Z

@MooglyGuy I’m pretty sure the issue is just that the bgfx module is always specifying texture clamping rather than wrapping (ignoring PRIMFLAG_TEXWRAP). Attached starwars artwork demonstrates it – choose “Analog Control Display” view and move the joystick around.
starwars.zip

Tafoid · 2022-05-17T11:56:23Z

To @SomeRandomGuyIdk - We haven't seen that you sent in the samples to our submission address. Kindly send these to the same address the other newly added data was sent in support for this PR, please.

cuavas · 2022-05-17T13:02:33Z

I don’t think trying to have “official” samples for this is a good idea at all. Machines sound different, it’s just a crude approximation. Let people put in whatever samples make them happy.

SomeRandomGuyIdk · 2022-05-17T15:08:21Z

@Tafoid Well as it stands right now the samples I'm using were "recorded" from someone's YouTube video of a real machine, so I'm not sure if that would really fly. Plus like cuavas said, the sounds differ across all the cabinets and techs, so samples seem like the kind of thing to be distributed together with a given machine's layout artwork, once we get that far. Though a set of generic samples could be useful. I don't have any such samples handy though.

ghost · 2022-05-25T21:30:45Z

scorpion 4 regressed at some point, yeah, the code to get it running in the first place was all kinds of gross though, and I think it breaking was probably a neccessary step in improving the CPU for other things, maybe it can be fixed up again.

and yes, it seems that elements without text get entirely lost in the process, eg. for Road Hog the 'police position' trail markers simply aren't there at all from what I can see?

some others have missing elements that maybe should be text though, boulder dash has a 'lose' lamp for some of the features, but no win lamps?

I was hoping there would be a Rocky Horror Show layout in here, alas there isn't

johnparker007 · 2022-05-25T21:53:21Z

Yeah I've just checked, started assembling some of the work dirs I used to have, since I actually back up now :) Time is tight, but I could look at setting up the 216x convert configs again. I could then conceivably get these missing lamps represented in some way.

Looking at m4rhog, it seems to have come from a classic (that's not the newest classic available back then curiously) - so it has a blue bitmap graphic for those blue markers:

What I'll do is chip away over the next week or so, and hopefully make some headway in getting these set up for live converting again, plus with the converter building from source, so then I could do stuff like, where there is a bitmap, give it a square lamp that is the average colour of the bitmap, or something like that...

And in the interim, those ones you have now should be good for debugging/testing :)

If I can get these rebuilding, the rebuilds will no have reel symbols set up as that takes a really long time (but then they could have blank lamps for lamps without text, or bitmap graphics). I'll see about some kind of automated thing that could lookup and paste the reel symbols in from these recovered .lay files... or something like that.

Also - just noticed - it looks like the 'labels' are missing too - clearly I still had some tasks left to do in this converter! Fingers crossed I can get it all up and running again, to make these improvements.

ghost · 2022-05-25T22:02:59Z

if you include the reel bitmaps in the packages I don't mind translating those to the layouts by hand, having all the lamps and labels etc. is the important part that's quite a chore to do otherwise

likewise some of the bitmaps (eg the 777 logos on that one) a placeholder in the layout, even if it just says 'image xx here' that I can modify is easier than no element at all

ghost · 2022-05-25T22:14:18Z

also any simple text element that is set to close to black probably needs to be set to white, as MAME's backgrounds is black by default, so elements can get lost that way

johnparker007 · 2022-05-25T22:16:46Z

I think for the MPU4 layouts I sent you tonight, the reel symbols are actually all set up :)

So that could hopefully be done automatically, to save having to type them again...

So, I think my initial to do list looks like:

get the building set up for 1 layout
export all the lamp/reel/static images per layout as a kind of debug feature
where there's an image, do a placeholder with that image filename, so they can be changed to text later
get the label working, not sure why I didn't do that before
any simple text element that is set to close to black probably needs to be set to white
something to patch in the reel symbol text from the old already built layouts
set it all up again for those 216 layouts, and build all layouts

I think they look better in the MAME colour scheme. I remember back when I did this, I was going to honour the original MFME layout colours (white background), but then it just looked a lot cooler with the black background!

Leave it with me, though I'm a little time challenged these days with work/life/arcade sim, but I will definitely squeeze this in here and there, and get through it :)

johnparker007 · 2022-05-25T22:23:21Z

Aaah right, I see why you mentioned black text elements! :) So in road hog layout above, those labels are there but in black colour text, doh!

<element name="label_69">
	<text string="Bid">
		<color red="0.0" green="0.0" blue="0.0">
		</color>
		<bounds x="0.05" y="0.05" width="0.90" height="0.90">
		</bounds>
	</text>
</element>

That's a bit better than I thought then, was thinking I'd not even done labels at all.

james-wallace-ghub · 2022-05-27T15:38:41Z

I was going to go through my workflow, but David already has, so that's fine. I ended up too busy to keep going with this, and started picking out games of interest instead, but if there were multiple minded people running this setup, it could be very useful.

…

On Thu, 26 May 2022, 00:23 John Parker, ***@***.***> wrote: Aaah right, I see why you mentioned black text elements! :) So in road hog layout above, those labels are there but in black colour text, doh! <element name="label_69"> <text string="Bid"> <color red="0.0" green="0.0" blue="0.0"> </color> <bounds x="0.05" y="0.05" width="0.90" height="0.90"> </bounds> </text> </element> That's a bit better than I thought then, was thinking I'd not even done labels at all. — Reply to this email directly, view it on GitHub <#9632 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACFVXMEWHOLWVYF2WD2LYODVL2R6JANCNFSM5UM3PSKQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

johnparker007 · 2022-06-05T17:01:23Z

@davidhaywood Just checking in, to say after a little break I've been looking into this stuff over the weekend. I am having some issues with it, but I'm also leaning towards porting/rewriting the MAME XML generation stuff in my Arcade Simulator project, as otherwise we're locked to an old version of MFME - and so I can't generate any Scorpion 5 MAME 'classic' layouts for example (as that 'tech' platform was not implemented in MFME at that point).

The new system I use is somewhat flakey, and built into my very large project... though I could potentially in future look at then porting that out, to make some kind of standalone converter that other people could use. The new flakey system (used by Arcade Sim) loads the latest MFME.exe, and then 'remote controls' it with simulated mouse/keyboard input, combined with screen scraping (which occasionally freezes and crashes). But this is how I work around the layers of obfuscation Chris added in (due to the original mfme2mame project I think!) - I really don't fancy trying to make something that can convert the raw .fml files themselves. A more ideal version would be something that actually pulls the C data structures and image data out of MFMEs allocated memory itself (rather than the remote control/screen scraping) after loading the layout, though this flakey way I've done it is far more intuitive to develop, and is already working ok-ish, as I've done 'DX' layouts for Arcade Sim.

Bonus example of Adders & Ladders I saw you worked on recently in your youtube video :)

So bear with me for the moment, this is my main focus now when I do have time for FME dev - but I think I will retire the old version of mfme2mame and build a new version inside Arcade Simulator, since once it's done it'll be much nicer to work in (rather than writing stuff in Borland c++ Delphi in a Windows XP virtual machine!), and we'll get many more layouts. I'll also get everything up to the latest MAME .lay recommended guidelines - I see the reels have changed to be scrollable text boxes etc.

If I do go this way, I will generate the MPU4 Classics as the first batch, to go in with all the work you've been doing recently.

ghost · 2022-06-05T18:28:30Z

Thanks for the updates, and yeah a lot has changed with MAME too.

The MPU4 progress PR is at
#9760 (comment)
(I closed it for now to stop mamedev getting spam from it)

I'm going through all the sets with lamp scramble and figuring them out manually, by comparing sets, unprotected/bootleg versions, groups the chrs etc. The goal will eventually be to adapt any layouts that are created to have correct values for all the different payment levels and such. In some cases I think existing layouts were built around incorrectly descrambled data.

Quite a few sets still don't boot due to reel issues, or hopper issues (although apart from the Dutch ones I can test those with Door Open) so I need to work on those at some point.

ghost · 2022-06-05T20:31:00Z

I've moved the MPU4 changeset to #9893 as the old one had merge conflicts

johnparker007 · 2022-06-05T21:36:55Z

Just been reading through your diffs, a lot of changes going on :)

"In some cases I think existing layouts were built around incorrectly descrambled data."

Yes that's definitely true for some MPU4 layouts, I have found this when creating 'chr free' ROMs for use in real machines (where the Chr chip has failed/been lost). So then on the real machine the lamps will be scrambled (as I'm using the 8x lamp values from the MFME layout, which only work within MFME as the layout also has some lamps swapped around to match the wrong Chr lamp data).

An example of that is Classic Adders & Ladders MPU4. On the real machine, the lamp numbers for the bottom row of the Snakes & Ladders board are:

120, 121, 122, 123, 124, 125

But in the MFME layout, the lamp numbers are:

120, 121, 122, 59, 60, 29

But the Chr lamp table values have been accordingly set up so that it actually all works in MFME - this is presumably from someone starting with just a ROM and nothing else, no manual etc, shuffling things around until the machine starts displaying correct lamps, to build the initial 'classic' layout.

ghost · 2022-06-06T00:05:38Z

yeah, that's exactly what I found with Adders and ladders, the PR in the other thread of conversation hacks the layout to work with the 'bootleg' ROM and the scramble table I made based on that, rather than the one based on the existing layout.

it's actually kinda obvious in that one, because if you look at the lamp layouts, the proper descrambled version dedicates a logical block to the 'big characters' it writes using the lamps on the game board, whereas the existing layout doesn't have that logically arranged.

it's also interesting that some games bypass the scramble entirely for a few elements / clear effects, so using the wrong descramble results in other imperfections. (eg some full board wipe effects are hardcoded lamp values in the game code, rather than going through the scramble)

I did notice in the code, after reading the lamp scramble it doesn't mask out some of the bits not involved in the lamp scrambling, so I hope those don't have a deeper meaning in terms of game balance, but for now the priority for me has been getting what seem like the most logical descrambles for each set.

I do also need to investigate if some of the scrambles aren't just the same logic, but with the output lines connected in a different order; there are a few interesting cases where it looks like a line has been tied high, eg. rocket money, where I wonder if they used a common chip but pulled up a single line on the output to make it appear different (I'll start to look for such patterns in a subsequent step)

in the end we need to figure out the real equations from the PALs, as I suspect even the quiz games, which make more extensive use of the device, are just checking states / lines that the regular CHR check doesn't care about. For now I'm just documenting all the patterns however, to see if anything sticks out. Sadly the PALs are protected parts, which means dumping them with traditional methods results in invalid equations.

it's also very obvious from the work I've done so far that we're missing a lot of sound ROMs for the alt. sets. where sound codes have been moved around on features etc.

in terms of encryption / protection of layout files output by newer MFME, we do have devs such as @galibert who are good at figuring out encryptions, so examples of a file saved out from the older version, then reloaded and saved out from a current version may allow for the format to be decoded, and the rather irresponsible action of trying to lock everything up reversed, but for now my priority is trying to get the machines running.

james-wallace-ghub · 2022-06-06T10:43:10Z

The Vegas Poker CHR is meant to be unprotected, I think we have that in the set as a PLD. If we don't, nag me tonight and I'll dig it off my external HD. Admittefly, that's a BwB game though, and I think they certainly used the hardware differently, if it's not altogether different in and of itself.

…

On Mon, 6 Jun 2022 at 01:05, David Haywood ***@***.***> wrote: yeah, that's exactly what I found with Adders and ladders, the PR in the other thread hacks the layout to work with the 'bootleg' ROM and the other scramble table. it's actually kinda obvious in that one, because if you look at the lamp layouts, the proper descrambled version dedicates a logical block to the 'big characters' it writes using the lamps on the game board, whereas the existing layout doesn't have that logically arranged. it's also interesting that some games bypass the scramble entirely for a few elements / clear effects, so using the wrong descramble results in other imperfections. I did notice in the code, after reading the lamp scramble it doesn't mask out some of the bits not involved in the lamp scrambling, so I hope those don't have a deeper meaning in terms of game balance, but for now the priority for me has been getting what seem like the most logical descrambles for each set. I do also need to investigate if some of the scrambles aren't just the same logic, but with the output lines connected in a different order; there are a few interesting cases where it looks like a line has been tied high, eg. rocket money, where I wonder if they used a common chip but pulled up a single line on the output to make it appear different (I'll start to look for such patterns in a subsequent step) in the end we need to figure out the real equations from the PALs, as I suspect even the quiz games, which make more extensive use of the device, are just checking states / lines that the regular CHR check doesn't care about. For now I'm just documenting all the patterns however, to see if anything sticks out. Sadly the PALs are protected parts, which means dumping them with traditional methods results in invalid equations. — Reply to this email directly, view it on GitHub <#9632 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACFVXMHJHYBV4YMG4GOQKTDVNU6FZANCNFSM5UM3PSKQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

johnparker007 · 2022-06-06T20:53:34Z

"the layout to work with the 'bootleg' ROM and the scramble table I made based on that, rather than the one based on the existing layout." - that's a good idea to get the real 8x Chr lamp values :)

I don't want to put @galibert out as at this stage, I'm probably going to soldier on with my slightly flakey remote control/screen capture method for now, just as I've got it kinda working already (even though it's probably the worst technique!).

That said, here is an example of (Classic Adders & Ladders DX) - the same layout in both the original format, and the new 'fml' format. I really don't know if I can devote the time to decoding that file format, even after it's decompressed/decrypted etc - but here they are regardless, if anyone fancies a poke around :)

Adders_&Ladders(Barcrest)_[Dx08_1280_6jp]_DAT_FORMAT.zip

Adders_&Ladders(Barcrest)_[Dx08_6jp]_FML_FORMAT.zip

I did have a little look before, and there are fingerprints of some Delphi compression system in there from what I remember.

I did also check, and as James says, there is indeed a pal dump to a bin file in the v4vgpok romset. It's marked as a prototype, perhaps that's how it slipped through without being properly protected, handy for researchers, shame it's a Bwb not the more common Barcrest, but still very cool! :)

ghost · 2022-06-07T12:06:13Z

The problem is, from memory the v4vgpok prototype set doesn't access the CHR in the first place, so I'd be surprised if it's programmed with useful equations, which may be why it isn't protected.

SomeRandomGuyIdk · 2022-06-08T10:42:50Z

So I decided to have a look at the MFME protection to see what it's all about, and well, long story short, I now have a patched MFME that can decrypt FML files :D

The protection itself is indeed some obscure Delphi compression library that can encrypt files with a password. I was
fiddling around trying to make a program to extract the password from an FML and decrypt it using the library. It
actually worked but was VERY janky and threw an error on some layouts, probably because the version of the library I had
was newer than the ancient one used by MFME, which was nowhere to be found anymore. Delphi was very fun to use, I can probably understand now how John feels towards working with it :D. Eventually I realized I can just patch MFME itself, so I did just that and looks like it works very well. Also found out MFME has a layout blacklist, because of course it does. Don't have any
further plans regarding layout stuff, this was more of a cracking exercise. Anyway, here's the link:

https://www79.zippyshare.com/v/0Vgxce2U/file.html

The EXE is larger than the original due to being unpacked. Usage is simple, just save the layout with Save Layout and it'll spit it out in decrypted & decompressed form.

johnparker007 · 2022-06-08T12:12:56Z

Oh my god lol! :) Respect to those hacking skillz mate :)

As I said above, I'm probably going to continue what I've already started back on last night, with using my existing Arcade Simulator extractor... But, I will absolutely take some times to explore how feasible it would be to use this instead of my 'flakey' system.

The problem I guess is that my system is already done and working (though it is flakey/delicate when running, it can lose sync and crash), I just need to spend more time adding in things that will be useful for MAME (extracting per-platform info, such as Reel Configuration, Hopper Configuration etc), so the per-game drive settings can be easily populated.

If I had to start from scratch, I would definitely go this way, as it'll be lightning fast per layout, and completely reliable - I just didn't have the skillset to know how to approach removing the obfuscation that was added (to stop me basically, as I already did this years ago, to make the original 'mfme2mame' layouts that are in MAME)... I'll have to see if I can now decode that data stream, to pull out the components, images, etc. I think it's going to be along the lines of figuring out the original C structures in MFME 20.1, like

int ReelNumber;
byte ReelType;
short ReelOffset;
etc...

and how the images are stored (based on what I remember of loading code from a very old version of MFME that had code leaked). I guess also there'll be unions to take into account, plus no idea if the images are just pointers and then an array later. In the original code that was leaked, the loader was very messy, so it would set up things on the fly based on certain bits etc, it's not really like how a modern loader would work (at least not how I would write one, in terms of readability/maintainability).

I don't want to appear ungrateful :) ...but it may take me far longer to decode this now-unprotected format from scratch, than continuing to develop the 'flakey' extractor. I'll definitely need to have a pause and re-evaluate at this stage - I really didn't expect anyone to actually crack it lol!

It is amazing to have the option though, I am looking forward to seeing what I can pull out.

Currently, my system pulls the MFME stuff out (via the flakey remote control+screen scraping) to raw .bmps and a big json file containing the data in human readable form. This interim 'format' is what I then use to build the Arcade Simulator 3d fruit machines, and also am planning to build the new MAME XML .lay files from. Here's an example extracted layout:
https://www.dropbox.com/s/jwci9evtkur55b7/Brix%28German%29%28Mazooma%29_Output.zip?dl=0

I'm torn right now, whether to switch over and start 'from scratch' to some extent, but it will be far superior, not having to remote control/screen scrape... decisions, decisions... :)

Thanks very much for doing this, it's a real surprise! :D

ghost · 2022-06-08T14:00:40Z

@SomeRandomGuyIdk could you throw it on mediafire or another sharing site, Zippyshare is blocking the UK, or at least large parts of the major ISPs, and has been for at least 4 years (I just get '403 error, forbidden' on any Zippyshare link)

johnparker007 · 2022-06-08T14:12:57Z

@davidhaywood I've dl'd via VPN and reuploaded to my dropbox:

https://www.dropbox.com/s/h66db42n8jrf5iv/MFME.exe?dl=0

(Windows Defender is throwing false positive btw)

ghost · 2022-06-08T14:21:50Z

Hopefully a false positive at least, I wouldn't put it past him to have hidden some malware in there back in the day given everything else...

johnparker007 · 2022-06-08T14:30:19Z

I dropped it in VirusTotal, looks like a false positive, most vendors not flagging it:

MooglyGuy · 2022-06-08T14:46:42Z

BehavesLike.Win32.Dropper.nh is a pretty common false-positive for anything that has an installer or installer-like functionality. I'm not seeing many (any) reports of false-positives involving the second one (BScope.TrojanDownloader.Agent), but it could also be a single over-sensitive program. If MFME has any sort of auto-updater where it can download things from a website, that could plausibly trigger that flag.

johnparker007 · 2022-06-08T15:04:31Z

"If MFME has any sort of auto-updater where it can download things from a website"

It does, it downloads ROMs and also the final update (v20.0 -> v20.1) from DesertIslandFruits fileserver

SomeRandomGuyIdk · 2022-06-08T17:18:18Z

@johnparker007 You're welcome man :)
Didn't know about the Zippyshare situation, will keep that in mind. I would say MFME is safe, there's no anti-debugging/reverse engineering stuff in there for possibly hiding something, and I didn't see anything suspicious while I was looking inside. Very likely indeed that it's the updater that the antiviruses are freaking out over, they're very paranoid nowadays.

ghost · 2022-06-08T21:35:08Z

Yeah to be fair I can't blame them, auto updaters are bad news,

I've got old game CDs and music CDs that will automatically open compromised sites, or download executables that ring alarm bells when they attempt to update / show 'bonus online content' as the original publishers are long gone and domain ownership fell into the wrong hands. It's probably only a matter of time until that happens with MFME, and if there's no real security on the update process it's a time bomb.

johnparker007 · 2022-06-08T22:34:26Z

@SomeRandomGuyIdk I did have an initial play, though I think it's as I suspected - to figure out and reverse-engineer this is going to be a ton of work (for me at least!).

Put a little thing together in Unity to pull out some 'header' data which is completely fixed so super simple, and I suspect I might even use that 'Caption' data, as it's the Window title I've been using for the scraping:

I see the info in there (coordinates, RGBA byte arrays etc), but offsets/lengths don't seem fixed once I start adding/changing things... some of it must be serialised/deep copies of class instances, a massive project to reverse engineer it all though. I'll perhaps spend another night or two on it, but I think it's likely I'll revert back to working on the 'flakey but already built' Unity-based MFME Layout Extractor for now, so I can get all the 'classic' MAME layouts and configs rebuilt.

Thanks again though, I will keeping poking around with it :)

SomeRandomGuyIdk · 2022-06-09T11:03:35Z

No worries, just wanted to get this thing out there, I'm not demanding anyone to immediately start using this :)

cuavas · 2022-06-10T08:18:51Z

Please don’t use pull requests/issues as a substitute for a forum. I enabled GitHub discussions and added a category just for you guys, so you have no excuse: https://github.com/orgs/mamedev/discussions/categories/fruit-machine-emulation

Robbbert · 2022-06-10T13:02:52Z

or https://github.com/orgs/mamedev/discussions/2 to continue this particular discussion.

JPM SRU improvements

37215ca

cuavas requested changes Apr 26, 2022

View reviewed changes

SomeRandomGuyIdk added 4 commits May 7, 2022 21:14

Fixes

7302e54

Formatting fix

0ac7595

Formatting fix fix, diff doesn't show things right

1ea7ece

Added consts

8d4ee43

cuavas requested changes May 8, 2022

View reviewed changes

Fixes

54ef505

Added fruit_samples_device

b921e4d

cuavas requested changes May 14, 2022

View reviewed changes

Fixes

91b3462

audio/fruitsamples.cpp: Cleanup

ece20fc

cuavas merged commit e9ff2dd into mamedev:master May 16, 2022

mamedev locked as off-topic and limited conversation to collaborators Jun 10, 2022


		DECLARE_DEVICE_TYPE(FRUIT_SAMPLES, fruit_samples_device)

		#endif // MAME_MACHINE_FRUITSAMPLES_H

		#ifndef GENFRUIT_H_
		#define GENFRUIT_H_

JPM SRU fruit machine improvements #9632

JPM SRU fruit machine improvements #9632

Uh oh!

Conversation

SomeRandomGuyIdk commented Apr 26, 2022

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ghost commented Apr 27, 2022

Uh oh!

ghost commented May 7, 2022 via email

Uh oh!

einstein95 commented May 7, 2022

Uh oh!

MooglyGuy commented May 8, 2022

Uh oh!

cuavas commented May 8, 2022

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cuavas commented May 8, 2022

Uh oh!

ghost commented May 9, 2022 • edited by ghost Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

SomeRandomGuyIdk commented May 9, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cuavas commented May 10, 2022

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ghost commented May 9, 2022 •

edited by ghost

Loading

SomeRandomGuyIdk commented May 9, 2022 •

edited

Loading

cuavas commented May 17, 2022 •

edited

Loading

johnparker007 commented May 25, 2022 •

edited

Loading

ghost commented May 25, 2022 •

edited by ghost

Loading