Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Playfield lamps

111 views
Skip to first unread message

Gerry Stellenberg

unread,
Apr 3, 1997, 3:00:00 AM4/3/97
to

I've been given two completely different recommendations on how to
drive the playfield ramps.

Firstly, for those who haven't read my other posts, I'm going to build
my own pinball game. I'm currently trying to figure out how
everything works and decide on the best way to implement them myself.
The current topic is lamps.

Suggestion A (which originally sounded like a great idea) was to
switch the lamps by outputting what the current state should be to a
latch and having the latch drive the lamp through a darlington
transistor. This way, the lamps wouldn't have to continually be
refreshed. The latch would either stay on or off until the state was
switched.

Suggestion B included a criticism of A. I was informed that giving a
lamp a constant source of power would likely quickly burn it out. The
new advice was to, when a lamp should be on, turn it on for a short
period of time, turn it off for about 10ms, give it another short
pulse, etc. Apparantly the light will not have a chance to lose its
"glow" before the refresh pulse is received.

I'm basically looking for a general concensus as to which suggestion
is the better one. It seems fairly obvious that A would be much
easier to implement as I wouldn't have to worry about refreshing.
Instead I could just deal with state changes.

So, what does everybody think? Is A going to burn out the lamps even
if I limit the current the lamp receives?

Does any have any additional suggestions?

Thanks.

- Gerry

Rodger Boots

unread,
Apr 3, 1997, 3:00:00 AM4/3/97
to

On Thu, 03 Apr 1997 02:24:36 GMT, g...@vt.edu (Gerry Stellenberg)
wrote:

>I've been given two completely different recommendations on how to
>drive the playfield ramps.
>
>Firstly, for those who haven't read my other posts, I'm going to build
>my own pinball game. I'm currently trying to figure out how
>everything works and decide on the best way to implement them myself.
>The current topic is lamps.
>
>Suggestion A (which originally sounded like a great idea) was to
>switch the lamps by outputting what the current state should be to a
>latch and having the latch drive the lamp through a darlington
>transistor. This way, the lamps wouldn't have to continually be
>refreshed. The latch would either stay on or off until the state was
>switched.

Atari did it this way. All lamps were constantly driven by
addressable latches. The processor didn't even have to handle updates
due to some strange DMA circuitry that handled the refreshes.

>Suggestion B included a criticism of A. I was informed that giving a
>lamp a constant source of power would likely quickly burn it out. The
>new advice was to, when a lamp should be on, turn it on for a short
>period of time, turn it off for about 10ms, give it another short
>pulse, etc. Apparantly the light will not have a chance to lose its
>"glow" before the refresh pulse is received.

Don't recommend this. For the same brightness you end up with current
surges that will be harder on the bulbs, the drivers, and cause radio
interference.

>I'm basically looking for a general concensus as to which suggestion
>is the better one. It seems fairly obvious that A would be much
>easier to implement as I wouldn't have to worry about refreshing.
>Instead I could just deal with state changes.
>
>So, what does everybody think? Is A going to burn out the lamps even
>if I limit the current the lamp receives?

If you limit the current bulb reaction time will be slow.

Bally does it a third way. When you have a power line zero crossing
they sense it and interrupt the processor. The interrupt routine
pulses SCRs for lamps that should be lit. Once pulsed, the SCRs will
latch on for the remainder of the half cycle. The same interrupt also
triggers a scan of the switches, running of the switch debounce
routine, and on/off solenoid control. By doing everything at power
line zero crossing you cut down on surges and radio interference.

Yet another way would be to use the addressable latches from method A
to drive darlington driver ICs (such as a ULN2003)---one driver will
handle 7 bulbs. There is a pin on those chips that is a common line
to a set of 7 diodes, one for each output. Normally those diodes are
used for spike suppresion if driving inductive loads, but by
connecting the right voltage to this pin or a resistor to ground you
can use it to provide a constant filament preheat current.

Another idea...forget bulbs entirely! LEDs are now available that
will do the job in most places. Then take one of those lamp drivers
that has a serial data input and 32 outputs and put it right on the
playfield next to the LEDs it drives. It would really cut down on the
wiring.

Clive Jones

unread,
Apr 3, 1997, 3:00:00 AM4/3/97
to

In article <334385e9...@news.cedar-rapids.net>, Rodger Boots
<rlb...@cedar-rapids.net> writes

>
>>Suggestion B included a criticism of A. I was informed that giving a
>>lamp a constant source of power would likely quickly burn it out. The
>>new advice was to, when a lamp should be on, turn it on for a short
>>period of time, turn it off for about 10ms, give it another short
>>pulse, etc. Apparantly the light will not have a chance to lose its
>>"glow" before the refresh pulse is received.
>
>Don't recommend this. For the same brightness you end up with current
>surges that will be harder on the bulbs, the drivers, and cause radio
>interference.
>

Sorry Rodger, I'll have to disagree. The current surge is only a real
problem with a cold element (in-rush current), since the element remains
hot the surge should not be a great factor. Therefore...

It's usually 'b', and it's achieved using a blanking signal/clock
generated from a zero crossing detector - a circuit designed to change
state when the 60Hz AC signal from a secondary winding passes through 0
volts.

The lamp row/column data is usually written into an octal D-type latches
to prevent unnecessary refreshing and microprocessor overhead. The latch
*outputs* can be shut down (go tri-state) by virtue of the output enable
(OE or OC) pin which is usually tied to the blanking clock (which in
turn disables the lamp drivers). The latch allows the outputs to be shut
down *without effecting* the data stored within those latches on a high
transition of the blanking clock.

The latch outputs will return to their previous states on the next low
transition of the OE pin. The same goes for the solenoids and displays.
This is exactly what WMS continue to do with WPC, but, it's unclear
whether WMS generate an interrupt during this period indicating the
outputs are off and it's okay to write new data to the latches (you can
do this to the latch regardless of the state of the OE/C pin).

Depending on what type of latch your using, the OE/C pin (if the device
has one) can be either active low or active high of course - check the
data sheet.

There's another factor also missed here - the lamps are usually on a
matrix, therefore, you only have *8 on* at any one time whilst the
others are off anyway - they're multiplexed.

Clive

_____ _ _____ _ ________________________ _
/_____ _ _\ /_____ __\ |*| English Lord and |*| / |____
\__||_/ \__||_/ \\\\\\\\\ |*| Squire of Property |*|( BONUS_|
____|__||_|______|__||_|____________|*|_____okay yar?______|*|_\_|____
//////////////////////////////////////////////////////////////////////
E-mail: <c.j...@sni.co.uk>
E-mail: <cli...@clivej.demon.co.uk>

Gerry Stellenberg

unread,
Apr 3, 1997, 3:00:00 AM4/3/97
to

Thank you all for your help figuring out how the current machines
drive their playfields.

Let me ask the original question a different way. If you could design
your own lamp driving circuit, how would you do it? Let's assume that
you will be able to individually address any logic unit necessary.
For example, an octal latch could be directly addressed.

Would you use a on-again off-again method such as the one WMS
implements or a constant on or off that a directly addressable latch
could provide?

- Gerry

Clive Jones

unread,
Apr 3, 1997, 3:00:00 AM4/3/97
to

In article <3343ca63...@news.vt.edu>, Gerry Stellenberg
<g...@vt.edu> writes

Okay, you asked for it! (and I've vhanged the subject heading for those
wishing to avoid tech articles). :)

Let's dispell a myth immediately. Unless you going to use an octal latch
that has a bus interface that goes tri-state when the latch is
deselected then your not going to get very far. Providing you understand
memory mapped I/O and chip selects you should be able to follow what I'm
about to say.

A octal D-type latch such as an LS374 can be selected using the *clock*
pin alone - it does *not* have a tri-state bus interface and therefore
hanging it directly off the uP bus will be bad news.

Lets look at how this latch works first...

It has 8 'D' inputs (D1-D8) and 8 outputs (Q1-Q8), when the 'C' or clock
pin is in it's active state (low to high transition), the data on the
'D' inputs appear at their respective 'Q' outputs providing the output
enable pin is in it's active state (low) - if it's not, the data is
still *latched* anyway within each latch until over-written. You simply
control whether the outputs are on or tri-state by using the output
enable pin. So, setting up this device, you'd want a bytes worth of data
available at the 'D' inputs before providing a transition change of the
clock pin, then, enable the outputs (alternatively you could just strap
the output control (OE/C) pin to ground but I suggest you keep the
blanking in place and use it to generate an interrupt). The OE/C pin
effects all the latches at the same time BTW.

So, now you can control the latch, but, you need two of them and still
require a bus interface so you can talk to the uP.

Right, we need two of them because we're going to drive the lamps on a
8x8 matrix. One octal latch will provide the row data byte and the other
will provide the column data byte to the lamp driver/sink circuits.

The bus interface can be provided by a 6821 or 8255 PIA - these you can
hang directly off the uP bus but still need to map them in to your
memory mapped I/O address space including the appropriate chip select(s)
to enable/disable the device when it does (or doesn't) fall into the
target address space area. You can use one of the interrupt input pins
(CA1/B1 - 6821) too generate an interrupt from the blanking signal.

Okay, following so far?

Next, you'll need to assign both the PIA ports as outputs so the uP can
right data through the PIA. Let's say you assign port 'a' as the byte
wide data port that feeds *both* latches at the 'D' inputs - PA0-PA7
corresponds to D1-D8. You configure port 'b' to provide the chip selects
via the LS374 clock pins - let's say for ease of explanation that PB0 is
clock/select for the row latch and PB1 is the clock/select for the
column latch. *Do not* use one bit (PB0) and provide an invertor to flip
opposite states to the other latch as one clock pin will always remain
high enabling any data available at the 'D' inputs to be latched. This
isn't an issue if your data port only serves these two devices as you
can just toggle between latches, but, if your going to extend this port
to feed other latches (such as those intended for coils or the switch
matrix) it's a bad move. Alternatively, you could have the lower 4 bits
of port 'b' (PB0-PB3) feeding a 4-16 line decoder to control further
latches via the clock pins (or any other devices). Be careful of loading
the PIA outputs with too many devices and causing problems - you may
need some drivers in there.

So providing you have the driver electronics designed for the lamps,
it's just a matter of software now. As it only takes two bytes to farm
out data to the matrix during multiplexing, this is a simple matter of
writing out the row and column data. Adding flashing lamps will require
more work in the software department though.

As for the timing - your looking to display *all* the lamps in the
matrix every 60Hz (a row on every 480Hz or every 2ms or *better* because
if you tie a single row on event to a single 60Hz event (blanking
interrupt) you will cut the complete matrix display time to 7.5Hz for 8
passes - painfully slow and it won't look too pretty either.

Gerry Stellenberg

unread,
Apr 3, 1997, 3:00:00 AM4/3/97
to

>Okay, you asked for it! (and I've vhanged the subject heading for those
>wishing to avoid tech articles). :)

Yes I did. Your answer was exactly what I was looking for.

>Let's dispell a myth immediately. Unless you going to use an octal latch
>that has a bus interface that goes tri-state when the latch is
>deselected then your not going to get very far. Providing you understand
>memory mapped I/O and chip selects you should be able to follow what I'm
>about to say.

My confusion begins here. I am confused about the need to refresh.
Do I need to refresh (by tri-stating and re-OE'ing every so often) or
can I simply leave the OE as is so that the lamps will be on until
switched off?

> (alternatively you could just strap
>the output control (OE/C) pin to ground but I suggest you keep the
>blanking in place and use it to generate an interrupt). The OE/C pin
>effects all the latches at the same time BTW.

Wouldn't wiring OE to ground mean the lamp is either on or off
depending on the latch outputs, which always exist? So, this is ok?
I don't have to turn the lamps of and refresh periodically?

>Right, we need two of them because we're going to drive the lamps on a
>8x8 matrix. One octal latch will provide the row data byte and the other
>will provide the column data byte to the lamp driver/sink circuits.

Question here... will I need to wire each row and column signal to the
inputs of 64 AND gates, whose outputs will drive the lamp driver
circuits?

This brings up another question. Do I need 64 darlington's to drive
the 64 possible lamps?

I am quite unfamiliar with the Voltage/Current requirements of the
lamps. If you don't mind, a quick lamp tutorial would be extremely
helpful. Please include a discussion of the driver circuits. If I am
to need individual darlingtons, what amplifier specs should I be
looking to achieve. Are there IC's I can use that encase multiple
darlingtons? Rodger recommended the ULN2003 as a good lamp driver IC.
Does everybody agree with that recommendation?

Note my inexperience in the lamp driver technology. Any and all
explanations you provide will help immensely.

>The bus interface can be provided by a 6821 or 8255 PIA - these you can
>hang directly off the uP bus but still need to map them in to your
>memory mapped I/O address space including the appropriate chip select(s)
>to enable/disable the device when it does (or doesn't) fall into the
>target address space area. You can use one of the interrupt input pins
>(CA1/B1 - 6821) too generate an interrupt from the blanking signal.

Ok, I think it's time for me to explain and let you critique my basic
hardware configuration. I'm going to install a digital I/O card in my
PC. On this card are n 8255's, which will provide 24n data lines.
Also on the card is an 8253 timer for generating timer interrupts.
Instead of generating an interrupt using the power line zero crossing,
I'm thinking that it will be easier to configure the 8253 to interrupt
me at the desired frequency.

Note, the card comes with drivers which make configuration all a
matter of software. Therefore, my program will set up the hardware
however I tell it to.

It seems to me that this is a wonderful way to build the pin. Can
anybody forsee any problems that may arise due to this configuration?

> you may
>need some drivers in there.

By drivers do you mean buffers, such as the 74LS240's?

>As for the timing - your looking to display *all* the lamps in the
>matrix every 60Hz (a row on every 480Hz or every 2ms or *better* because
>if you tie a single row on event to a single 60Hz event (blanking
>interrupt) you will cut the complete matrix display time to 7.5Hz for 8
>passes - painfully slow and it won't look too pretty either.

Ok, this goes back to my "refresh" confusion. I would think that if I
use an on/off lamp circuit driver, by which I mean the lamp is always
on or off, I wouldn't need to worry about a matrix display rate.
Instead, I could change the matrix values whenever necessary.

However, if I do in fact need to implement a "refreshing" lamp driver
circuit, will this work:

I can set my 8253 to interrupt me every 8ms. Then, every other
interrupt I can tri-state the latches, and every alternating interrupt
I can OE the latches. This would provide me with a 60Hz lamp driving
rate with a 50% duty cycle. I'm guessing that this is to simple.
Please explain what would be better.

Thank you so much for all of your help. The discussions I've had here
have been extremely informative and helpful.

- Gerry

Clive Jones

unread,
Apr 4, 1997, 3:00:00 AM4/4/97
to

In article <33441dd3...@news.vt.edu>, Gerry Stellenberg
<g...@vt.edu> writes
>

>My confusion begins here. I am confused about the need to refresh.
>Do I need to refresh (by tri-stating and re-OE'ing every so often) or
>can I simply leave the OE as is so that the lamps will be on until
>switched off?
>

Okay, lets make sure we're not talking about the refreshing of 'data' as
the data written into the latches requires no refresh (it's 'latched' or
'stored' until over-written). We're talking about shutting off the
outputs to the latches only.

Rodger gave the reason for the zero crossing circuit and the blanking
interrupt (I should say 'signal' as 'interrupt' is probably incorrect
unless you intend to use it as such) that's generated from it - it's to
cut down on RF/EMI noise emissions by switching loads at the point in
which the AC passes through zero volts (well thats the most common use
of the circuit apart from a regular clock). This will be approx. 120
times/sec (120Hz - 8.33ms) as a single cycle will pass through zero
volts twice (0 and 180 degrees) and not 60Hz as I wrongly pointed out
earlier in this thread <Sound FX: Slaps self violently around face>.

Yes, you could drop the blanking but may suffer buzz/hum/spikes or other
induced noise when switching.

But wait a minute! I thought about this and something didn't quite fit
properly - if the WPC OE/C pin of the latches was tied directly to the
blanking signal from the zero-cross circuit then the matrix could not be
sweept at more than 120Hz max making it impossible to perform 8 sweeps
to display all the lamps in the matrix during that time as the outputs
of the latches were forced off (I'm suprised none of you picked this up
BTW - tut, tut). This led me to the conclusion that the blanking signal
generated by the zero crossing circuit in WPC must be sychronised
(probably AND'ed) to the Motorola 'E' system clock (or a divided down
variation of the clock) so that you got *burst firing of pulses* to the
OE/C pins for the lamps/coils/display etc. at a higher frequency using
the blanking signal as an 'enable'. As I can't see inside the WPC ASIC
I'm guessing that this is the case.

Sooooo, armed with my 'scope (which lasted about 60 seconds after power
up before the raster collapsed - bugger!!) and 'iffy' frequency meter, I
clocked the lamp matrix latch OC pins at 10KHz. I couldn't get a duty
cycle for the wave as the 'scope decided not to play, and what I did
manage to see on it very briefly was extremely noisey. Take those
frequencies with a pinch of salt as I don't have all the fancy toys at
home that I have in work (and no, I'm not going to drag a pin into
work!). When I checked the dot controller out, the blanking is indeed
synchronised to the 'E' clock (you can hear the high frequency whine
when your close to a DMD anyway).

>Question here... will I need to wire each row and column signal to the
>inputs of 64 AND gates, whose outputs will drive the lamp driver
>circuits?

No, - not if you are driving the lamps on an 8x8 matrix - you would only
need 16 gates and unless your using darlingtons that will except a logic
level input to the base, you won't have enough power to drive the
transistors from TTL AND gates. Instead, you may want to use gates with
*open-collector* outputs and use them to drive (for example) PNP
darlingtons by sinking the current from the pull-up resistor attached to
the transistors base, thereby switching the transistor on. Alternatively
use Rodgers suggestion of ULN series drivers.

>
>This brings up another question. Do I need 64 darlington's to drive
>the 64 possible lamps?
>

No, it's the same as the gate question - 16, eight for the rows and
eight for the columns (source and sink transistors). You may also need
pre-driver transitors depending on your driver circuit design if you
decide to go that route.

>I am quite unfamiliar with the Voltage/Current requirements of the
>lamps. If you don't mind, a quick lamp tutorial would be extremely
>helpful. Please include a discussion of the driver circuits.

#44's and #555's are 6.3v/250ma (1/4 amp) lamps and are the most common
used in games. Since you may be using a matrix(?), then only 8 will be
on at any one time (this does not include the G.I. of course) that's 2
amps constant if your intending to leave them static (less if your not).

>If I am
>to need individual darlingtons, what amplifier specs should I be
>looking to achieve. Are there IC's I can use that encase multiple
>darlingtons? Rodger recommended the ULN2003 as a good lamp driver IC.
>Does everybody agree with that recommendation?
>

Crikey! You don't want much do you? :) I leave this to someone else (my
wrist is starting to ache - from *typing* that is). Rodgers use of the
ULN-2003 is probably okay providing it has a sink capability of 250ma or
greater (I've never worked with them).

>
>Ok, I think it's time for me to explain and let you critique my basic
>hardware configuration. I'm going to install a digital I/O card in my
>PC. On this card are n 8255's, which will provide 24n data lines.
>Also on the card is an 8253 timer for generating timer interrupts.
>Instead of generating an interrupt using the power line zero crossing,
>I'm thinking that it will be easier to configure the 8253 to interrupt
>me at the desired frequency.
>

Yes, I know the 8255 - 3x8 bit I/O ports but it's not as flexible as the
6821. You won't be needing the LS374 latches as the 8255 has output
latches in each port to hold the data stable at the outputs once
written.

>
>By drivers do you mean buffers, such as the 74LS240's?
>

Yes - buffers/line drivers.


>Ok, this goes back to my "refresh" confusion. I would think that if I
>use an on/off lamp circuit driver, by which I mean the lamp is always
>on or off, I wouldn't need to worry about a matrix display rate.
>Instead, I could change the matrix values whenever necessary.

Not quite (if I read you correctly). You'd want to drive the lamps on a
matrix or at least switch them on/off again in series of eight according
to the state they should be displayed in (some on, some off, some
flashing at different frequencies). If you have a possible 64 lamps on
at any one time - your going to be drawing *a lot* of current. The
payoff is simple - 64 transistors 'on' to display your 64 lamps all at
the same time worst case (providing your PSU can handle that amount of
current) against 16 transistors driving 8 lamps (8 source and 8 sink) on
8 seperate sweeps with 1/8th the power - 8 lamps x 8 sweeps = 64 lamps
displayed. The 8 sweeps required to display all 64 bulbs in the matrix
is where your display timing comes into play.

>
>However, if I do in fact need to implement a "refreshing" lamp driver
>circuit, will this work:
>
>I can set my 8253 to interrupt me every 8ms. Then, every other
>interrupt I can tri-state the latches, and every alternating interrupt
>I can OE the latches. This would provide me with a 60Hz lamp driving
>rate with a 50% duty cycle. I'm guessing that this is to simple.
>Please explain what would be better.
>

Yeah, the timing sounds alright - you may wish to sweep the *whole* lamp
matrix every 8ms or 16ms/phase 2 interrupt. The duty cycle isn't a big
issue providing your interrupt service routine has time to execute the
code before the next incoming interrupt (if it's an *NMI* otherwise
you'll be okay as the uP should not ACK another interrupt until the
current service routine has finished). Since you intend not to use
blanking(?) the choice of what to do with the OE/C pin on the latches is
yours (if you use them - which you don't if using 8255's). You have the
luxury of playing around with the timing to see what works best.

Actually, it would be interesting to find out what the minimum sweep
frequency is for the lamp matrix before the strobing becomes noticeable?

If your regular interrupt is fast enough (and you could squeeze all the
code into the timing window), you could handle all the housekeeping
sweeps on consequetive interrupts - 1st lamps + Switches, 2nd displays +
coils then back again leaving your main program to handle the game rules
or something along those lines.

These are only suggestions and I'm sure there are others who want too
say something, so, I'll shut up now! :)

>Thank you so much for all of your help. The discussions I've had here
>have been extremely informative and helpful.
>

Good luck!

Rodger Boots

unread,
Apr 4, 1997, 3:00:00 AM4/4/97
to

On Thu, 3 Apr 1997 15:56:12 +0000, Clive Jones
<cli...@clivej.demon.co.uk> wrote:

>In article <334385e9...@news.cedar-rapids.net>, Rodger Boots
><rlb...@cedar-rapids.net> writes
>>
>>>Suggestion B included a criticism of A. I was informed that giving a
>>>lamp a constant source of power would likely quickly burn it out. The
>>>new advice was to, when a lamp should be on, turn it on for a short
>>>period of time, turn it off for about 10ms, give it another short
>>>pulse, etc. Apparantly the light will not have a chance to lose its
>>>"glow" before the refresh pulse is received.
>>
>>Don't recommend this. For the same brightness you end up with current
>>surges that will be harder on the bulbs, the drivers, and cause radio
>>interference.
>>
>
>Sorry Rodger, I'll have to disagree. The current surge is only a real
>problem with a cold element (in-rush current), since the element remains
>hot the surge should not be a great factor. Therefore...

Disagree all you want, but this is the way Williams did it and the
result IS in fact higher peak currents which isn't good on anything.
The only reason they even end up pulsing the bulbs is because they
are driving them in a matrix. If a driver transistor shorts you end
up with supernova light bulbs. That's the same power that was there
before, only the duty cycle has changed. On the other hand, take the
Bally constant-drive system, short out an SCR, and the result is an
almost normal brightness bulb.

>It's usually 'b', and it's achieved using a blanking signal/clock
>generated from a zero crossing detector - a circuit designed to change
>state when the 60Hz AC signal from a secondary winding passes through 0
>volts.

All those constant-drive bulbs on Bally are, in fact, switched at zero
crossing.

>The lamp row/column data is usually written into an octal D-type latches
>to prevent unnecessary refreshing and microprocessor overhead. The latch
>*outputs* can be shut down (go tri-state) by virtue of the output enable
>(OE or OC) pin which is usually tied to the blanking clock (which in
>turn disables the lamp drivers). The latch allows the outputs to be shut
>down *without effecting* the data stored within those latches on a high
>transition of the blanking clock.
>
>The latch outputs will return to their previous states on the next low
>transition of the OE pin. The same goes for the solenoids and displays.
>This is exactly what WMS continue to do with WPC, but, it's unclear
>whether WMS generate an interrupt during this period indicating the
>outputs are off and it's okay to write new data to the latches (you can
>do this to the latch regardless of the state of the OE/C pin).
>
>Depending on what type of latch your using, the OE/C pin (if the device
>has one) can be either active low or active high of course - check the
>data sheet.
>
>There's another factor also missed here - the lamps are usually on a
>matrix, therefore, you only have *8 on* at any one time whilst the
>others are off anyway - they're multiplexed.

On Williams they are in a matrix. You pulse the bulb at higher than
rated voltage for roughly an eighth of the time and give them nothing
the rest of the time. The result is current surges beyond the rating
of the bulb but the effect appears to be normal brightness, unless a
driver shorts out.

The old Bally system didn't use a matrix, they used 60 independent SCR
drivers. The bulbs were fed their recommended voltage and current.
All switching was done at zero crossing.

Now, if you want to be a purist, you wouldn't even be driving the
bulbs with DC, you would use AC. This has to do with the "filament
notching" effect that happens on DC. But that is another subject all
by itself.

Clive Jones

unread,
Apr 5, 1997, 3:00:00 AM4/5/97
to

In article <33456147....@news.cedar-rapids.net>, Rodger Boots
<rlb...@cedar-rapids.net> writes
>

>Disagree all you want, but this is the way Williams did it and the
>result IS in fact higher peak currents which isn't good on anything.
>The only reason they even end up pulsing the bulbs is because they
>are driving them in a matrix. If a driver transistor shorts you end
>up with supernova light bulbs.
>That's the same power that was there
>before, only the duty cycle has changed. On the other hand, take the
>Bally constant-drive system, short out an SCR, and the result is an
>almost normal brightness bulb.
>

Point taken on the 'supernova' lamps, but, Williams games will run for
years without blowing lamps and there isn't a Bally system I haven't
worked on that I didn't have to change at least one or more of the
2n5060 SCR's - including the 6803 system.

Your mileage may vary...

Rodger Boots

unread,
Apr 5, 1997, 3:00:00 AM4/5/97
to Gerry Stellenberg

Gerry Stellenberg wrote:
>
> Ok, I think I'm finally understanding. Thanks for your patience... I'm
> fairly new at this kind of stuff.
>
> So, let me see if I've got this straight. In the Bally/Midway Beat the
> Clock schematic I have, the lamp driving circuit works like this: Whenever
> a power line zero crossing occurs, the 6803 controller is interrupted. The
> ISR must include a routine which pulses the SCR's of each lamp. Because we
> are now at the beginning of the 6.3 VAC cycle, the ground pulls current
> through the SCR's, through the lamps, from the 6.3 VAC source almost until
> the next power line zero crossing occurs. At this point, the cycle starts
> over. Is this correct?

Yes. Some games pulled some stunts to double up 2 independant bulbs on
each
SCR, but you have the concept for the original approach.

> So, in the older Bally games, the lamps are powered by a 6.3 VAC source.

Sort of. They take 6.3 volts AC and run it through a full-wave bridge
rectifier with NO filter capacitor. The result is unfiltered DC.
Adding
a filter would have kept the SCRs turned on---not what they wanted to
do.

> After reading your last USENET posting, I'm guessing Williams games (at
> least newer ones) use a DC supply to source the lamps.

As far as I know, yes.

> This brings up a power supply point. If I buy a relatively new Power
> Supply / Power Controller Board, will it have the 6.3 VDC power signal with
> which I can source the lamps?

Probably, as long as you supply a transformer winding.

HOWEVER (and this was my whole point about bulb stress) they do NOT use
6.3 volts. They have to have a higher voltage since they are only
giving
the bulbs power 1/8th of the time (slightly less, if you include
blanking).
I'm not exactly sure what voltage they do use, but I would guess it to
be
over 12 volts.

> Ok, now, being unfamiliar with the LED market, I'm going to ignore that
> possibility for a little while. I'll try to learn about those after I make
> sure I understand the lamp situation. I'll definitely be informed enough
> to make a good decision as to which to use before I start building the game.

Pity, power switching would be much easier using the LEDs. You wouldn't
need the higher power supplies (the 5-volt supply would do nicely),
driver
design would be much simpler since you'd only have 1/10th the current,
and
blocking diodes wouldn't be needed since the LED would do it's own
blocking.

> So, assuming I'm going to use lamps, I want to minimize the necessary
> wiring. Given that I'll be using 8255's, which will be present on my
> digital I/O board, it seems to make sense to use Clive's idea of driving an
> 8x8 lamp matrix.
>
> Therefore, one 8255 8-bit port will drive the rows, and the other will
> drive the columns. Let's say I want port A to source the rows and port B
> to sink the columns. I'll need to wire 8 darlington bases to the outputs
> of port A and use them to provide the lamps with the supply voltage. I'll
> then need to wire the other 8 darlington bases to the outputs of port B and
> use them to provide a path from the lamps to ground. This way, I can drive
> all of the rows with a data word describing which of the lamps in the
> current column need to be on. At the same time, I should turn the
> corresponding column on so that there is a direct path from power to ground
> through the lamps that should be on. I should run through each column each
> time (or every other time or so) I get an interrupt. Do I have this
> correct in my mind?

If you are doing matrixing run the lamp driving software as part of the
display driving software and run it off the display interrupt instead of
the power-line interrupt. This is about a 480 Hz MINIMUM interrupt
(60 Hz overall refresh X 8 columns).

> Will the aformentioned ULN2003's be useful in this situation? If not, do
> you know of any other package that might? I guess what I'm asking is will
> the ULN2003 sink the 250mA that the lamps need?

You'll be running too much current for a ULN2003 to handle. And you can
forget that 250 mA lamp current spec, too. At a 1/8 duty cycle the bulb
current will probably be over .5 amp.

> Also, will I need to add anything else to this circuit, such as resistors
> or diodes?

Each lamp will need a blocking diode if you use a matrix. A 1N4000
series
is a little slow to be running at this frequency---use a faster part or
live
with a slight "ghosting" of bulbs that shouldn't be lit glowing dimly.

I the ghosting does occur the diodes will probably overheat. This is
due to
a 1N4000 series diode not being able to turn off quickly so if it is
"on"
(from just having the bulb lit) and then you switch to the next column
it will
take a short time for the diode to turn off. During this time you are
pulling
a fair amount of current backwards through the diode---NOT good.

Of course you might very well get lucky and have it work just fine.

> Thank you so much.
>
> --
> Gerry Stellenberg g...@vt.edu
> Senior in Computer Engineering (540) 953-0683
> Virginia Polytechnic Institute and State University
>

Clive Jones

unread,
Apr 5, 1997, 3:00:00 AM4/5/97
to

In article <33456147....@news.cedar-rapids.net>, Rodger Boots
<rlb...@cedar-rapids.net> writes
>
>Disagree all you want, but this is the way Williams did it and the
>result IS in fact higher peak currents which isn't good on anything.

Where's your tangible evidence that this is effecting WMS system
resiliance Rodger?

>The only reason they even end up pulsing the bulbs is because they
>are driving them in a matrix. If a driver transistor shorts you end
>up with supernova light bulbs. That's the same power that was there
>before, only the duty cycle has changed. On the other hand, take the
>Bally constant-drive system, short out an SCR, and the result is an
>almost normal brightness bulb.
>

Yes, Williams fed the lamps 18 volts (and still do), as, the result of
sweeping the matrix at speed was a dimmer lamp - the answer was to make
the bulb appear as bright as a it would be running static at 6.3 volts
(or thereabouts) by boosting the supply voltage. I take your point that
a shorted transistor is bad news for the lamp on the receiving end, but,
the proof of the pudding is in the eating - I've got a draw full of
TIP42's (WMS) but I don't have any 2n5060 thyristors left (BLY), you can
draw your own conclusions from that.

Williams is just following an *electronics industry standard*, and I for
one cannot see a problem with it. It's common practice to sweep displays
whether it be LEDs, lamps, segmented displays or otherwise as it cuts
down the *component count* and the *immediate* power requirements
optimising the circuit design. Granted, the lamps will recieve in-rush
current of upto anything 10 times their nominal rating from a cold start
and that's a factor born of using filament lamps. You could also argue
that since the matrix is being swept at speed, that the bulbs have been
pre-heated ready for the next sweep since the filament does not have
sufficient time to cool to a great degree - reducing the in-rush
current. That doesn't apply to lamps that have been allowed to cool
through being switched off of course.

And here's some evidence... I have never seen a problem with WMS systems
blowing lamps on a regular basis or transistors, in fact, I can't
remember replacing any WMS lamp driver transistors (although I probably
have done a few??). So, I just called a friend of mine who repairs/sells
pins *everyday* of the week for a living (yes he's often working on
Sunday) and he swears that he can only remember a handfull of problems
with the WMS lamp matrix (across all systems) and even they were not
related to the transistors or regular lamp failures.

In short, WMS stuff was/is well designed - make sure you've got a bucket
full of SCR's for the Bally lamp matrix (and aux. driver board). :)

>
>The old Bally system didn't use a matrix, they used 60 independent SCR
>drivers. The bulbs were fed their recommended voltage and current.
>All switching was done at zero crossing.
>

Yes, I'm well aware of how they did it - unfortunately. :(

>Now, if you want to be a purist, you wouldn't even be driving the
>bulbs with DC, you would use AC. This has to do with the "filament
>notching" effect that happens on DC. But that is another subject all
>by itself.

But the lamps weren't AC driven, besides, you could argue a whole host
of other factors involved in the failure of lamps in pinball design
including vibration and the premature failure through DC notching of the
filament as you've pointed out, which by the way, it be interested in
seeing some figures on since Bally had a longer period of directly
applied DC - WMS pulsed their DC lamps by sweeping the matrix.

Gerry Stellenberg

unread,
Apr 5, 1997, 3:00:00 AM4/5/97
to

>Pity, power switching would be much easier using the LEDs. You wouldn't
>need the higher power supplies (the 5-volt supply would do nicely),
>driver
>design would be much simpler since you'd only have 1/10th the current,
>and
>blocking diodes wouldn't be needed since the LED would do it's own
>blocking.

Again, I was not discounting the possibility of using LEDs. I just
wanted to make sure I understood how the lamp driving circuit would
work before I moved on to something different. I believe I now do
understand the lamps and would like to begin a discussion of LEDs.

OK. So let's say I'm going to use 64 LEDs in my game. I guess they'll
have to be high-brightness LEDs so that they appear fairly bright from
the top of the playfield.

These LED's require a DC power supply of 5V, correct? Therefore, it
would be possible to simply connect the LED's to the outputs of any of
a number of latches or buffers and the ground them using the logic
ground. Will I need any current limiting resistors in this circuit?
How much current do the LED's draw?

Again, there are a number of possible ways to design this circuit. I
could use the matrix idea in much the same way the lamp matrix was
discussed (without the lamp driver darlingtons), or I could wire each
LED to the output of a latch. The difference would be that the matrix
would allow only 8 LEDs to be on simultaneously and it would required
refreshes. This is the 1/8th duty cycle. Not using the matrix would
mean the possibility would exist for all of the LEDs to be on at the
same time. Am I correct in assuming this would NOT be a problem
because of the much smaller current needs of the LEDs compared to
lamps? What configuration would you recommend?

I realize I temporarily ignored the idea of using the serial LED
driver you previously mentioned. Again, I am not forgetting about it
altogether. I just want to make sure I understand the way the LEDs
work before I begin a discussion about something else I don't
understand.

Thanks.
- Gerry

Rodger Boots

unread,
Apr 5, 1997, 3:00:00 AM4/5/97
to Gerry Stellenberg

Gerry Stellenberg wrote:
>
> >> Ok, now, being unfamiliar with the LED market, I'm going to ignore that
> >> possibility for a little while. I'll try to learn about those after I make
> >> sure I understand the lamp situation. I'll definitely be informed enough
> >> to make a good decision as to which to use before I start building the game.
> >
> >Pity, power switching would be much easier using the LEDs. You wouldn't
> >need the higher power supplies (the 5-volt supply would do nicely),
> >driver
> >design would be much simpler since you'd only have 1/10th the current,
> >and
> >blocking diodes wouldn't be needed since the LED would do it's own
> >blocking.
>
> Like I said, I certainly was not counting out the possibility of using
> LEDs. I just wanted to make sure I understood the way the lamp
> driving circuit would work before I moved on to something else. I'm
> pretty sure I've reached that point. So, I would now like to figure
> out how I can do the same thing with LEDs.
>
> Ok, so now let's suppose I'm going to use LEDs instead of lamps.
> LED's can use the logic 5 V supply, correct? So, all of the LED's can
> be wired to a buffer or latch and to logic ground. Will I need any
> current limiting resistors?

YES! But if you matrix them you only need 8 resistors.

> What do you think would be better (assuming 64 LEDs). Should I wire
> each LED to and output of an octal latch? In this case, the
> possibility exists for all LEDs to be on at the same time. Or should
> I create some type of matrix pattern to limit the number on to at most
> 8. I'm guessing that because of the much smaller current needs of
> LEDs when compared to lamps, having all 64 on at the same time
> wouldn't be much of a problem.

Using direct drive: One resistor per LED, can be driven right off
of an IC output. Software is simple. LOTS of wiring.

Using matrix: Two ICs or one PIA driving buffers to handle
higher current. 8 resistors handle entire matrix. Wiring simpler.
Software nastier, but if you already do display driving in software
display driving can be handled in same subroutine. Unlike bulbs,
LED matrix doesn't need extra diodes.

> I'm not very familiar with LEDs, but if I have a 1/8th duty cycle,
> would there be a noticable strobe effect?

Strobe effect is same as displays. Same as pocket calculators or
digital watches that used LEDs. ALL those examples are multiplexed
displays. The whole key is to refresh each column at least 60 times
a second so the eye won't see the flicker. So if you have 8 columns
and a 60 Hz refresh you simply make the interrupt 8X60=480 Hz.
Make it less and you will have flicker. Make it more and your
processor spends too much time handling interrupts.

> I realize I ignored your original solution of using the serial LED
> driver. Again, I want to make sure I understand the basics before I
> move on to something I haven't heard of before.

For outright simplicity and economical use of parts it's hard to
beat the matrix approach.

> - Gerry

Clive Jones

unread,
Apr 5, 1997, 3:00:00 AM4/5/97
to

In article <334630...@cedar-rapids.net>, Rodger Boots <rlboots@cedar-
rapids.net> writes
>Gerry Stellenberg wrote:
>>
<snipped>

>
>> So, assuming I'm going to use lamps, I want to minimize the necessary
>> wiring. Given that I'll be using 8255's, which will be present on my
>> digital I/O board, it seems to make sense to use Clive's idea of driving an
>> 8x8 lamp matrix.
>>
>> Therefore, one 8255 8-bit port will drive the rows, and the other will
>> drive the columns. Let's say I want port A to source the rows and port B
>> to sink the columns. I'll need to wire 8 darlington bases to the outputs
>> of port A and use them to provide the lamps with the supply voltage. I'll
>> then need to wire the other 8 darlington bases to the outputs of port B and
>> use them to provide a path from the lamps to ground. This way, I can drive
>> all of the rows with a data word describing which of the lamps in the
>> current column need to be on. At the same time, I should turn the
>> corresponding column on so that there is a direct path from power to ground
>> through the lamps that should be on. I should run through each column each
>> time (or every other time or so) I get an interrupt. Do I have this
>> correct in my mind?
>

Yes, you've got this bang-on Gerry. The 8255 will source 2ma@3v for the
darlingtin drive from each port so you can write out a words worth of
data to the matrix via the drivers.

In it's simplest form you'll need a table of 8 bytes with each bit set
corresponding to the active lamp to be displayed - 1 bit per lamp. Port
'a' is your row sweep byte so you can update the data in the 8255 output
register directly but you'll need to load the column byte to be
displayed from the table into port 'b's output register. We'll call the
column byte the 'lamp status' byte to make things easier.

If you want to implement psuedo software controlled blanking use a line
from port 'c' (PC0 for example) and *AND* it (use two 7408s or whatever
- 8 gates) with the column driver transistors. When that port 'c' line
is high, the column transistors should be logically ANDed (via the
7408s) with the data from your lamp status byte indicating which lamps
are 'on' by the active bits/switched on column transistors.

So,- <interrupt> assert blanking (logic 0), rotate the row bit, pull the
next lamp status byte from the table and move it to port 'b', negate the
blanking (logic 1) </interrupt [RTI] >. Then do it all again on
consquetive interrupts until you've done the 8 sweeps. Can you get the
interrupt down to 2ms per event? If not, you'll be sweeping the matrix
at 15Hz - too slow, you'll see the strobing.

I'm not keen on the idea of hanging the darlingtons off the ports
directly (call me anal but I don't think it's 'clean' enough) - your
offering a chance of your I/O card going up in smoke if something goes
horribly wrong so put 1n4004's or greater in series from the ports/gates
to the bases.

I suggest that if you wish to build your own driver electronics then
copy a WMS system 11 or WPC etc. as the technology is proven and will
save you the hardware debugging. Initially, you'd probably want to just
drive the matrix with a few LEDs connected to the driver circuits to get
it running (1 per row for example). Use a variable resistor so you can
overdrive the LEDs during the sweeping to get them up to a brightness
you can work with - you'll be able to work on the code and implement
flashing or any other effects before moving to filament lamps.

As for the matrix diodes themselves - you should have no problem using
1n4004's as the recovery time should be more than adequate, but, if your
really concerned you could move to 'UF' series 4004's as they have an
_U_ltra _F_ast recovery time (stupidly quick for a silicone rectifier -
50ns). The 1n/UF4004 has a repetitive reverse voltage breakdown of 400
volts so you'll have no problems here either.


My work here is done.

Clive Jones

unread,
Apr 6, 1997, 4:00:00 AM4/6/97
to

In article <3346DD...@cedar-rapids.net>, Rodger Boots
<rlb...@cedar-rapids.net> writes
>Gerry Stellenberg wrote:
>>
<snipped>
>

>> What do you think would be better (assuming 64 LEDs). Should I wire
>> each LED to and output of an octal latch? In this case, the
>> possibility exists for all LEDs to be on at the same time. Or should
>> I create some type of matrix pattern to limit the number on to at most
>> 8. I'm guessing that because of the much smaller current needs of
>> LEDs when compared to lamps, having all 64 on at the same time
>> wouldn't be much of a problem.
>
>

No!! NEVER drive LEDs using TTL gates as a source of power - you'll load
the outputs and the gates won't have the drive anyway and if it works at
all it'll probably last about 5 seconds. Hanging LEDs off the octal
latches is going to be *really* bad news - you'll need at least 10ma per
LED which the latches can't source (and neither can your 8255's).

For example: Use the 8255 to drive the bases of small signal transistors
(8 off - 1 per row) *sourcing* at least 80ma to the eight LEDs for each
row, then use a gate with an *open collector* or *open drain* output for
each LED in those columns to *sink* that 10ma current. The ULN-2803 sits
nicely here as it's octal and will easily handle that 10ma/LED sink
current.

It did some testing previously with LEDs for this application the
results weren't really appealing. You can purchase 'ultrabright' LED's
in most colours (I'm not sure whether anyone has been able to develope a
white LED yet) but they tend to focus the light into a point - very
noticable when under a lamp insert as the light doesn't tend to diffuse
outwards to any great degree without about a 6 inch stand off from the
insert. Using 'starburst' lamp inserts will help here, your mileage may
vary of course.

>
>> I'm not very familiar with LEDs, but if I have a 1/8th duty cycle,
>> would there be a noticable strobe effect?
>
>Strobe effect is same as displays. Same as pocket calculators or
>digital watches that used LEDs. ALL those examples are multiplexed
>displays. The whole key is to refresh each column at least 60 times
>a second so the eye won't see the flicker. So if you have 8 columns
>and a 60 Hz refresh you simply make the interrupt 8X60=480 Hz.
>Make it less and you will have flicker. Make it more and your
>processor spends too much time handling interrupts.
>

I couldn't let this go by. :) Despite an interrupt being invoked every
480Hz that's *NOT* how long the CPU spends processing that interrupt.
The length of the interrupt service routine depends on how long it takes
the CPU to execute that routine in clock cycles before encountering an
RTI (ReTurn from Interrupt) where the program control is handed back to
it's previous task before the interrupt was invoked.

Since your system performance is unknown (as is the length/timing of
your ISR) you could/should have boat loads of time. The routine only
takes a hand full of lines of code so the execution should be pretty
quick depending on what language your using and the speed of execution.
Plus, your the latching the lamps/LEDs between interrupts cutting out
the processor overhead.

Also, if your system uses a method of prioritising interrupts, your
interrupt could be asserted at the same time as another - the highest
priority interrupt will be processed first, and if it's not yours, it
will be held over. Since the NMI interrupt cannot be masked, it is
usually given the highest priority.

Gerry Stellenberg

unread,
Apr 6, 1997, 4:00:00 AM4/6/97
to

>Yes, you've got this bang-on Gerry. The 8255 will source 2ma@3v for the
>darlingtin drive from each port so you can write out a words worth of
>data to the matrix via the drivers.

Thanks, Clive. I hope to try out some LEDs in the near future to see
if they will illuminate enough to be worthwhile. I'm hoping Digi-key
will send me some samples of the diffused high-brightness LEDs. If
they aren't bright enough, I'll go with lamps.

>I suggest that if you wish to build your own driver electronics then
>copy a WMS system 11 or WPC etc. as the technology is proven and will
>save you the hardware debugging.

Can you recommend a game whose schematic I should peruse? Of course,
I'd probably have to order it from somebody and maybe wait a while
before I got it, but it would definitely be more informative than the
Beat the Clock schematic I've been looking at.

>My work here is done.

Thanks for all of your help. I hope you'll be a willing participant
in the coil driving discussion... after I start it!

- Gerry


AReizman

unread,
Apr 7, 1997, 3:00:00 AM4/7/97
to

At Bally we had no problem with the 44 lamps running of the SCRs. The
bayonet sockets we used were another problem. Apparently the resitance of
the seam between the cup and bracket of the bulb socket would increase
over time preventing the bulb from turning on. Many of the older Bally
games require replacement of the bayonet lamp sockets to work reliably.
The wedge base 555 bulbs had no socket problems but the early vintage
bulbs would bur out quickly until GE found and corrected the problem a
year later.

Phobes

unread,
Apr 7, 1997, 3:00:00 AM4/7/97
to

>No!! NEVER drive LEDs using TTL gates as a source of power - you'll load
>the outputs and the gates won't have the drive anyway and if it works at
>all it'll probably last about 5 seconds. Hanging LEDs off the octal
>latches is going to be *really* bad news - you'll need at least 10ma per
>LED which the latches can't source (and neither can your 8255's).

