OASIS (working title)

[johnparker007]

6 hours ago, thealteredemu said:

Yes, I concur, great to hear you’re starting to feel a little better JP   take care bud.

I’ve been getting into rom hacking, spending a lot of time in the debugger, I’m currently getting my head into the 20p version of Project Coin Bullseye (v29) it’s the final £6 token version and once offering skill shots you can just go for hold after nudges but it must have a hold after wins pot unlike earlier version so a watchdog to monitor reel wins.  I’m slowly working bits out but I hope to put this part of the emptier back in, also going to try to put the bullseye trick back in, it isn’t fixed like the fixed 10p version was, that has some extra code and jumps around that portion of the game, I’m hoping it was more a hacky fix  I’m certain it is just clearing the 20 bill mystery ? So it’s still in memory when the machine exits that feature with no credit.

Progress is slow but I’m learning a load of stuff along the way, keeps me out of mischief anyway

I also slowly working on some artwork for the 20p Bullseye and will likely continue if I successfully put the emptiers back in

J

Thanks man, early days, but definitely seem to be improving a little at present  

I remember your elaborate emptier, it was very cool - waiting in attract mode, until the correct symbol on the dartboard flashed last, so then that could be hit guaranteed on a feature, something like that, plus forcing it to give out nudges for the 30 skill shots. Just had a look and that is on a Z80 CPU, which is the same as the trusty Speccy   

Good luck with the hacking, I wonder if you could use something like skoolkit, a tool for disassembling Speccy games, perhaps with some adaptions... so rather than just poking around the rom, you'd use a tool like this to fully disassemble the entire rom into opcodes/data.  Then all the jp/call type commands, it would add in local/global labels in the asm.  So then in theory you can slowly reverse engineer the codebase into readable asm with comments, correct labels etc, all while being able to at any point compile it and get back to the original exact rom.  Probably a bit overkill for your emptier, though it would probably be a first!  I don't think anyone's done that before (reverse engineered a fruity back to source).  Perhaps one day we could get AI to reverse engineer all these fruity roms!

Here's an example where someone has fully reverse-engineered Manic Miner (runs on same Z80 CPU as Project Coin Bullseye):
https://skoolkit.ca/disassemblies/manic_miner/

One advantage of this is that you don't have to store all your custom code at the end of the rom, plus it's like you have the actual original game code... like I say though, maybe overkill for your use case  

Edited January 4 by johnparker007

[thealteredemu]

4 hours ago, johnparker007 said:

Thanks man, early days, but definitely seem to be improving a little at present  

I remember your elaborate emptier, it was very cool - waiting in attract mode, until the correct symbol on the dartboard flashed last, so then that could be hit guaranteed on a feature, something like that, plus forcing it to give out nudges for the 30 skill shots. Just had a look and that is on a Z80 CPU, which is the same as the trusty Speccy   

Good luck with the hacking, I wonder if you could use something like skoolkit, a tool for disassembling Speccy games, perhaps with some adaptions... so rather than just poking around the rom, you'd use a tool like this to fully disassemble the entire rom into opcodes/data.  Then all the jp/call type commands, it would add in local/global labels in the asm.  So then in theory you can slowly reverse engineer the codebase into readable asm with comments, correct labels etc, all while being able to at any point compile it and get back to the original exact rom.  Probably a bit overkill for your emptier, though it would probably be a first!  I don't think anyone's done that before (reverse engineered a fruity back to source).  Perhaps one day we could get AI to reverse engineer all these fruity roms!

Here's an example where someone has fully reverse-engineered Manic Miner (runs on same Z80 CPU as Project Coin Bullseye):
https://skoolkit.ca/disassemblies/manic_miner/

One advantage of this is that you don't have to store all your custom code at the end of the rom, plus it's like you have the actual original game code... like I say though, maybe overkill for your use case  

Oooh, I like that idea, I did try this with an app called IDA Pro, but it didn't decipher the Z80 code very well sadly.  I might try that one just for something to look into, I'll likely learn a lot more with a more readable code base .  Binary compiled code is a bit of a head feck!!  

Cheers for that John, will let you know how I get on with it

J

[thealteredemu]

@johnparker007 I'm very new to python, I'm probably being a noddy but how can I install the skoolkit scripts?   I'm only away till teatime and I want to get into this!!!  No worries though I will research more when I'm able

J

[johnparker007]

33 minutes ago, thealteredemu said:

Oooh, I like that idea, I did try this with an app called IDA Pro, but it didn't decipher the Z80 code very well sadly.  I might try that one just for something to look into, I'll likely learn a lot more with a more readable code base .  Binary compiled code is a bit of a head feck!!  

Cheers for that John, will let you know how I get on with it

J

Yeah if you can get it looking more like:
 

	LD A,0

etc... rather than raw hex, and then be able to 'recompile' it again... i.e: more like simply translate directly back to a file that you can put back in the rom, and it is exactly the same.

If you get to that point, then you can start adding comments to the code:
 

	LD A,0 ; reset nudge count to zero

etc... and things get a little less crazy.  Then, when you have absolute addresses for jumps and calls, like:
 

	CALL $ABCD

etc... you can put labels at the point that compiles to $ABCD, so it'd read more like:
 

	CALL ResetNudges

...and the reset nudge routine would look more like:

ResetNudges:
        LD A,0
        RET

etc.

You don't have to do this of course   But if you really want to own that code, and potentially rewrite large chunks of the machine, that's the way to start going about full reverse-engineering it.  It's a super manual process though, I've only done a teeny little bit of that really - I end up handcompiling the hex!

There may be other good Z80 disassemblers/assemblers around, that SkoolKit is not necessarily the best one, just one I remembered.  Good luck  

[dondplayer]

4 minutes ago, johnparker007 said:

Yeah if you can get it looking more like:
 

	LD A,0

etc... rather than raw hex, and then be able to 'recompile' it again... i.e: more like simply translate directly back to a file that you can put back in the rom, and it is exactly the same.

If you get to that point, then you can start adding comments to the code:
 

	LD A,0 ; reset nudge count to zero

etc... and things get a little less crazy.  Then, when you have absolute addresses for jumps and calls, like:
 

	CALL $ABCD

etc... you can put labels at the point that compiles to $ABCD, so it'd read more like:
 

	CALL ResetNudges

...and the reset nudge routine would look more like:

ResetNudges:
        LD A,0
        RET

etc.

You don't have to do this of course   But if you really want to own that code, and potentially rewrite large chunks of the machine, that's the way to start going about full reverse-engineering it.  It's a super manual process though, I've only done a teeny little bit of that really - I end up handcompiling the hex!

There may be other good Z80 disassemblers/assemblers around, that SkoolKit is not necessarily the best one, just one I remembered.  Good luck  

How things have changed - I remember searching through pure numbers with the assembler mnemonic table (which was in the back of the ZX Spectrum manual) - was 35+ years ago mind you 

[johnparker007]

1 minute ago, thealteredemu said:

@johnparker007 I'm very new to python, I'm probably being a noddy but how can I install the skoolkit scripts?   I'm only away till teatime and I want to get into this!!!  No worries though I will research more when I'm able

J

I've not actually used SkoolKit ever, just one that sprang to mind - as I mentioned above there could be better ones.  If I remember I'll have a look when I next am doing some FME stuff...

Something like this might also be good or better:

https://github.com/toptensoftware/yazd

though you'd have to build it yourself.  Not sure if more user friendly options out there.  You want the disassembler, to generate a text file from the non-blank parts of the rom (or NOP the blank areas) containing the assembly code ('LD A, 0' etc).  Then an (ideally matching) assembler, that can take that text file containing the assembly, and build it back to an identical binary file again.

Once you've got that workflow sorted, you are good to go with commenting, changing subroutine/data addresses to labels etc  

[SomeRandomGuy]

Haven't posted in a while, just checking in here. Haven't abandoned this place or anything, just been hella busy with work stuff, school stuff, and much of the non-busy time has gone to other reversing projects. Very cool to see progress @johnparker007 as always , great to hear you're feeling better as well!

10 hours ago, thealteredemu said:

Oooh, I like that idea, I did try this with an app called IDA Pro, but it didn't decipher the Z80 code very well sadly.  I might try that one just for something to look into, I'll likely learn a lot more with a more readable code base .  Binary compiled code is a bit of a head feck!!  

Cheers for that John, will let you know how I get on with it

J

