P2 & Pinball
PurpleGirl
Posts: 152
While I might never start such a project, I can imagine that a P2 could simplify a solid-state pinball machine.
.
How Solid-State Pinball Machines Have Traditionally Worked
Solid-state pinball machines tend to function like this. The power comes out of the transformer and goes to a power supply board that rectifies and produces some of the necessary voltages. Then from there, it goes to the solenoid driver board which also regulates and filters the voltages further. Those that used plasma displays also had plus and minus 190-volt lines, for a potential close to 400 volts, and that is rectified, regulated, and adjusted on the solenoid board too. So the 5-volt line to drive the MPU board typically comes off of the solenoid driver board of all places. It doesn't have to be done this way.
The solenoid driver board typically has two types of solenoid circuits. There are the regular solenoids and the "special" solenoids. The difference is that the regular ones are CPU-controlled only, while the special ones are more autonomous and can be driven by user/game interaction or by CPU intervention. The CPU intervention isn't strictly necessary for some things, but it is helpful for the test mode. TBH, that isn't always helpful since the logic from the CPU might be fine, but something is screwed up between the playfield and there. The reason for doing it this way is that some things need to happen in real-time and not wait on a PIA chip to throw an interrupt and the CPU taking the time to service it. That is a common mistake that those designing Arduino-controlled pinball machines fail to take into account. So they have lag in the flippers because of the bottleneck of going through the controller. Instead, a better strategy is to handle things directly based on the actions of the player or features on the board and also tell the CPU that this occurred. The only actions the CPU needs to take with the flippers is to mute them when necessary, such as during attract mode, and perhaps flip them during test mode.
Speaking of flippers, they are designed to work off of 2 different currents. There are 2 separate windings on those with 2 different gauges of wire. They are wired in series and center-tapped. There is an end-of-stroke switch that is normally closed and shorts out the finer coil. That way, you draw more current to rapidly flip the flipper. Then the switch opens and places the finer coil in series to hold the flipper without burning up the coil or shorting the transistor driving the coil. The high current mode is only momentary. That might be another pitfall for a newbie at designing a pinball machine. While there are replicas of what the machines used that are rather easy to obtain, some might still use the wrong coils with the flippers or wire them wrong.
Now, the MPU board contains the CPU, ROM, RAM, PIA/VIA chips, line decoders, a watchdog circuit for the CPU, and sometimes the light driver circuitry. Decoupling caps should go without saying. Of course, the MPU board functions might be split off onto another board, or the light drivers might be on their own board. The sound is often on 1-2 other boards. The reason for 2 boards for the sound is that one may be the main board that is used for tones, noises, and amplification, and it may have a slave/coprocessor board for speech generation. The MPU board will also have a way to back up the settings and high scores. Often, you can configure things in one of the test mode selections (and you can only get to the test mode switch inside the coin door). The original machines used batteries, but some have replaced the SRAM with an NVRAM chip. At the least, if you find one with batteries on the MPU board, do yourself a favor and move the battery pack to the wall of the cabinet and run wires to the MPU board. You don't want to deal with corrosion and leaking batteries.
Now, the displays were mostly plasma in the beginning, though Gottlieb used vacuum fluorescent displays, and later machines started using Dot Matrix Displays. TBH, I wouldn't use DMDs. Sure, you can do neat things with them and even include mini arcade games on a pinball machine, and put up information, instructions, and public service announcements ("Only losers use drugs!" or "Settle it with words, not violence.") However, my reason against using those is that they are patent-encumbered, expensive, and somewhat complicated. Plus you might have to get them to make a ROM for it for you, and they tend to use activation keys. Likewise, HDMI isn't friendly for hobbyists and small businesses either due to licensing, and yes, they will sue you, even if you sell just a couple on eBay or Etsy. And really, in this day and age, if you want to go modern, just install a flat panel monitor in there. But if you want to go more retro, I'd say to use large segmented LED displays, and they even come with colors that closely match the plasma displays. You can make your own boards or get them from Rottendog Amusements or some other 3rd-party company that makes replacement displays that use LEDs and are designed to work with plasma displays. So you don't have to bother with 200-400 volts. Those run off of 5 Volts, and you might want to harden the power and solenoid boards and use larger rectifiers, larger regulators, higher current resistors, maybe heavier gauge wiring, and maybe increase the capacitance of some capacitors. Plus you could then remove the fuse to the high-voltage section since nothing would use that if you use only LED displays. Now, if you want to use the LED boards with a custom design, then you'd need to know the protocol that the MPU board (and light driver board if it is separate) uses. It is some sort of strobed serial signal, I think, but it could be parallel, but with all the displays' data running on it. The plasma and similar displays are daisy-chained, strobed, and have a blanking signal.
.
How the P2 Can Be Used
So the above is a general overview of how pinball machines have traditionally been done. I think a P2 can replace a good majority of what is in a solid-state pinball machine. You can likely put all the ROM data needed in the hub and use the internal memory. Without multiple socketed ROMs of the old machines, you remove a point of failure. There should be enough pins to emulate 3 PIA chips if needed, and the P2 has 3 interrupts. The sound and speech can be produced in the P2, so one or two fewer boards there. In place of the MPU board components that are not needed, you'd have room to put the lamp driver components and maybe the solenoid driver components all on that board. You can't get out of using power transistors for this application. (And don't bother with chips that include more than 2 transistors as they are harder to find. I say two because you might very well need to use Darlington transistors.) Now, interfacing with the P2, you'd likely need voltage levelers, and to be honest, some buffer or transceiver chips or even optocouplers in some places wouldn't hurt. And one thing that I think would be good is that for switches, add Zener diodes and maybe a 1/4 amp fuse downstream from the MPU board. Generally, you'd fuse things upstream, but the biggest risk here is accidental shorts on switches. Techs can be careless with tools and terminals can get bent, possibly hitting something it shouldn't, and in the worst case, someone solders a solenoid wire to a switch terminal. So you want to protect your MPU board.
Now, you might find a use for decoder chips on your board if you use mutually-exclusive lights. Thus you can save pins like if you need 8 lamps where only one can work at a time, you get to use only 3 GPIO lines. Or, you could resort to Charlieplexing since the lines can be z-stated and you can use LEDs or transistors to treat 0 and 1 as drives, and you could strobe them if desired for persistence.
So you get a CPU, sound, speech, and PIA/VIA functionality, and a lot fewer inter-board connectors. You might even get to replace some of the other driver circuitry if you have pins to spare.
And, if you want to design your own LED displays for the scores, you could make your own protocol, maybe use at least a P1 to handshake with it, and have a master display board and 4 slaves, or whatever. Or just design for the industry standard and use existing boards. That might be the better option.
Comments
I think Ben Heckendorn used a P1 as a coprocessor in a pinball machine some time ago. I wouldn't use CharliePlexing as it's easy enough to use shift-register with FETs (or combo chips like the TPIC6b595) to get a lot of outputs with just a few pins. It doesn't take a lot of code to do 8-bit PWM across those those shift-register outputs (for devices like LEDs or lamps). I wrote a P1 driver that is used in arrow boards (like this)...
...and has been used at Disneyland by their tech group in a lot of 1-off projects. The driver allows 32, 8-bit PWM outputs using four shift-registers. It's nothing to write home about, but it works in the applications it was designed for. With P2 Smart Pin SPI, it would be easier and much faster.
Personally, I'm looking for a really clean (not just "good enough for experiments") SD driver, and a Flash driver to match. I co-designed and coded a commercial WAV audio player for the Halloween and Escape Rooms industries, and porting the audio portion to the P2 was easy, and provides more features. Now I need a really good SD driver, and I'm not anxious to write one myself.
The SD card VFS driver that comes with flexspin is really good (because the FAT layer is a pre-existing library), but slightly clunky to call from Spin due to lack of structs and only works on flexspin (I know you prefer PropTool). I think someone made a flash VFS driver at one point?
@Wuerfel_21 your xYume uses the spi driver from FSRW with Kye’s high level code.
I recently modified fsrw a hair so that both FSRW and Kye code can use same spi driver. Also think the cogged version of spi driver is now fixed, maybe by you I think.
A long time ago, I did adapt fsrw for flash. Worked well but haven’t used it lately. People complained that it could wear out the flash if used improperly. Which is true, so don’t use it improperly.
Presumably, one could likewise adapt the flash driver to use Kye’s code now…
FatFs, used by flexprop and virtually everybody is a much more bulletproof code. Maybe Eric knows some magic way it could be used in Prop Tool.
That said, I added super fast sequential multi block reads to FSRW. So, I’m going to hold onto that…
No, it uses flexspin VFS
You’re right…. Did it used to?
I’m remembering your thread about this..
No, that never did. But SpinHexagon for P2 does.
Some lower tech can be used for general illumination. For instance, for the "infinity lights" on the "claw" machine games, the lamp driver board for that is quite low-tech. (They are called "infinity lights" as only 5 bulbs appear to be many more because of a mirror and a slightly tinted glass, with cascading reflections.) Those use a split-phase transformer mounted on that board, with the AC being common to the primary of the transformer and the triacs that drive the bulbs. There are 2 diodes to provide full-wave rectification at half the rated voltage of the transformer and a capacitor to clean that up. Then there is some sort of oscillator, maybe a 555 timer or something that feeds a counter chip. The counter drives address lines on a small ROM. That drives the output triacs through optocouplers. That makes sense in case the triacs short out so that 120 volts don't go up the board and possibly cause a fire. So you don't even have a microcontroller, just a clock, a counter, and a LUT, with optocouplers and triacs to control the high voltage and keep it otherwise off the board. So for general illumination, tricks like this can work and not cut into your signal lines.
Ada's 'sdspi_with_audio' and the FAT32 driver, has been rock solid for my light controller. 0 problems with it. The config file for the controller is read into memory with that driver and all web pages/CSS/Image files are served up to from that driver. It just works.
I have had to back out my changes with Rayman's cogless driver. It zapped a few cards due to instability with other things I was working on. Not sure why. I had to format the cards to get them back into a usable state. Not sure it is the fault of the driver, most likely in the way my system was crashing due to my bad code.
I guess the approach comes down to how you envision the wiring handled.
If you bring every Light control into the master, that quickly becomes a 64 legged octopus.
I wonder if a more distributed approach could be used, where Serial RGB leds are used in strings - already common tech, and I think a small MCU can be coaxed to emulate a LED, allowing some power output nodes to be mixed-into the strings at any location.
Yeah, you have two types of lights in a pinball machine. For a claw machine, having sequenced lights using their own controller board makes sense, since the game itself doesn't use lights to do anything. So that would be general illumination.
Pinball machines use general illumination, but they also have feature bulbs. I gave an example of handling mutually-exclusive bulbs. For instance, if you have levels and a "level chart" on the playfield, you could use 3 lines and a 3-to-8 decoder, though that would need to be one that works opposite of what you use for memory banking. So an active-high decoder rather than an active-low decoder. The active-low ones are used to drive /CS lines when memory is divided into banks. The memory ICs would be all wired in parallel except for the chip select line, and the unused addresses drive the decoder so that only one /CS line is driven low (asserted) to enable that bank. An active high decoder would be good for driving mutually-exclusive bulbs (or the transistors that drive the bulbs). So using LEDs where you can make sense as that allows for simpler circuitry.
Your idea does sound interesting. And yeah, you could likely even coax the bulb flasher for a claw game to act that way. In that case, I think the /CS on the ROM would be a target. With that disabled, it can keep naively displaying and nothing would happen with the bulbs.
Speaking of bulbs. Those restoring old machines tend to use lower wattage versions of the original bulbs, such as using #47 or whatever number in place of #44. So that produces less heat and is kinder to the machine. In solid-state designs, that helps the drive transistors while in EM machines, they help preserve the contacts on the relays. And blinker bulbs have been used in EM machines to time relays. A relay would latch to drive a buzzer, and a blinker bulb would unlatch the relay when it gets hot enough to blink. So there was hackery even in EM machines. For other time calculations, the scoring motor would be used. That would be too much trouble to rig that up for short intervals that might not even happen within a desired time, so a blinker bulb can do those.