BOP and Pinmame - the background for those that are interested in the detail....
I’m Mark (Snux) and for a couple of years I’ve been looking after the version of pinmame which has been modified for use with the P-ROC. Some of you may have been reading my F14 custom “Second Sortie” thread as I P-ROC that. For BOP I’ve recently made some additional adjustments to the pinmame code to fix some issues that have been reported by the DP team and their early testers (flippers working during attract mode, lane change and high score entry not working, helmet lamp issues etc). At this time I believe those changes are only in the latest beta release being tested by some folks. I don't work for Dutch Pinball and I'm not paid for the work on pinmame; it's a hobby and I do that for the benefit of anyone using a P-ROC wanting to try and run the original software.
The build is based upon pinmame version 2.4, and it's just pinmame, no visual pinball or whatever front end. Although the pinmame team have made a number of changes to the base pinmame software over the last few years, none of them are of particular interest to the P-ROC as they’re generally related to adding functionality to emulate pinball machines from different manufacturers.
Pinmame in it’s entirety runs to just short of half a million lines of code; mostly it’s written in C with some C++ thrown in for good measure. That’s just the code to emulate the hardware and throw a basic DMD or alphanumeric display on the screen. For general MAME cab kind of usage, Visual Pinball then sits on top of that with all the table physics, modelling, graphics and so on. That’s not in the half million.
To have pinmame interface via the P-ROC to the physical machine comprises “basically” of :
• Having the P-ROC catch switch activations, passing them to the controlling PC and then updating the status of the switch matrix within pinmame.
• Monitoring pinmame lamp states and updating the P-ROC physical lamp states to match.
• Monitoring pinmame coil states and updating the P-ROC physically driven coils to match. So internally within pinmame we see a coil activate, we tell the P-ROC to do the same. We see it deactivate, we get the P-ROC to follow.
The above comprises around 2500 lines of code. So less than a half of one percent of the total code base is related to getting the P-ROC running; the rest is just standard untouched pinmame.
In this process there will be some latency (call it lag if you want). When a switch is closed, the P-ROC sees it, passes it to the controlling PC which then needs to tell pinmame about it. Pinmame will then react with a sound, a score, flashing a lamp or whatever which the new code will see and pass back to the P-ROC. When you run a MAME cab with VP or FP or whatever, you don’t get that latency – your computer *is* the pinball machine (and people sometimes complain about lag even then).
In most situations that latency is either not noticeable or doesn’t really matter. That said, sound emulation in mame generally (and so pinmame too) has always been something that gets noticed as not great. If you use Google and search for “pinmame sound quality” or “mame sound quality” or “visual pinball sound quality” there are pages of threads about it. Emulating all of those ICs and processors in C code and getting something that sounds 100% original just isn’t always possible. It’s also affected by what sound hardware / software your computer has and the settings being used on that, also the CPU performance of the computer comes into play to some extent. It’s actually *far* more CPU intensive running pinmame for emulating the older games on the P-ROC than running the 2.0 versions (or whatever you want to call them).
Do to these very slight differences in timing, it’s also possible that some switches etc that previously worked just fine are now just slightly out of the tolerance that pinmame will accept. As someone else mentioned, that should just be a case of slight adjustments to have them close a little earlier or something. That’s especially the case where one person reports a problem that nobody else is having. Specifcally regarding coil pulse timings, that we do have some control over but it’s behind the scenes and not adjustable from the front end. If (for example) the ball release pulsing too long and letting more than one ball through is something more people see, then we can look to adjust the pulse time. If 2 balls are getting put in the shooter lane, that won’t be related to a pulse time as it’ll be doing 2 pulses to get 2 balls out, so is more likely to be related to a switch that needs some little adjustment.
So, just like with BOP 2.0, report any issues with the 1.0 (pinmame) back to Dutch Pinball. I don’t think the sound is going to improve much – that’s all handled somewhere in 448000 lines of code that we haven’t touched. Nobody has done any work on it in regular mame, so it’s unlikely to get worked on in pinmame. If there are coil pulse times that need adjusting up or down to resolve issues, we can probably do that. As with 2.0, the pinmame build being used here has only been tested on a very few machines, so as it gets rolled out to a bigger audience I expect things will be found in both 1.0 and 2.0 Report it, we’ll build up a picture of what’s going on and we’ll see what we can do.
One last comment – unlike the 2.0 code, pinmame is all open source, so after I’ve done a little tidying up the full code being used within the P-ROC environment (including BOP) will be available for anyone take a copy of.