IDA is a very very useful program, I've been using it for all my fruit machine RE in fact, and many other things too. Z80 code it can handle just fine (Bonus Talker has one) plus so far I've also dealt with MC6800, TMS9900 and Intel 8048 on the fruities. The last 2 don't have processor modules in IDA so I had to make my own, with these simple 8-bitters you can get away with quickly hacking something together in Python though . There's also Ghidra that's aimed at the same things IDA does, it's main advantages are that you don't need to pirate it, and that it can decompile assembly into C for theoretically every CPU that's supported. Though in practice trying to decompile handwritten 8-bit assembly such as here breaks down quick, and the overall quality of the decompiler isn't as good as IDA, which has been worked on for longer but only does certain architectures, though Ghidra will probably get closer as time goes on. I use IDA myself since Ghidra didn't exist as far as the general public was concerned when I was first getting into all this stuff, and IDA works better for certain niche applications like 16-bit x86 code if you're into that type of thing.

Had a look at the PROCONN stuff, threw in one of the Bullseye ROMs and it looks fine in IDA as far as a quick glance goes at least. One thing that IDA kinda sucks at is dealing with banked memory, where there can be different parts out of the entire ROM code visible in memory depending on what's selected, you see this on the SNES for example.  Doesn't seem to be the case with PROCONN on this game at least. The memory map is simple, total size of the ROM chip is 64K, in Z80 memory 0000-EFFF is the first 60K of the ROM, then 2K of RAM at F000-F7FF, and then the last 2K of ROM at F800-FFFF. Dunno if that last 2K of ROM can be switched in some way, but that part is empty for this game anyway so doesn't matter.

What can be confusing though is all sorts of tricks that programmers used back in the olden days of handwritten assembly, for example there's this code here:

It looks like it's jumping to the middle of another instruction, which definitely shouldn't happen. But if you look inside the function at DA04 that's called right before the sketchy code and look at what it's doing, you can see that it reads 2 bytes following the call instruction to DA04, does something with them, then continues to the code after them. So what it should actually look like is this:

Here's another one with code that doesn't disassemble at first:

Much better after fixing:

That's just one example, but you can see many different kinds of this strangeness, depending on how 'clever' the programmer was feeling that day. Jump tables are pretty common for Z80 as well, usually a jp (hl) instruction that has a list of addresses close by that go to different parts of code. With enough experience you eventually develop a feeling for this sort of stuff, but at the same time you never really run out of new ways of being clever. It can get especially bad if the programmer was focused on intentionally making the code hard to follow, but that's more of a thing for stuff like copy protection on home computer games, shouldn't be much to worry about as far as fruit machines go at least. Anyway, good luck with the reversing!

Edited January 4 by SomeRandomGuy

[johnparker007]

45 minutes ago, SomeRandomGuy said:

Haven't posted in a while, just checking in here. Haven't abandoned this place or anything, just been hella busy with work stuff, school stuff, and much of the non-busy time has gone to other reversing projects. Very cool to see progress @johnparker007 as always , great to hear you're feeling better as well!

IDA is a very very useful program, I've been using it for all my fruit machine RE in fact, and many other things too. Z80 code it can handle just fine (Bonus Talker has one) plus so far I've also dealt with MC6800, TMS9900 and Intel 8048 on the fruities. The last 2 don't have processor modules in IDA so I had to make my own, with these simple 8-bitters you can get away with quickly hacking something together in Python though . There's also Ghidra that's aimed at the same things IDA does, it's main advantages are that you don't need to pirate it, and that it can decompile assembly into C for theoretically every CPU that's supported. Though in practice trying to decompile handwritten 8-bit assembly such as here breaks down quick, and the overall quality of the decompiler isn't as good as IDA, which has been worked on for longer but only does certain architectures, though Ghidra will probably get closer as time goes on. I use IDA myself since Ghidra didn't exist as far as the general public was concerned when I was first getting into all this stuff, and IDA works better for certain niche applications like 16-bit x86 code if you're into that type of thing.

