I disagree. The best software to use is the MPF, and it supports both platforms equally.

Let me give some hardware examples though...

One of the things that Multimorphic recommends is using an AnTek power supply driven by a transformer. It works, but a switching supply is a much better choice these days. The power factor is better with a switching supply and they don't suffer nearly as much from line voltage issues (drops at shows, etc...).

Another, as markinc mentioned, is the solenoid banks that require the same voltage. In a deep and complicated pin, you have a lot more mechanisms than just high voltage solenoids. I need to switch several things at 12v, and even my GI at 5v is switched via a driver on the FAST board. I can do that natively with a FAST driver board without having to add additional hardware to the setup.

It doesn't matter which hardware you use. If you design and program based on hardware selection then you're doing it wrong.

Design and write your game to interact with a generic hardware interface class, and create a NullDevice child class uses that interface as its parent and stubs out all necessary functions with debug code. Write your entire game using this on your PC/Mac. Deal with hardware later.

When the time comes to actually build and test with real hardware, simply create a new child class using the interface you previously defined that correctly communicates with the board set you want to use. Replace the NullDevice class' instance you've been passing around with the real hardware class' instance.

Vuala game complete, debugging easy.

MPF isn't technically necessary, but you are going to have to code things like modes, light shows, etc.. on your own (in whatever language you choose).

When I first decided to go FAST, I wasn't going to use the MPF. I was going to write my own code in .NET. I even wrote several test apps for the FAST hardware. One is the FAST Playground, which anyone can download and use right now:

https://github.com/Wolfmarsh/FASTPinballPlayground

It uses .NET code to talk directly to the FAST hardware via the serial connection that Aaron mentions.

The advantage of pairing MPF with the FAST hardware is that the MPF provides a TON of systems that you don't normally think about. One example is trough code. That code is actually a nightmare to write and get correct. Jan has spent a considerable amount of time tweaking that to work well.

I'd be willing to answer any specific questions about stuff as well, PM may be the best option if you are nervous to ask in public.

Ok summary.
Missed a key post:

markinc offering a P3ROC and boards for sale.

Ah! No, I got ya. I was just thinking along the same lines you were - specifically .NET. That's what I do for a living, and while I don't now, I've done plenty of serial communication in the past, and was thinking that'd be easy. (I do NOT know Python. ) So the MPF would then be uploaded or saved to the FAST controller and run directly, I assume? (Or, does it still run on a host system (linux, mac or win machine with python installed) and then communicat via serial?)

My problem with this whole discussion is someone looking to possibly get into making a custom pinball in the future. But have no real idea where to start. I have coded throughout my life, and once started I can figure stuff out, but the intial setup is usually the tricky part. I have also done sodering and used small Microcontrollers, so that side (again once started) doesn't seem daunting. It's just the vastness of choice that it appears when just starting out that is really stopping me.

I don't want to jump all the way in without some expirence, so I have the idea of getting one of the Sentinal/Wonder Wizard home pinballs (that are everywhere on craigslist) and create a custom ruleset.

Is there someplace to actually read what suggested hardware/software would be for certain requirements?

For example it looks like (ignoring how they actually do it) that there would be
17 Inputs
10 Outputs
Custom Audio Out
Custom Screen of some kind, with animations

MPF runs on the host computer and just communicates with the FAST hardware via serial.

I'm in the same boat as you. I've been coding for 30+ years and have spent the past 10 years mainly in the MSFT ecosystem. I will always give you my honest opinion, and I still think Python sucks even though I really like the MPF.

Right now I've just got some Config files for MPF, and my game has attract modes, multiball modes, lights, switches, sounds, graphics, DMD animations, etc....

If you want to see some MPF config files, I've decided to share my Spaceballs code so you can check it out:

https://github.com/wolfmarsh/spaceballs

Feel free to browse the configs. The ones in Github are all on MPF 0.21. I have not checked in the 0.30 version of Spaceballs yet.

A good baseline start is to assume:

32 direct input switches
64 input switches via an 8x8 matrix
at least 8 if not 32 high/mid power outputs
64 lamps via 8x8 lamp matrix controller OR some form of LED driving board
Audio comes from the PC and gets fed into some amp
Screen comes from whatever you want- DMD, VGA, DVI, HDMI... your choice

Design your game on paper first to get an idea of what you need

That's good advice.

Another thing to remember is that both the hardware systems are modular. Just buy what you need to get started, you can add on more boards later as you flesh your game out.

