Monday, January 7, 2013

Walking backwards into the future...

I have (finally) started to wire up the lights and switches... About time, if I may say so.

1) Wires, wires, wires. And that's not even half of them. The power cables are connected in a network with multiple contact points so that the power always (as in - hopefully) get routed to most switches and lights in case a connection breaks somewhere. I bless the testing mode I've developed which has already helped me tremendously while troubleshooting. 

The machine is now autonomous in terms of starting a game, loading balls, autolaunching, ball search, multiball etc, so an actual game can be played. Without any rules.
I've begun thinking about the rules and have a basic framework set up, but nothing's programmed yet.

Due to some unfortunate incidents it took a little longer than it should've. But we'll get to that later.

All right,

As I wrote before, the machine is now autonomous.
When inserting a credit and pressing start, or simply pressing start during free play, a game is started.
The game then checks if there's any ball in the shooter lane and launches one in case there's none.
During the initial ball launch a switch hit other than the shooter lane switch is required to properly start the game. In case the game is started and a ball magically falls down the shooter lane, that ball is automatically kicked back into play.

When the drain switch is hit, the bonus sequence starts and the ball is kicked back into the ball-through.
Then another ball is ejected to the shooter lane and the next ball is played. In case there's no game running the drain simply kicks the balls out of the way. This is also the way balls are being loaded into the game after maintenance etc.

In case no switch is hit for a 25 second period a ball search is initiated. All relevant solenoids (and the motorized target bank) are being pulsed three times during seven second windows, stopping at any time if any switch is being hit. In case no switch has been hit after a total of 46 seconds the ball is considered lost and a new ball is autolaunched (or simply ejected, in case that's the preferred option chosen). Should the lost ball somehow return to play, both balls will be lost when either of them drains.

I've experimented with multiball and thought of a simple system -
A total number of balls are being requested by the game and in case there's less than that number of balls, a new balls is autolaunched into play. Great care has been taken in designing it, so that it's non-blocking and allowing for easy gameplay design. In case a ball is drained and the "shoot again" timer is still active, the drained ball doesn't decrement the total ball count requested, causing a new ball to be launched into play.

It's simple and very elegant i.m.h.o.
I will combine this with an additional ball counter so that the game hopefully never looses track of any balls. I need this since it's a 4-ball multiball game and there's a physical lock involved. In case the lock is partly filled and another multiball is launched, one or more balls will be released from the lock. During single ball gameplay and the lock is missing balls, the locking could be restored until the same amount of balls has been locked as before the other multiball - or simply become virtual locks instead.

( Actually, I have a mode that allows you to collect any number of balls to use in multiball, sort of like an unlimited ball save timer until the last collected ball has been drained )

The slingshots, VUK's, saucer and bumpers are wired up as well.
But when testing I noticed that something isn't right with the new power-driver board I order last. 
For some reason the bumper rigged to that card stopped working - and after a little troubleshooting (to be very modest) I replaced the MOSFET with a spare one and it started working again. 

Unfortunately - most of the switches on the right side of the board stopped working. It turns out the shift register that handled those 8 switches had been fried. Once that was fixed everything was good. 
For a while. 

Then the very same bumper broke down again. This time without killing any switches however, to my great joy. The MOSFET is probably busted thou. The card is a pain to remove so I'll probably won't be doing anything more on it until I need it.

I had the same problem with the magnet a while ago, so I'm thinking the diode might be broken on the bumper and causing a reversed voltage spike to fry the MOSFET, perhaps? In any case - that's five broken MOSFET's on the same card. None of the other cards has had any troubles at all, so I'm leaving my options open on this one.


No comments:

Post a Comment