Re: Tech: Bally Lamp Driver Operation
- From: Steve Kulpa <stevekulpa@xxxxxxxxx>
- Date: Thu, 27 Mar 2008 13:08:29 -0700 (PDT)
Ok, I get it now. So what happens is that these 15 addresses, strobe
and zero cross keep going in a loop around and around again until new
data updates it (obviously from input from the switch matrix), in
which the lamp status is upgraded and it does it again.
Just after the zero crossing, the MPU sends all 15 sets of data, one
at a time, but real fast. The data it uses to send to the lamp driver
is stored in a table in memory (see below).
Now in terms of the input now, the input matrix would be hooked up
directly to the MPU, correct? On the William's system, both in AND
outs are present on the driver board. So on a Bally the input isn't
present on the driver boards, so they are output only and thus, they
have to get into the CPU another way. I am guessing the switch matrix
goes in directly, correct?
the switch matrix has nothing to do directly w/ the lamp control.
Obviously some switch closures require lamps to be lit, but that's
handled in the programming. For controlled lamps, I believe the
program maintains a table in memory of lamp data, and when lamp
updates occur, based on programming that says "lamp so and so needs to
be turned on/off), the table is updated. Then when the lamp service
routing is invoked (120 times per second), it just uses this table to
send whatever data is currently in the table to the lamp driver
board. this way, the main program just updates the table when needed,
and the interrupt routine knows the table always has the current lamp
states.
No input/output is connected directly to the MPU. All input/output is
handled by the two PIA chips, which are controlled by the MPU. (PIA =
Periphial Interface Adapter). All switch inputs go to a PIA first,
and then data are delivered to the MPU by the PIA. Bally handles
switch data by sending out strobes, and then seeing what data comes
back. It does it 8 strobes at a time, by 8 times, so 64 switches can
be addressed. Plus, to avoid false readings caused by bounce, it does
special stuff, like having to see 2 closures in a row before assuming
a switch is closed, etc.
I know nothing of how Wms works.
So then the MPU must get a sync signal directly from the pulsating DC
output so it knows exactly when to sent the 15 address pules, correct?
That's what the zero crossing circuit is for - to generate an
interrupt (pulse) every time the 43v reaches the zero crossing.
When the processor gets an interrupt, it stops whatever it's currently
doing, saving what info it needs to recover later, and then goes off
and services the interrupt. After the interrupt is serviced, it pulls
out the info it saved, and resumes along it's merry way where it was
before it was interrupted. I know the solenoids are handled via a
zero-crossing interrupt routine too. I'm sure there's other stuff
being done during this interrupt too (switches, etc...).
So basically, in a way, the strobe actually "writes" the information
to the driver board to update it.
The strobe signal tells the decoder to "do it's thing". The inputs
need to be applied first, but the decoder does nothing until it's
strobed. That's why the program sends the inputs first (4-bit address
and 4 inhibit signals). Then pauses a little bit, then sends the
strobe signal. A microsecond or two (I think) after the strobe, and
the decoder outputs will react. Propagation delay on these 74xxx
logic circuits is to be considered, but I don't remember what they
are. The deeper the logic, the longer it takes stuff to travel from
one end (input) to the other (output), but it's real quick, just not
instantly. Decoders are sort of deep. AND, OR, and Inverters are
not.
Yeah, I figured there would be some kind of delay to let the CPU
update itself and get the driver boards "ready" to accept the new data
stream.
No, the delay is to allow the voltage to raise a bit above zero, so
the SCRs will conduct when gated. If the voltage across the SCR is
zero (or below the SCR's threshold), it will not conduct when gated.
this delay is not needed for the solenoid stuff, which also is handled
via the zero crossing interrupt. The processor is always "ready" as
it's zipping along at a clock speed of 1MHz.
To me it almost sounds like a weird off take on a serial transfer
system, because just about all the information seems to be coming down
in line.
the 68xx chip set has 8-bit I/O busses and it does do lots of things
in parallel. the switches are serviced 8 at a time, solenoid data is
sent as 4-bit addresses with strobe, lamp data, display data, etc.
I must say I am amazed at the complexity of the system considering
this was early 80's.
It's all in the programming, and the skill of handling input and
output is beautifully executed. The logic circuitry was around then
and they took full advantage of it. This is the stuff I studied when
I was in school, that's why I like it so much. Did my share of 6502
assembly programming too. I assume the 6800 is similar to 6502. And
I agree, using the zero crossing like they did was brilliant. They
fire coils off at the start of a cycle too, so the current draw starts
out low, and then gradually increases, rather then one big draw. And
only one coil can fire at a time, the next coil does not fire until
the previous one was released.
If you want to see something really cool, visit this page and read how
the displays work.
http://www.geocities.com/stevekulpa/bally_disp6.htm
steve
---
Steve Kulpa (cargpb10)
Hermitage, TN
http://www.geocities.com/stevekulpa/pinball.htm - Pinball
http://www.geocities.com/stevekulpa/faces/rgpidx.htm - Faces
.
- Follow-Ups:
- Re: Tech: Bally Lamp Driver Operation
- From: EvilOompaLoompa
- Re: Tech: Bally Lamp Driver Operation
- References:
- Tech: Bally Lamp Driver Operation
- From: EvilOompaLoompa
- Re: Tech: Bally Lamp Driver Operation
- From: Steve Kulpa
- Re: Tech: Bally Lamp Driver Operation
- From: EvilOompaLoompa
- Re: Tech: Bally Lamp Driver Operation
- From: Steve Kulpa
- Re: Tech: Bally Lamp Driver Operation
- From: EvilOompaLoompa
- Re: Tech: Bally Lamp Driver Operation
- From: Steve Kulpa
- Re: Tech: Bally Lamp Driver Operation
- From: EvilOompaLoompa
- Tech: Bally Lamp Driver Operation
- Prev by Date: Multiball Restart FT
- Next by Date: Re: The Garage EM wins - again! (Pic)
- Previous by thread: Re: Tech: Bally Lamp Driver Operation
- Next by thread: Re: Tech: Bally Lamp Driver Operation
- Index(es):
Relevant Pages
|