MPF wraps up all the game logic, device handling, player control, mode control, etc. All sorts of stuff that makes making a game easier to do. Just like on the web where you could absolutely write your own blogging engine to post your content on the web, or you can install wordpress and get right to content creation. But you still need a server running the software, etc. in that analogy we are the server.

Aaron
FAST Pinball

Ah awesome, thanks, I'll start poking around.

So it sounds like the FAST system is just a 'dumb' system (technical term guys, not description..), and needs a host/controller to accept commands from. Gotit - that was my biggest question.

I agree that I want as much on paper first, but just in your response
"64 input switches via an 8x8 matrix" I don't know what that is or where to find out more about it.

But I can tell, my questions are better off in my own thread, to not derail this one.

If you install MPF 0.21 on your computer, you can download Spaceballs and run it if you wanted. That way you could see how the configs translate to the actual game code.

There are some "smart" things that the FAST boards do, but for the most part you are correct. For example, the FAST boards can be configured via software to link switches and coils, so when a switch fires it automatically fires the coil without having to communicate back to the host PC.

For sure. We are going to be selling bundle "starter kits" for electronics, power, cables, connectors, etc. here soon. It is what a lot of people have asked for. "Just tell me all I need to buy. I dont want to order from 10 places and get it wrong." Our European customers have asked for that so that they can pay less import taxes and that some items are hard to find locally.

My plan with the Starter Kit Bundle is to have my tutorial videos mirror exactly what is in the kits. Like open the box, get to work. Where all the wire colors match, etc. I have been told again and again, mostly from software guys, that this is the intimidation hurdle that they need to get over. I think that we can definitely help with that.

Aaron
FAST Pinball

Totally a technical term! There FAST hardware is your interface to the physical game. Its smarter, like John said, in that you can ask it "how many switches do I have?" "How many drivers do I have?" "How many nodes do I have?" "How are my drivers configured?" "How are my switches configured?"

Fun stuff.

Aaron
FAST Pinball

PS: These are great questions. Will help greatly in the topics I need to cover.

http://pinballrehab.com/1-articles/solid-state-repair/repair-guides/146-switch-matrix-theory-and-troubleshooting

Understanding switch matrices and lamp matrices are vital in pin design. They can go beyond just switches and lamps to more complex things such as enhanced toy control, dmds, and alpha numeric displays.

Besides- do you really want to piss away money on 64 wires for a switch bus and lamp bus (128 total!) when you only need 16 wires for each (32 total)? I sure don't... I'd much rather buy that extra drop target assembly instead

I tend to design more the way you do, physically. Working with others I have been trying to get more into Fusion360 and other software tools. I wanted to make sure that the hardware played nice with all design approaches.

For example, I can get my game wired up and I don't even need to run MPF to get flippers flipping. I have a snippet that I copy/paste of FAST Pin Protocol commands to make it easy. Here are the two lines I enter into my terminal connection with the FAST NET processor to make a flipper flip:

DN:00,01,00,10,20,FF,00,00,50
DN:01,01,00,18,20,FF,FF,00,00

The first line says: Driver 00 (Main Coil) should be triggered when switch 00 is pressed.
The second line says: Driver 01 (Hold Coil) should be latched when switch 00 is pressed.

Now if I press switch 00 the flipper flips! I keep a raspberry pi laptop in the garage so i dont need to get sawdust in my Macbook Pro. But that's all that is needed to start my physical game testing.

Other parameters are for coil pulse times, cool down times, as well as empty params not used by these modes. All this is in the FAST Pin Protocol and will be available on our website.

Aaron
FAST Pinball

Good conversation!

