I’m going back and resurrecting the old OPP pinball framework. The reason was that it should be the shortest path to getting back to having a running SS3 game. Problem is that the architecture of the boards changed so some of the assumptions that I made are not going to work.
So with the OPP pinball framework, you create a text file that describes your hardware and how you want the hardware to be initially configured. This file is converted into Python files that are used by your pinball rules to identify bit positions on the hardware. If you look in the Python directory of the repository, the converter is called GenPyCode. Here is a quick link to the text file that is used for SS3. The generation can be done off line since it really only happens during initial development.
So if you take a gander at that file, it is pretty simple. It basically has multiple sections. The sections include SOLENOID_CARDS, INPUT_CARDS and LED_CARDS. That worked great with Gen1 cards because each of those cards were dedicated to a single purpose. Now with Gen2 cards, each card can have inputs, solenoids, and LED or incandescent wings. That change is pretty simple because I just have to keep a list of which wing is which by looking at the individual pins, and I can return errors if a wing board is configured as two different things. Fantastic.
Then last night, I ran into a problem. The file generates constants so when programming your pinball machine, you can verify that certain things happen. The constant must uniquely identify the physical bit. For example, I have a seven target drop bank (SHOOTER letters are on the inserts), and I want to reset the drop bank if all the targets are down. GenPyCode automatically generates the constants. In Python, the first drop target is InpBitNames.INP_DROP_TRGT_1S, second target is InpBitNames.INP_DROP_TRGT_2H, third target is InpBitNames.INP_DROP_TRGT_3O, etc. To check if all the drop targets are down, I simply OR all those bits together to make a mask, and check to see if all those bits are 0 when read from the hardware. Very simple. Whatever scheme I come up with, I want to easily be able to combine masks together to form larger groupings.
The problem is that I also embed the card number in the constant so the framework can tell which bits need to be compared. This all falls apart with Gen2 cards, since there are 32 possible bits and I don’t have enough space to put the card number in the bit mask. I finally figured out a good solution last night, of embedding the card number, wing number, and then the mask for the input. So for 32 bit architectures, the card number is 5 bits, the wing number is 2 bits, and there are only 8 possible bits on each wing, so that easily fits within 32 bits. Sweet. That will mean I don’t have to rewrite large portions of the pinball framework.
Another time that I use this is to program multiple lights at once. Let’s say I want to make all of the drop targets blink to indicate that you should shoot at them. I can simply OR all the drop target bits together, and pass them into standard function called Led_Blink_100, and they will all start blinking.
That’s what I’m going to be working on for the next couple of weeks so that I can get another video together. At that point, I will hopefully be back to the same spot that I was a year and a half ago. (Of course, now using newer and better hardware).