eh, National makes an octal tristate TTL latch capable of sourcing 32ma and
sinking 64ma per output. works very well for driving LEDs. 74ABT374. go
to national's web site and they'll send you a handful of samples for free.

Of course, that being said, even 32ma source/64ma sink is not enough to
drive a whole matrix row of 8 superbright LEDs, so a transistor solution is
probably a better for a matrix arrangement. Keep in mind that you'll also
need to drive each LED with more current than a continuous method because
it's only going to be on for a fraction of the time (1/8) and you want the
same effective brightness.



>in most colours (I'm not sure whether anyone has been able to develope a
>white LED yet) but they tend to focus the light into a point - very
>noticable when under a lamp insert as the light doesn't tend to diffuse

LEDTronics makes an LED cluster they call "white", available in several
flavors of "white." Since LEDs really only emit in a vary narrow range of
wavelengths, you really just get a strange "white" by mixing as many colors
of LEDs and trying to balance the net effect to look something whitish.
www.ledtronics.com. They also sell all sorts of form factors for LEDs,
which have various angles of diffusion and lenses to minimize the focused
light effect. They also sell LEDs cased in the same bayonet mounting and
voltage as the GE44 and GE47 lamps. Of course, these aren't the bargain
basement LEDs...

larz
pin...@phobe.com

