E2000 Bally Fun Project - Call on experts

[ramegoom]

I have a number of Bally E series machines in my game room and want to put a project together where I can "rig" the machine to win. This would make the machines a bit more enticing to play and I could have some fun with it.

So here's the initial plan:

Starting with my understanding, the reels start the spin during a play and the processor has determined where they will stop. When the each reader gets to the pre-determined binaries, the processor sends a signal to trip the solenoid, in order of left to right. If it misses the mark once, the processor watches it but lets it pass; more than twice in a row, the processor sets a tilt code. But it doesn't set the code unless the problem persists at least two out of eight pulls.  So my thinking is that I can force a particular stop at least one time within a minimum of eight game plays.

If I'm correct, the plan would then be to toggle between "normal" and "rigged" play using a wireless remote as a trigger, and force a pre-determined reel stop using logic while at the same time, ignoring the processor commands. I'd do that by monitoring the binary numbers at the readers, and trip the solenoids at a determined binary.

For example, say the triple bars on each reel are at binary 6, binary 20 and binary 14 respectively. I can monitor the binaries, and using my hidden remote, bypass the controller requests, then stop the reels where I want them. The game would then pay out based on where the reels stopped.

Since each reel reader sees binary 1 thru binary 25, monitoring those would be simple logic. I would send a stop signal when the selected binary was reached. The processor stop requests would be ignored, at least for one time. It would be similar to a sticky release mechanism that only happened for one pull.

So, essentially, I'm simply "delaying" the stop points on all three reels, using a remote control.

Am I missing something or would this actually work? Experts chime in...

[dhellis]

OK so somehow I missed this message. I really need to dig in to it a bit but I think that the 2650 CPU writes in
one cycle so what ever it is that you use to intercept the codes has to be pretty quick.

Also, and this is only a thought, suppose the MPU generates a code which results in 1 cherry and you want it
to show up as a jackpot. The results of the code is likely to be stored in memory and then when the reels stop
is compared to insure that the reels indeed stopped as it was supposed to.

If the memory states Cherry, Plum, Orange and at the end of play the reels read 7,7,7 you should get an error.
My guess is that the error would be a 91, 92, or 93 and because of this there would be no payout unless you
are also pulsing the hopper to force a payout.

Obviously if you know the memory locations you could write the data but perhaps the actual data is only
stored in one of the 7 available registers of the CPU.

If registers are used then seeing the predetermined values becomes more difficult.

The other issue that I see is that you would have to monitor the reel readers to see how fast the reels are
turning and then develop an algorithm to trigger the reels at the proper time so that it stops where you want
it to. Since we know that you can add diodes to the reel reader control card then we also know that
the rotational speed is somewhat sensitive.

There you go, my 2 cents worth.

[ramegoom]

Thanks, Dan. I delved so far into the E series machines that the wheels are spinning in my head now.

I believe there is a routine that allows a "slippage" of the readers to pass thru once out of eight pulls. It allows a sluggish reel to work - once in a while - the way I'm seeing it. You notice when you play these machines, sometimes the commanded stop misses, and rolls past where it appears to have wanted it to stop, displaying the next symbol. No tilt though. So the challenge becomes a timing question; just how much wiggle room do I have, and can it apply to all three readers and stops during one play?

I can intercept the binaries of each reader and pass the data thru very quickly to the stops. But I'm thinking, I can intercept where the CPU wants to stop, and thru a separate routine, command three particular binaries (three triple bars, for example) to fire at those points. If the CPU will allow a sloppy stop without tilting, the question becomes a function of timing - how long of a delay does the CPU permit without setting a tilt. I also thought I could halt the clock signal completely during this routine, causing the CPU to wait in the wings while I'm making the reel stop changes. A paused clock should do the trick.

I have started to work out a circuit for this and will prototype it eventually.

On a separate project, I want to set up a machine so that it only pays ONE coin regardless of what was commanded to win. Why? Let me explain. I'm working on converting a machine to become a "trade show" attraction, where the payout table and strips become certain hand-out trinkets rather than the usual bells and cherries. So, if the trade show booth operator gives out say, a toe-nail clipper, a pack of band-aids, a safety flare kit, and for the grand prize, a gift card. I can appropriate the two cherries to win the smallest give-out, the three single bars to win the more expensive give-out, three triple bars for the most expensive give-out, and the three 7's to win a $50 visa card. Neat concept, re-purposing a machine to attract customers (the bell would ring for the duration of the win). I really think it's a great idea to use these old machines for something else.

But I don't want the booth operator to have to deal with re-loading tokens. So, if the win is on cherries, and the hopper commands a 10 coin win, I want to pay out only one coin, halt the hopper, and then feed a counter back to the CPU that makes it think it's paid out all ten coins. If the counter runs slower than a typical coin hopper, the bell would ring longer, attracting more potential customers. The booth operator simply looks at the win reels, and hands out the freebie that matches the reels once the customer turns in the won token.

I have a circuit worked out for this one, but haven't tested it yet.

Anyway, picking your brain for this. The only thing I am not sure of is just how long will the CPU wait for the slippage before it starts its tilt complaint.

[dhellis]

I looked at every source I had to see if the timing was described, unfortunately I didn't find anything. What
was found was that on those reel reader control boards that have dip switches, turning on SW-1 provides for
the maximum delay for all of the reels. Boards without the dip switch you can add a diode on the back to accomplish
the same thing. Turn this switch off and that gets the shortest delays.

Apparently, SW2- 3 control reel 1 and SW4-8 are reserved for future use.

I wonder if it wouldn't be easier to handle payouts by modifying the game eprom? Someone posted
the table where the payouts exist and that post is here

http://newlifegames.com/nlg/index.php?topic=2354.new;topicseen#new

This would save you from building circuitry for the payout and you would not need to trick the CPU
into thinking that the payout was correct.
Even if you decided against going this way, the information in that post is pretty interesting.

[ramegoom]

What I was thinking is the Error Code 9x  (91, 92, 93) which is set if there is a positional error on any of the readers, twice within eight pulls.

If I can simulate a "positional error" only once within eight pulls, the code won't be set. So, forcing the stops to stop where I want them to, only once, should not set a tilt code.

Just as long as I don't get greedy and make it happen twice within the necessary eight pulls.

I think that would make the project fairly easy to try.

Then, the payout scenario would involve a different system, but still should be fairly easy to test.

On the other hand, rewriting the code would be an interesting possibility. It would get complicated unless we found someone who has written code for these machines in the past and could shed some light on the operation...but who knows? These techies are long gone from the scene as far as I know.