Had a look at the PROCONN stuff, threw in one of the Bullseye ROMs and it looks fine in IDA as far as a quick glance goes at least. One thing that IDA kinda sucks at is dealing with banked memory, where there can be different parts out of the entire ROM code visible in memory depending on what's selected, you see this on the SNES for example.  Doesn't seem to be the case with PROCONN on this game at least. The memory map is simple, total size of the ROM chip is 64K, in Z80 memory 0000-EFFF is the first 60K of the ROM, then 2K of RAM at F000-F7FF, and then the last 2K of ROM at F800-FFFF. Dunno if that last 2K of ROM can be switched in some way, but that part is empty for this game anyway so doesn't matter.

What can be confusing though is all sorts of tricks that programmers used back in the olden days of handwritten assembly, for example there's this code here:

It looks like it's jumping to the middle of another instruction, which definitely shouldn't happen. But if you look inside the function at DA04 that's called right before the sketchy code and look at what it's doing, you can see that it reads 2 bytes following the call instruction to DA04, does something with them, then continues to the code after them. So what it should actually look like is this:

Here's another one with code that doesn't disassemble at first:

Much better after fixing:

That's just one example, but you can see many different kinds of this strangeness, depending on how 'clever' the programmer was feeling that day. Jump tables are pretty common for Z80 as well, usually a jp (hl) instruction that has a list of addresses close by that go to different parts of code. With enough experience you eventually develop a feeling for this sort of stuff, but at the same time you never really run out of new ways of being clever. It can get especially bad if the programmer was focused on intentionally making the code hard to follow, but that's more of a thing for stuff like copy protection on home computer games, shouldn't be much to worry about as far as fruit machines go at least. Anyway, good luck with the reversing!

Good to see you around man!    Yeah damn I forgot about opcode alignment issues, with data peppered through the rom - good examples you posted    So no one-click perfect solution unfortunately...

And yeah feeling a bit better at the mo ta, so back to some light dabbling with FME dev!  Next thing to sort out is these alpha displays...

Edited January 4 by johnparker007

[dondplayer]

Remind me of the purpose of these two statements:

78EB cp a

78EC pop af

cp a just compares the a register with itself without changing the value so this just sets the zero flag.

But the next instruction populates the a and f registers with whats on the stack anyway.

Similarly afterwards we appear to see two memory locations loaded with the same value that for some reason is passed between the a and c registers.

It's been a long time since I played with z80

[johnparker007]

49 minutes ago, dondplayer said:

Remind me of the purpose of these two statements:

78EB cp a

78EC pop af

cp a just compares the a register with itself without changing the value so this just sets the zero flag.

But the next instruction populates the a and f registers with whats on the stack anyway.

Similarly afterwards we appear to see two memory locations loaded with the same value that for some reason is passed between the a and c registers.

It's been a long time since I played with z80

Those instructions from @SomeRandomGuy's example above are showing where the disassembling is wrong, that's why they look odd.  Once the word is set to define bytes, everything is opcode aligned again and the cp a, pop af are gone.

[dondplayer]

10 hours ago, dondplayer said:

Remind me of the purpose of these two statements:

78EB cp a

78EC pop af

cp a just compares the a register with itself without changing the value so this just sets the zero flag.

But the next instruction populates the a and f registers with whats on the stack anyway.

Similarly afterwards we appear to see two memory locations loaded with the same value that for some reason is passed between the a and c registers.

It's been a long time since I played with z80

 

9 hours ago, johnparker007 said:

Those instructions from @SomeRandomGuy's example above are showing where the disassembling is wrong, that's why they look odd.  Once the word is set to define bytes, everything is opcode aligned again and the cp a, pop af are gone.

Ahh I'm not going mad then 

[johnparker007]

Little bit hacked in for now, doesn't look great but it's working - it's a new 16 segment alpha renderer for the Layout Editor.  Each individual segment is driven individually (the AS version worked via 'fonts'), so should somewhat futureproof for non-fruit machines from MAME in future... haven't done the variable brightness effect yet:

 

[johnparker007]

Little bonus vid of playing some Andy Capp now I have those two displays vaguely functional.  The sound is too fast, that's actually my fault!  I recommended an xtal freq be changed in MAME for all MPU4 (to fix audio speed on Adders and Ladders), I think it turns out that if there's a sound card with samples, the xtal should stay at original speed (Andy Capp sound was working correctly before my change - oops!  ).

Also wins count up very slowly, I think this is due to the program waiting for sample completion, but that is not coming through at the right time, so again a sound related bug.

Anyway here's a little gameplay in the Layout Editor (even though that's not really its purpose!  )

 