Rodger Boots

unread,
Apr 8, 1997, 3:00:00 AM4/8/97
to

Oh, I forgot, those bayonet-based LEDs were being sold by Mendleson
Electronics, a surplus outfit. I'm not sure, but I think the polarity
is backwards for use in a regular pinball. And since they have their
own internal resistor I would think that running them in a matrix
(with the higher voltages and currents involved) would damage them,
not to mention being non-ideal since you don't get to pick the
resistor yourself.

But am probably wrong about that, now that I think about it.

>larz
>pin...@phobe.com


Rodger Boots

unread,
Apr 8, 1997, 3:00:00 AM4/8/97
to

On Mon, 07 Apr 1997 00:12:38 -0700, om...@phobe.com (Phobes) wrote:

>
>>No!! NEVER drive LEDs using TTL gates as a source of power - you'll load
>>the outputs and the gates won't have the drive anyway and if it works at
>>all it'll probably last about 5 seconds. Hanging LEDs off the octal
>>latches is going to be *really* bad news - you'll need at least 10ma per
>>LED which the latches can't source (and neither can your 8255's).
>eh, National makes an octal tristate TTL latch capable of sourcing 32ma and
>sinking 64ma per output. works very well for driving LEDs. 74ABT374. go
>to national's web site and they'll send you a handful of samples for free.
>
> Of course, that being said, even 32ma source/64ma sink is not enough to
>drive a whole matrix row of 8 superbright LEDs, so a transistor solution is
>probably a better for a matrix arrangement. Keep in mind that you'll also
>need to drive each LED with more current than a continuous method because
>it's only going to be on for a fraction of the time (1/8) and you want the
>same effective brightness.

A simple, but overlooked device that can be used as a power inverter
is the old 555 timer. Just connect pins 2 and 6 together and use that
for the input and use pin 3 as the output---good for about 300 mA.

>>in most colours (I'm not sure whether anyone has been able to develope a
>>white LED yet) but they tend to focus the light into a point - very
>>noticable when under a lamp insert as the light doesn't tend to diffuse
>LEDTronics makes an LED cluster they call "white", available in several
>flavors of "white." Since LEDs really only emit in a vary narrow range of
>wavelengths, you really just get a strange "white" by mixing as many colors
>of LEDs and trying to balance the net effect to look something whitish.
>www.ledtronics.com. They also sell all sorts of form factors for LEDs,
>which have various angles of diffusion and lenses to minimize the focused
>light effect. They also sell LEDs cased in the same bayonet mounting and
>voltage as the GE44 and GE47 lamps. Of course, these aren't the bargain
>basement LEDs...

The LEDTronics part he's talking about is probably the multi-color LED
that has red, green, and blue chips in it. You fire all three at the
right current and get white out. Vary the currents and get any color
you want. I suspect the brightness to be on the low side, though.

Cree made a similar part that used to be in the Digi-Key catalog.
Alas, Cree isn't sold by Digi-Key any more.

>larz
>pin...@phobe.com


