johnparker007

So does it work that whatever number it is on at the start, that is the number it times out on? I'm only vaguely familiar with the machine (used to pay it as a nipper) - are there other features on the board that allow a number reel timeout, and if so, do they also have the same behaviour? I'm reminded of Adders & Ladders (and probably Hyper Viper?) where when it gives you 'Even to continue' on the ?, that will also land on an even number when it's even at the start and left to timeout... however, I don't believe it can be used to actually exploit any emptying afaik.

I guess from my limited knowledge of how these exploits work, is; if you can get it so it's ready to get you near the £6 at the end of the feature trail, can you land on Pound A Round whilst on a 6+ often enough to gain an advantage (assuming that win doesn't count against feature board %age, so you can keep getting back onto that feature square). Followed this post, interested to see if any kind of advantage over standard percentage payout could be found, that'd be kinda wild (Reel Fruits won't be happy if there's a shiny new 2024 Andy Capp emptier haha, we'll have to write a custom patch for their ROM!). Edit: I think on JPM Indiana Jones, the value of the next move is already in RAM before the number reel spins from the user input (or you can patch it mid-move), if a similar thing is present on this machine, it could be a way to see if it's getting the £12 repeatedly without affecting percentage). Here's a @Chopaholic vid showing controlling the numbers moved on Indy, different tech, but might be an angle for testing some of this idea in the emulator:

Goddammit!

Googling: Andy Capp "Pound a round" The only result is this post, so if you found something, it doesn't seem to have been talked about on public forums before. Be crazy if it could be leveraged to find a new unpatched exploit in 2023

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

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! )

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:

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)