Source code / disassembly / reverse engineering question.

[redbags]

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

[Mort]

This is something we have never seen. In fact irrespective of reverse engineering a ROM, I do not believe we have ever had any machine source code shared by anyone in the scene! Amazing really, considering how long we have all been around here but also I assume the source code would be just as meaningless as looking at the compiled ROM for most of us, especially as the source would have often been in assembler language, especially for 80s/early 90s machines.

The best person for insight on this would be @edwardb

I personally would love to have seen source code for some of my favourites machines, such as Club Cops N Robbers, Club Bullion, Rollercoaster.

[slotsmagic]

The only source code I ever saw was from smaller manufacturers - rebuilds and the like - and while I was allowed a glance at it - I was never given a copy (nor would I dream of 'stealing' it). What I saw was in C or C++.

Would be amazing to see some source appear for download. The logic behind the ROMs, but also the ability to (I assume) make changes - bring older code up to date with higher jackpots, conversely take modern games and mess about with them.

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.

Edited July 6, 2024 by slotsmagic

[dondplayer]

Not source code but you can see the machine code executing whilst a game is running in MFME.

People such as @hitthesix and @thealteredemu have hacked ROMs so may be able to give you some insight.

[johnparker007]

Part of this process would be reverse engineering 'libs'.  So each fruit machine, even something like a somewhat templated Speccy game by Ocean would use libs, and then these would most likely be using some 'relocatable source' for generic functions.  So, if you are writing a routine for an MPU4 machine to pay out a coin, you may 'call' (not really a call) a Macro in the src:

PAYOUT(1)

Of course, lots is nested in there.  It gets tricky, quick, unfortunately  

So in assembler, you'd do the equivalent of a c #include, and include some say 6809 source (in an MPU4 game).  It's all fairly straightforward when writing the game, but to work backwards from the ROM is near infinitely more a ball ache.  It's all stuff that's not impossible, but is a massive amount of effort even (only) in the hands of a highly skilled retro coder.  Maybe one day something with AI could be employed to expedite the process, but for reference here's a quick random n64 repo I found, early commits from 4 years ago, still in progress   
https://github.com/pmret/papermario

TLDR: it's complicated and takes bloomin' ages.  Also the code is less interchangeable than n64 game code due to the manufacturer fragmentation, so bonus despair ahead.

TLDR TLDR: it's a lot more work than it sounds, even if you have leet skillz

On a non-despair note; if @edwardb reads this, and is up for sharing his set of libs and build env, perhaps as part of a VM, for incoming coders to use to build new games, that would be a great step forward in creating new machines on those platforms etc.  Totally understand Edward if this is impossible due to still binding NDAs etc.  

Edited July 6, 2024 by johnparker007

[edwardb]

@johnparker007Yeah we need to do something to let people code games etc. I think the EPOCH stuff is the easiest to use and everyone involved in that tech won't care anymore. Won't touch any BFG code as that'll still be copyright, but Maygay don't exist anymore and whoever inherited their IP won't even know it or have record of it.

I had it compiling on Windows 10 but something in Win 11 broke it all, and I can't get it to build.

IIRC you're Sheffield area (?), as am I. We could do a bit of a hackathon to get this building and compiling some ROMs on a Win 10 PC, with a demo game to get people up and running?

It's all pretty basic C code, and I wrote a sub-language for doing attract modes etc so even if you can't code, you can knock up attracts easily enough (that's how I learned at the University of Mazooma  ). I only have Hungarian games on EPOCH but to convert to GBP is easy, but the hold/nudge logic isn't there, but is easy enough to code. Just don't expect test routines etc unless you want to code them!

Let me know what you think.

 

Ed

 

[johnparker007]

2 hours ago, edwardb said:

@johnparker007Yeah we need to do something to let people code games etc. I think the EPOCH stuff is the easiest to use and everyone involved in that tech won't care anymore. Won't touch any BFG code as that'll still be copyright, but Maygay don't exist anymore and whoever inherited their IP won't even know it or have record of it.

I had it compiling on Windows 10 but something in Win 11 broke it all, and I can't get it to build.

IIRC you're Sheffield area (?), as am I. We could do a bit of a hackathon to get this building and compiling some ROMs on a Win 10 PC, with a demo game to get people up and running?

It's all pretty basic C code, and I wrote a sub-language for doing attract modes etc so even if you can't code, you can knock up attracts easily enough (that's how I learned at the University of Mazooma  ). I only have Hungarian games on EPOCH but to convert to GBP is easy, but the hold/nudge logic isn't there, but is easy enough to code. Just don't expect test routines etc unless you want to code them!

Let me know what you think.

 

Ed

 

I wonder if setting up a Windows 10 Virtual Machine image might be the way to go, if it has a very picky toolchain to set up... so then when it's working, that image can be shared/preserved, and should work in the future even on Win 11 / Linux / Mac (running the Virtual Machine Image on something like VirtualBox).

I'm not sure how much I can really contribute to the process, I never actually worked on making fruit machines, and my free fme dev time is usually committed to working on the new Oasis project - but if I can help in some way with you copying your set up that used to work over to the Win 10 VM and testing etc, lemme know    The VM should mean that if it works on your machine under VirtualBox, it should run on anyone's machine using VirtualBox (in theory!  )

Your plan to use Epoch sounds sensible, if that has little to no legal risks compared to the Bell Fruit stuff   So people could test their games they have created in MFME, and then in theory burn to chips, and build a real machine from them using Epoch parts.

Edited July 14, 2024 by johnparker007

[edwardb]

Right, we're back in business.

My EPOCH Hungarian games are now compiling on Windows again, so I'll rebuild them all with the data-capture system disabled, the ROMs uploaded and then at least people can work on emulating those games when they get time. Would be so nice to see them up and running again after so many years!

I'll then work on knocking together a basic UK game so the structure is all there, and then figure out how to make it available for people who want to contribute.

 

[barcrest junky]

Road Runner over at the Mecca reprogrammed a System 80 rom from Fruit Chaser (£2 version) to Fruit Snapper (£3 version) in assembler itself. I recall testing it and finding a bug when you had 8 nudges and there was the grapes available (I think).  It was a long tome ago and only done because we didn't have the roms.

If anyone does thi sand wants to try recreating the original £2 Line Up roms I'd be interested.

[redbags]

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.

 

[slotsmagic]

4 hours ago, 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.

 

I think there's several reasons why source code hasn't been leaked - quite often it seems to be written by one person. So there was (probably less so now!) the fact that it could be easily traced back to the original programmer, who at the least would lose their job over it. There may also have been NDAs or similar signed to not take / use code with competitors?

Now that the industry regarding reel based, analogue AWPs is basically in it's death throes, I'd hope that more would become available. That's really just to satisfy my curiosity though, and fully get why people might not be keen. It's their hard work after all, even if their hard work was designed to get addicts like me to empty our wallets

[redbags]

45 minutes ago, slotsmagic said:

I think there's several reasons why source code hasn't been leaked - quite often it seems to be written by one person. So there was (probably less so now!) the fact that it could be easily traced back to the original programmer, who at the least would lose their job over it. There may also have been NDAs or similar signed to not take / use code with competitors?

Now that the industry regarding reel based, analogue AWPs is basically in it's death throes, I'd hope that more would become available. That's really just to satisfy my curiosity though, and fully get why people might not be keen. It's their hard work after all, even if their hard work was designed to get addicts like me to empty our wallets

I was definitely thinking more along the lines of someone reverse engineering vs leaking the actual source code.

@johnparker007 I did read something interesting recently regarding AI and rewriting code from assembler. I'll dig out the article and share if I can find.

[andrew96]

AI's can write small bits of code that actually do work when given the right prompt, but as for disassembling and them explaining how it works may be a bit beyond AI's available on home computers due to there working buffer storage (they forget what they have done and said when the buffer gets full and the first data in the buffer is deleted automatically), It is likely the ones in the future that could do it won't be available to the likes of the general public. AI is moving fast, but there is still a long way for us Meer mortals in the everyday world to see it I think. I am just saying its unlikely to be possible at this time or in the near future, but the way AI is progressing it is certain the developers of AI have AI's way more advanced than we know about!

Edited August 12, 2024 by andrew96

[johnparker007]

Fully automated AI disassembly is still a fair way off, but it'll become another tool in the toolbox soon if it's not already being used for some small standalone parts.  Fortunately compared to things like home computers (ZX Spectrum etc), fruit machines run their code from ROM, which at least gets rid of any self-modifying code, which really makes things crazy complicated to disassemble  

I guess if I were ever going to get into doing one, I'd probably do a simple lo tech MPU4, since I've got a bit of familiarity with that platform... so you can take the ROM, and take all the static jumps and returns, and from there at least build up a list of subroutines... and then start to reverse engineer and comment them one by one.

It's a massive undertaking though, so I'll only be working on Oasis in my limited free time - with unlimited free time, it would be a 'fun' exercise (though may also lead to insanity)  

Ideally you want to be able to do recompiles of small sections in place, so you can try get to the ultimate goal, of being able to recompile your code and end up with the exact same ROM image (like has been done with various old arcade and console games).

Here's one example of a 6809 (used on MPU4) disassembler for example: https://github.com/Arakula/f9dasm

Edited August 12, 2024 by johnparker007

[johnparker007]

As a quick example, I grabbed Line Up MPU3 and pulled up the asm, and found an area with some dense calls, so those JSR are 'jump to subroutine'.  I put a breakpoint on, then ran the machine... it didn't hit the breakpoint until it went to do it's corrective autonudge, so you would then be able to conclude that this part of the code does the autonudging to best win... then you'd break each subroutine down further etc.  Takes an absolute ton of patience and time, plus you need a reliable way to recompile it - but doable if someone really had the dedication and time to spend on doing it!  

[redbags]

On 13/08/2024 at 00:07, johnparker007 said:

Fully automated AI disassembly is still a fair way off, but it'll become another tool in the toolbox soon if it's not already being used for some small standalone parts.  Fortunately compared to things like home computers (ZX Spectrum etc), fruit machines run their code from ROM, which at least gets rid of any self-modifying code, which really makes things crazy complicated to disassemble  

I guess if I were ever going to get into doing one, I'd probably do a simple lo tech MPU4, since I've got a bit of familiarity with that platform... so you can take the ROM, and take all the static jumps and returns, and from there at least build up a list of subroutines... and then start to reverse engineer and comment them one by one.

It's a massive undertaking though, so I'll only be working on Oasis in my limited free time - with unlimited free time, it would be a 'fun' exercise (though may also lead to insanity)  

Ideally you want to be able to do recompiles of small sections in place, so you can try get to the ultimate goal, of being able to recompile your code and end up with the exact same ROM image (like has been done with various old arcade and console games).

Here's one example of a 6809 (used on MPU4) disassembler for example: https://github.com/Arakula/f9dasm

Do you happen to know which processor architecture is used in the MPU5 tech? I'm assuming it's not a single one for some reason.

I would like to have a poke around with this as a I have free time on my hands. I know MPU5 increases the complexity but anything MPU4 is probably just a bit too old / before my time to make it interesting.

 

[Altharic]

A skeleton driver exists in mame

 

https://github.com/mamedev/mame/blob/af8a5ef6f6a4f1e86a742365d8fb7a159e366447/src/mame/barcrest/mpu5.h#L13

[thealteredemu]

Pretty sure it’s single cpu, possibly 68000 series.

J

[thealteredemu]

Ah just seen the driver it’s the 68340.

J

[andrew96]

I would definitely say start with something simpler, MPU5 has custom made chips on it for which there is no information on, its 16 bit so as I said start with something more simpler like 8 bit. MPU4 is still a good tech as lots are based around the processor on those. your just get bogged down as MPU5 has lots of code! older ones don't have as near as much code to wade through.

[Altharic]

36 minutes ago, andrew96 said:

I would definitely say start with something simpler, MPU5 has custom made chips on it for which there is no information on, its 16 bit so as I said start with something more simpler like 8 bit. MPU4 is still a good tech as lots are based around the processor on those. your just get bogged down as MPU5 has lots of code! older ones don't have as near as much code to wade through.

Mpu4 in mame is also quite complete many games do run so reading the code would help see how it ticks

[andrew96]

I personally would love to work through Maygay M1 tech code, which uses the same processor as MPU4

[redbags]

4 hours ago, andrew96 said:

I would definitely say start with something simpler, MPU5 has custom made chips on it for which there is no information on, its 16 bit so as I said start with something more simpler like 8 bit. MPU4 is still a good tech as lots are based around the processor on those. your just get bogged down as MPU5 has lots of code! older ones don't have as near as much code to wade through.

Sounds like good advice. I'll see if I can find an MPU4 game which I've got some knowledge of.

In meantime - has anyone successfully created a trace of an MPU5 game? I used the feature in MFME v20.1 but it just locks up the process and never completes / terminate process required.

Also...... the whole debugger built into MFME is truly remarkable. I suspect built out of necessity but still....what a thing to do.

[thealteredemu]

Yeah the debugger is excellent, especially if you are a tinkerer  

J

[johnparker007]

11 hours ago, redbags said:

Do you happen to know which processor architecture is used in the MPU5 tech? I'm assuming it's not a single one for some reason.

I would like to have a poke around with this as a I have free time on my hands. I know MPU5 increases the complexity but anything MPU4 is probably just a bit too old / before my time to make it interesting.

 

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