Mike :FX: Morrey

unread,
Apr 8, 1997, 3:00:00 AM4/8/97
to

>>in most colours (I'm not sure whether anyone has been able to develope a
>>white LED yet) but they tend to focus the light into a point - very
>>noticable when under a lamp insert as the light doesn't tend to diffuse
>LEDTronics makes an LED cluster they call "white", available in several
>flavors of "white." Since LEDs really only emit in a vary narrow range of
>wavelengths, you really just get a strange "white" by mixing as many colors
>of LEDs and trying to balance the net effect to look something whitish.
>www.ledtronics.com. They also sell all sorts of form factors for LEDs,
>which have various angles of diffusion and lenses to minimize the focused
>light effect. They also sell LEDs cased in the same bayonet mounting and
>voltage as the GE44 and GE47 lamps. Of course, these aren't the bargain
>basement LEDs...

I've seen the 'white' LEDS in a catalog.. The ones I saw had
four elements in them: 2 blue, one red and one Green. By mixing input
values, you can get assorted colors, including a violet.. They were
rather expensive however..


Mike..

Andrew Dudinsky

unread,
Apr 12, 1997, 3:00:00 AM4/12/97
to

Actually, the "White" is really a washed out yellow... It looks like
a light bulb being run at 1/2 its rates voltage. Currently there isnt a
true WHITE led on the market.


