johnparker007

Works in MAME but missing sound roms. Appears to soft lock (a couple of blocks of light flashing), after playing enough credits to get either Nudges or a Feature board (I am unfamiliar with the game). This is likely due to the fruit machine's program awaiting a signal from the emulated sound chip that a sample has finished playing. This may be fixed either by sourcing the original sound roms, making some substitute sound roms from another game, if after that the issue still persists, then the issue will be fixed by implementing the correct feature in the sound chip emulation (to provide the 'sample finished playing' signal or 'sample is playing' status). When fully working in Mame, and Oasis project is at that level (1+ years!) the layout can be converted from BFEmulator -> MFME... then hopefully improved with high res artwork etc... then extracted and imported to Oasis Layout editor, and built to be played in the Machine Player app or Arcade Sim v2 (though it can be played now in the Layout Editor, but that's not really the nicest way to play). So one day it will be playable

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.

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

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!

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

Bit of progress getting built in fonts to match original classic layout, next will sort out OS fonts:

Oh for sure, this will all get sorted out alongside developing Oasis, there'll be a ton of MAME driver fixes and config to do (plus they will all be getting internal text-only layouts built from the Oasis Layout Editor, from imported the existing MFME Classic layouts). One thing we need to code for a lot of the Scorp4s is the ccTalk system, it was done before in a very basic test version for one machine (DOND) and worked correctly, but the code was lost... and then we could run them properly instead of in Door Open mode. A lot of work to do, but all doable Also I've noticed multiple platforms have some incomplete aspects of sound emulation, which is commonly relied on, and can result in slowdowns, pauses, or even full softlocks. So the fruit machine program as waiting for the sound chip to either provide a 'sample is currently not playing' state, or maybe it is even some kind of interrupt 'sample has finished playing'. That will fix up a bunch of issues I believe, that are quite specific to how fruit machines were programmed back in the day.

That is mame

Another interesting milestone, got a scorp 4 classic just about running (Door open mode). Bunch of issues, but nice to see a new platform doing something

Glad you got it working! That Access Violation error is MFME itself, so no changing of Arcade Sim settings would fix it - so great news you found a workaround! Enjoy the Arcade Sim now it's working There is a future Arcade Sim in development, but it's part of a large overall project; Oasis Suite, that will contain a bunch of inter-operational programs to design and play arcade machines, so then these kind of issues will be resolved for all, as it will be using MAME rather than MFME, for a more stable integrated emulation system. But it's a long way off, so great news you got it working, so you can get into those fruit machines right now!

Hey I don't mind if SD wants to comment on older threads I commented on one or two since they'd appeared on the Unread section, then noticed they were from 2+ years back from inactive users, so thought I should give a heads up I think if the original poster hasn't been active on Dif for like 3+ months it's worth pointing out, since they'll likely not come back to see the replies...

I think @SocialDragon368 commented on a bunch of ancient forum threads a day or two ago, so they all popped up at the top of my 'Unread' list!

As it's thread necro time today it seems It's prob some old baked in stuff, MFME also connects to Dif to try to download ROMs for layouts. It's nothing malicious

I love necroing a thread as much as the next man, but I think he's gone

There's a lot more technical stuff at the mo, but when I get new interesting screengrabs I'll pop 'em up here

Bit more text

Update since it's been a while Been working on stuff to do with classic style layouts, since the Oasis LayoutEditor will have a MAME Exporter in it, to create pure text layouts to go in MAME codebase... first signs of life, I can see some text!

That is a very high spec card wrt Arcade Sim. Ok so if you want I can remote into your PC with a program like TeamViewer and we'll very likely be able to get this working Apologies it's a faff, on the new Oasis project, it doesn't do anything 'weird' (Arcade Sim hacks its local copy of MFME.exe) so it should work for everyone, but it's a long way off. Feel free to DM me if you want to set up a session where I remote in and diagnose and apply whatever fix is needed to get it working on your machine

Direct link to the post with the fix: This also needs you to have the latest MFME installed on your system, and updated to the latest version (v20.1). Good luck - if you are still stuck, post here and tag my username so I see it, we should be able to get you up and running. In the future there won't be these issues, it's all down to the various hacks that have to be done to use MFME as the emulation backend... but the new project is a very long way off yet.

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.

Just a heads up, I've been busy so time is precious Work on Oasis has been continuing on an almost daily basis, mainly on the Layout Editor system, however, as time/energy is limited, I've not been posting updates compared to the past and on Arcade Sim projects. If you want to see the live updates to the code, you can watch the commit list on github (as this is a fullly open source project): https://github.com/johnparker007/Oasis/commits/main/ Also, we have a new coder @oldfruitlover, who is (initially) looking into some super important base areas, such as file formats and the MAME Layout Builder system, so props and welcome to him I think for now, the lack of updates from me will continue, but that link above will give you an live snapshot of what's being worked on with Oasis. I know it's not as 'fresh' as the Arcade Sim updates were, but the key thing is for the work to continue at pace, so I hope you understand the prioritising github commits over forum updates

@spinrite This version of Arcade Sim also needs MFME v20.1 to be installed on your system. Suspect you may either not have it installed, or haven't run the Updater in the MFME install folder. After installing MFME, there's an Updater exe in the MFME install folder (default path is usually C:\MFME\v20). If it's still not working after doing that then rerunning Arcade Sim, let us know, though hopefully that will fix it for you

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.

If it is set up correctly in Windows Defender it should work...it should appear like this in your excluded folders list:

@royb232 I saw your post in the chat box on the front page of the forum. With this prototype version of Arcade Simulator, the virus protectors have started picking up one of its components as a false positive. This is what causes the input to not work. There are steps to fix here: