What's new
By:
Pinball info

Register a free account today to become a member! Once signed in, you'll be able to participate on this site by adding your own topics and posts, as well as connect with other members through your own private inbox!

Complete Mishmash self build - let’s make a pinball machine

I'd keep OT with cab and playfield together.

I'd even venture to say you might be better restoring it to original condition and finding another cab for the 8 ball.
 
Cheers @myPinballs - great advice and help there. I never did C, or C++ or any of those sorts of languages, so have really struggled with the basics of arduino programming and still do. I was a "business basic" and then 4GL coder, back in the day.

Objects is a concept that I still struggle with, but I've used a number of libraries that use them. Not sure I am up to creating my own. I'm pleased I managed to create a structure to hold my switch attributes, to me this is advanced, :) :

typedef void (*Switch)();

typedef struct {
byte swNum;
String swName;
byte debounceTime; // millisecs
Switch pswitch; // routine to run if this switch is fired in game, not tilted etc.
byte fireSolenoid; // 0 = none
byte soundToMake; // 0 = none
int stdPoints;
int lampToLight;
int lampcolour; // Alan replace with proper led attributes later RGB, CHV etc
byte activeOnStatesUpTo;

} SwitchAttributes;
typedef SwitchAttributes SwitchList[];
// List of Switches and their attributes

SwitchList switches = {
//no, name, debounce, process, solenoid, sound, points, lamp, colour, active on
{0,"Outhole",1000, switchOuthole,0,0,0,0,0,3},
{1,"Rebounds",1000,doNothing,0,1,100,0,0,1},
{2,"Credit Cab",1000,switchCredit,0,0,0,0,0,3},
{3,"Saucer",1000,switchSaucer,0,2,250,0,0,9}, // eject on tilt
{4,"Left Slingshot",100,doNothing,0,3,100,0,0,1},
{5,"Right Slingshot",100,doNothing,0,3,100,0,0,1},
{6,"Left Bumper",10,doNothing,0,4,50,0,0,1},
{7,"Right bumper",10,doNothing,0,4,50,0,0,1},
{8,"NU",0,doNothing,0,0,0,0,0,0},
{9,"Tilt Cab",1000,switchTilt,0,15,0,0,0,9},
{10,"Slam Cab",1000,switchSlam,0,14,0,0,0,9},
{11,"Right Rollover Button",500,switchRightRollover,0,5,200,0,0,1},
{12,"Left Rollover Button",500,switchLeftRollover,0,5,200,0,0,1},
{13,"NU",0,doNothing,0,0,0,0,0,0},
{14,"NU",0,doNothing,0,0,0,0,0,0},
{15,"NU",0,doNothing,0,0,0,0,0,0},
{16,"Right Outlane",500,switchRightOutlane,0,6,100,0,0,1},
{17,"Left Outlane",500,switchLeftOutlane,0,6,100,0,0,1},
{18,"NU",0,doNothing,0,0,0,0,0,0},
{19,"P Lane",500,switchPLane,0,7,300,0,0,1},
{20,"M Lane",500,switchMLane,0,7,300,0,0,1},
}
 
Anyone got an Operation Thunder manual and schematics please? Blooming Gottlieb and their IP over protectiveness.........
 
myPinballs said:
Think so, I’ll check later
Click to expand...
Damn, i've got quite a few system 3 manuals (All originals) but not operation thunder it seems
. Got car hop, cactus jacks, title fight (which is red cover and thought was operation thunder doh!) which are all system 3 alphanumeric games. I also have stargate and street fighter 2 but these are later dmd system 3 games

Maybe some of the wiring diagrams are useful from car hop for the cab cabling?

Side note - if you've never had a gottlieb alan then *warning* *warning* you might be about to take a 'gottlieb detour' which could last years :) ha ha

IMG_0040.JPGIMG_0041.JPG
 
Some of this will be the same aswell. Like the 3 relays, the flipper stuff, gi. so might also allow you to work out how operation thunder coils and flashers are wired up if you use the colour coding to the cable pins shown here. Some of it might even be generic to (maybe outhole & kicking rubbers) , as gottlieb hated to change things!! (This is car hop)

IMG_0046.JPG
 
AlanJ said:
@myPinballs - thank you for looking and yes these car hop ones give me some clues on where to start. much appreciated.
Click to expand...
No problem. i think from the looks of it solenoids 25 to 31 are generic mappings.

25 - GI/ Lamp relay (A)
26 - Coin Meter
27 - 5" Bell /Ball Release (multiball games)
28 - Outhole
29 - Knocker
30 - Tilt Relay (T)
31 - Game over Relay (Q)
 
Last edited:
I’m away on holiday for two weeks with my family. Arrived yesterday, today i had a nice relaxing day by the pool dreaming of pinball switch matrix’s and how i can possibly code up a full game.

i started making notes on my various thoughts and ideas.

pinball operating system

  1. some switches can be on and stay on eg drop targets , even outhole. saucers etc
  2. other switches we need to track if achieved. eg a stand up target. or rollover
  3. we may want to carry over these hits from one ball to another, so hold them per player.
  4. so for each switch have a “switch made (this ball)” flag per player
  5. also hold a parameter to determine if multiple hits allowed - yes - it scores and performs the switch process every time, no it only does it the first time
  6. outhole would need multiple hits as it is possible to launch ball , hit nothing and back in outhole.
  7. at ball end, clear all these switches (but may want rules that allow some to hold over)
  8. After reading matrix and handling debounce then we can go onto processing any switches made, that haven’t already been made, or have already and allow multiple hits :
  9. perform the action of coil, sound, light, points , bonus points and the switch process and mark the switch as having been made for this player.
  10. Once all switches have been processed then go onto the rules processing
  11. rules look at groups of switches and do other things, like switch on “game-achievements” and “modes”. need to define what i mean by each of these.
  12. an “achievement” is something that gets switched on once you’ve closed a number of switches and or achieved other achievements. some may be incremental. eg knocking drop targets down each time advanced a score multiplier, and eventually a special, extra ball, free game etc.
  13. maybe some achievements can only happen in certain modes??
  14. maybe some achievements can only be achieved once or once per ball?
  15. implies we need a list of achievements that have been made per player
  16. some achievements will reset at end of ball, others will not
  17. a “mode” is switched on by an achievement or a switch. it runs for a number of seconds on a timer and enables different scoring, achievements. implies achievements are tied to a mode or a number of modes. maybe no modes running is a special mode called “normal mode”
  18. achievements will be the way to determine if a mode has been started and if it’s been completed.
  19. modes could be stacked, eg running at same time as others all with their own timers.
  20. modes cease on end of ball
  21. rules got achievements and modes should be held in a config file and be easy to modify
  22. Lamps. might want a feature lamp(s)to follow a pattern of flashing or colour changing when a certain game target is achieved. somehow this i guess should be tied into achievements and modes.
  23. a feature light might be set on when an achievement or a single switch is met. eg rollover switch lights the lane feature light up, but then something else may “flash” the whole pf lights when something else happens. but when that glass sequence is over, the feature light needs to be relit, so implies holding a status of all the lamps, ir maybe just reading achievements and relighting the lights??? needs some more thought.
  24. complex lighting sequences which may last a number of seconds need to be non exclusive, so the sw matrix read can still run, etc.
writing software is not new to me, but i’ve never written or worked on any type of game code, so i’m going to be reinventing the wheel and I also know that i’m not going to get this right first time. The benefit of being away for two weeks is that all i can do is dry run ideas in my mind and note down the ones i like best.
I know the ideas above will change and evolve, some will be good, others will be scrapped.

Ok time for another mythos or 4🍻🍻
 
AlanJ said:
I’m away on holiday for two weeks with my family. Arrived yesterday, today i had a nice relaxing day by the pool dreaming of pinball switch matrix’s and how i can possibly code up a full game.

i started making notes on my various thoughts and ideas.

pinball operating system

  1. some switches can be on and stay on eg drop targets , even outhole. saucers etc
  2. other switches we need to track if achieved. eg a stand up target. or rollover
  3. we may want to carry over these hits from one ball to another, so hold them per player.
  4. so for each switch have a “switch made (this ball)” flag per player
  5. also hold a parameter to determine if multiple hits allowed - yes - it scores and performs the switch process every time, no it only does it the first time
  6. outhole would need multiple hits as it is possible to launch ball , hit nothing and back in outhole.
  7. at ball end, clear all these switches (but may want rules that allow some to hold over)
  8. After reading matrix and handling debounce then we can go onto processing any switches made, that haven’t already been made, or have already and allow multiple hits :
  9. perform the action of coil, sound, light, points , bonus points and the switch process and mark the switch as having been made for this player.
  10. Once all switches have been processed then go onto the rules processing
  11. rules look at groups of switches and do other things, like switch on “game-achievements” and “modes”. need to define what i mean by each of these.
  12. an “achievement” is something that gets switched on once you’ve closed a number of switches and or achieved other achievements. some may be incremental. eg knocking drop targets down each time advanced a score multiplier, and eventually a special, extra ball, free game etc.
  13. maybe some achievements can only happen in certain modes??
  14. maybe some achievements can only be achieved once or once per ball?
  15. implies we need a list of achievements that have been made per player
  16. some achievements will reset at end of ball, others will not
  17. a “mode” is switched on by an achievement or a switch. it runs for a number of seconds on a timer and enables different scoring, achievements. implies achievements are tied to a mode or a number of modes. maybe no modes running is a special mode called “normal mode”
  18. achievements will be the way to determine if a mode has been started and if it’s been completed.
  19. modes could be stacked, eg running at same time as others all with their own timers.
  20. modes cease on end of ball
  21. rules got achievements and modes should be held in a config file and be easy to modify
  22. Lamps. might want a feature lamp(s)to follow a pattern of flashing or colour changing when a certain game target is achieved. somehow this i guess should be tied into achievements and modes.
  23. a feature light might be set on when an achievement or a single switch is met. eg rollover switch lights the lane feature light up, but then something else may “flash” the whole pf lights when something else happens. but when that glass sequence is over, the feature light needs to be relit, so implies holding a status of all the lamps, ir maybe just reading achievements and relighting the lights??? needs some more thought.
  24. complex lighting sequences which may last a number of seconds need to be non exclusive, so the sw matrix read can still run, etc.
writing software is not new to me, but i’ve never written or worked on any type of game code, so i’m going to be reinventing the wheel and I also know that i’m not going to get this right first time. The benefit of being away for two weeks is that all i can do is dry run ideas in my mind and note down the ones i like best.
I know the ideas above will change and evolve, some will be good, others will be scrapped.

Ok time for another mythos or 4🍻🍻
Click to expand...
Prefer Alfa myself, but either way, don't forget the gyros to go with it ;)

Don't think of it as writing software, think of it as writing (loose) requirements, then when you're developing, you can argue with yourself as to what's achievable & what's not. Gotta admit I'm seeing a lot of things that could be classes, but I'm not convinced an OO approach wouldn't add too much of an overhead (though where I'm working now, they have HUGE numbers of classes, yet it seems to absolutely fly).
 
Nice timing with the weather for getting away! Have a nice time over there.
The stuff in this thread is a little over my head, but is still great to see!
 
AlanJ said:
I’m away on holiday for two weeks with my family. Arrived yesterday, today i had a nice relaxing day by the pool dreaming of pinball switch matrix’s and how i can possibly code up a full game.
Click to expand...
Id be quite happy to help with any coding requirements. (Once I get my head around arduino a little. Ive sorta got it doing something.. still trying to figure out if theres a useable way to debug it.
Deffo think you want to make classes for a bunch of these (dead easy once you get your head around it)
 
yeah - sussed that much. Been spoiled over the years with breakpoints and the like. There is a visual studio extension that claims to let you use VS for arduino and claims to support breakpoints. had no luck thus far though
 
aha. that’s all way over my head. yes and i will take you up on the offer of help with classes etc.

I have also made a decision on which playfield to use in the operation thunder cabinet :both !

there is absolutely no reason why i can’t have one cab with two swappable playfields. it solved the problem nicely.
 
Managed to get something building and uploading in VS this evening.
Then I had a bit of a test writing a simple class - just to make sure everything did what I expect.
Which it did.
Will go back to looking at the other ard samples now I think.
 
Just been reading about shift registers to multiplex the ins/outs
Turns out its simpler than I expected not least because there's shiftIn and shiftOut - so you dont even have to write the bits manually :)
Not sure if you have considered this already, but my next thought was to consider how many ICs would be needed to drive enough lamps, switches, solenoids and display segments for a pin. This is assuming of course taking a simple approach of just driving each with its own pin (pun intended)

And I have to say - Damn that's a lot of ICs !

My first thought was to go for overkill (I'm a big Motorhead fan so why not :) )
Took a quick look at the Cosmic Gunfight switch, lamp and solenoid counts - I happened to have the manual pdf open anyway :)
Looked at the numbers and as I said - went OTT with how many would be needed
So assuming 128 switches, 64 solenoids, 128 lamps and 5 displays with 7 segs each (OK that really is ott for the displays)
That's a whopping 75 ics.
To break that down assuming 8bit shift reg ics:
  • 128 switches - 16 ics
  • 64 solenoids - 8 ics
  • 128 lamps - 16 ics
  • 240 segments - 30 ics (there are 7 segs per display so 1 ic per digit, 7 digits per display * 5 displays)

I guess that was a little ott.. So adopting a more sane approach I took the same values from VG, added 8 to each and rounded up. This gives:

  • 64 switches - 8 ics
  • 32 solenoids - 4 ics
  • 64 lamps - 8 ics
  • 240 segments - 30 ics (7*5 digits per display * 4 + 2 digits for match)
I guess that's more sane - but still a lot of ICs !
 
For the 8 ball champ i have :
2 shift registers for the switch matrix. 8 x 8 = 64 switches but the game actually only needs 5 x8 =40

2 shift registers for the solenoids =16

1 shift register for sound output

i’ve then added 2 more shift registers for future use. one input and one output. so a spare 8 on each

the score displays will be controlled directly from 3 output pins on the cpu, that’s all i need to display to all 5 of the score displays.

the leds will all be controlled using a single output pin off the cpu. that’s the beauty of using a string of addressable leds - all controlled off a single data feed. look at the fastled library.

my first project with shift registers , i didn’t use shiftin or out, i coded it manually, which is useful if you are only using less than 8 bits, as you’re cutting out unnecessary shifts, but it’s so fast that i now just use them by default.

there are useful bit functions too.

For me, the real power of arduino is that there are so many folk using it and supporting it that there is usually a library for everything, or easy to find a code snippet that someone else has already done.

I’m happy to share mine if i’ve done anything you need
 
I figured it would need some matrix type setup rather than directly addressing each switch/lamp/whatever.
wasn't sure if it was fast enough to do the lamps and displays. Solenoids I guess wont be a big deal - since you're never going to fire them all at once :)
 
I am hoping it’s going to be fast enough to do it all😂😂😂

First stage is to get some solenoids firing when switches are closed, then do the flippers in a similar way.
 
Am enjoying this thread and reading up around the topics as it progresses.

Re. the addressable LEDs, weren't you plugging into the existing pf wiring/connectors (Gott matrix, Bally individual), but doesn't this approach need extra wiring?

Keep up the good work, I'm thinking it would be fun to (reversibly) interface to an EM pf via the big jones plugs to play with it.
 
I am ripping out the existing lamp wiring on the bally playfield, but i will leave three wires for the replacement leds - 2 power one data.

Probably do the same with the gottlieb playfield, so it’s a destructive project in that respect.

If you wanted to do an EM non destructively, then a lamp driver circuit needs developing, the bally SS lamp driver board design is a simple enough one to base a new design on, ie a demultiplexer into an array of scrs. probably do it with modern components though as those 4-16 chips are expensive and hard to get.
 
I'm adrift with the software side of things, but re. an electro-mechanical game, I suppose a change to dc solenoid power (if necessary), and addition of tie-back diodes would be required.
 
You must log in or register to reply here.
Back
Top Bottom