I've been sitting on the sidelines in this thread and the other one about FAST versus P-ROC, but I'll jump in here quickly. I'm one of the creators of the Mission Pinball Framework (MPF), an open source Python-based pinball framework that works with both the FAST and P-ROC/P3-ROC pinball controllers. MPF is platform agnostic, and there are platform interface modules (which I wrote) to translate MPF calls into the raw hardware calls the FAST or P-ROC needs.

So while I have not built a custom machine from scratch like Rosh, Bonnevil69, gstellenberg and many others, I do have very deep knowledge of both the FAST and P-ROC hardware platforms. And after spending more than a year very deeply involved in the intricacies of both platforms, I can tell you this: They are both fine, and neither could be considered a blanket "winner" over the other.

Honestly it's a Coke/Pepsi Ford/Chevy iPhone/Android thing. In some situations one is better, in some the other is better. In 99% of cases it doesn't matter and it all comes down to personal taste. (Same for MPF "versus" other pinball frameworks like pyprocgame, prprocgameHD, rampant slug, open pinball project, netprocgame, etc. All are free. All have pros and cons. Pick your favorite. No hard feelings.)

If anyone were to do a side-by-side comparison then it would be like comparing a Camry versus an Accord where the cars really are similar and people end up arguing over how much they hate the taillights or the placement of the cup holders.

Put another way, if someone comes to me saying "I am building a machine and I'm using a P-ROC," that's fine. No prob. And if they say "I am building a machine and I'm using FAST." That's also fine. I really don't care.

There have been funny/poking/eye-rolling tit-for-tat moments on pinside over the past year between Gerry and "P-ROC people" and Aaron and "FAST people". I personally know both Gerry and Aaron. Both love pinball and both really believe in their hardware. Of course they will pick at each other, but again that's no different than the Ford dealer picking at the Chevy dealer. Neither will ever "win", and that's fine. The real winners here are the members of the community who want to build custom pinball machines, since they have hardware options supported by passionate makers and a thriving community.

