Need to come up with a catchy card themed name that hasn't been taken by one of the hundreds of card themed EMs...

Been working on this for a while, finally realized I should make a thread. I'm gonna start posting from the beginning and try to catch up to the present...

I've had an idea in my head for a while for a poker themed pinball machine. There are lots of card themed games, but much less are actually specific to poker (or any other card game). Games like Royal Flush or World Poker Tour come closest, since they involve actual poker hands, but you're still not really playing *poker*. In most EMs with poker hands, your real goal is really just to get as many drops as possible. In WPT too, if you just keep hitting drops randomly or even ignoring them, you'll just accrue hands.

pasted_image (resized).pngpasted_image (resized).png
So I want to have a game with a ton of targets, and a display (either dot matrix like WPT, or an LCD like Full Throttle, etc) in the playfield to show your hand, including suits, etc. The targets you hit become your hand, your hand is compared to your opponent's hand, you can bet/raise/fold somehow, etc. Not sure exactly how the rules will work, but that's the goal.

With that in mind, I've been accruing random drop target assemblies (since drop targets are always better than standups!) for years at various flea markets. I've got about 18 assemblies to choose from now, ranging from 1 banks to 6 banks. Gottlieb, Bally, Stern, Williams. Some have individually controlled 'memory' drops. Other mechs and random pieces too, such as flipper parts, slingshots, pop bumpers, gates, etc.

I didn't really have an exact layout in mind, other than having an upper flipper or two, to give more ability to hit targets, and that I want to have some sort of 'savers' in the outlanes (like magnasave, etc) since outlanes suck.

None of this ever got anywhere until I saw a partially populated Mars: God of War playfield for sale:
pasted_image (resized).png

This had a few very important things on it:
1. more drop targets. can never have too many
2. a multi ball trough. No need to spend $100+ on one from PBL
3. four flipper mechs. The WPC mechs I'd use otherwise are $50 each, but these would just need a slight rebuild, and they're gottlieb mechs, which are my favorite type, and will fit well with the more 'retro' style design all the drop targets will be giving
4. The lift ramp. This is what really set me off to actually start designing. I immediately started picturing layouts involving the ramp, and how I could use it as a lock possibly, or use the up/down as a diverter to give more shot variety, etc.
5. Lots of other little playfield parts. Hopefully I can scavenge lots of rollover switches, wire guides, etc. Those add up fast when you're buying new too

I threw out my previous idle layouts in Future Pinball and started making a new one with the ramp in mind

Old design:
pasted_image (resized).png
Future Pinballis great for seeing how big things really are. When I sketch something on paper or in my mind, stuff enver actually ends up the right sizes, so using a virtual pinball designer is a great way to get a rough idea before you start really drawing stuff in CAD.
pasted_image (resized).png
The first attempt was very rough, but it gave me the basic idea of a ramp on one side, a spinner on the other. A 3 bank in the middle, and above it some pops and an 'upper'/mini playfield area with another flipper and some more targets.

With a basic idea in mind, wanted to figure out the shot angles better. I decided to copy the bottom areas (flippers, slings, inlane) from Alien Star, since I liked the feel. img_20190408_173343 (resized).jpg pasted_image (resized).pngThis also allowed me to test out shots by imagining where they are on the alien star playfield, and then trying to shoot them, to gauge difficulty etc. One thing I wanted was a center shot that could be hit from a ball coming down the inlane when you flipped as early as possible, since I find those really satisfying. So I tried some trial shots on Alien Star, noting the angle the ball went at off that 'early' shot, and made sure to put something there in my cad drawing.

I got a cool idea for an outlane saver: a mini flipper positioned behind the main flipper, and raised high enough that you could shoot the ball over it into play:pasted_image (resized).png
I 3d printed the feed ramp for this and stuck it on alien star to give it a try, but sadly the physics just didn't work out. The ball would roll part way up the ramp and run out of momentum. In order to make the ramp shallow enough, it would have to start about 3" above the inlane, which just couldn't work I'll have to come up with another idea for this outlane...

I modeled the lift ramp, which was pretty complex. I just blocked out the more complicated lift parts on the bottom, since I really just need it for spacing. pasted_image (resized).png
I realized that, due to the ramp's right side exit, I couldn't put it on the right side of the playfield as I had in my original drawing, so I had to reverse the playfield:
pasted_image (resized).png
I also got more of the upper playfield figured out
- three banks down below, with possible room for a fourth under the upper left flipper.
- two upper banks, each with some targets hittable from the lower flippers and some from the upper flipper
- a shot in the middle (the 'early' shot from before) that can feed the upper left flipper
- a lane to the right of the upper right drops to go from the upper playfield to the upper right area, where there will be some lanes
- one pop bumper (that's all that will fit, but all the best games have one pop bumper!)
- a shot under the upper left flipper from the upper right. not sure where the ball will go once it gets in there yet
- a shot back to the shooter lane from under the upper right flipper, similar to Star Trek, but with drops below it, so you can hit down the drops to make the shot wider pasted_image (resized).png

More refinements:
- placed lots of mini targets to prevent vulnerable metal edges
- replaced the area below the upper left flipper with a single target to make the shots to either side easier
- replaced the upper left bank with standups, since sadly it looks like there isn't clearance for two mechs that close together
- added the lanes in the upper right. there isn't enough room for a full set of three lanes, so I've opted for just some mini posts to drop the ball between. the right most 'lane' will drop down to feed the upper right flipper, and there's also a place below it for a magnet to feed the flipper too off orbit shots. I wish this was a widebody, so I had more room to put stuff in areas like this, but sadly widebody cabinets are hard to come by, all I have is a narrow body
pasted_image (resized).png

I modeled some of the drop target banks and added them, as well as a rough habitrail for the ramp
pasted_image (resized).png

Clearances are already getting quite tight with all the mechs there.
- I originally wanted the upper left flipper to be more to the left, but the ramp lifter mech is in the way
- the upper right flipper had to be moved up slightly, since the 5 bank below it was in the way
- I had to change my 3 bank mech for a different one that had the coil on the left instead of the right
pasted_image (resized).png

Bought some used magnets from a parted out Addams Family, which allowed to to add a magna save on the leftlane. I got an evil idea though, and decided to invert the inlane/outlane, bally style. This way, if you just hold the magnet, you can bring the ball to a stop, but it'll be above the outlane! I want to make the game more bouncy, encouraging the ball to fly around all over. Both the outlanes with have helpers of some kind like this, so it should be okay to be a bit more out of control.
The inverted inlanes also allows me to use the left side of the playfield as an inlane feed. I'll but a controllable one way gate above the upper lanes, so then a spinner shot can either feed the lanes, or come all the way around, down the left side, and feed the left flipper again for a repeatable shot.
pasted_image (resized).png
Similarly, on the left side, I'll put a diverter in the shooter lane, so balls can either go back to the plunger, or feed the left inlane. This will allow another repeatable shot by shooting under the ramp on the left, coming around the top, and down the right side. Hopefully this will give some good combo potential (especially combined with the lowered ramp to feed the left side, to give the game some shots and modern feel, despite most of the playfield being taken up by drop targets
pasted_image (resized).png

At this point I start to worry I'm getting ahead of myself. I don't even have a whitewood yet! There's no reason to be putting this much detail into a design that could change drastically if something doesn't work out. So it's time to do a whitewood. I won't install everything yet, but at least get some guides and flippers installed, see how it shoots.

I don't have access to a CNC machine, so I'll need to do this all by hand for now. I take my current drawing and send it to Staples to get printed at 1 scale. My thinking is, I'll attach the paper over the playfield, and use that as a guide to cut all the holes needed. Hopefully I can play test on paper without ripping it up too badly.pasted_image (resized).png
Tomorrow, the first steps of construction!

It was also used on spirit and raven, I think. Williams uses a different style with a latch and release mech, while gottlieb uses an always on flipper coil and eos to hold the ramp up, which can cause issues. When I got this playfield, the ramp coil was gone, and the entire mounting bracket was discolored from the heat. I've heard other issues about it on Mars too, since they keep the ramp up (energized) most of the time. I'm hoping I can pwm mine to reduce the strain.

I think I just exported a pdf from my cad software. Told staples 1 to 1 scale, and it came out perfect.

I think I've chatted with him too for this stage in the prototyping I'm not bothering with any inserts yet though. I don't know how to rules will go well enough to even know what lights will be needed...

Ooh, interesting. Used to play cribbage all the time with my parents before school

It is using a dual wound coil stock in Mars. But even a flipper coil apparently heats up when it's on for the entire game, minus a few seconds here and there

Yeah, that was part of my concern too. The ball would need to be going pretty fast to make the save still a challenge. Optimally I feel like an outlane save should save the ball maybe 2/3 or 1/2 of the time. Then make the outlane meaner so you drain out it twice as often

I don't think there's room for that to quite work. One other thing I'm considering is using the area on the left hand side, where there's no trough in the way. That way the flipper could be farther back, and have space for a small jump ramp over the flipper back into play. The problem there is that if the flipper is below the outhole, so I'd need to somehow get it back 'up' to the outhole if the flipper missed

Got some 'cabinet grade' plywood from Home Depot. Closest thing I can find to playfield style... I also picked up a cheap 2x2 sheet of rough plywood and some 8" feet for it, to experiment with cuts and mech mounting. Was able to find that a 3/8" hole is not big enough to fit a mini standup through, but 1/2" works.

Played around with another outlane saver idea: a player controlled vuk the ball rolls over to fling the ball over the flipper and back into play:
ezgif-4-28b5aa015eb7.gif

This should be able to barely fit in front of the trough on the right side, and can be activated by an extra flipper button...

I liked the idea on Pinbal 2000 of having full length support rails, so I made my own out of some angle iron. This should allow me to easily take the playfield out without worry of crushing mechs, and work on the top side easier. I also made some temporary legs for the top side, so I can set it upside down to work on the bottom.pasted_image (resized).png

Hopefully, I can make double use of these as a place to mount the wiring to. Put some zip ties through the holes, run the harness through them, with wires running down to individual mechs from there. Wire management can be such a pain

Attached the paper with thumb tacks. I wasn't able to get it as tight as I'd like, but I think it should be close enough.

I figure that once I actually get the holes drilled, etc, and every thing placed in a way that works, I'll have to strip the top of the playfield again, remove the paper (if it's survived), and then scan in the raw playfield again, and make a new CAD file based on the actual holes+positionings I ended up with

pasted_image (resized).png

My goal with the initial whitewood is to do as little as possible to get the maximum info. If anything isn't going to work, I want to find out fast, so I can stop doing work I'll have to undo, etc. So top priority is: does everything fit? If it fits, do the shots work? Worry about the rest later. At the same time though, mounting a mech means I can't do any more cutting in the area while it's installed, and I won't want to be uninstalling tons of mechs and posts throughout assembly. Simple holes can be drilled at any point, but slots and other shapes will need more complex work, so I decide to try to cut every slot needed first before doing any assembling. That means, one slot for each drop target, one rectangle for the outlane saver, two slots for the lift ramp arms, and one weird shape for the trough.

My technique for any large slots/shapes is to drill the ends/corners first, then use a jiqsaw to connect them. I use a forstner bit instead of a regular drill bit, since they produce nice clean edges. pasted_image (resized).png
I discover immediately that the paper doesn't like being cut with the jigsaw, and if I drill through the paper then bits of sawdust get stuck under it, making it uneven. So now any cut starts with marking the centers of holes with a punch, then cutting away the paper around the cut, and then making the cut itself
pasted_image (resized).pngpasted_image (resized).pngpasted_image (resized).png

For slots too narrow to fit a jigsaw blade in, such as the 1/8" rollover switches, I needed to use a router. I picked up a cheap one for $20 at harbor freight, which was probably a bad idea, and a 1/8" bit. I drill holes in both ends to give the router a good entry point, then clamp a length of wood on to act as a guide so I get a straight linepasted_image (resized).pngpasted_image (resized).pngpasted_image (resized).png

I need to cut 8 large slots and 5 small slots. I made it through all but two small slots without messing up, and then my router slipped a quarter inch on the left inlane Won't affect play, but the playfield is now forever marred.

I'm using a gottlieb 3 ball trough, which was used on all their games from Mars (their first multiball game) through their last game in the 90s. They're a nice design, with a separate ball release coil and a little wireform to prevent releasing two balls. Very simple to program for. But they also require mounting 5 parts (bottom rail, both side walls, outhole kicker, and release arm) all with very good accuracy. Instead of eyeballing it, I try to trace everything on the old playfield first. After removing the mechs, I tape a sheet of paper to the mars playfield, and sketch over everything with a pencil to find the holes, and use that to mark my new playfield. Worked out quite well, and the trough fits on the first trypasted_image (resized).pngpasted_image (resized).png

I started test mounting a few mechs to check clearances.

Upper left flipper and ramp lifter fit, juuust barely. I think there'll be about 2mm between the crank and the lift arm.
pasted_image (resized).png
Right bank and center bank also fit:pasted_image (resized).png
As to the upper 3 bank and the pop bumper:
pasted_image (resized).png

I also found that, if I use a williams 3 bank with only two targets, and then chop out a bit of the base plate, I can fit a two bank on the upper left, nestled in perfectly with the 3 bank:
pasted_image (resized).png
The other mechs I knew 'should' fit, according to the cad, as long as I didn't screw up the measurements, but this one was so close that there was no way to tell without just doing it, so I'm glad it worked out

Got the ramp fully mounted, and found my first major design issue. My model for the ramp was way off. In retrospect I should have printed it out 1 to 1 on a piece of regular printer paper to test first before getting it printed on the big sheet. Luckily it seems like the existing placement will still work, it's just that where I was planning on putting two targets on the upper left, I can now only fit one, since the ramp mounting hole overlaps that slot, and you can't really take the ramp off while the upper left flipper is installed. Will also need to adjust the habitrail design somehow to match the new placement.
pasted_image (resized).png
Installed the side rails and the spinner and inlane guides. pasted_image (resized).png
At this point I now had enough worked out to technically test some of the main shots and see how they felt, but for that I'd need to get it in the cabinet. I'm using an old whirlwind cabinet I bought from a restorer a few years ago. It came with the side rails, lockdown bar, etc, but no playfield mounting hardware. That's probably good anyway though, since I hate the hinge on system 11s. For now, to make playfield removal easy (since I'll be doing that a lot!) I'm just going to go oldschool and put some wood bars down to rest the playfield on. I got some really big C clamps from harbor freight and used them to attempt to level the bars. pasted_image (resized).pngThis was a bit of a pain since I need them to also match the playfield hanging from the lockdown bar at the front. I ended up installing some permanent back panel support legs, and using that to set the playfield in the cabinet upside down, then reaching in through the speaker hole to mark the height. pasted_image (resized).pngpasted_image (resized).png

Installed the transformer panel, taken from a mystery 80s gottlieb, and luckily it has clearance from the playfieldpasted_image (resized).png
Did some initial power wiring to get the transformer the 110v it needs to generate the 25v I needpasted_image (resized).png
The lightswitch kills the power going to the transformer so I can turn off the high voltage to safely work on the machine without shutting the whole thing off. One outlet will be to power the ATX computer power supply I'll be using for the logic voltages and is controlled via the power switch, the other is an always on service outlet.

It's definitely more wobbly than I'd like, but not so wobbly you can't drill on top of it. Would have liked thicker metal but they only had one size with holes. Maybe a metal warehouse would have more options? Definitely better than nothing though, especially if you don't have any Welding tools. I may remove them eventually and try to get them welded to solidify them, or switch to some thicker stuff without holes, and drill the holes myself, since I don't need as many as there are here.

Also, I'm currently attaching it with #12x1/2" wood screws, which isn't optimal. I would have preferred a 3/8" bolt through the playfield, but I didn't have any 'covered' areas on the top sides some of the places the rails needed to go. Probably something to keep in mind when designing the layout itself: make sure you have covered areas at the top and bottom.

Now for the fun part: my first board!pasted_image (resized).png

I've been hoping to avoid FAST/PROC for cost reasons, and rolling my own sounded like fun, so I designed these. 2"x4", 16 drivers controlled by their own dedicated processor. 12 'high power' drivers using a step up chip to convert the CPU's 3V signals to 5V, 4 low power drivers for things like relays, which can also be configured as fast react inputs by replacing the mosfet (an IRL540N) with a jumper wire and all controllable via SPI. I'm hoping these can act as psuedo node boards spaced around the playfield to reduce wiring.

From prior experience making a homebrew 5 years ago, I know that direct high current switches can be a pain to deal with due to the arcing and EMI causing board resets, so my goal for this project is to have everything transistor controlled, but for initial testing, I'm going to leave the EOS switches on the flippers wired in.

I installed some low current stagable flipper buttons in the cabinet, wired them up to 3V, and ran a connector up to the playfield through zip ties on the support rails. Mounted my driver board under the trough for now, and hooked it to the lower flipper, and had my first flip! Success!

Well, until I hooked up the second flipper. Then both flippers flipped at once! A bit of troubleshooting narrowed this down. As should have been obvious, don't run your low voltage signals in the same bundle as your high voltage coil wiring! Basically, when I flipped one flipper, the first 3V pulse would go to the board fine, and it would engage that flipper. All the electrons flowing up the harness would create a magnetic field and induce enough current in the flipper button wires to be read as 3V, triggering the other flipper as well. I knew that generally, you want to keep those harnesses separate, but didn't expect to see that so soon, and so reliably.

Luckily, the next day I was at some friends' wedding, with a pinball machine in tow, and I got talking to another guest who was an electrician, who confirmed my issue, and told me that "about 6 inches" should be fine separation for the signals I'm dealing with, as well as the advice to try to cross high and low current at right angles when possible, which doesn't sound too bad. Since all the switches and lights will be close to the playfield anyway, I'm now planning on having two layers of wiring: one high current harness run through the rails, and one lower current one near the playfield. In the mean time for testing, I just run a separate wire down directly, bypassing the harness.

With that 'working', it was time to actually test the shots! Instead of moving the playfield in and out of the cabinet all the time, I found a two foot block of wood whose thickness would result in a 6.5 degree incline if I stuck it under the back end of the support rails, allowing me to play with the playfield sitting on a table next to the cabinet. This revealed that, despite me trying to account for it, my connector from playfield to power supply was too short! I spliced another 2 feet in for now. Lesson learned: always make your connectors way longer than they need to be, and then make them longer.

So I made my first shot, at the spinner, and actually hit it which was surprising considering that I was standing two feet to the left at the cabinet. However, it also illustrated a new issue: the ball didn't even reach the back of the playfield. I took another shot, avoiding the spinner so it couldn't steal any momentum, and was able to reach the top, but the power just wasn't there. It felt like playing a gottlieb EM with AC flippers. I tried playing with the pulse length, etc but nothing helped. To rule out the board, I tried manually grounding the flippers, and they were super strong! So the driver board was causing issues somehow...

I tried taking the CPU out of the equation by controlling the step up chip directly, no different. Tried sending 5V directly to the mosfet, no difference. I looked up the schematics for other games, since most modern games seem to use IRL540s, but couldn't see any difference. I tried driving the mosfet with 12v instead of 5V, since it technically can go that high, and the flipper seemed a bit stronger, but still not close to how it was when grounding it directly. Very confusing. I'm not sure if there's something else with this circuit I'm missing that's causing issues, but I think I eliminated every part of it being an issue. Maybe it's something with driving these very high power flipper coils on 25V (resulting in very high current), vs how modern games all use 50V with weaker coils? I also discovered that Stern node boards have special driver chips designed for mosfets, although they run them at just 6v, so those might be worth a try, but no other manufacturers use anything like that so it doesn't seem likely. The issue only seems apparent with flippers too; my drop target bank resets fine, the outlane saver is nice and strong. Both of those use a weaker coils though.

I'd love to figure out the answer to this, but for now I decide to work around it for testing, so I swap over to high current flipper contacts. I don't mind this too much really, since it's more like how the gottlieb games originally worked, and I love the feel of 80s gottlieb flippers. No need to spend time trying to get CPU controlled flippers working really nicely or anything, just do it old school. I'll have to add some arc suppression to the cabinet and eos switches, but that's not a big hurdle. I'm also gratified to see that my driver board seems to work fine (no resets) even without the arc suppression, so maybe my increased electronics knowledge is helping too.

With the directly controlled flippers, the game is nice and powerful. Perhaps too powerful! On my third shot I break off one of the drop targets on the center 3 bank. The spinner shot works well though, the ball makes it all the way around and comes down the left side. Will need to work on some inlane guides. I wish I had a laser cutter....

All the lower flipper shots seem at least makable. I would have liked the center bank to bit a bit more to the right, to make a shot from the right flipper to the upper playfield area easier, but with the clearance issues with the right bank I can't do too much. I played it a bit safe on the initial whitewood, so I'll adjust it a bit closer next time, but at most I'll gain half an inch.

In order to test the upper playfield shots, I needed some ball guides. The shot I was most worried about was the one behind the upper right drops, since the angles looked a bit weird. pasted_image (resized).png
I got some 1" stainless strips, and bent one to follow the path on the playfield. I also got some #4 hex button cap screws, since they're very low profile. I can mount them near the top/bottom of the guides, and the ball won't hit them.

Made a test jig using a spare block of wood and one of my big C clamps for a quick test:
ezgif-4-a417c8ca028c.gif

Success! Now to mount it for real...
I've never found a good place to buy these premade, so I'm making my own L brackets to mount the guides. I got a strip of 1/2"x1/16" aluminum, and cut it into ~1.5" sections:pasted_image (resized).png
Bend it into an L using my vice:pasted_image (resized).png
then drill both ends, one for the #4 machine screw and one for a #6 wood screwpasted_image (resized).png
Then, mount it using the button head screw and a nylon lock nut on the backpasted_image (resized).pngpasted_image (resized).pngpasted_image (resized).pngpasted_image (resized).png

In the back you can also see my next 'custom' mech, a controlled gate: pasted_image (resized).png

As is going to be common, I don't know the dimensions of a lot of the mechs available online from marco/pbl, and I don't want to spend $50 to find out if it fits, so I'm making a lot of this myself... This one is made from a normal one way gate, with a piece of slightly flexible thin metal rod (I think piano wire from a PBR kit) that I bent so that it sticks through the housing and when I pull down on it, holds the gate open. Then I used a spare slingshot bracket, a random coil, and a custom plunger I made from some round stock, with a hole through the top to stick the piano wire on, and a threaded hole on the side to clamp down on the wire. ezgif-4-b60d1339190a.gifThe wire's hole is pretty deep, allowing me to adjust the 'pull' of the mech, and the set screw also acts as a holder for the return spring. Luckily since the piano wire is so flexible, the mech can be positioned pretty freely, as you can see here where the whole wire is going through the wood at an angle... I'll need to figure out exactly where this needs to go eventually, but for now it works.

Playfield isn't in flippable position right now, but I'll try to grab one next time it is. Realizing as I post this stuff that I should be taking way more photos/videos

From thinking about the idea of the jump from a flipper behind the main playfield, the idea turned into, as BorgDog was thinking, what if you shot the ball up between the flippers? ezgif-4-2d07ab3abb42.gif

It's a tough shot, but it is possible!

But, if you drain the ball from that flipper, how does it get to the outhole? Originally I wondered about doing this with a newer style below-playfield trough, so I could try to gravity feed it, but from my issues with the reverse outlane ramp, I was wary of any slopes going against the playfield slope.
ezgif-4-a7b6b2a37313.gif
I really hoped this worked when I drew it up in CAD, but wasn't sure how it would go. So many variables. I tried to leave some room to maneuver the kicker arm around to get different angles if needed, but my guess for an initial angle that I drew a line for turned out to work. I had to use a gottlieb kicker arm due to the clearances needed.

With that proof of concept looking promising, I decided to make a whole mini playfield out of itpasted_image (resized).png

There was not much room to work at all down there. I positioned the flipper mechas low as it could go, which resulted in this angled mech, with it pressing right up against the bottom and left side of the playfield. I couldn't put it any more to the right or else the angle for the eject would be too steep. That limited the place where the drop targets could fit. I needed to use a williams mech since they're the only style that has the coil mounted in front of the mech instead of to the side, since I had mechs to both side. And since those have a bit base plate in front of them, I couldn't put it any lower since the flipper mech was in the way, and I couldn't put it any higher and still have room for the ball to roll under the main flipper. I wanted to make sure I could disable the mini playfield area during multiball, etc to prevent anything getting stuck down there, so it needed to still have the standard outlane path. I put a down-post at the entrance to redirect balls away from the mini playfield. No room for a rubber band behind the drops either, so I figured I'd have a metal wall with some of that blue rubber sheet behind it for minimal thickness. No room for any standups to the left either since the drop mech was underneath. I also wanted to put the flipper at as low an angle as possible so that it could make the shot back between the flippers, but at the same time I wanted it to go up at least to 'level' so theoretically you could cradle the ball.

I needed to make a custom one way gate for the exit since it's so wide. I reused the little gottlieb spinner mounts from the mars playfield to mount it since there were no brackets that length either. While i was doing that I got the idea to just also put one of those behind the drop targets. Minimal width, and now I get to use the back side of the main flipper as a rebound rubber. If you knock down the drops, there's also the possibility of shooting through them and getting into the outlane area and draining that way too. Hopefully I can make this mini area super valuable, to make you willing to risk going for the targets instead of going for the saving shot immediately, or maybe if you complete the whole bank you get a ball save? We'll see how the risk reward works once you get in there...pasted_image (resized).png

It was a big pain yeah. At first I used the hole where the kicker arm went to pick it up, but once I put the arm in that didn't work anymore. But then I saw these on the mars playfieldpasted_image (resized).png
Problem solved:

pasted_image (resized).png

Started wiring all my drop target banks at my workbench. Each will have a connector for easy removal. Not going to bother with that on every mech, since most are pretty simple and either serviceable from the playfield or unlikely to need service, but drop targets and pop bumpers are another story.pasted_image (resized).png pasted_image (resized).pngpasted_image (resized).pngpasted_image (resized).png

Realized I'd made a big mistake during initial planning... Most of my banks are williams or gottlieb, which is fine, but the 5 bank on the right is a bally, which I chose because they have thicker targets, which will make shooting past them into the shooter lane smoother, and they had 'memory', so I could knock them down with code if needed to make the shooter lane shot easier. Problem is, Bally used 50V coils, while gottlieb and williams used 25V, and I'm using a Gottlieb transformer. A quick test revealed that, of course, the giant 50V reset coil on this bank doesn't even move when you apply 25V to it. I dug through my spare mechs box, but the only other 5 bank I had wouldn't fit due to space issues with the flipper mech immediately above it.

So I needed to get creative. How do I get 50V when my transformer only puts out 25V? With a voltage doubler! Here was my simple test setup to see if this would even work: pasted_image (resized).png

Basically, creative insertion of two big capacitors in the middle of a half bridge rectifier allows each to be charged by half the AC circuit to 25V. But they're wired in series, so that combines to 50V (technically, I guess it's -25V and 25V compared to the rest of the voltages in the system). Those TO-220 transistor looking things are actually just really big diodes, I think 10A each? I overspecced this thing for sure, since I couldn't find exact details on what tolerances were needed. And it worked! Bank resets just fine. You can't energize anything continuously with it since the caps will empty pretty quick, but it also recharges within a second, which is good enough for resetting one drop target bank. I got a new PCB made for this, with even more fuses (again, wasn't sure where to fuse, so I just fused everything), and a bleeder resistor so the 50V (actually, it reads as 80V for whatever reason) doesn't sit around after the machine is powered off pasted_image (resized).png

The issue with this of course is that, since it's operating off its own rectifier with a weird half-ground system, I can't control it via the MOSFETs on my driver boards, since they don't share a common ground. For the reset, this isn't a big deal; I can just add a relay in to control it. But I also have the 5 knock down coils. I don't want to have to wire up 6 relays for this bank. Luckily, since the knock down coils are so small, I find that they can be moved via 25V. But not enough to actually knock the target down. So I added a 4700uF cap onto my 25VDC rectifier, similar to what gottlieb did on games like Black Hole to give the kickers more juice. That gives enough strength for the knock down coils to operate 90% of the time, and I can just code them to try again if they don't detect the switch closing to handle the other 10%.

ezgif-4-a687dfe62fdf.gif

None fit that I could find. It's a weird large coil that only bally and stern seem to use. My other alternative was that perhaps PBR could custom wind me a coil, but I'm not sure if a single 25V coil could even reset that mech. Williams always used two separate reset coils on their 5 bank, for instance, and their drop bank design moves way free-er than bally's does.

In order to get the sequenced firing working to test the 5 bank, I had to get some more control going on. Previously when testing the flippers I was just editing the driver board firmware manually to configure coils. I made a custom MPU board with hookup for up to 8 external driver boards for solenoids, lights, displays, etc. It's powered via a raspberry pi for simplicity, and also has support for an 8x16 switch matrix. Here's my first test setup, with the two boards just screwed to a spare piece of foam core. pasted_image (resized).png

The driver board can have each solenoid configured with a default pulse time, a maximum on time, and PWM duty cycle. The switch matrix and board I/O are handled via a small Java app for now, which can be connected to via a socket to send commands. The game code will eventually send those commands, but for now it makes for easy testing to just connect directly to the socket via PuTTY and type them in. To fire the 5 bank, I just made a quick bash script to send six commands in a loop with some pauses in between.

Bottom of the playfield already getting pretty crowded...pasted_image (resized).png

Before I got much farther, I realized I'd forgotten to cut the magnet holes in the bottom. Those will need to be done with the router, which needs some space, so I'll need to remove all the mechs in the area and the support rails.

I very scientifically traced the magnet out, and routed out a depression: pasted_image (resized).pngpasted_image (resized).pngpasted_image (resized).png

I wanted to hook it up to test, but that meant installing the relay somewhere. When I was looking around for the best place to put it, I realized that this was a bit dangerous, as I didn't know where any of the lights, switches, or wiring was going to go. I tried to mark out roughly where I was picturing things, and that actually left me with no safe spaces to put the relay! I'm sure once it's all done there'll be room, especially in the middle of the upper playfield area, but I have no idea what sort of lights are going to be up there now, so I want to avoid mounting anything there. Then, I realized the one area I knew was safe...pasted_image (resized).png

Some more small build updates...

Made these little clips for the ball arch. They go on top of the side rails and clamp one long piece of stainless down to the playfield. Eventually I'll probably drill some holes through it to mount it, similar to how williams games do it, but for now this will allow some easy adjustment while I play with the curvespasted_image (resized).pngpasted_image (resized).png

In the spirit of getting as much mounted as possible to figure out placement under the playfield, I started mounting all the rollover stars. Had to special order a 1-3/16 forstner bit (dang, these are expensive!) to cut these. Manually drilled down the proper distance to get them flush, was a big pain. pasted_image (resized).png

My biggest innovation yet, a target in front of the spinner wire instead of a mini post. Should be back handable from the right flipper pasted_image (resized).png

Threw together a 60 degree kicker for the upper eject hole as it was the only shape mech that would fit with the drop targets so close. Didn't want to pay for a full mech so I used a random plunger from a vuk or kickback, not sure. The plunger was too long, so I just put some 1/2" standoffs under the mech
pasted_image (resized).png

Needed a down-post for the mini playfield diverter, so I 3D printed one. It just presses up against the bottom of the playfield to stop it at max height, and uses a plunger from a williams drop reset mech that has a built in thread on the end. I had problems with the rubber I put on it sticking in the hole of the playfield, and being too bouncy when up, so I switched later to just a straight plastic post on top. ezgif-4-8f22118a1b66.gif

pasted_image (resized).png

Printed some inlane guides, and made a one way gate for the left inverted inlane. pasted_image (resized).pngpasted_image (resized).png

Had a lot of trouble getting the inverted inlane to work properly. I made it with slots so it could be adjusted up and down, but if I put it lower, than a ball that just dribbled into the lane above the separator wireform wouldn't manage to make it over the gap, and if I put it higher to save those balls, then a fast ball coming down from the top of the playfield would hit the back of the slingshot and drain. There was also a weird issue that I could never reproduce by hand where a ball dropped from a middling height would somehow rattle to a stop and then fall down the outlane.

I designed this little gate to make it work at any speed. It works surprisingly well, although I'm sure it's going to break sooner or later since it's quite flimsy. I'll have to come up with a more solid way to accomplish it..
ezgif-4-f1bfa56ae95e.gif

Not sure how I'd even get another mech in there at this point... I think with a magnasave above the lane, and the ability to be diverted below to the mini playfield, there should be plenty of opportunity to save a ball on this side.

Actually, it's almost too easy right now. The ball tends to go to the left most of the time it's over in that area for some reason. I may need to look into widening the outlane or something. Maybe add a metal wall on the left of the slingshot to prevent the bouncy rubber from helping you

Next step was adding the diverter to the shooter lane. I have a bally gate mech, but it's designed for low speed inlanes, not very flowy. So I 3d printed a much smoother gate:
pasted_image (resized).png

This mostly works, but I had issues where very fast balls would somehow get too much horizontal force out of it and hit the top post of the slingshot instead of directing down into the inlane. So I had to take 3 iterations of straightening it and adjusting the curve to get it to a point where even the fastest ball I can manage still goes towards the inlane, while a slow ball that just drops from the end still has a good chance of getting to the inlane.
Original:pasted_image (resized).png
Final:pasted_image (resized).png
It's a fine line because it needs to be able to fit behind the right drop targets and not block the shooter lane, so it can't be too wide or too straight.
ezgif-4-2d64440d33e7.gif

I also added a little guide on the slingshot to smooth the transition, since the ball tended to bounce back and forth before coming down to the flipperpasted_image (resized).png

With the diverter and the left inlane done, I now have two more shots I can test.

First, the spinner/orbit:
ezgif-4-58df6689f562.gif
This works, although it's a bit clunkier than I'd like. The spinner eats up some of the energy from the ball. I'll have to do some more tests with the spinner removed to see if there's any geometry improvements I can do. My upper arch isn't optimally designed, since it has a large flat part, which gives the ball time to 'drop' at the top and not follow the other side curve smoothly. Plus, with the lanes on both sides of the playfield, the shots hit the side walls at a more oblique angle which is probably leading to a less smooth shot. Might need to get the camera in slo-mo to see for sure

Second, the under-ramp/orbit:ezgif-4-7fd4b73e516a.gif
I was worried about this shot since the left side curve of the upper arch is tighter than the right due to the ramp and upper eject area being in the way, so the ball had a the potential to hit the wall and bounce off at a ~25 degree angle, missing the curve completely, but luckily this doesn't seem to be the case somehow. In fact, it's smooth. SUPER smooth. And ridiculously fast. I took 20 shots at it, and didn't manage to loop it even once due to the sheer speed of the ball coming down the inlane. But I'm also not very good at that type of repeating shot. Can't wait to get this flipping enough to see some better players take a crack at it.

Yeah, it's a bit of a weird shot. I've got that metal guide in front of it on the right, which it looks like I glanced off of with this shot, causing the ball to be going more vertically. Then there's a metal guide above it on the left, to try to direct it more towards the right. Maybe if I'd hit the spinner directly instead of hitting the guide first, it would have helped? or if I angle the upper guide more, to catch those vertical balls? Luckily it's not the biggest issue, since even a 'bad' shot still makes it around. If a good shot gives you more spins and a smoother feed, maybe that's ok as is.... Will definitely bear more playing with

Mounted the final mech today, the outlane saver. I'm having some trouble with its reliability currently. It keeps going up too high and getting stuck above the playfield. I added a bolt across the bottom to stop it from going too far, but then the bolt got stuck instead. So I added a spring to prevent the bolt from hitting the bottom of the coil so hard, but the spring reduced the travel enough to make the mechanism weak. I'll need to play some with adjusting the lengths of the parts in an attempt to lengthen the travel, or maybe make a custom bracket to allow everything to be longer (currently I'm just using a regular up-post/vuk bracket).

Here's a video of what the saver does when it doesn't get stuck or bottom out:ezgif-4-e81e13f2d3f2.gif

It's super strong and just sends the ball flying back onto the playfield if you time it right. I like having an outlane saver that doesn't save you completely, it just keeps the ball in play. The magna save does the same thing to a lesser extent, and the mini playfield shot between the flippers also manages pretty well, since your shot tends to go right into the right slingshot and out of control. This can be good or bad, depending on your playfield situation, since chances are once it gets bouncing around it's going to knock down a few drop targets, which will help you complete your hand, but they might not be the cards you want to make a good hand.

If you fire the popper too late though, you'll end up with a ball that, due to its left/down motion, leaves the metal guide sideways, and just flies off to the left. I've had it end up in the left inlane, the left outlane, all the way down in the mini playfield, and even somehow jumping backwards into the trough. I'll have to put up some air ball protection to make sure it always returns to the playfield somehow.

To control the magna save and the outlane saver, I needed my secondary flipper buttons. I took measurements of my Black Knight, WCS, and JM to find out what the spacing should be, and was surprised to find that they were all different! JM's secondary buttons are further back than BK's, while WCS is not only further back, but also isn't 'parallel' to the rail (it looks to be parallel to the bottom of the cabinet instead, which makes it way harder to hit 'in the moment'). Both JM and BK feel okay to me, so I copied BK's spacing.

Luckily, the depression for a williams flipper button seems to be the same diameter as a star rollover, so I was able to use my forstner bit here too. pasted_image (resized).pngpasted_image (resized).pngpasted_image (resized).png

After I installed these, I realized that, in order to use them, I sorta need a switch matrix! That will be my next step

I populated the switch matrix components on the MPU board, and they seemed to test okay with any single switch. Still a bit worried about if the way I'm driving the switch matrix will work once I've got lots of switches down, but so far so good. Luckily, the actual wiring of a switch matrix doesn't really change regardless of how you connect to it, so even if my board ends up being bad, that won't mean rewiring the playfield. With that in mind, I started trying to plan out the matrix, which was surprisingly involved. Technically any switch could go in any position, so all that really mattered was what made wiring easier. I'd already wired up all the target banks as individual rows, so that constrained me somewhat, but beyond that I just tried to lay out all the other rows based on what groups of switches were closest together:
pasted_image (resized).png

Doesn't look too bad so far!
Then I tried to connect up the columns...pasted_image (resized).png
That looks a bit worse. Then I realized I was going about this a bit wrong. No matter what, I was basically going to end up with two big bundles of wire going up each side of the playfield, and then joining at the back. So I need to re-order the rows in a way that will minimize how many rows/columns need to be run to the back, since that's where the most wire will be used. I also don't need the rows/columns to all connect together, since they'll join at the connector anyway, so I can simplify that a bit.
That left me with a new, more concrete wiring plan for the rows:pasted_image (resized).png
The columns, again, look a lot messier...pasted_image (resized).png

I feel like there must be a way to simplify this more, but I can't see any obvious major changes, and it doesn't look too bad overall. I'd love to see inside the mind of someone who designs the wiring harnesses for these games professionally.

I have nine colors of 22awg wire to work with, and the playfield itself uses 62 switches, which requires an 8x8 matrix. To keep things clean, I'd like to stripe the wires, so I can tell the rows and columns apart when working. Sadly I couldn't find any cheap sources of stranded wire online, so I came up with this:
pasted_image (resized).png
Tried it first with a regular sharpie, but the ink would rub off quickly, so I got some oil based ones, which seem to stay on the wire well once they dry. Stick a marker in the top, pull your wire through the side, and you'll get a messy but usable stripe.

With that figured out, I started trying to assemble a minimal corner of the switch matrix for more testing, which ended up being the first three columns on one side of thee playfield, and two rows:pasted_image (resized).png

Switch matrix still checked out fine, so I'm going to go ahead and wire the rest of the switch matrix

I bought all the colors at my local staples: black, white, gold, red, and purple. Weird arrangement, but ok. I used black stripes for the rows, since it was a color I was sure could show up on every wire color I was using. For the columns, since there was so much wire, I just left them blank (the sixth stripe color, invisible). Depending on how I handle lights when I get to that point, maybe they'll use some of the other colors.

I've also been using it to mark some of the coil wires. I managed to get 10 feet x 10 colors of striped 18awg fire off ebay that I used first where possible, but 10 colors is much less than my current 27 coils, and it turns out that 10 feet isn't long enough to reach from the bottom of the playfield all the way to the boards, so I had to reserve the striped wire for only coils on the back third of the playfield. My coil drivers are arranged into 4x 8 pin connectors, so I made one of those with no stripe, one with gold stripe, etc and tried to always use the same color ordering for pins. My rows go red-orange-yellow...purple-pink-brown, and so do my coil connectors, minus the random pre-striped wire thrown in. I've got a giant spreadsheet of all my connector wiring, and also use upper case vs lower case to denote 18 vs 22awg wire, which will allow me to reuse my limited stripe options more.
Coils: pasted_image (resized).png
Switches:
pasted_image (resized).png

Wiring is progressing, not a lot to show...

I'm ending up running two main bundles of wire, one along each outside edge of the playfield, for simplicity. It gets a bit hairy in a few places where mechs are near the edge of the playfield; I need to make sure the wires don't get caught on the cabinet's supports. I guess this is another reason to use a wpc or stern style mounting system... Maybe if I get to a point where I can say the construction is 'done' and I don't need to take the playfield out completely anymore, I'll try to convert. Assuming it fits my playfield...

Trying to keep the switch wiring high enough to clear the mechs, and any future lights that get installed, while also keeping it as far from the coil wiring on the support rails. These stern wiring supports are great, and cheap at PBL, but sadly I only have two on hand. Wasn't planning on getting this far when I did my last parts orders, or if these would be useful, and now we're in quarantine so I'm trying to avoid unneeded orders.pasted_image (resized).png

To work around that, I found some random strips of metal I had on hand, and bent them. Seems to work just as well, and probably cheaper too, but I'd probably still use the plastic if I had a choice, just to avoid having random metal things to possibly short stuff against.pasted_image (resized).png
This all looks a bit messy right now, but hopefully once I have all the wires in, and zip tied together into a harness, a lot of the slack will disappear and it'll look cleaner. I also have a lot of coil wiring (like that white loop) where I've had to repeatedly rewire stuff as coils get added or changed, resulting in extra too-long lengths and wire nuts that can be cleaned up eventually. The wiring is going pretty well, and is pretty easy as long as I can reach stuff. The biggest pain is doing the connectors for all the drop target mechs. part of me almost wishes I hadn't bothered with them, but I know I'd regret it down the line. They require a lot of extra planning since you need to have both wires ready ahead of time before crimping, and you need to make sure never to have three wires join at a connector, even though that'd be fine at a regular switch.

I'm also realizing another issue: since I salvaged most of my switches from a Gottlieb playfield, they don't have the third lug for the diode. Right now I'm just sticking a diode on one lug, with the other end hanging free, which hopefully doesn't come back to bite me down the road...pasted_image (resized).png

One other hurdle to figure out soon is how to actually hook all these wires to the MPU. Right now I'm just terminating everything in the upper left corner of the playfield, which is vaguely where I picture the switch wiring leaving the playfield, since all the coil wiring is on the right side. I'm hoping I can use a big ribbon cable to connect the playfield to the MPU, to avoid having to assemble more connectors and run a lot of extra wire, since my wire supplies are already running low.

My ribbon cable connector idea has solidified into a small custom PCB. I would have liked to have this custom fabricated, but the turnaround time is long, and the board is simple. If I'd known exactly what I needed sooner, I would have ordered it with some other boards a few months ago, but oh well.

pasted_image (resized).png
My MPU board has a slot for a 26 pin ribbon cable. 16 columns + 8 rows = 24, but 26 was cheaper. I just ran every wire from the playfield to this board, and soldered them to the pins:pasted_image (resized).png

Wouldn't have been too bad, except that, since I want to avoid having any left over wire hanging around, I need to be soldering it while it's within an inch or two of the playfield, sideways A lot of careful soldering, but luckily no issuespasted_image (resized).png

On a custom board I would have made all the wires come in one side, but with no room to route traces here, it still gets a bit messy. 3D printed some simple brackets and mounted it to the very back of the playfield, and it was good to go

In the midst of wiring, I've been taking some breaks to start on the code. Against my better judgement, I'm going to attempt to write all the game code in Typescript (a type safe superset of javascript), and run it via Node off the Raspberry Pi. I'm a bit worried about performance, but I figure I can always optimize it, shirk off some duties (such as video or sound) to a C backend, or upgrade to a Pi 4 or a x86 based board with a Pi compatible GPIO header at worst. Why Typescript? Because I've been using it at work for so long that trying to use most other languages is unbearable. Typescript is just so nice and developer friendly...

Hopefully this all makes vague sense to people who haven't coded a pinball machine before:

I also am going to try to take a different route from how (to my knowledge) all other pinball games are coded. I've worked with/explored a lot of systems (early williams/bally/gottlieb, wpc, MPF, skeleton game, etc) and they're all very much focused around a central concept: events come in (from switches, timers, etc), and then the code listens to those events, and sets some state (light on/off), fires some coils, etc. It seems to often lead to bugs where lamps get stuck on, balls get stuck in holes, etc, because there's state where there shouldn't be, or there isn't state where there should be.

For instance, on Demolition Man, when you collect the third claw award, it lights the 'car chase' inserts on both ramps. When you finish the mode, it turns them off again. But there's a bug where sometimes, if you drain while in car chase, on your next game, those lights will still be lit! Clearly, it's storing the 'state' of the lamp globally, and then forgetting to turn the state back to 'off' in some edge case. In my mind, that implies something wrong with the methodology they're structuring their code around. The lamp's state should be directly tied to being in car chase mode, it shouldn't be possible to 'forget' to turn if off. I'm sure there were tons more bugs like this that were found and fixed during development we never saw, if this one was able to get through multiple software revisions. I've even seen similar bugs on modern games, like Alice Cooper. On an older game like DM where they were writing in assembly and bytecode, and modes were a new concept, it's understandable that their handling of all this wasn't the cleanest, but with modern games where there can be tons of stacking going on, I want to come up with a cleaner solution for the lights.

Another example of the reverse case is something I've run into on my Taxi. In certain edge cases, the ball will go into one of the eject holes, and then won't kick back out. The game knows the ball is in there, since it registers in switch test, and it doesn't trigger ball search. Somewhere in the complex code surrounding the kickouts, there must be an edge case where it forgets to fire the eject coil. But again, that shouldn't be possible! We have a piece of set continuous 'state' here, which is that the ball is in the hole (the switch is closed), but its tied to a momentary input and output (the switch closing, and the solenoid firing). Since one of those momentary events was missed, the continuous state is now stuck.

In my mind, whenever possible, you want to match up these types of events/states. If a the eject switch is closed, the ball needs to be ejected. That's a 1 to 1 issue. The fact that sometimes, this might result in multiple momentary firings of the eject coil should be abstracted away. Similarly, imagine you had a shot where there's a down post and an opto. The game knows the ball is behind the post, since the opto is blocked, therefore it needs to release it. The same exact situation from a logical perspective: ball in hole/etc, ball needs to be released. But this time it's a down post, which isn't a momentary coil. You just need to energize the post until the ball leaves, no need to repeatedly fire the eject coil like in the first case. So I want to have a system where, in both cases, the game/mode's code is exactly the same. All it would say is something like "coil on if switch closed". Then a separate layer, which actually interacts with the hardware, can take care of things like, is this coil momentary? If so, fire it, then wait a bit. If the game is still requesting the coil to be on, fire it again. Increase the strength if necessary, or maybe trigger an operator alert if too many attempts have failed, etc.

With this in mind, my code works like this:
I have three layers: the game code, the machine driver code, and the actual hardware code. The game code is going to support stacking modes, sub-'modes', etc with their own priorities to override each other, etc. The machine driver code handles turning the 'wants' of the game code into commands for the hardware. In the simple cases this is just stuff like sending the 'turn on coil', 'turn off coil' commands to the hardware, but in cases of more complicated devices, it'll also manage that. For instance, my ramp has a switch to tell when it's up, and I put a switch underneath, to tell if a ball has gotten stuck under the ramp by rolling in from behind while it was down. The 'driver' will handle raising the ramp temporarily if it detects a stuck ball, or giving the lift coil another pulse if it detects the ramp has fallen down when it's supposed to be up. The hardware code will be very simple. It'll just handle reading the switch matrix, toggling IOs, etc, based on what the driver tells it to do.

The driver layer is going to have a list of every 'output' (coils, lamps, etc) the game has. Each mode will be able to specify its own values for any lamp or coil it wants to control. I'm then going to have a system that watches all the modes for when one of those values changes. It'll figure out which modes have priority, etc, and propagate the final value down to the driver. This way, I can have one mode say 'eject the ball from this scoop', but then, if needed, a sub mode that's playing an animation could say 'don't eject the ball right now', and block the coil from activating. When that sub-mode ends, the system will take care of automatically reverting all the outputs' values to remove any effects the sub-mode was having. In the case of lights, I'll also add support for combining values instead of overriding, so for instance I could have one mode say an arrow is green, and another say the arrow is white, but since they're stacked together at the same priority, the driver will take care of flashing the arrow green-white-green-white for them.

Hopefully this is all a good idea....