Source code / disassembly / reverse engineering question.

[redbags]

22 hours ago, johnparker007 said:

Are you looking to further develop the existing emulation in MAME?  Or simply looking to have a tinker with existing fruit machine ROMs and seeing how they run?   If the MAME route, I can give you some pointers to get up and running, and some of the areas that need working on, depending on what you are interested in  

Sadly I'm just in the tinkering with existing ROM phase. I have some experience with reverse engineering on windows & x86 and wondered if I could put that to use but I suspect I'm already way out of my league to be honest.

Out of interest - what happened to the MPU5 work for MAME? I had a look through some of the code and I saw some references to Spanish fruit machines. I naively assumed that would be something very UK centric tbh.

[johnparker007]

26 minutes ago, redbags said:

Sadly I'm just in the tinkering with existing ROM phase. I have some experience with reverse engineering on windows & x86 and wondered if I could put that to use but I suspect I'm already way out of my league to be honest.

Out of interest - what happened to the MPU5 work for MAME? I had a look through some of the code and I saw some references to Spanish fruit machines. I naively assumed that would be something very UK centric tbh.

A lot of FME dev in MAME is stalled for the mo (including MPU5), due to lack of skilled emu devs with the time/motivation to work on these old fruities. 

I'm busy  with Oasis, but if it gets to the point and where we have quality internal layouts built for MAME for all platforms, and still no interest, I may devote 6-12 months, and sort out a lot of the more basic config type issues initially, along with more of the hardware security stuff for sc4/5/6/mpu5 (ccTalk then DES).  Also, some reel controllers need reverse engineering, and sound chip emulation is missing stuff, that will also bring more machines to working.  Also some issues with alpha displays... there's a lot to go at!   I'm somewhat optimistic that if I put in a big amount of donkey work grinding through these things, Haze may look at some more of the more complex stuff again.  Once we have the layouts built into MAME.exe with labelled reels, this is all a lot more interesting to work on, otherwise, even when it works, it's just a boring grid of flashing lights that you can't really 'play' in a fun sense of the word!

Ideally others will get involved again once we have the full set of layouts done, so playtesting and machine operation can easily be done in MAME  

There is also some working MPU5 emulation with source code in an old leaked MFME.  This isn't directly portable to MAME, but I'm sure some things could be learned that would help with developing the driver further.  Also, using the debugger in MAME and the debugger in MFME, to compare behaviours for issues where we really don't understand what the issue is... but there's a lot of lower hanging fruit first to be honest.

Machines were released in other countries on UK developed platforms (like Bellfruit Scorpion, Barcrest MPU and others), Spain, Germany, Netherlands to name a few.

Edited August 15, 2024 by johnparker007

[edwardb]

On 12/08/2024 at 09:57, redbags said:

I completely missed the follow ups on this thread and didn't get any notification it was being posted to. Assumed I'd just asked a daft question.

Back to the original question - thank you all for your input. Very useful. I understand reverse engineering is a massive amount of effort with no guarantee on the end product. Still find it a bit odd not a single source code has ever been looked at though. As I think it out even further though - presumably doing the reverse engineering today would require the initial reverse of the emulator to then potentially reverse the executable code itself. Time for a lay down in a dark room.

@edwardb It's coincidental you mentioned you worked at mazooma as I was thinking in my head I used to speak to a dev called Edward at mazooma 20+ yrs ago on some forum I don't remember. Good to speak with you again.

 

Wow - what forum was that? Time flies..!

[niallquinn]

Nice read this thread.  @Garywould have an insight if he's still around.  He's still on FB.  Don't think I've seen him post here since Wizard passed though.

 

 

[edwardb]

