FireSlash
New member
Custom pin
I've been sitting on this idea for years, a few beers and digging up ye olde Arduino finally kicked me into gear on it. I had a thread going on vpforums but it seems a bit more relevant here so off we go.
The design was originally spread around the bally board set entirely. I ended up replacing the lamp board after realizing the bally lamp driver is really really hilariously simple, and I want to get all fancy. I'm still on the fence on replacing the power and solenoid boards, but for now they're still based around the bally boards. However there's nothing particularly complicated about them so there's a good chance they'll get replaced if it becomes necessary.
Arduino Mega R3
This is the brains of the operation. It can quite easily replace the MPU in the original bally system (16mhz of fury) and the massive IO potential makes it perfect for interfacing with the various bits of a pinball machine. On top of that, the microcontroller approach eliminates the annoyances of dealing with an operating system, so no extra latency and layers of complication.
Raspberri Pi
The rPi is a itty bitty SoC that runs linux. It'll be hooked into the arduino via serial to do things that microcontollers are bad at, specifically sound and video processing. Currently I'm using a laptop for this purpose but all of the code is written in python and will directly port to linux when the time comes.
So how does it work?
Currently there's not much to it. The switch matrix can be read directly from the arduino; there's no need to deal with switch controllers. I might change my mind on this later as the programming becomes more complex, but so far it's been more than adequate and that's without factoring in how much easier the lamp matrix is going to be to manage with the new board. So effectively 16 lines are burned with strobe/return lines for the switch matrix. 4 lines are burned for the solenoid board (Bally uses a simply 4->16 decoder so wiring it isn't exactly brain surgery), and right now the bally lamp driver is wired (8 pins; 4 data 4 select) but it'll be replaced with the PWMing controller I've got breadboarded which only requires one serial line plus a few common pins for things like clock.
What about the display?
I've not decided what I'm doing here yet. Part of me wants to go with the classic DMD, another part is leaning LCD, but the form factor in an LCD isn't exactly conducive to pins. Also a DMD would double the project's budget thus far.
Show me shiny things!
Early testing: http://www.youtube.com/watch?v=uHRC6d9WarQ
Quick gameplay: http://www.youtube.com/watch?v=Pe24bHsGebI
Lamp driver test: http://www.youtube.com/watch?v=9Xs_zw19ZBU
Status
I've fixed the switch matrix issues by using comparators (similar to the WPC switch matrix design) instead of the bally design. This was necessary because the switch return voltages aren't stable enough and they were falling outside the logic ranges the arduino uses (there's a dead "floating" spot that could read randomly).
Right now I'm mostly trying to source a playfield so I can start coding field specific logic and build the boards to meet the demands of the field. Right now it's hard to start sketching up PCBs because I don't know what kind of connectors and such I need to handle, nor do I know the width of the switch/lamp matrices, solenoid voltages, etc.
Got a spare populated PF you want to unload?
I've been sitting on this idea for years, a few beers and digging up ye olde Arduino finally kicked me into gear on it. I had a thread going on vpforums but it seems a bit more relevant here so off we go.
The design was originally spread around the bally board set entirely. I ended up replacing the lamp board after realizing the bally lamp driver is really really hilariously simple, and I want to get all fancy. I'm still on the fence on replacing the power and solenoid boards, but for now they're still based around the bally boards. However there's nothing particularly complicated about them so there's a good chance they'll get replaced if it becomes necessary.
Arduino Mega R3
This is the brains of the operation. It can quite easily replace the MPU in the original bally system (16mhz of fury) and the massive IO potential makes it perfect for interfacing with the various bits of a pinball machine. On top of that, the microcontroller approach eliminates the annoyances of dealing with an operating system, so no extra latency and layers of complication.
Raspberri Pi
The rPi is a itty bitty SoC that runs linux. It'll be hooked into the arduino via serial to do things that microcontollers are bad at, specifically sound and video processing. Currently I'm using a laptop for this purpose but all of the code is written in python and will directly port to linux when the time comes.
So how does it work?
Currently there's not much to it. The switch matrix can be read directly from the arduino; there's no need to deal with switch controllers. I might change my mind on this later as the programming becomes more complex, but so far it's been more than adequate and that's without factoring in how much easier the lamp matrix is going to be to manage with the new board. So effectively 16 lines are burned with strobe/return lines for the switch matrix. 4 lines are burned for the solenoid board (Bally uses a simply 4->16 decoder so wiring it isn't exactly brain surgery), and right now the bally lamp driver is wired (8 pins; 4 data 4 select) but it'll be replaced with the PWMing controller I've got breadboarded which only requires one serial line plus a few common pins for things like clock.
What about the display?
I've not decided what I'm doing here yet. Part of me wants to go with the classic DMD, another part is leaning LCD, but the form factor in an LCD isn't exactly conducive to pins. Also a DMD would double the project's budget thus far.
Show me shiny things!
Early testing: http://www.youtube.com/watch?v=uHRC6d9WarQ
Quick gameplay: http://www.youtube.com/watch?v=Pe24bHsGebI
Lamp driver test: http://www.youtube.com/watch?v=9Xs_zw19ZBU
Status
I've fixed the switch matrix issues by using comparators (similar to the WPC switch matrix design) instead of the bally design. This was necessary because the switch return voltages aren't stable enough and they were falling outside the logic ranges the arduino uses (there's a dead "floating" spot that could read randomly).
Right now I'm mostly trying to source a playfield so I can start coding field specific logic and build the boards to meet the demands of the field. Right now it's hard to start sketching up PCBs because I don't know what kind of connectors and such I need to handle, nor do I know the width of the switch/lamp matrices, solenoid voltages, etc.
Got a spare populated PF you want to unload?
Last edited: