Of "Kugler Family Pinball", one of the best shooting custom games ever made. I wonder if that's AP's next theme!

- Gerry
https://www.multimorphic.com

Yeah, the upper part of the Kugler's playfield has much more flow (two loops that feed the upper flipper). It's really not that similar to TAF. Even the ramp is modified. It's a great layout, and there's now a trend for putting family members on backglasses.

- Gerry

Full product pages with board specs can be found on our site at: https://www.multimorphic.com/p3-pinball-platform/hardware-control-system/

The P3-ROC and associated switch and driver boards handle the low level interfacing and control logic, and the P3-ROC connects to any controller you want (over USB). Lightweight processing games can use R-Pis or other STBs. Heavier processing games can use more powerful computing systems. Game designers can therefore design their processing system (CPU, GPU, memory, etc and associated costs) around their needs.

- Gerry
https://www.multimorphic.com

Hadn't read this thread in a month or so but just read the last few pages. Wish somebody had reached out directly instead of guessing about the P-ROC. I'm easy to contact and am always happy to talk about non-confidential technical details.

There are a lot of incorrect assumptions about how the P-ROC works being discussed in this thread. The P-ROC doesn't slow down when a lot of different things are happening. Rather, that's where it shines. The P-ROC logic is implemented in an FPGA, which performs all of its logic simultaneously, very much unlike a sequentially operating processor. Switch events processing and driver updates are completely independent and can't/won't bog each other down. Yes, it's possible to overload the driver bus if the number of commands being sent exceeds the max bandwidth of the bus (P-ROC driver bus runs at 8 mbps vs 1mbps from other manufacturers).

We're currently working with Josh to add more features to manage priority driver requests. This will make the hardware smarter about what to do when too many commands are sent. We've also been jointly debugging some other things that happen in Houdini that don't happen in any other P-ROC-based game. If the root causes are in the P-ROC, rest assured, they'll be fixed.

- Gerry
https://www.multimorphic.com

I can clarify the [non-confidential] parts of my (P-ROC?) involvement in the R&M changes, though I can't speak for any specific MFG's implementation (other than of course the P3 machine's).

I've suggested a few changes relative to how R&M programs the hardware for flippers with EOS switches and to add a few software commands to close some timing holes related to fast flips.

These software changes aren't relevant to the P3 machine today, as the current P3 flippers don't have EOS switches (The first playfields didn't need them. CCR and Heist get the ball moving a lot quicker than LL-EE and CL do, though the hold profile we use is pretty good). That said, we're designing EOS switches into the assemblies to eliminate the issue, hopefully in a way they can be added to existing modules - fun engineering challenge.

- Gerry
https://www.multimorphic.com

Yeah, I'll defer to Josh on Houdini's implementation. The new EOS code in R&M might be useful in other games, but every machine's hardware is different.

- Gerry
https://www.multimorphic.com