Hey everyone, I'm the podcast host that has discussed every single Bally bingo ever produced (and some not!).

As announced in episode 365 of For Amusement Only, I am now in the process of writing a multi-bingo emulator to recreate every Bally and United bingo (with some surprises in store)!

Basic tenets:

1) Multiple footrail/button/dial controls
2) Real bingo cab, with real Bally hardware for ball lifter/trough/shutter, etc.
3) Custom made head (or repurposed bingo head) with LCD monitor sideways, rendering at 1280x720.
4) Swappable playfields
A) 25 hole with magic pockets
B) 25 hole with hold feature
C) 20 hole with ball return feature
... Perhaps others.
5) Jones Plugs for primary connectivity - preferably unmodified from exisiting bingo connectors on the male side, female side will have diodes, etc for switch matrix switches.
6) P3-ROC with driver board (to drive motors and coils), SW-16x3-4 and an Intel NUC to drive it all.
7) pyprocgame to drive the P3-ROC and pygame to drive graphics/sound.
8 ) Open Source for the actual code. Graphics to be released for all only if approved. My illumination layers can be released.
9) All circuits properly emulated. This includes the search and reflex circuits, as well as mixers for portioning, etc. As such, this will largely be educational for me.

I started with pyprocgameHD as I've never written anything using pygame directly, but found it a bit too limiting based on what I was trying to accomplish. I've stepped back and worked directly with pyprocgame.

If anyone has any questions, feel free to post! I'm making this thread to separate 'programming' talk from the podcast thread.

Note that I'm not really a programmer, but I've been programming since I was very young. I have the majority of the first game complete.

I'm excited to see this project move forward!

Thanks DefaultGen! I'm looking forward to finishing game one. Been working on it off and on for the last six or so weeks. I'm taking it quite a bit slower than my podcast.

I'm more of a hardware guy (though I write some Python for my day job), and this tickles just about every soft spot I've got.

The only thing that would make this better would be to actually control the whole thing with EM hardware, but that is a project for another day.

I've got some screenshots that I posted in the podcast thread. I'll do a cross post here at some point.

It's funny, I've been so deep into this for so long now, I forgot to post what I'm working on!

Initially, I started working on Night Club. Night Club is my favorite machine. I played it for the first time three or four years ago at the York show in PA, and immediately fell in love. It was the first Magic Squares game I had played, and the score quadrupling feature allows for some really amazing wins.

But... that was a bit too ambitious for me to start with. I know how to work on the portioning circuits, but the actual portioning has (intentionally) remained a mystery to me until this project. Night Club has four mixers and the reflex to contend with, and, while I could start with this machine, I decided that for this (and the fact that graphics do not come quickly or easily to me - particularly the backglass animation I would need to make for the squares), I would take a step back.

The first machine I am implementing is Coney Island. Coney Island was the second Bally bingo produced, in 1952. It was the first Bally bingo with the Extra Ball feature, and brings back the mixer unit from the one ball horse racing games of the 40s.

Once Coney Island is finished, I'll be stepping back in time and working on Bright Lights (1951), then moving forward one game at a time. This should give me the ability to learn each portioning circuit, and produce the artwork necessary for the animations with the first squares/screen/line/etc game. I'll be building off the same basic blocks (as Bally did) for each subsequent game.

I'll be posting about various neat items I learn as I go through the games - especially for games that didn't make it to full production, like Broadway '51...

Yep! Similar to Heighways' system or Pinball 2000 in concept, except mine will use standard Jones plugs (at this, more conceptual phase).

This is actually precisely why I am using a playfield swap system. What stinks about virtual pinball today? The fact that it cannot replicate the physics, sights, sounds and control of real pinball. My project aims to use real lower cabinet components and merely replace the head. This way I don't have to have recorded sounds of the ball lifter or shutter. The sound will be made because the real physical part is moving. I do have plans after the programming and artwork are all complete, but those will have to wait till (much) later.

I've put in my theory in another thread about how to use bingos for redemption. (You tie the ticket dispenser to replay reset and force the timer to spit out any credits when it maxes out by opening the anti-cheat). Chuck E. Cheese is not returning my phone calls yet.

Seriously, though, I have a deep love and affection for these games. I would own every one if I had the space. I love fixing them, finding them, playing them, the artwork, the history, the ingenious touches that the designers imparted. They're amazing.

I will! I'm very lucky to know several Coney Island owners. The main thing I would like is difficult. Mapping and documenting the reflex and mixers. This is very time consuming and is not something I would ask anyone to do for me. Luckily, Phil Hooper has documented many of the mixer and reflex units on his site bingo.cdyn.com. Using a similar era's documented units and the schematic, I've recreated Coney Island's circuitry. They only get tougher from here!

I'm going, I'm going.

Ha-ha! Yes, absolutely! No pressure there, Vic! If I don't have a selection of early games playable at this year's show, I'll definitely have some (more) next year! My hope is that I'll have the cabinet and a basic 25 hole playfield wired up and ready for York with at least two games. No guarantees!

I'm very excited to share this with bingo lovers new and old. You'll have to beat every single one, you know.

So I'm coming back from a trip right now, but yesterday during travel I was able to clean up the majority of my functions, fix some naming convention (had a method called search and a unit called search - that ain't gonna work), etc. Once I get home I'll be able to test changes to game state, etc, and then start linking in my (already complete) graphics.

Been working on the conversion from pyprocgameHD to pyprocgame and have realized that I need to do things in the framework's way rather than my own... which means that I have to rewrite the whole thing... again.

I committed the cardinal sin of programmers - I didn't read the full API/documentation for the vanilla pyprocgame before doing my implementation. This means I did something dumb, so I have been working to convert everything over to the 'pyprocgame'-ish way.

Summary of something dumb I did: I wrote the entire game's logic for pyprocgameHD in a single mode. This is not really the way it should be written. I cannot stop and poll for a switch the way I intended (while loop within certain methods) as it kills all switch polling... this may be different with the actual hardware plugged in, but for testing, I am using a keyboard to simulate switch presses. So now I am splitting the whole thing into separate modes, which will be very clean for troubleshooting - find the file named for the mode, and it'll be in there. As things progress, I can copy and modify simple modes like 'tilt' or 'selector' or 'search'. This is exactly what I planned to do before, but again, it does it in a way that the P3-ROC hardware can understand. One thing that makes this difficult (again, I realize now), is that I am testing with a keyboard, but the real hardware may react completely differently.

Now, the good news: while I was playing with my kids earlier today, I realized I already knew a way to display score/instruction cards on a dynamically changing screen. If I use a Raspberry Pi or other incredibly low-powered computer with a screen plugged in, I can poke it over Ethernet in the background either once you make your selection in the menu or once you switch games on the menu. This is one of the little surprises I talked about above, but figured something is better than nothing.

Because I will not have complete control over the Pi via Ethernet, I'll have to script this separately and run it in a different thread. No big deal, it'll actually be a lot simpler than I was worried about - I won't have to worry about the main computer having to draw the score/instruction cards, so that's pretty neat!

For Red Letter games, there are no long/thin screens that I could put in the bottom center, so I'll likely have to take up part of the main screen to show it. On the plus side for that, you'll be able to see it much more easily! I can add it to my backglass images and such, so that's also pretty simple. Not perfect, but I have to wait for the tech to catch up.

Oh, I never posted screenshots here!

Coney_Island_Off_(resized).png

Off (this'll be the menu image).

Coney_Island_GI_(resized).png

GI on

First_Selection_#5_(resized).png

Game started, #5 in the hole, and one coin in to increment selection to first card.

One thing I don't have: where the tilt is displayed on the backglass. If I recall correctly, it's in the sky above the register? I don't remember, though. If one of the Coney Island owners in this thread could post, that would be awesome!

Perfect, thanks!

Oh boy! I figured out that I needed to write my own custom portion of pyprocgame that dealt with the DMD (since I'm not using a DMD).

The result? I have illuminated numbers as a result of switch presses! This is the majority of the issue with the graphics resolved!

Now, I'm still rewriting my functions to work completely differently (though since I am running a custom pyprocgame anyway, I may just rewrite the remainder to function the way I wanted initially...), but this is a MAJOR component resolved. I'm pretty darn happy!

Screenshot_from_2016-04-17_16-45-35_(resized).png

Selector unit now lights each card appropriately. Boy, it's a lot easier to see progress when you can see_ it.

Thanks Vic! It's coming along quite nicely now.

Things are really flying now. Extra Ball mode functions and more importantly - Extra Ball probability works. Right now I am working on the animation for the EB scan. It's a little tricky since the EB scan animation changes as the EBs are accrued. I have the graphics complete, but need to link them in.

Tilt works, and thanks to the photo of the back of NoQuarters' backglass, I have it displaying in the appropriate spot of the backglass.

One of the things I need to rewrite is the timeout function. I had it written by using a real-world timing function to measure the time between steps on the timer unit. Once it hit step #40, it would throw to tilt. The only problem: the program would sit and wait for the timeout to happen and would not let me put in a coin until it timed out! This is a good example of one of the things that I had written in a way that the framework couldn't understand. I still have to tackle this, but I expect I'll find an ok solution.

I am really excited at the progress today.

Thanks NoQuarters! Very fun thus far. We'll see what I think when I'm 20 machines in.

Working on testing my search algorithm - still having to shuffle it around a bit from what I initially wrote, but so far, it will pass in a list of holes that are currently active (for ex: [9, 1, 5]), and then for each position of the search disc, it will return the search relays which should be closed and the hole they correspond to.

Ex: {5, 1:2, 9:3, 25:4, 3:5}

Based on the search relays which are engaged(), the winner detection methods will fire. These will look at the current state of the selection unit (which cards are active), the current state of the replay counter (how much have you already won), and then start incrementing your score. It's pretty simple, since Bally laid it out (at least in Coney Island) with each number corresponding pretty directly to left to right or top to bottom - and I can review the placement in the array. In my little psuedocode above I used a dictionary, which in Python does not store in the same order it is entered. Therefore I have to use something else, like a dictionary of lists or something. Tuples, perhaps? I am not sure yet. Probably a list of tuples. Anyway, point is that it's coming along.

I will have a real replay register attached underneath the cabinet (for sound), but the register on screen will be incremented separately.

I've thought about just making the register on screen a dummy, and including a real register mounted behind the bezel that will be necessary surrounding the monitor, but I think that might be kinda silly looking, since the register is typically integrated into the artwork and etc.

Haven't started my physical build yet, but I have been slowly accruing the boards I need to run the thing. At the moment, I am missing the P3-ROC, but have the driver and switch processors. One of the drivers will be a high-power (50v) line, which will activate the real coils I've got in the system, and the other half will light playfield rollover lamps. Lamps and coils/motors will not need diodes as they are integrated on the board.

Oh! And I'm a big dummy and forgot that the SW-16 boards have diodes built in, and thus I don't need to add diodes to every switch. Pretty darn cool.

Because the motors are AC and not DC, I will have to use the driver board to latch a relay and drive AC to the motors. Pretty simple, as I plan to use a real bingo transformer.

My current thought for the wiring is to reuse all the cabinet and playfield wiring (obviously I can ignore the majority of the playfield wiring since I will only need to know the state of one shutter switch), and then make my own wiring from the female side of the Jones Plugs to the connectors needed on the switch and driver boards. Pretty simple, actually!

I will have to lay out the boards on the back door, with a similar trunked bundle for service.

As I will be controlling score/instruction cards display via a second/third computer via SSH, I'll need to have networking capabilities. Therefore, I'll need to have a local network with a switch installed within the cab, along with my RPis. Driver boards for displays will be mounted somewhere relatively convenient and the screens themselves with their ribbon cables will be mounted on top of the wooden apron.

After I have finished wiring, I'll draw up a schematic and release it along with the source, and then others can build as well!

I am not certain if Bally modified the playfield wiring from one game to another drastically, and as such, the schematic is going to be necessary if anyone wants to do the same thing.

And what, you may ask, is going on with the EB animation? Well, I haven't done it yet. But I'll get back to it after search!

NoQuarters, that's an excellent suggestion. I was going for authentic sound, but if I used a real 'sounder' which is springloaded and hits an adjustment screw, that could work well! I'll probably have to experiment for a bit. This would mean that my 'virtual' display of replays could be knocked off just like the real thing, and I wouldn't have to zero out the fake register inside the cab. Hmm!

So I've apparently stumbled into something that's a little tricky, and my programming chops (or lack thereof) is stopping me.

I mentioned above that I've got a dictionary comprised of hole and relay pairs. My gut was correct, and a dictionary is exactly what I needed.

I have my list of holes and compare to the key in the dictionary, and that gives me the relays I need.

I take those and run them through set() to ensure there's not any duplicates, then call sorted() to ensure that they are in order.

This is all working as expected. Now, I have to figure out if each number is in consecutive order. If I can crack this nut, I'll be able to get my 3, 4, and 5 in a row winners worked out.

Issue is as follows:

A result of [1,2,3] is a winner. [1,2,3,4] is a 4 in a row winner. [1,2,3,4,5] = 5 in a row. But! If I instead get [1,3,4] - that's not a winner. So I can't just determine the length of the resultant list. I have to do something a bit more complex, and compare each value to the next in the list. I've written a few little functions to determine this (and surprised that there's no python built-in to do this). Nothing's gelling yet for this - so if anyone has an idea, I'm all ears!

Once I determine the type of winner, I'll hand that off to the replay stepper function, which increments my replay counter unit, register and etc.

Well, as soon as I post, I figured out a way to do it that's not too bad.

Hi acebathound - to clarify, this is not a simulation to be played on a computer, but instead a recreation using a full cabinet and so forth.

There are some really excellent simulations out there written by a great guy in the Netherlands - take a look at http://www.bingo.joopriem.nl/

Joop's simulations take a couple of small liberties with a few things, and can only be run within Windows or Mac, so my little Linux machine wouldn't be able to run them. On top of that, I'll be able to come up with some other surprises once I finish what I have planned (probably in the far-flung future). The gameplay on Joop's simulations is fantastic, and I've whiled away several hours playing games I don't have access to.

I think that all of the new bingo pinball players will be interested in seeing these simulations. If they get a game, it can help with determining if it is working properly, etc.

He also offers a cabinet interface, but again, my version will do things a bit differently in a couple of 'behind-the-scenes' ways. There are a couple of folks doing a cabinet installation using his software.

On my side, I'm emulating each unit individually, doing full portion control based on position of units within the game, and will be allowing for multiple playfields. My wiring will be a little more robust than a serial link, and I'll have room for expansion and things like displaying appropriate score and instruction cards.

A fully working bingo pinball machine is my favorite type of pinball machine! I love all pinball, but bingos are something very special. The gameplay has insane depth, and it definitely keeps you coming back for another shot.

Thanks Dennis!

Guess what? All three in a row searches work! Now I'm writing the graphic routines to move the reels, then I'll be testing all three, four and five in a row winners.

Got confirmation that you can score on all three cards in a single game tonight (manual and schematic showed that it was possible, but I wanted to confirm), so my methods are working. Pretty cool!

I have the difference between the initial position of the reels and each number, so I just have to write the programming that will loop through the reels as they spin. I've got it passing in the current position of the reels, and at 9 it will step the next. I'll post a graphic of my first five in a line.

Thanks to NoQuarters' backglass masking photo, I was able to place this tilt relatively properly (may need to move it down a hair/resize)!

Tilted_(resized).png

3 In A Row scores 4 replays:

3_in_a_row_(resized).png

4 scores 16:

4_in_a_row_(resized).png

5 scores 100!

5_in_a_row_(resized).png

This is a 'glass-off' 5 in a row. Now, I just need to finish my animations and test game function sequence, and then I'll be ready for the next one! (First one of each feature is definitely gonna be the hardest).

Steve, that Turf King not only turned out to be an extremely fun game, but was a great bonding experience. Memories made that will never be forgotten. Thank you again.

You've gotta take me down on BP so next time I swing by I can accidentally set a better one.

Believe me, I feel the same way.

One of the things I most like about programming is the 'refactoring' process. Finding a better solution to a problem is very satisfying.

At lunch today, I was working on the Extra Ball animation. One of the difficulties is that I have to light the words 'Extra Balls' and light each lamp in turn as the extra ball selector unit steps. That's no problem - it'll work the same way that my selector unit does, lighting each card.

But in the case of the flash animation, where you press the yellow button to light 'Extra Balls' and then drop a coin to 'spin' the machine and potentially light EB #1, the game will flash the EB #1 light a certain number of times (based on the bumps on the CU cam #4). It will flash only one lamp at a time (according to the schematic), which is quite different from later games that would flash the entire panel.

In pygame, when you blit an image to the screen, it is done. No longer accessible. The screen is as it appears. When I initially wrote my replay register movement functions (decoupled from the game logic), I wrote a generic movement function that would accept a positive or negative integer, then move and do calculations, etc. Based on NoQuarters' suggestion above, instead of relying on the physical limit switch on the real replay counter, I implemented an internal counter. This allows me to very easily abstract each reel as a subclass of 'reel', with a position and an image.

When I did this refactoring, it just felt right, and allowed my scoring to work in the game! It also removed two coils and one switch from my BOM.

Now, take my current problem: I don't have access to the existing layers of images. I have up to 36 layers on screen at once! When I blit the 'Extra Balls' to the screen, there's no way to remove them without re-blitting every other layer.

Thankfully, I am storing the position of each reel, and can call those back and re-render very easily. For each selection, I store the position of the 'unit', and can recall that as well. It will be a bit of work before I can get this up and rolling, since I have to write the code to re-render the screen, store it somewhere, and call it multiple times per 'revolution' of the control unit. But, I have a handle on HOW to do it, and that is often the hardest part of getting started.

I've mentioned before that I'm not a good programmer, but I do enjoy it. I like finding solutions to problems - this is also why I love working on pinball machines!

Now, I need to figure out exactly how many bumps are on that cam, then determine how far it goes per latch of the timer cam. For now, I'll put in a dummy value that I can swap out.

Got the EB animation working properly for all three extra balls!

Now fixing up some functionality to make it play properly with real hardware. Once that's done, I'll move on to the next game!

All done with Coney Island! Woo hoo! (Well, done is a relative term. I need to plug in sounds, and test in a real cabinet. Right now because some switches don't physically exist, they are not getting exercised as they would in game. Will have to wait till the physical build out).

Tomorrow, Bright Lights begins!

Anybody ready for a lil sneak peek at game #2?

download_20160424_084039_(resized).jpg

Source image for Bright Lights, Bally's first bingo. More to come...

Thanks Ryan!

Been working on the artwork yesterday and today...

Here's Bright Lights running with first card selected in-game.

I still have to adjust starting position for the meter and reels, and implement search disc #2 which scans cards 4-6. Cards 1-3 score appropriately already.

BL_(resized).png

I should clarify - I have searching working on card 1-3 using the search disc setup from Coney Island. That isn't actually how it works on Bright Lights. The search wipers are 180 degrees apart. Crazy.

Verified that the search disc rotation for search disc #1 works exactly the same between Coney Island and Bright Lights. Now, I have to program search disc #2 numbers with a release noise. Very close to a functional Bright Lights as well! Game #3 is going to be a bit of a surprise (hint: if you think I'm moving to 'Spot Lite', you'd be incorrect).

I have also begun (at lunch today) to write the menuing system. Not super fancy, but you will page left and right between backglasses, then press the R button (or enter or whatever I choose) and it will fire off the appropriate game. Stretching the limits of my graphical programming skills and my poorly thought out attempts at modularity.

I have it loading the images (including full multi-layered images for replay counter and so forth), but need to work on separating my graphics module a bit more. It's a little creaky with adding a second game, and that will only get worse as I add more. I'm pretty sure that I will either need a separate keyboard encoder with a double-stacked switch to handle the menu events, or I will need to look into using the P3-ROC switch reading software in the menu as well. Doable, I think, but not sure how much I can remove from the stack just to read switch events, so I may just wimp out and run a separate switch for left, right and R.

Some new hardware is supposed to come today! I'm excited to get started with that this evening and rest my brain for a moment regarding the menu.

New hardware is not only here, it's all done! This was much much easier than I thought it would be.

13086674_1721373414775095_4692258918316410056_o_(resized).jpg13047749_1721380804774356_2755734328302169468_o_(resized).jpg

This pile of wires and junk is my new custom score/instruction card displays! Already working, loaded with images, and ready to go! Pretty darn cool.

Tomorrow, back to the game.

At lunch today I wrote the remaining linkage needed for search disc #2 for Bright Lights (cards 4-6). Close to the finish line on that game, now!