Oh now there's an interesting idea. Certainly that would be possible. However to really be useful, you'd have to be able to not just trigger frames and animations but also dynamic text and stuff. So that would require some kind of code component running on the CPU node that was more than just the bridge.

What's really interesting about this is this is already the exact architecture of MPF. MPF is two parts: the game engine which is like the MPF core which controls the hw and runs the game logic and everything, and then the media controller (MC) which handles all the graphics, displays, and sounds. (The two are connected via a simple socket protocol.)

The catch here is that MPF's MC requires OpenGL and a GPU which doesn't exist on the SPIKE CPU node, so running it there (at least with our current architecture is out). However I would guess that SPIKE 2 has a GPU, so maybe this is an option?

Actually what we first thought about for MPF was to just install and run MPF itself on the CPU node, but the SPIKE CPU node is not powerful enough. It's basically like a Raspberry Pi Model 1 but with less memory. (Which is fine for Stern of course since they built their code around the SPIKE hardware.)

Again SPIKE 2 might be different? Maybe we can just run MPF on the SPIKE 2 CPU node itself? Though for SPIKE 2 it wouldn't matter as much since we don't need the DMD and we can just use the HDMI port of the computer running MPF for the display.

Anyway, lots to think about and play with over the next few months.

Wolfmarsh suggested that we should build up some example configs for the SPIKE machines that are out there so you could just download a working base game and have at it. That would certainly be cool and make it easy for people to try out MPF!

That would definitely be possible. You can look at the mpf-spike-bridge source and MPF's spike platform source and see how that works, and based on that you could write whatever you wanted just for this specific hardware. Since the SPIKE CPU node runs Linux, there are lots of options for how you could do custom code to run on the board directly. I'm excited to see what you come up with!

The homebrew community has taken the approach of separating the pinball control hardware from the game logic / game code hardware. This is why the P-ROC, FAST, and Open Pinball Project controllers don't include game processing elements on them. They control the pin hardware, and then you control them with whatever type of computer you want depending on your preferences and needs. (Big, small, fast, slow, mac, windows, etc.) It also means that the pin controllers can have a long shelf life (the P-ROC is 8 years old this year) and still be relevant since people can always use the latest computer to run their game code. This is the approach that MPF takes too and why the MPF SPIKE bridge works this way.

Stern, on the other hand, builds tens of thousands of boardsets where they know exactly when they will be used and exactly what code will be used. So in their case they can combine game processing and pin control on the same board.

What this MPF SPIKE bridge does is essentially turn the SPIKE CPU node into a P-ROC. The advantage of not running MPF on there is you're not limited by it. So a SPIKE v1 machine only has enough horsepower to run the game that Stern made at the time they made it. But if you're retheming that machine years later and you want to add an LCD or do all sorts of other things, you can do so since you're controlling it with whatever computer you want.

Another way to think about this is if you want to retheme or rewrite a 1990s WPC machine, you have two choices: FreeWPC or P-ROC.
FreeWPC is amazing and cheap because you don't need any new hardware, but you're limited to what the 1990s 6809 CPU could do with 1MB RAM and 8MB ROM, and you have to write your code in the language that can be compiled for it. P-ROC means you have to buy a P-ROC ($325) plus a computer to control it ($50-150), but on the flipside you can write your game code in whatever language you want and you can support HD LCDs and more lights and LEDs and surround sound and whatever else you can think of.

So that's the approach with the MPF SPIKE bridge. Separate the pin controller (SPIKE CPU node) from the computer that runs the game code (can be a $35 RPi 3) so that people can write code however they want without the limitations of the platform decisions Stern made when that game was new.

Correct.

The code that ships on a game from Stern is in a form that is not human readable. So it's not really possible to edit or add to that unless you have the original "source" code that the Stern programmers wrote.

So instead what this thing does is it adds new code to the SPIKE pinball machine (which is on an SD card) which causes the machine to not load the original Stern code, but to instead let the pinball machine be controlled by a computer connected via USB, which then can have the code written on it by someone else (like one of your programmer friends).

There is a free and open source piece of software called "The Mission Pinball Framework" which helps people write their own pinball code which is the thing that we use, but the Stern SPIKE stuff we're talking about today could let someone write new code for a SPIKE machine in any computer language. They wouldn't have to use MPF.

So really this is an either/or thing. Either the original Stern code, or your own new code.

The reason we can't do both is because the original Stern code is locked up by Stern, we don't know how to make new code interact with it. So that's why we say that if you want to use this for your own code, you would have to write a complete game code from scratch.

Agreed.

That's what's cool about this thing, that if you do go to all the trouble to rewrite a SPIKE game, you can give it to someone else and they can run it in their machine without needing a P-ROC. They could run it off their laptop just to try it out.