johnparker007

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.

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...

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

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

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

Started feeling a bit better over Xmas, so I've been chipping away at 7 segment displays for the layout editor over the past couple of nights Next job is the 14/16 segment displays - unlike the 7 segments, I can't port them over from Arcade Sim, as I want to make the new ones more versatile (at the expense of a tiny bit of speed). This is needed, as any 3d machine will be able to be built that MAME runs (like Korg synthesisers for instance), and these may use different 16 segment displays to the 3 main types found in fruit machines...

Hopefully one day probably years away yet though! ...there is occasional action on the vpengine repo (https://github.com/freezy/VisualPinball.Engine/commits/master/). I am doing very small bits on Oasis again since past couple of nights as been feeling a smidge better, also open source (https://github.com/johnparker007/Oasis/commits/main/).

I've been given a heads up that Arcade Simulator website is down again. I did manage to temporarily fix it before, unsure why it has failed this time. For the moment, here is a dropbox link to the same installer: https://www.dropbox.com/s/dy9cgg2c71y5k91/Arcade Simulator Setup.exe?dl=0 Arcade Sim still seems to be booting and running fine (it also accesses arcadesimulator.net) so files are being served, but the website rendering must have failed on the backend... Link for @bullionbars2011

Just an update to this, he said he didn't realise how powerful the artwork system was (i.e: playable slot machine layouts), so he's going to take a look into it when he gets some free time Issue is here: https://github.com/seleuco/MAME4droid-2024/issues/1

Good shout, I have opened an issue, as I'm not up to coding owt at the mo, he might be up for fixing If he does, I will then look into a test of an old mfme2mame dx... though I did notice when setting the internal render resolution to native (from 640x480), the speed was very slow... so this won't ever be a satisfactory android DX FME experience, while the rendering is so very slow. This was on my Fold4, which I treated myself to, so it's a pretty modern phone... Oasis will probably still end up being the way to play high res DX layouts on mobile tbh... interesting to tinker with this thing though

Probably a good shout - though could be how the mame4droid java wrapper is passing through the mouse data, though I'm not really up for implementing this part to be fair if not! I'm certain it could be hooked up though with a bit of coding on the mame4droid side of things I recorded a terrible quality video showing indy running on my Fold4 , though having to workaround to control some of the buttons - WARNING heavy breathing in this video! To be fair I'd just eaten and I was doubled over one phone holding another phone, sat in bed, it was all really awkward, I'm not actually that out of shape

Ah right, I see that MAME 0.139 was built in 2010, so that's 6 years before I did that first pass of internal layouts thru MFME2MAME. I have a Galaxy Fold 4 here, I have given it a test on mame4droid v261 - while internal layouts display, the touchscreen taps are not passed through to the layout (this is different from touchscreen video game roms, where input is handled differently). If another coder or the author himself wanted to, code and an option could be added, to allow the touches to also be sent through as 'layout taps', then the flashing start/hold/collect buttons etc would work.

Ah to clarify, what I meant was keeping up to date with MAME master branch itself (so it will pick up improvements to FME as they are added). He makes these mame4droid android wrappers for a fixed version of MAME (i.e: MAME v139, MAME v261 etc). So if some work is done in the future that goes into MAME v265 for instance, that will not be present in the google play store version. But if the relevant FME changes can be merged into the mame4droid v261 fork (I set one up here: https://github.com/johnparker007/MAME4droid-2024 ), then those new capabilities would be present in the build compiled from that branch. Not up to doing coding at the mo, but will hopefully get chance to have a look at this in the future, since the Oasis layout editor could convert DXs for use with it (if artwork is fully supported by the wrapper). Edit: just checked, looks like it shouldn't be too bad: 1/ Download 0.261 MAME or later src <--- so hopefully will be forward compatible while the makefile/lua stuff stays similar 2/ Put files inside MAME src forlder 3/ Modify makefile/lua scripts so use new OSD

Nice that it's up to date with the latest version, be good to see if it properly renders the per machine artwork, and handles touch input to that artwork. If someone sticks a MAME fruit rom in there that has an internal classic layout (e.g. Indiana Jones), and it renders the internal layout correctly, that is interesting (as Oasis will be able to output DXs in the same way it'll be able to output Classics, from imported MFME layouts). Then it would need to be confirmed that it can render a non-internal override layout from the layouts dir (to see about getting DXs running). Could be a lot of nice mobile FME enabled with this, though prob better on tablets or folding phones with large screens (that or use a Nintendo DS-style stylus to press the small layout buttons) I've forked the repo in case it goes anywhere, also as I think this is just a one off from David the same as his previous mame4droid builds, but it may be possible to keep it up to date for minor FME updates (not massive refactors) going forward. Original repo: https://github.com/seleuco/MAME4droid-2024 Good spot @Altharic!

Haha yeah indeed, I vaguely remember having a look at these, they are encrypted archives. Further info: Bitpacker or bpak for short is a tool and library for creating firmware archives that can be cryptographically signed, support custom metadata and enable advanced update schemes. Bitpacker is primarily designed for embedded systems. Embedded systems are often composed of several software components, for example: bootloader, kernel, file systems, device configuration, third party applications, etc. It is common to have many different formats and tools for the various components. One of the main goals with bitpacker is to reduce the number of tools and formats required to manage these components. Sauce: https://github.com/jonasblixt/bpak

No idea who 'blueonesarefaster' (the github coder who submitted this preliminary display code) is, he only joined mame github about a week ago, and then this is already his first commit. Perhaps we'll see more from him...

Ok I've copied a few files around on the FTP server, and tested on a 'remote browser' - I think it is now fixed, though it may not appear fixed until local browser caches are cleared: So you may see the same error you saw before, but over time, as local browser caches are cleared, hopefully it will look like this again (and allow for downloading of the Setup exe)

Hi Davados Someone else told me about this issue and I'm seeing it too now, so the website appears to be broken at present. Shows this: I can hopefully fix, I'm guessing @slasher rolled out an update as he is kindly hosting the Arcade Sim website for us. All the actual data for Arcade Sim is hosted here by the folks at Dif. Some great folks in the community, so I've not had to pay for hosting! Anyhoo, so for now, here is a link to the Installer exe from my dropbox: https://www.dropbox.com/s/dy9cgg2c71y5k91/Arcade Simulator Setup.exe?dl=0 Download that and run it, and everything should install fine from there. Remember in this 'legacy' version of Arcade Sim you'll need to also install MFME and update it from v20.0 to v20.1 (this won't be a requirement later, although dev of the open source successor Oasis is on hold due to health). Hopefully that should all work for you, and you'll be back Arcade Simulating again!

Even though I was involved, I have to admit that the Amiga may have faired better had it not been for the ubiquity of software piracy. All the talented game devs got out of the Amiga ecosystem, and focused on SNES/Megdrive/Saturn/PS1 and the poor old Amiga was bereft of software... amazing computer for its time though

I used Protracker and Noisetracker - but ultimately found OctaMED Pro to offer the best editing features (I think partly because it was built on the OS native Intuition lib).

I did a work experience from, school at a place called something like Humberside Computer Services. He sold Amigas and printers etc, but the real cash cow was we had several amigas along the wall, and people would browse the games, and choose some, and then we'd write them a copy. I believe it was £3 for a single disc game; multidisc games were £2 per disc. There became a problem with kids coming in, browsing the master copies (Dave was getting these via post and BBS) and then 'shoplifting' games... so then Dave set up a system, so his masters were all on 5 1/4" floppies instead - in X-Copy, it didn't mind if the source drive was an external 5 1/4" drive (so you'd then copy from DF1 -> DF0). The shoplifting dropped to zero overnight! (As no-one could use those massive discs in their Amigas). He got busted by FAST three times, each time, the fine was far less than the money being made from selling the copies, so he'd just pay the fine and carry on

There was also a 'software only' version of this. It was a little hit and miss as to whether a game would overwrite the interrupt stuff and/or the RAM area of the resident program, but when it did work, it was pretty much the full hardware, but in software - was good for finding cheat values in memory, and general hacking. For ripping soundtracker modules from memory, I recall that it was actually better to do another way (soft reset machine while mod to rip is loaded, then fire up a memory ripper). I amassed a lot of samples from games/demos to use for my own music making endeavours with this technique

At least someone actually paid the devs for games! There was another awful lot of this going on in the late 80s-early 90s That said you did need to be linked to someone who could source the cracked games, ultimately coming from a BBS (or the snail mail). I didn't play many games, but I was lucky to be 'connected' to a couple of people who were in the scene