I'll post some example code from one of my Hungarian games when I get to the office later this week. I should probably write a walkthrough of it, but it's a pretty reasonable example of typical AWP code albeit just not for the UK market (which isn't hard to make functionally work, anyway).

I'll be honest - much of the code I saw of games from other coders was utterly diabolical. Sloppy, messy and error prone. As much as I liked BFM/BFG a lot of their game code was a car crash. I remember seeing Crazy Fruits and thinking, christ almighty, this is just a mess. Their system software however was very long winded but robust. I guess that's the difference between systems engineers and game coders.

I learnt my trade from an ex-BWB programmer who was incredibly diligent, regimented and whilst not the fastest coder, his games were bulletproof. At the age of 18 that seemed like a good thing to aspire to. My code from back then was neat and tidy, and not complicated - on purpose.

I'll sort something out along with some other goodies from way back....

 

Ed

[johnparker007]

13 minutes ago, edwardb said:

I'll post some example code from one of my Hungarian games when I get to the office later this week. I should probably write a walkthrough of it, but it's a pretty reasonable example of typical AWP code albeit just not for the UK market (which isn't hard to make functionally work, anyway).

That would be interesting to see!  

At some point, for the new Oasis project I also plan to provide a scripting language (much like how Visual Pinball uses Visual Basic).  This will allow for people to build fruit machines with their own logic, it would be nice to be able to base it on real logic code from back in the day - theoretically 1:1 (ish) ports from real machines would be possible if someone can be bothered to port the ASM to whatever the scripting language ends up being   

16 minutes ago, edwardb said:

I'll be honest - much of the code I saw of games from other coders was utterly diabolical. Sloppy, messy and error prone. As much as I liked BFM/BFG a lot of their game code was a car crash. I remember seeing Crazy Fruits and thinking, christ almighty, this is just a mess.

This doesn't surprise me!  

18 minutes ago, edwardb said:

I learnt my trade from an ex-BWB programmer who was incredibly diligent, regimented and whilst not the fastest coder, his games were bulletproof. At the age of 18 that seemed like a good thing to aspire to. My code from back then was neat and tidy, and not complicated - on purpose.

This is the way  

[redbags]

On 16/08/2024 at 12:08, edwardb said:

Wow - what forum was that? Time flies..!

Struggling to remember exactly.....arcadia or something like possibly and we're talking early 2000s.  I was probably quite in awe of an actual fruit machine dev in those days   But yes - time flies.

[Damici]

On 15/08/2024 at 21:56, johnparker007 said:

Ideally others will get involved again once we have the full set of layouts done, so playtesting and machine operation can easily be done in MAME  

Machines were released in other countries on UK developed platforms (like Bellfruit Scorpion, Barcrest MPU and others), Spain, Germany, Netherlands to name a few.

This topic gets me excited. Allready discussed a few things bout MAME earlier with you @johnparker007 but I never really understood how MAME worked. Yesterday I got the Dutch games working which are listed in MAME. The layouts are not even classics but just a display and bunch of square lamps so I would love to know and help how to make layouts more like the way it is now in MFME. If I can help in any graphic part or provide Dutch stuff then please let me know.

[johnparker007]

9 hours ago, Damici said:

This topic gets me excited. Allready discussed a few things bout MAME earlier with you @johnparker007 but I never really understood how MAME worked. Yesterday I got the Dutch games working which are listed in MAME. The layouts are not even classics but just a display and bunch of square lamps so I would love to know and help how to make layouts more like the way it is now in MFME. If I can help in any graphic part or provide Dutch stuff then please let me know.

They will work in Oasis which is the new software which is being (slowly) built.  You will be able to build the layouts in MFME and convert them to Oasis  with the Mfme Tools component of the Oasis suite, or, build them directly in the Oasis Layout Editor.  All this stuff will take a long time to build so please bear with me  

[hitthesix]

On 06/07/2024 at 07:01, redbags said:

I've done a search through the forum but was unable to find a clear answer to my question.

Has there ever been a good example of a complete reverse engineer of a fruit machine rom? And if so, what are the challenges to taking that on as an activity...... obscure assembly code based on even more obscure compute technology? Clearly the fact so many hardware platforms have been emulated demonstrates it can be done....but I've never seen a clear tear down of any particular rom to source code level.

I sometimes read discussion threads where certain fruit machines seem to exhibit psuedo random behaviour i.e. sometimes it does it / sometimes it doesn't. I was just curious if anyone has ever dug deeper to identify the function or line of code which highlights why that is the case.

Be curious if anyone can shed any light.

Cheers

The bfmulator has reverse engineering built in i am led to  believe

On 06/07/2024 at 13:48, slotsmagic said:

 

I know some work has been done to implement stake / prizes changes via ROMhacks - which blows my mind - but having the source code and being able to dissect things would be incredible.

Yeah we have done a few over the years, and i have just about finished some more 

BWB the streak

classic tic tac toe

classic red hot roll all on 30p play with jackpots @ £20, or £25 red hot roll is fine (as it plays the jackpot tune also) the other two don't(as yet)

as for the oldies, the last one i done was jokers wild

and had a go and changing some code to see what /if there was much difference

1 example was to change 2 bites, and  that change gave 3 nudges  or lit the jokers every single spin

changed it to something else, and it never gave nudges at all.

the other one i looked at is silver ghost deluxe

and usually when you are looking for the  prizes and p-o-p code  there is about ten bites for the prizes and 8 bites for p-o-p

but!!! in this silver ghost i only had to alter was 2 bites, and that double all the wins

and the p-o-p.it still needs work done to try to finish it off.

 

here is a video for you  

 

[Road Hog Mad]

Pity we can't get Rainbow Riches, Elvis Top 20 etc. emulated with all of these clever people around!

[andrew96]

3 hours ago, Road Hog Mad said:

Pity we can't get Rainbow Riches, Elvis Top 20 etc. emulated with all of these clever people around!

It has a pc involved, not just a mpu5/6, much harder than you might think 

[andrew96]

no one has even been able to unpack the BPAK files as of yet

[slotsmagic]

21 minutes ago, andrew96 said:

no one has even been able to unpack the BPAK files as of yet

The BPAKs are unpacked during installation to a game menu, so not sure the BPAKs themselves would be required? Not sure if they are only unpacked there - install to the \running rather than \master folder once installed. Plenty of us have images with a group of games (up to 40) already installed if anyone wanted a fiddle about. They aren't small though!

No idea how well they would run though and what may or may not need to be done. I know that they skip a certain amount of checks / verification when running in demo mode, but whether they'd throw an error due to lack of MPU5/6 among others I don't know.

 

Edited October 7, 2024 by slotsmagic

[andrew96]

10 minutes ago, slotsmagic said:

The BPAKs are unpacked during installation to a game menu, so not sure the BPAKs themselves would be required? I know they install to the \running rather than \master folder. Plenty of us have images with a group of games (up to 40) already installed if anyone wanted a fiddle about.

No idea how well they would run though and what may or may not need to be done. I know that they skip a certain amount of checks / verification when running in demo mode, but whether they'd throw an error due to lack of MPU5/6 among others I don't know.

 

The computer is 'set hardware' any deviation on the hardware and it wont work, so the complete version of the pc has to run first, the mpu5/6 is really just a 'slave' of the pc, the pc controls the show, without the pc talking to the mpu5/6, nothing will work

[slotsmagic]

5 minutes ago, andrew96 said:

The computer is 'set hardware' any deviation on the hardware and it wont work, so the complete version of the pc has to run first, the mpu5/6 is really just a 'slave' of the pc, the pc controls the show, without the pc talking to the mpu5/6, nothing will work

Absolutely, with regards to the OS itself, but unsure about the game EXEs? For example I have Storm games running on my PC - the menu won't load (no dongle, no PayLink, and a bunch of other reasons) - but the game EXEs do run and are playable, albeit in a demo mode.

[Road Hog Mad]

On 07/10/2024 at 14:39, slotsmagic said:

Absolutely, with regards to the OS itself, but unsure about the game EXEs? For example I have Storm games running on my PC - the menu won't load (no dongle, no PayLink, and a bunch of other reasons) - but the game EXEs do run and are playable, albeit in a demo mode.

what storm games in demo mode do you have?

[redbags]

On 07/10/2024 at 15:33, andrew96 said:

The computer is 'set hardware' any deviation on the hardware and it wont work, so the complete version of the pc has to run first, the mpu5/6 is really just a 'slave' of the pc, the pc controls the show, without the pc talking to the mpu5/6, nothing will work

I'm not sure how accurate this comment is to be honest. I spent a LOT of hours looking at barboot and there is nothing in there about locked hardware aside from soft predefined configs. To be even more specific - the PC and Barboot definitely work in the absence of the MPU.

It may be a different story when it comes to the exec. I hit an issue related to an old/obscure graphics library (SDL) crashing out which I never had the time to fully dive into. My suspicion is that the graphics card bundled with a T7 has capabilities you don't get as standard in an emulated environment.

I never quite figured out the specific role of the MPU. My suspicion is that it runs the core game engine along with handling the machine specific hardware i.e. hopper etc. I believe the PC probably just handles the UI bells and whistles along with handling the management of the unit i.e. installing games, accounting etc. If that is the case then emulating the MPU sounds tricky and adds to the complexity. But people have been slowly tapping away at MP5 emulation so you never know.

Re: game encryption. I think that is also a moving target. Early T7 games look quite different when installed/unpacked Vs later T7+T8 games.

My personal thoughts are that T7 is very emulate-able - but it's going to need someone a lot experienced than me to do it.

[andrew96]

yes I agree totally, as in locked hardware, in the PC, I was actually meaning specific hardware which is locked into windows xp embedded so cannot be changed for something else that sort of thing, motherboard, graphics card, that's what I meant but worded it wrong lol, but yes agree with you

[Altharic]

I've always thought the starting point would be qemu mame is too rigid in its 'rules' to get it past the commit stage it would sit there 2 years and be closed.

[redbags]

8 hours ago, andrew96 said:

yes I agree totally, as in locked hardware, in the PC, I was actually meaning specific hardware which is locked into windows xp embedded so cannot be changed for something else that sort of thing, motherboard, graphics card, that's what I meant but worded it wrong lol, but yes agree with you

I'm reasonably certain there is no hardware lock-in enforced at the operating system / hardware level. I'm also reasonably sure there is no hardware lock-in enforced at the barboot phase. The reason I say this is because I have it up and running in a Hyper-V virtualised environment. It's possible the exec does some additional checks but I never got that far, or rather, the exec crashes with a graphics error after it's initiated by barboot.

Now....I have an idea on what might cause this but I'm not sure how easy it will be to workaround in a pure virtualised environment. It might need something like vmware to setup a raw device map through to an actual GPU. 

What I can say is that it's very time consuming work especially when tinkering around in XP embedded. The bare bones nature of the OS and it's age make it difficult to get a good working environment. Not insurmountable but definitely a ball ache.

I'll do a proper write up once I get the time.

[redbags]

5 hours ago, Altharic said:

I've always thought the starting point would be qemu mame is too rigid in its 'rules' to get it past the commit stage it would sit there 2 years and be closed

I suspect there are past and present members of this community with the skills to do this. Sadly, I don't include myself in that.