The only other wrench I'd throw into it that hasn't been mentioned yet is that with MPF, you don't have to use the YAML-based config files for everything. Our goal is that you *can* use the config files for everything, but if you would rather, for example, program your game logic in Python versus using the MPF "logic blocks" YAML-based functionality, then that's an option too. (In fact I do that myself. Sometimes I'm thinking, "yeah, X action would be like 20 confusing config lines or just two lines of Python, so I'm writing it in Python.")

MPF supports adding your own code to the base machine as well as your own code for modes. So you could, for example, use MPF config files to define when modes start and stop, but then when a mode starts, you could use your own code to do everything. Then your own code, once it figures out that multiball needs to start, could post a multiball start event that the MPF multiball device is tied to, and then your multiball would happen based on all the options you have in config files, because why rewrite all the logic and logistics of tracking how many balls are out there and where they should eject from and ball save timers and events from drains and stuff when that already exists?

So I don't view MPF as being all config files, rather, I view MPF as a collection of modules and devices, all of which have a config layer that allows them to be configured via YAML files. But at the end of the day, your complete game could be 90% YAML configs, 10% Python code, or 80/20, 50/50, 20/80, etc. The balance of configs-to-code is up to the personal taste of the game developer.

Frankly there are some things you don't need to write in Python from scratch because the way you'd write them is the same as they exist already in MPF. So (for example) why write all the logic for ball devices and ball tracking and ball search and failed eject retries and moving balls around and all that when you can spend an hour or two to build out a YAML config for your ball devices and then never have to worry about that again? (Bonus is that if you do use configs and find a bug, then fixing it is on us, not you.

Does that mean you have to learn the MPF YAML format for ball devices? Yes. But I think that's less time than learning everything you need to know about ball tracking in pinball and then writing that yourself. (And new versions of MPF come out, if you're using MPF configs, then all your game "code" is updated automatically, versus if you write code yourself you'd have to manually rewrite it or change it if you had a idea of how to do something new.)

And of course, if you like 95% of the way something works in MPF but you just want to tweak it for your specific need and you know how Python, then just subclassing some base feature from MPF and changing it for your own needs is way faster than writing your own way from scratch.

The MPF API has decent Sphinx-based documentation (http://missionpinball.com/apidocs), and frankly if you want a real "how to" of how to use the MPF at the API level, just look at all the code for the automated unit tests. (https://github.com/missionpinball/mpf/tree/dev/mpf/tests)

The other thing is that I have been working on MPF full time for almost two years. That is literally almost 4,000 hours of my time (both in code and documentation), and Jan, Quinn, and Gabe have put in hundreds of hours each too. So MPF, while not complete, represents over 5,000 hours of work, and (most importantly) is getting probably 60 hours of work every single week with no plans to let up soon. (There are literally dozens of commits per week.) So MPF is moving forward at a rapid pace, and will continue to do so. If you use MPF, you get that for free. 60 hours every week of people writing core pinball logic, GUI tools, etc., so you don't have to.

When I started with Pyprocgame and the P-ROC in 2013, I saw complete and very advanced games that already existed. Some made their code available, and some did not. (The advice for newbies was "check out these complete games, and take what you want from them." The problem was that even though I had access to complete source code from 4-5 different machines, because Pyprocgame was fairly basic, each implementation of a complete game in Pyprocgame was very different (since each dev did things in their own way). So while you can look at Eric's CCC code to see how one would create a bonus mode, for example, you can't just grab his bonus code and drop it into your own game because CCC's bonus code works with the CCC way of doing things.

That's actually how MPF came to be. I was like, "man, it's too bad that all these smart people are writing all this code that's not compatible with each other. It would be cool if there was a framework that tried to pull all that together which would allow everyone to benefit from the collective efforts of everyone else." That was what I outlined when I started MPF in May 2014. That was also around the same time that I learned about FAST, so then I was like, "Oh, cool, we'll make MPF support FAST as well." And since then Hugh has added Open Pinball Project hardware support to MPF.

BTW, the whole notion that "FAST would have nothing without MPF" is kind of true, but kind of irrelevant. FAST didn't build their own framework because MPF meant they didn't *have* to. I'm sure Gerry wouldn't have built his own framework in 2009 if something like MPF had existed at the time, and once Adam and others started adding to it in 2010, Gerry hasn't made any contributions to Pyprocgame apart from updating and adding things as they relate to interfacing with the P-ROC hardware. SkeletonGame was all Rosh and Mocean, and even adding the accelerometer support to pypinproc was done by Jan so we can use accelerometer-based tilts in MPF. (I mean all of this in a positive way. The vendors make their hw interfaces, and the community takes it and runs with it. True for FAST. True for P-ROC.)

Also BTW for the record, there is no actual code from Pypinproc in MPF except for MPF's P-ROC and P3-ROC platform interface code which used the Pyprocgame P-ROC library interface code as a starting point back in the day. That said, I cut my teeth on Pyprocgame in 2013, so I definitely learned a lot about pinball programming from Pyprocgame and the games that were publicly available at the time. (Gerry's JD, Adam's CFTBL, Eric's CCC, Jim's IJTBA.. probably a few others I'm forgetting now, but there was definitely no shortage of people and examples to learn from around the P-ROC community.)

So for the whole thing about honoring your ancestors and influences, I hear you on that! I don't want to make light of the influences, but everything in the world is based on the shoulders of what came before it, so this is not an MPF or FAST thing, it's an everything thing. MPF would not be what it was today had I not first learned Pyprocgame, so a huge thanks to Gerry and Adam there. But also for some of these things, there's only one logical way to do things. Pyprocgame from 2009 has a lot of similar concepts as Brian Dominy's FreeWPC from 2006, which has a lot of concepts from the original WPC code from the 90s, which..., etc. The FAST hardware has many concepts similar to the P-ROC in terms of a USB-controlled device controlling the hardware with code running on a computer, but of course Williams Pinball 2000 had a similar thing, and today's SPIKE is similar in terms of I/O boards, and JJP's system is similar. Again, there aren't too many different ways to skin this cat. (Similar to how all cars today kind of look the same. Even a Telsa still has four rubber tires in the corners, 2x2 seating, a trunk in back, etc.)

And you can play that back even farther. Everything MPF does is also based on the thousands of hours other people put into OSS projects like Python, Kivy, SDL2, Gstreamer, YAML, Linux, etc. Hopefully if anyone makes another pinball framework in the future, they can use everything that MPF does as an influence too.

Getting back on topic, bottom line for me is I don't want to people to think that the only option for MPF is to do everything in configs. Use as much or as little of the configs as you want, fill the rest in with your own code. MPF is moving forward at a fast pace and will continue to do so for some time. If you use MPF, you can spend time writing fun pinball stuff and not boring pinball plumbing. And if you are the kind of person who likes boring pinball plumbing and loves a coding project (like me!), then if you use MPF you can write or improve on boring pinball plumbing code that will benefit lots of people all over the world versus spending hundreds of hours writing code for a machine that sits in your basement 360 days a year.

Congrats on taking the plunge into the crazy world of home brew pinball. We need more of it!

Multimorphic does not recommend this, per se, they offered it at one time, and put it on there site to help users solve the power challenge. Switching supplies certainly have their benefit and there are plenty of P-roc users going that route, I'd bet a majority are at this point. I use a mix of the two, was very easy when I was starting out to get the Antec and not have to go research on high voltage supplies, which would have likely just confused me. You can get a version with 70/12/5 or 70/24, which certainly can be handy, but by no means I am saying that is the way to go.

There are really only four voltages I have used, and personally I have only needed three with drivers (I don't drive any coils, lamps, etc. with 5 volts, well, I do some 3 volt "driving" right off the p-roc for controlling steppers and servos). So, yes having banks of 8 drivers tied to one voltage, can result in a few wasted drivers (pinballcontrollers driver boards have 16, in two banks of 8). Off the top of my head, I believe I am running, 24 drivers with 70volts, 8 with with 24v and 16 with 12. I believe I currently have a few spare drivers on the 12 volt bank and 2 or 3 on the high voltage). Certainy smaller boards would help avoid wasting drivers. But given the incredibly high cost of making a machine from scratch, I'm not losing sleep over the $50. Most folks don't realize how expensive building a machine is.

For the .net fans, I believe there is a .net version of the pyrprocgame framework, call netprocgame. There are others who would know more about that, I'm a linux guy, and while Python not necessarily my first language of choice, I really have no animosity towards it. Then again, over 30+ years I have worked with dozens of languages from assembler to Basic and not sure I've truly hated any, most have some redeeming value, although certainly plenty I have no desire to touch ever again -- so maybe that could be defined as hate

With either FAST or P-roc you don't need to use a framework, but the foundation those provide will get you up and running with a functional game in significantly less time. When you start to get into it you realize how many different aspects of a game you need to handle. The range of problems you need to solve is quite massive and diverse. It is great that there is a choice of frameworks, so you can find which works best for you based on your skill and desires.

Actually I tend to do dozens of drawings on paper and some in cad before ever cutting a piece of wood. Pinside and Youtube never sees that part of my design phase. There's a little bit of it on my www.linscustompins.com web page, though it is a bit abridged.

King of the Arcade is different, Mike Testa is spearheading that table's design with me there as suggestion, philosophy, and build support. That game is purely a spit-ball bolt-on-the-table design. I'm in the process of inputing everything into cad now... and it is VERY tedious to measure and rebuild that into a cohesive schematic. I don't think I'll really ever design like this again.

I also never program my games, do a build, test, make changes, do a build, test, etc. I always 100% write game rules, logic, and visuals on my PC in my office. Every once in a while I make a new release build to test on real hardware. For example- Tail of the Dragon was written in 1 weekend while sitting on my couch. it wasn't until like 2 weeks later I tested it on the actual table. I have my custom LinPingine engine built and ready to go, I know what my hardware IDs are and what wire to hook up to what pin so everything works.

Oh I've done C# windows stuff, C++, iphone app, etc but in my day job I'm strictly in C and some python. I don't really care for custom python libraries for the most part, mainly because if you have a problem it becomes very difficult to troubleshoot...if the author isn't available, then you're basically trying to figure it all out yourself and then it ends up being more trouble than if you had just started clean. So to me, I'm sure you can get from point A (start) to point B (prototype game) much faster using the python libraries. However, my guess is that getting from point B (prototype) to point C (full debugged complete game) you're going to be better off with C if you're an experienced programmer at it due to being able to debug issues way easier that come up...they may fix the library issue in python you found, but when you take the new version, two other bugs you weren't expecting popped up.

Okay, a hardware question - I see in the store that there's a WPC/S controller, Nano controller, and Core controller. Am I correct in assuming that the WPC/S controller has built-in switches (compatible with switch matrix), etc? If not, the only other I/O I see are all listed as 'direct switches'..

--Mike

Yes, the WPC/WPC-S controller does switches the same way as WPC did originally. We also have a Switch Matrix daughter board coming "soon" that allows you to add a switch matrix in a FAST system using a Nano or Core controller. So you could at it to a FAST I/O 1616 and have 64 Matrix Switches, 16 Direct Switches and 16 Drivers.

Aaron
FAST Pinball

PS: Busy day incoming, so my replies might be slow. I'll catch up though later.

I eagerly await this!

Ah, cool!

I think the one thing we can all agree on is that the P-ROC guys are terrible at naming things.

pyprocgame, which needs pypinproc to work, and pyprocgameHD for graphics, then skeletongame.

Oof. Clearly names chosen by programmers...

hey now, thats not a bad name. It provides the skeleton (supporting structure of a machine) that you then have to flesh out with your rules.

BTW, skeletongame is used in a programming class at a University, to get the students up and running quickly in creating games.

I put together the board which allows you to interface a P-ROC to a Sys11 pinball. I call it the "P-ROC / System 11 interface board". Doesn't sound so terrible I'm also a programmer and added some more code to pinmame to allow it to drive a physical System 11. I called it pylibpinprocmameskeletonsys11. Oh, wait....

Since only programmers are using these then it weeds out those that shouldn't worry about them

Libpinproc is C++ but easily interfaces to C.

My $0.02 worth of custom game tips:
1) a service menu/screen should be your first item to get running, especially with any custom hardware and especially with custom wiring. I used P-ROC's pinproctest module as a starting point for a simple standalone display for switch matrix activity, then later added keyboard commands to fire outputs (solenoids, LEDs, Flashers). During game hw dev you'll want to quickly verify any changes you made, or find that solder joint that broke, that noisy opto, that fuse you blew, etc...

2) assets take time. After getting your whitewood flipping and basic play sorted out, you now realize how boring modern pinball is without music, sounds, and animations (unless you're re-imagining an EM with over $1000 of custom electronics hardware.) Grinding out mode code is one thing but gathering suitable assets is a challenge. Fortunately for use there's the innerweb and DVD's!

So.. Aaron.. any plans on making an I/O module for Gottlieb Sys 3 combined light/switch matrixes?

That actually is a good related question - I didn't see any method for connecting a DMD - either plasma or RGB - to the system? (LCD could easily be handled by host computer..)

My first three custom games used the PROC, but for my fourth game (completed June last year) I had the machine wired up with both PROC and FAST during the development stages. With a couple splice connections in the wiring harness, I was able to do a head-to-head comparison and change back and forth as needed.

I ended up going with the FAST system, I felt the hardware had a slight performance advantage in auto-fire mode (like the machine-gun effect you get on your thumpers), and being able to adjust the debounce of the switches made things a little easier. The PROC stuff is actually still in the machine unused, just sits under the FAST hardware.

My fifth game is also using FAST hardware...

One of the differences between the FAST Nano controller and the FAST Core controller is the Nano doesn't have the DMD port while the Core does.

If you are using a traditional DMD, you need the Core controller. If you are using a RGB DMD, that just plugs into the host PC via USB and MPF takes care of the rest. The data doesn't go through the FAST controller for RGB DMD.

I asked the same question last year, maybe you also can find some input in that thread despite it being from 2015:

https://pinside.com/pinball/forum/topic/custom-game-p3-roc-or-fast#post-2582452

Due to other commitments my whiteboard with the blueprint is still standing in my hobbyroom, but I am looking forward to when I get it going and settle on a board set.

Yay another one of these with all the usual suspects I see. Well I can't really give an accurate comparison since I haven't used a fast system and I haven't used mpf so I can't say it's better or worse than the tools I used. I have one complete fully functional game made from scratch powered by P-roc called deadpin and another made with the P3-roc that is just about in the testing phase. Connecting the boards is simple and fun. Really easy to be neat or should I say gives you the choice to be neat . My first machine was written in pyprocgame. I am not at all a software guy but I was able to write a set of rules pretty quickly. If a had a problem I just asked and got an answer pretty quickly on the forum. The community is strong that's for sure. Lots of smart. Capable builders and programmers ready to help.

I am working on a fresh wiring setup on the portable pinball machine I built. I will be live streaming that tomorrow evening. Probably around 7pm PST. I figure since I was going to be doing the work for photos and documentation, I may as stream it so people can toss out some questions in real time.

Aaron
FAST Pinball

Check out http://pinballmakers.com/ - tons of info on making your own games.

Lots of docs here . . .

http://pinballcontrollers.com/index.php/products/p3-roc/documentation

It will be archived online. We discovered we could push the Twitch streams to our YouTube channel.

Live Streams are at:
twitch.tv/fastpinball

Archives:
https://www.youtube.com/user/fastpinball

Our last stream showing how the FAST Firmware Bootloader worked is archived there. You will see hardware wiring samples on our demo table too.

Aaron
FAST Pinball

This topic always brings passionate discussion, and it's nice to see most of the opinions from both sides being backed up with facts and experiences. There are a lot of talented, passionate, and dedicated people who have chosen pinball and custom pinball development as their hobby, and we're all better for it.

I know it's sometimes nice to have these discussions without the manufacturers involved. So I'm going to write up this post and then step aside. If you want me to come back and answer any specific questions, I'm happy to do so. Also, always feel free to PM or email me directly at [email protected].

If you're looking for people to help and support you with your projects, you can't go wrong with either choice. Custom pinball building tends to bring people together, and it's clear the both sets of products have a bunch of passionate supporters. The P-ROC community started building custom pinball machines in 2009 and has grown to be a very passionate group made up of many of the most talented developers in the industry. Many of us have been chatting and hanging out almost daily for nearly 7 years on the P-ROC forums (http://www.pinballcontrollers.com/forum) and for the last couple of years on our slack channel (https://pindev.slack.com). While the slack software is set up to require people to request access to the group (email me with your email address if interested), we welcome everybody into our discussion areas, even those who disagree with our views and opinions. You'll even find the majority of our competitor's customers are members of our forums or slack channels, and they're welcome. The P-ROC community is all about helping people. That's why I started the company, and that's the type of community I'm proud to have helped develop.

OK... on to the products:

Unless I'm mistaken, the original P-ROC is still the only choice for interfacing a computing engine of your choice (R-Pi or mini-computers are common choices these days) to WPC, WPC-95, Stern Whitestar, or Stern SAM machine. Literally hundreds of unique retheme and custom pinball machines have been developed on the original P-ROC, and it will remain an important part of our product lineup for a long time.

For fully custom machines, there are now two fairly similar choices. We started selling our P3-ROC and PDB driver boards in 2012, and last year the FAST boards came to market with a very similar feature-set and price point. If you're building a fairly generic custom machine without too much complexity, I'm sure either set of boards will work fine for you. If you're into details and want to take advantage of a superior set of products, you'll want to go with the P3-ROC and PDBs. Here's why:

- Product maturity: We've been selling the P3-ROC and PDBs since 2012, enhancing the firmware as necessary to improve customer experiences and to add features.

- Product adoption: Literally hundreds of machines are being built with the P3-ROC and PDBs, including those from multiple professional pinball manufacturers. We (Multimorphic) are also using the P3-ROC and PDBs in our P3 Pinball Platform, which uses 1 P3-ROC and at least 5 PD-16s, 1 PD-LED, and 5 SW-16's per machine. This shows our long-term commitment to each specific product.

- Documentation: We have never released a product without documentation showing how to use it.

- Software support: We developed our own drivers and co-developed the original Python pinball development framework, pyprocgame. Since then we've supported the efforts of multiple groups forking pyprocgame and either re-architecting/rewriting from the ground up (MPF) or enhancing (pyprocgameHD). For the non-Python developers, there's a .NET port of pyprocgame (netprocgame), and people have successfully built P-ROC games using Java and just straight C/C++ layers on top of our libpinproc driver.

- Features: Instead of just listing the features that you can read from our website (http://www.pinballcontrollers.com), let me address the things others have tried to label as shortcomings of our products and explain why they were intentional design decisions that are actually better for custom machine builders:

As already corrected by Rosh, Multimorphic doesn't recommend any specific power supply solution. We just provide options. You can use regulated or unregulated DC supplies between 5V and 90V with our PD-16's. And for the record, inductive loads like coils are very tough on power supplies. Most power supply experts will tell you the exact opposite of what Wolfmarsh said above. Unregulated supplies like transformers are much more reliable than regulated supplies in pinball machines. The industry is largely moving towards regulated (switching power supplies) because of costs and easier-to-meet safety regulations with lower voltage switching supplies. We have customers using unregulated supplies (transformers with bridge rectifiers), and we have customers using switching supplies. We're using switching supplies in the P3.

You can of course use the FTDI Virtual COM Port Driver to control a P-ROC too, but very few experienced developers would ignore the advantages of a well-architected low level library that abstracts all of the hardware control logic away from the high level framework. libpinproc is our open-source C-level interface library to the P-ROC / P3-ROC. Yes we struggled early on with making it easy for people to install, but thanks to Jimmy, Michael, and Gabe, those days are mostly behind us. If you're just using the high level frameworks (ie. pyprocgameHD or MPF), you likely won't care if they make use of the libpinproc library or make calls directly into a virtual COM port. If you're developing your game with any other tools, you'll be thankful for libpinproc, as it keeps you from having to reimplement the low level calls and management of hardware resources. There's a reason almost all hardware products in the world have low level interface libraries. Users and framework developers shouldn't need to know details about the hardware. If they want to know them, all layers of the P-ROC software stack are completely open-source.

This breaks the "separation of functionality" paradigm and makes it significantly more likely that at some point high voltage from the drivers will short out and blow up a switch circuit, either by accidental user error or perhaps a wire coming lose on your game.

For a modular control system, creating more and more variations and combinations defeats one of the main purposes of modularity. For drivers, we offer the PD-16. For switches, we offer the SW-16. For LEDs, we offer the PD-LED. For pinball-style lighting bulbs (incandescents or LEDs), we offer the PD-8x8. Use as many of each as you want in whatever combination you want. If something goes wrong on a driver circuit, debugging is easy. Swap PD-16's to isolate the issue. If need be, replace one. You don't need to stock all of the strange permutations and combinations of features. Modular control systems are most efficiently implemented when all of the same functionality is minimized into the smallest functional block possible. We settled on the PD-16 being 2 banks of 8 drivers because that's a good balance. More than 16 drivers would oftentimes be too many. Fewer would oftentimes not be enough. Sure, there will people who need just one more driver and need a full additional board to support it. That'll happen with competitor boards too.

This completely breaks modularity and even makes certain machine configurations impossible (like the modular-based design of the P3). Such a setup makes it nearly impossible to provide any kind of user-friendly safety mechanism. In a pinball machine, you want your safety mechanisms (ie. fuses) as close as possible to the devices they're serving, and you want them protecting well organized groups of devices. With the PD-16's, each bank of 8 drivers can be sourced with whatever voltage you want (5V-90V), and each bank has a local fuse. You wire power from that fuse, to the devices that bank is controlling, and back to the bank inputs. Wiring is localized and much cleaner than the alternative. If something blows a fuse, voltage is taken down only from that bank. The issue is localized, and debugging is easy. If there isn't a fuse protecting the drivers on the actual driver board, I'd suggest looking for a new driver board.

I've said it before, and I'll say it again. No electrical engineer worth his salt will recommend running a serial chain of single-ended (ie. non-differential), digitally controlled devices under a noisy EM environment such as the one that exists under a pinball playfield. If you're buying machines with such configurations, be prepared for issues. If you're designing machines with such configurations, be prepared for issues as well. You might get lucky and never notice any problems, but that'll be pure luck. Best case, you'll get periodic glitches on your LED chains that are quickly overwritten and essentially invisible. Worst case, chips will fry, resulting in dead circuits and possibly fires.

Our PD-LED boards communicate to the P3-ROC via the same 2-wire RS-485 as the rest of the PDBs. RS-485 is designed to run through noisy EM environments (ie. car control systems). Our PD-LEDs convert the commands from the P3-ROC into the 3 control signals for each LED. There is no single-ended digital communication bus running under the playfield with our boards.

Daughterboards make very little sense in a closed system like a pinball machine. It's not like you're buying a carrier board from one manufacturer and daughterboards from other vendors. You're buying all of your functionality from the same supplier, and there's never any reason to swap the daughterboards. Things would be more reliable and less expensive if the carrier and daughterboards were combined into a single board. The only caveat to this is if the manufacturer is opening the spec of the daughterboard interface, allowing you to create your own daughtercards for specific functionality. In that case it makes sense for the original designer to design the common/carrier circuitry, allowing you to design just your specific device-control circuitry. We've done something similar by opening up our driver bus protocol in 2012 when we first released our PDBs. Anybody wanting to develop their own logic to interface to our driver bus can do so.

Further product differentiation: the P3-ROC's serial communication channel runs over 8 times faster than anybody else's in the industry. For machines with typical feature sets, you won't care. If you ever want to add a high bandwidth device, you'll be glad for that bandwidth.

One more technical comparison between our products. We use .1" molex headers and simple 2-conductor cables for our serial chain. Everybody else seems to be using cat-5 cables and RJ-45 connectors. Our .1" molex connectors use a friction locking method (ramp). RJ-45 use a latching lock. If you're raising your playfield and one of your cat-5 cables snags, you'll rip your RJ-45 connector off of your board, likely ruining the board. With our .1" molex headers, the cable will get pulled away from the connector, but everything will likely be fine. The 2-conductor cables are also much easier and less expensive to make. They're made from the same components and with the same tools as other cables in custom machines.

If there are any other statements you've heard about the P-ROC, P3-ROC, PDBs, etc, that I haven't addressed. please ask me. In the 7 years we've been doing this, our customer satisfaction rate is incredibly high. Those that have issues are treated with respect and as a priority. Usually the issues are easily resolvable through email or forum discussions. However, due to the variety of custom pinball machine implementations, sometimes we depend on you to help us help you debug and resolve issues. Our products have matured over the years because of input and feedback from all of you, and I know of no outstanding issues remaining to be resolved. We continue to appreciate your support and your business, and we look forward to helping you realize your custom pinball development goals.

- Gerry
http://www.pinballcontrollers.com
http://www.multimorphic.com

Gerry, just typing something in a long pinside post doesn't wipe the past and make what you say true. If you aren't proud of the experiences that some people have had, own it and make steps to keep it from happening with others.

Aaron
FAST Pinball

This might be the least classy post I've seen on pinside in a long while.

If you're going to attack someone's character at least have the decency to substantiate it with evidence.

Michael,

Talk to Gerry about this. If he felt compelled to address a topic of "treating people with respect" there must be something to it. Treating people with respect should be a given.

Aaron
FAST Pinball

I'm still after a 64bit pinproc.

science-dog1_(resized).jpg

I need to enact a "don't post when you first wake up I the morning" rule on myself. I latched onto the comment I did because it reminded me of the experiences some friends had and I get defensive of my friends. They are big boys and can stand up for themselves, so I just need to remind myself I don't need to get involved.

I intend to finish this cup of coffee (and most likely another!) and then I will respond to Gerry's breakdown, focusing on the topics relevant to building pinball. (EDIT: I need to stay on track with my documentation goals. I will link back to this thread when they are posted. Should cover the topics addressed.)

I am human. Sometimes I care too much and the heart speaks before the brain knows what's going on. If that is going to be a "fault," I guess there could be worse. But man, that fault suuuuuucks in forums in the morning!

Aaron
FAST Pinball

Maybe those engineers aren't as smart as me?

Careful contradicting yourself in the same paragraph. "Transformers are better and more reliable, but in 'the most innovative platform in the world' we've gone with switching supplies."

"Buying functionality from the same supplier"...... Why would you close your ecosystem and not want third party developers adding hardware to the system? With the daughterboard interface I've been able to add my own circuitry right into the FAST system. Imagine having an arduino sketch compatible daughterboard. What a low entry point for people to extend the system. For a system that claims to be the most open, that's an interesting decision.

What is an example of a high bandwidth device that you think FAST can't support?

This is not exactly a technical comparison. There are a lot of "what-ifs" in both methods.

Like, "what-if" that delicate 2-wire twisted cable get separated or undone, by even an inch, you are liable to get noise on the bus. Ask an automotive engineer.

Edit: Removed a rude statement I shouldn't have made. You can see it below in mocean's quote.

Stay classy.