Setting up different test scenarios using MFME

[RickB]

I'm very new to MFME but I'm already very curious about the payout algorithms used by various machines. They vary wildly in how they behave in situations where you'd think the machine would be very keen to pay out. The old Maygay EastEnders machine was very easy to "read", but some others - such as X Marks the Spot or Crazy Fruits were nigh on impossible to suss out.

Since we have no access to the original source code, including the system libraries, it's not really feasible to work these things out by looking at the disassembly (while I am totally fine with C and C++, even if I knew the mnemonics for 6502 or 68000 assembly language, you'd also need an intimate understanding of the hardware and memory maps to really get anywhere). And even though tools exist for converting assembly language back into a higher level language, it would still be very hard to understand without hints from variable and function names, code comments, and detailed knowledge of the hardware.

So, it looks like trial and error might be the only way.

In MFME, I've played around with using the "C" button to put the machine into configuration mode, then set up the "In" value to try and manipulate the machine's own idea of its current payout status (adjusting it to something like 10%). Am I on the right track? This doesn't seem to have worked so far. Not sure if I'm fiddling with the wrong value, or accidentally overflowing an internal counter, or similar.

Thanks for any insight you can give me

 

[Mort]

Hi Rick, welcome to the journey!

I think many of us here with inquisitive minds have thought about these sorts of things and have tried to find answers over the years.

Completely agree with all you say about disassembly. It's a huge amount of work, more than anyone can fully realise, and even then much of it will require some elements of guess work, and we will still not receive many of the answers we are looking for at the end of it (even if there could be an end of it!)

For this, we need to look at help from the ex. real coders, by releasing the original source code, but even with this, most of us will not understand it anyway and then there are surely multiple libraries related to that source code, so we would need source code for those libraries as well, and the issue goes on.

In my honest opinion, if we were going to see this, then we would have seen it, or at least some of it, by now. We have had everything in FME really except this.

As for your query on meters, whether those be long-term or short-term, you have to think of them as just separate counters in the RAM. They most likely have no relation to how a game plays or what it owes etc. That information, in our compensated machines, is instead stored in the various game compensators that a machine has. It's a virtual money value, then linked to different compensator levels, ultimately then controlling the % likelihood of something happening. (e.g. a 4 symbol win spinning in, holds after nudges etc.)

This post may provide you with some further insight: 

 

Enjoy the journey, but just don't drive yourself mad with this stuff!

 

Edited October 27, 2024 by Mort

[RickB]

Aha. Thanks Mort, I suspected it wouldn't be so simple as adjusting a simple counter.

Maybe one day an ex-employee from Maygay will publish some of this stuff on github or something. If not then it seems the code may have disappeared along with the companies, which would be very sad indeed.

It just makes all the work that went into MFME all the more impressive. I know that the MAME project reverse engineered various arcade systems the hard way, and MFME must be no different in that respect.

 

[redbags]

On 27/10/2024 at 17:36, RickB said:

Aha. Thanks Mort, I suspected it wouldn't be so simple as adjusting a simple counter.

Maybe one day an ex-employee from Maygay will publish some of this stuff on github or something. If not then it seems the code may have disappeared along with the companies, which would be very sad indeed.

It just makes all the work that went into MFME all the more impressive. I know that the MAME project reverse engineered various arcade systems the hard way, and MFME must be no different in that respect.

 

Having C or C++ skills will always be valuable to the community. In the excellent thread mort shared theres stuff waiting to be tackled if you're interested.

Alternatively, if you wanted to turn your hand to looking at something a bit more modern I would be happy to give some suggestions *cough* brain dump on you

[RickB]

23 hours ago, redbags said:

Having C or C++ skills will always be valuable to the community. In the excellent thread mort shared theres stuff waiting to be tackled if you're interested.

Alternatively, if you wanted to turn your hand to looking at something a bit more modern I would be happy to give some suggestions *cough* brain dump on you

For the moment this is just curiousity about how some of these machines were programmed. Maybe when I retire I'd have the time to go deeper down the rabbit hole.

Following on from what Mort said, I fired up Albert Square and started to look seriously at the contents of RAM, just as a game to see if I could figure out where the counters were and how they related to the compensators (since both EastEnders and Albert Square have reasonably easy to spot "happy times"). And yeah, it's tough. I think I found three separate counters related to spending credits, always incrementing, not always by 1, with some counters being 8-bit and others 16-bit. No rhyme or reason I could figure out at all. My main achievement was finding where the ASCII display memory was mapped into RAM - whoopie doo

 

[johnparker007]

On 27/10/2024 at 15:23, RickB said:

while I am totally fine with C and C++, even if I knew the mnemonics for 6502 or 68000 assembly language, you'd also need an intimate understanding of the hardware and memory maps to really get anywhere)

Maybe we could lure you into some emulation programming on MAME...?  

[RickB]

MAME is even more hardcore! I have no idea how folks managed to reverse engineer ROMS to get them working - they could be entirely custom hardware throughout. I recall that in the late 80s some of the ATARI arcade machines like APB and RoadBlasters were based on the same hardware system, but I don't know how much they really had in common.

[johnparker007]

33 minutes ago, RickB said:

MAME is even more hardcore! I have no idea how folks managed to reverse engineer ROMS to get them working - they could be entirely custom hardware throughout. I recall that in the late 80s some of the ATARI arcade machines like APB and RoadBlasters were based on the same hardware system, but I don't know how much they really had in common.

If you are ever curious about having a dabble (since you mention proficiency in c/c++), the full live source for MAME is here:

https://github.com/mamedev/mame

If you wanna see how a driver works that isn't too crazy (Scorpion 4 is currently 50,000+ lines, so I may refactor that one!), I've very recently been looking at Maygay M1A/B platform (which needs some work, it has various issues), it's a bit more sane in terms of source size, and the game configs are mercifully already split out to a separate file from the machine logic:

https://github.com/mamedev/mame/blob/master/src/mame/maygay/maygay1b.cpp

No pressure though, it is a steep learning curve if you're not familiar with chip pin outs and clocks etc!  ...but always good to see a fellow coder around these parts  

[RickB]

20 hours ago, johnparker007 said:

No pressure though, it is a steep learning curve if you're not familiar with chip pin outs and clocks etc!  ...but always good to see a fellow coder around these parts  

So - you hit the nail on the head. My day job involves stuff like DSP compiler development, algorithm optimisation and so on. Understanding processor and instruction set architecture is one thing, but it's a different ball game to poking bare metal. I don't suppose you have conveniently documented processor models and hardware specs to work with either!

[johnparker007]

1 hour ago, RickB said:

I don't suppose you have conveniently documented processor models and hardware specs to work with either!

No unfortunately, it would make things easier!   Things like the reel controllers, I believe they've just been reversed engineered thus far... they were custom chips, so it's not like they're super plentiful for decapping shenanigans...