[johnparker007]

Improved rendering of segment displays (more readable now), add alpha duty voltage support (fade effects):

 

[johnparker007]

Small tech update on this project... been getting small amounts of work done here and there with it, started to build a UI Form for the options for MFME Extraction, and decided it's still not a good enough foundation for the UI.  All these cross-platform non-native UI solutions have issues, here the problems that are becoming clear are:

- awful to design forms in, it's built off the old WinForms system.  It isn't taking advantage of Unity's UI stuff at all.

- it is crap for resolution-aware scaling, and people use there computers with 16:9, or 'Ultrawide'.. or even in Portrait etc.  Plus a Form in 1080p would simply display at 1/4 the size on 4K, and dynamically sizing docked/undocked panes would also not scale the contents.

These things are going to be very hard to back-implement down the road (since Unity UI has already solved some of this), so I'm setting the project up for having a perpetually crap UI, which isn't good when it has:

- a Layout Editor (for designing 2d and 3d machine 'layouts'

- a Machine Editor (for importing 3d models to build the 3d machine cabinets)

- a Level Editor (for creating environments contains machines, such as arcades)

That's 3x the pain, as they're all Editors requiring Editor-style UI... so for now at least, I'm planning to:

- change the top bar menus to be OS menus (so this will be working in a nice usable way on Win / Mac / Linux)

- change the window content to be based of a basic framework I found in an open source Unity Runtime level editor project.  It's very basic and missing a lot of stuff, but, the bones are good from what I can see - and will allow for a much better end result, with far less pain when creating more UI stuff, as it's based around standard Unity runtime UI techniques

So pausing on looking at MFME Extraction feature, and replacing the WinForms style UI with those two new UI approaches.

I have worked around implementing as an MVVM pattern fortunately, as I thought I may end up doing something like this down the road - so the work so far (Emulation control, machine extract importing, layout rendering, emulation input) isn't intertwined with the code that renders the UI - it's all pretty much decoupled.  So it'll take time, but as there's no spaghetti code, it should be relatively straightforward  

Edited January 12 by johnparker007

[spa]

Good luck, and thanks for the update.

[johnparker007]

Getting there with the smaller first UI change task, switching to native OS menus   

Out with the old ones:


In with the new ones:

 

[johnparker007]

A little video showing the WIP of the new cross-platform UI Dockable Windows system  

 

[woodsy]

On 10/06/2023 at 16:11, spa said:

You could have just called it...

'Better than life' - Red Dwarf lol

McGruder!!

On 11/06/2023 at 23:04, aetherhaze said:

I'd hate to get smegged over by the Inland Revenue on that one though! 

Joking aside, looking forward to the progress of this as time goes by John; every success to you along the journey. 

 

i can't keep up with the code, but i recognise the effort!

i was as now in and out, and you had a tuppenny nudger 3 reel example of what is now a blissful recreation of an arcade.

thanks basically

 

[johnparker007]

8 hours ago, woodsy said:

McGruder!!

i can't keep up with the code, but i recognise the effort!

i was as now in and out, and you had a tuppenny nudger 3 reel example of what is now a blissful recreation of an arcade.

thanks basically

 

Ah yes, the early days

 

[Altharic]

On 15/06/2023 at 21:32, johnparker007 said:

It'll get there, the wheels turn very slowly in MAME-land, they've got a bit stuck with that commit due to samples I believe, really crappy for code contributors like @SomeRandomGuy though   Haze has been saying to be more lenient on FME wrt MAME standards, but Cuavas runs such a tight ship, it can cause discouragement unfortunately...

Ironically its not happened and Haze still has similar issues now

[johnparker007]

54 minutes ago, Altharic said:

Ironically its not happened and Haze still has similar issues now

I know, I think I said elsewhere on Dif recently, I'm just staying out of it for the moment.  Worst comes to the worst, MAME could be forked... but that's got its own whole host of nightmare issues then! 

[johnparker007]

Layout Editor - cross platform UI system - latest WIP:

 

[johnparker007]

MFME Import - initial rendering into window working:

 

Edited February 3 by johnparker007

[johnparker007]

Sorting some icons out for the dockable UI tabs, I think a Yoda is appropriate for the MFME Import window   RIP @Wizard