One thing to be concerned with, you will have to match brightnesses of
the led's. Various colors are brighter/darker.

Common colors red, yellow, orange, green, blue.

Peter Clare

unread,
Apr 18, 1997, 3:00:00 AM4/18/97
to

In article <qA1IJjCJx$QzEwg$@clivej.demon.co.uk>, Clive Jones <cli...@clivej.demon.co.uk> wrote:
>A octal D-type latch such as an LS374 can be selected using the *clock*
>pin alone - it does *not* have a tri-state bus interface and therefore
>hanging it directly off the uP bus will be bad news.

<snip>

I'm not sure that I follow your argument here, Clive. It's the *inputs*
to the latch that will hanging off the data bus. Doesn't really matter
whether the outputs are tristate or not. What does matter is the fan out
of whatever is driving the data bus and the number of devices (I/O chips,
memory etc) hung off it. A '245 buffer between the processor and the
rest of the data bus should sort out the bus drive issue.

For a '374 latch, I would use a chip select signal applied to the clock
input and either leave the output always enabled, or use this input for
blanking as you suggest.


<various discussion on PIA and PIO devices snipped>

Whilst on this subject, I've wondered why the designers of the early
SS hardware had such a propensity to use 6820/6821 PIAs. Maybe they
had shares in Motorola? Just look at the number of PIAs on a System 11
board - see what I mean? In a lot of cases the interrupt facilities
provided by a PIA are not used. At the time (early 80s) PIAs were costly
devices. It seems to me that most of these PIAs could be replaced by
'244 buffers for inputs and '374 latches for outputs (plus
a little extra address decode logic). I doubt that this would have
taken up much more (if any) board area and would have been a lot
cheaper. Any pinball hardware designers of the time care to comment?

=====================================================================
Pete Clare |
C R L | Telephone: +44 181 848 6521
Dawley Road, Hayes | Facsimile: +44 181 848 6565
Middlesex UB3 1HH | Email: pcl...@crl.co.uk
UNITED KINGDOM | WWW: http://www.crl.co.uk/
=====================================================================

0 new messages