System Structure - some initial thoughts

I find that one of the best ways to know if you understand something is to see if you are able to explain it to someone else.

To that end, I'm going to see if the plan knocking around in my head can be written up in anything near a coherent fashion. Now that I know that the controller can successfully talk to the pinball's CPU board, it is time to focus on writing more code. This then is the first pass at describing the software system structure. I guarantee it will change, but you have to start somewhere. Read on!

I hinted at the system structure previously. It is largely influenced by the hardware we are replacing and the hardware we are using to replace it. Here is a high level view of the major components.

Mode Engine |

Sound System |

Dot-Matrix Video Driver |

Mass Storage |

Physical Machine Interface

This component monitors the pinball switches and drives the pinball lamps and solenoids. Switch input is queued to be processed by the Mode Engine. Data for driving lamps and solenoids is provided from the Mode Engine and synchronized with the Sound System and Video Driver via cross component data modules and timers.

Mode Engine

Pinball games operate through a set of modes. In each mode, target goals and objectives and scores differ. Generally, the game progresses through a set of modes and once they are completed, a final wizard mode is played after which the main modes are played again, possibly with different rules.

The Mode Engine is an event based system which allows for the tracking of states, switches, timers and ball paths. The Engine provides the ability to control lamps, solenoids, sound and video and to award scoring. This control is managed by interpreting a compiled Mode Engine Control Language byte code. More than one mode may be in operation at a time (the key reason is to have a basic operation mode and the current game mode overlap). I will describe the control language, compiler and byte code later.


The sound system is essentially a sound driver. It will play sounds as indicated by the Mode Engine, pulling the data from mass storage via the Mass Storage driver. The basics of the sound playing is well understood, however I anticipate interesting problems around the need for quick reaction to events. Synchronization with lamps and video as well as caching techniques will be interesting problems to solve.

Dot-Matrix Display Driver

I fully believe that a pinball machine must have a dot matrix display. I appreciate the ease of use of video screens, but it just doesn't feel right to me. A core within the processor will be dedicated to driving the dot matrix display. I'm rather confident that the display can be driven at an adequate rate. Synchronizing with sounds and events will be challenging. In addition, I would like to have more than just on/off for each pixel, so some method of pulse width modulation on a per pixel bases will be required. Interesting challenges. As with the sound system, video data is pulled via the mass storage driver.

Mass Storage

There needs to be a place where we get mode data, sound and video from. Also we will want to be able to store high score information and game settings. Currently we are looking at using a Secure Data card. This is easy to interface with the controller with only a few I/O pins and, according to our initial calculations, we will be able to read data from the card quick enough for both sound and video applications.

Cross Component Data

Not really a component here, but worth noting. The propeller is a very memory restricted chip. At any time, only 32k of memory is available for all cores. Each core is granted access to the memory in sequence. Each of the components will likely be operating independently in its own core, thus the Hub memory will be used to pass critical data between cores. There are a set of synchronization objects built into the chip for the express purpose of keeping critical sections safe. Initial investigation shows that 32k will be plenty of memory provided we can buffer the video and audio data efficiently. Only experimentation will tell for sure.

That's the initial look at the system. The first component being coded is the Machine Interface. For that (and all of the code) we will be using Propeller assembly language. I know, I know, I said I didn't want to hack asm code. I'm definitely not hacking 68B09E assembly and burning roms. I guess the promise of such a small, inexpensive and elegant solution is too compelling for me to pass by. Even if I end up using 2 propeller chips, this is still a small and inexpensive setup.

Next up, diving head first into the assembler code deep end.