I have experience with many of these small form-factor computers. (I'm the guy writing the Mission Pinball Framework.) They're not technically embedded PCs since they are just regular computers with a regular file system that run regular Linux. They just happen to be very small and run off of flash memory.

Raspberry Pi 1 is too slow for anything we're doing.

Raspberry Pi 2 is fantastic. Quad core which is huge (MPF is multi-process so it can make use of multiple cores--1 for game logic & hardware control, and 1 for graphics/sound/media/DMD/LCD). Plus it has 1GB RAM which is nice because we can pre-load a lot more stuff in memory which just makes everything faster. Downside is it's proprietary (which may or may not be an issue, depending on whom you ask).

Beagle Bone Black Rev C. This is fine for DMD-based games and older (128x32 pixels, 8-bit/1-byte per pixel only). No way it works with LCD-based backboxes. (Even just having the GUI running slows MPF down to about 7 ticks per sec. We use it with MPF by running without a GUI.) It's only single core and it only has 512MB RAM. Plus is the hardware is open and you can get them built yourself if you wanted to go into production.

ODROID. Also seems nice. This is what we used in Big Shot last year at expo. Ordering it is tricky because it only comes direct from Korea. Not too much support. We had weird issues with our OSC interface which disappeared when we switched hardware.

At this point, all things considered, it seems like the RPi2 is the way to go, but running Ubuntu, not Raspbian. Several MPF users are running this, and even with LCD graphics it seems to hold its own. (And when we move MPF to SDL2 in a few months, we expect better performance.)

Obviously this is a moving target since this market changes every few months.

EDIT: RPi2 will also be able to run Windows 10 which is nice for "non-Linux" people. Haven't tried that yet though. (Actually I don't even know if it's available.) We'll get to that at some point though in the next few months and I'll post back here when we do.

To add to what Rosh is saying, picking an ideal "loop rate" is tough to do because it means different things in different scenarios. Plus one of the problems with just looping your code balls out as fast as it goes is that you peg the CPU at 100% and it gets hot and you can't do anything else. (Not that you'd want it to do anything else while you were playing pinball, but even things like saving audit data could take 10 seconds when one thread is pegged and not yielding because it's looping as fast as it can.)

There's a difference between the "loop rate" of your main game "tick" and the loop rate that hardware is polled. The main game loop rate doesn't have to be crazy high to have a great player experience. True, you need a damn near immediate response for fast moving balls with diverters near switches, but as Rosh says, that's all handled by the pinball controllers (true for FAST and P-ROC), so your game can have a loop rate of 5hz and you still won't miss the diverter.

For example, in MPF we set the main "timer tick" to 30hz by default. That means the machine is waking up every 33ms, running through its loop (updating the display, dealing with timers, etc.). So the code wakes up, does it's thing, and if it takes 10ms to do that, then it goes back to sleep for 23ms.

While it's "sleeping" it will periodically wake up (configurable, set to 1ms by default) just to poll the hardware controller for switch changes (both P-ROC and FAST have to be polled), and if any changes occur, those are processed immediately (including anything tied to them.. events, effects, score, lights, sounds, etc.). So that's sort of done "out of band" of the main machine looping tick.

Same for timers. (Say you have something you want to happen every 15ms.) Those timers wake up when they're supposed to wake up, outside of the main game loop tick.

I've played with taking the switch polling sleeping time up to 2, 3, 4, 5ms.. and of course I can't tell a difference because I'm a human. (Again this assumes that slings, pops, flippers, diverters, etc. are written as hardware rules to the pinball controller.) I've also played with taking the main loop rate down from 30hz to 25, 20.. I even went down to 5. The only effect is that drops the display fps down, but it doesn't effect game play otherwise.

As Rosh said, you can measure whether the loop is lagging, but that requires instrumenting the loop itself which can effect performance. (Though not in a way that's measurable as far as I can tell.) In MPF we have two loop options. The default one which is bare bones, not logged, and then there's an "instrumented loop" which watches for that sleeping time period and will log warnings if the main timer-tick loop is running longer that the time allotted via the configured HZ rate. (Basically if it comes back from the main loop and it's already past the time to do the next loop, it logs it.) Though honestly that's not needed because you can just look at the CPU utilization of the Python process. On my Windows VM on my laptop with a 30Hz main loop and a hardware polling sleep time of 1ms, the MPF game engine takes about 12% of the CPU core. (That's another advantage of not running balls out as fast as you can. In the balls out case, the Python process will always be super high. With the sleeping and polling every 1ms approach, the CPU utilization correlates to the actual percentage of time it's busy, so you know whether your hw can handle it just by looking at the CPU utilization.

The other key about getting good performance on the the RPi2 which I can't stress enough is that it has four cores, which means if you do run into performance issues but you only have a single process pinball engine, then you either have to get faster hardware or re-architect your code into multiple processes. (I'm not saying that all pinball engines have to be multi-process. I'm just saying that if you do run into CPU bottlenecks and you have a multi-core machine, switching to multiple processes is like a "free" hardware upgrade.

That's what we did in MPF for this exact reason. The MPF game engine is a separate OS process from the thing we call the "media controller" which is responsible for graphics and sound, and in our case when we've seen things get bogged down, it's always (100.0% of cases) been the media controller process that gets slowed down, which is kind of cool in a way because it means the game engine is still running full speed and won't get behind. The solution for the media controller is just to drop frames (which sucks of course), but really the only alternative to that is to use a more powerful computer. (Actually the other solution is to have better code. PyprocgameHD which is what Mocean and Rosh created uses SDL2 which leverages the GPU to do the graphics processing so it's way faster than the CPU-based method that the original Pyprocgame and MPF use. In fact they have subtlety suggested that we move MPF to SDL2 as well, and we're going to take them up on that with that effort starting next month.

I've used the RPi2 with great success with DMD-style games, including color DMD. No lag, even after hour of play. No dropped frames. No delay. But that's a "loop rate" of 30, though like I said with the 1ms hardware polling and timer interrupts, combined with the pinball hardware handling the instant response drivers, the code is still doing things while sleeping in between ticks.

So we'll see if we can get good LCD (way more res than 128x32) out of an RPi2 when we go to SDL2. I feel like it will be solid for color DMD maybe up to 192x64 or so. (It's decent there now and that's before we go to SDL2.) But if you're wanting a 1920x1080 LCD display or anything like that, then you're using a $200 mini PC board with a real GPU, not the RPi2.

hahaha.. Word.

That's an option too. There's a group of folks who made a Unity 3D media controller which also works with MPF (it just replaces the MPF media controller) for people who want to do "real" graphics.

Yeah but that's more like a hardware H.264 1080p video decoder versus a general purpose GPU. So if you just want to play 1080p videos, yeah, no prob. But if you want to do other GPU things needed to create dynamic effects... rendering, particles, textures, floating point math, etc., the GPU in the RPi2 is benchmarked way, way lower (like 4-5x worse) than the next lowest-level GPU the testers could find, and it's like 100x worse than the $150 Nvidia GPU they tested.

Source: http://www.geeks3d.com/20150603/quick-benchmark-of-the-raspberry-pi-2-gpu-videocore-iv/

+1,000,000 for this design decision!

I mean let's be honest, by the time anyone here is ready to choose the "final" hardware for their machine, we'll be talking about the BBB Rev D and the RPi3 and which ones support 4K.

EDIT: And think about what CPUs existed in 2009. The fact that the same P-ROC from 2009 is what you sell today brings this home.

Love the new avatar Gerry!

Python Anghelo showed something like this at Expo maybe 2 years ago? He talked about new approaches to devices he was working on (and used this as an example of a better trough). I wonder how far along those were and/or what happened to that IP? It seems like a good idea to me?