Re: Basic Stamp controlled pinball machine

Comments inline again...

"EvilOompaLoompa" <jukingeo@xxxxxxxxxxxxx> wrote in message
news:516129ab-8e91-432d-9aee-e68528ca7291@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Mar 15, 11:18 pm, "Mark Clayton" <spamuser1...@xxxxxxx> wrote:

There isn't a special driver. The DC-16 or expansion board I
mentioned is basically a way to get more than 16 control lines into
the BS-2. DC-16 works by taking a serial instruction from the BS-2
and having that instruction access the 16 outputs. Now all the while,
this will only take up one I/O line on the BS-2. While both the BS-2
AND the expansion board have ULN2803's for output control, the current
capacity isn't enough to drive lamps directly. So while the DC-16
expansion board may seem like a redundant device, it isn't. It is a
way to get more outputs on a BS-2.

Technically expanded to the max I can run 4 DC-16 boards off of ONE I/
O line of a BS-2. That is 64 outputs right there. Now put a set of
four on EACH 16 outputs for a total of 64 DC-16s. So that now becomes
1024 outputs.

So this may expand your I/O, but it does it at the cost of latency.
Sending the I/O commands serially to the DC-16 may just be too
slow for a real-time control application running on the Stamp.

Are you still with me? Now if I put the Gottlieb System 1 board on
each DC-16 accessing it to the max using the 36 derivative outputs
from the matrix and three of solenoid drives. So with using 39 of the
Gottlieb board outputs and each of the 64 DC-16 boards hooked up to a
Gottlieb board, I would have access to a total of 2496 outputs....All
from one BS-2.

I don't know how locked you are into this DC-16 thing. There are
lots of other ways to expand your parallel output capability, and
they don't need to use the DC-16's slow serial I/O protocol. See below.

Without the DC-16 board and going directly to the BS2, I would only be
able to hook up one of the Gottlieb boards. It MAY be enough for a
simple game, but I would like some additional flexibility put in the
system.

So wrapping that up...the DC-16 isn't a driver...it truly is an
expansion board in which I am able to get more than the 16 outputs out
of the BS-2.

Can I do away with the DC-16? Sure, but I would need a more capable
driver board then. Something that would make better use of the output
lines. A 7 by 7 matrix would yield me 49 outputs. Why not 8 by 8?
well, keep in mind that I do need to access the board serially from
another BS-2 and that needs one port. If I decided the sound would
run off of the board then I have to send that information out another
line to the sound board. So I would need two lines for the serial I/
O. So that would leave me with 14 lines, which could be split into a
7 by 7 matrix.

It seems that you're trying to keep things simple, but you are being
hampered by the limitations of the BS-2. Adding I/O complications
will make your programming more complex and if you already
max out your I/O just in the planning stage, you're more likely
to get stuck down the road.


<<> A ULN2803 can only sink 500 mA, so you can't drive much of a coil
with it, and if you're connecting to the TTL side of the pinball driver
board, you don't need drivers at all on your board.>>

Look at the specs carefully on that IC. That is the rating for ONE
output driven at a given time. That figure changes for multiple
outputs. Worst case scenario is that all 8 are on and then the
current rating drops to 125ma. This clearly isn't even enough to
drive a #47 bulb.

So it's no good as a driver on its own, and using an existing driver
you just need a TTL interface. So buh-bye to the ULN2803's.


Given the fact that I know that these ULN arrays will not drive
pinball components, I only have two options, either use a more
powerful version of the ULN array (which I don't think exists) or use
a pinball driver board. Thus it is a no brainer that I am going to
choose the latter. But as I said above, the main reason why I would
still use the DC-16 expansion board is because of the serial
addressing capability.

The more powerful version of the ULN2803 are discrete Darlington
driver transistors, and that's already what's in use on the Gottlieb
driver board. So there's no reason to re-invent the wheel.

<< It doesn't matter if you
have 16 or 40 outputs. You can always multiplex the outputs to
create as many discrete I/Os as you need. That's what a 6820 does,
for example.>>

Explain the 6820.

6820/6821 are a microprocessor peripheral chip used to provide multiple
parallel I/O ports. It's commonly called a PIA:
http://en.wikipedia.org/wiki/Peripheral_Interface_Adapter

It's one example of how you can get at least 20 I/O pins from
an 8-bit bus-connected device. The Bally CPU board uses two of them.



<< > The other day I came across a schematic for a Gottlieb system 1
driver
board and I thought this board could make my life easier. For one,
because it is a pinball machine board, it certainly would have enough
capability to drive the bulbs and coils I would need to use.

Yes, it would, and it has a simple TTL interface.>>

Yup, my only qualm with this board is that I am not sure if 36 lamp
outputs and 8 solenoid drives would be enough. Now TWO of these
boards would give me 72 bulbs and 16 solenoid drives. That is most
certainly enough. But thusfar, this is the only board I looked into
because it didn't have anything fancy. As you said it was a direct
TTL interface and already had demux capabilities on board. So the
board is a good choice in terms of being able to drive what I want to
do. But will the 36 lamp and 8 solenoid drives be enough?

I guess I could say yes to that question IF, and only IF my test
playfield just happens to be from a System 1 Gottlieb as well.

As I said, thusfar this was the only driver board I looked into
because I just happened to have a schematic for it. Well, I have a
Williams schematic too, but their drivers are on the main board. The
Gottlieb system one had a totally separate driver board. So that is
kind of something that I would like to use...but with more output
capabilities.



<<> > Now using just one Prop-2 (Basic Stamp 2) and one DC-16, I can
connect
the driver board to the outputs of the DC-16 and still use the single
output serial interface on the Prop-2. The Gottlieb System 1 driver
board already has a matrix in place. It has 36 lamp outputs that are
addressable via a 9 by 4 matrix. Thus 13 of the DC-16 channels would
be used to access the 36 lamps. Now there are also an additional 8
coil drives. So I have 3 pins left over from the DC-16 and I would
need 5 more pins off of the Prop-2.

It's not really a matrix, they lamps and coils are individually
addressed.>>

Ok, I left one word out. An addressable matrix then.

<< All you need are a four-bit data bus and nine individual
strobes. You could further reduce the number of I/Os needed by using
a 74154 and then you'd only need four I/Os to generate your 9 strobes.>>

What is a 74154? What does it do? For some reason though that number
looks familiar.

There's one on the Gottlieb CPU board. It's the chip that generates the nine
strobes for the driver board. It only takes four CPU signals into the 74154
to get all the outputs that you need. The 74154 can generate 15 strobes,
so if you wire up your own 74154 you will have six strobes left over, which
you could use to control a second Gottlieb driver board. The four data lines
would go to both driver boards in parallel.


You want to tap right into the CPU chip socket with a Basic Stamp?

It's absolutely possible. The 6802 microprocessor can be removed and
you can patch in to the 8-bit data bus and the necessary control lines
in order to directly control all of the I/O peripherals as-is. Most acid-damaged
boards have problems with the 6802 reset circuit or the NVRAM, neither of
which you would need to function. You would then need a working
zero-crossing interrupt, but that circuit is already on the Bally CPU.>>

Soooo you are saying that you would only need 8 lines going directly
into an existing MPU? Ok, now you have my attention...Keep talkin'.
Now the old program is on the existing ROM... I am assuming you have
to pull those, correct?

You need a few more than 8. You need 8 data lines, and you need to drive
a few bits of the address bus and some control lines. You may need to
generate a clock as well. You could read the ROMs if you control enough
address lines, but there's no reason to. All you need to do is control
the I/O and you can ignore the rest.


<<> > So you are suggesting I used a regular PC?

No, I'm not suggesting that you use a PC at all. I'm suggesting that
you could use the PinMAME source code to tell you how to program
the built-in peripherals. Once you have that info (e.g. the memory addresses
of all of the peripheral devices), you can write your code however you like.>>

How do I get the information from PinMame into the game? You lost me
on this one.

The information has to go into your brain. If you take that route, you need
to know where in memory all of the I/O ports are wired. Then your code
has to be written in a way to wiggle the correct address and control lines
to access the I/O device that you want. You'd be using the existing I/O
architecture of the Bally CPU, so you need to know what it is. You can
find out what it is by reverse engineering the schematics, but that has already
been done and is manifest in the PinMAME source code. So if you look
at that, and you can understand C declarations, you can see where everything
is mapped in memory.

Ok, so it looks like you are on to something with using a main MPU
board. With the need only for an 8 line or 11 line buss I wouldn't
need the DC-16s

Well, you'll need more than 11 lines. Probably more like 14 to 16.


But, now the question remains on how to handle the input switch matrix
AND the output together. I would still think you would need separate
BS-2s for that.

That's another strike against the BS-2. It's just not very powerful. The lowly
30-year-old 6802 in the game had no problem doing everything. You said that
you wanted to make it easy, and having some CPU overkill is a good way to
make things easier.


<<> As for the LCD, dot-matrix LCDs with RS-232 serial interfaces are
a commodity
product. If your Basic Stamp has a serial port on it, all you need to do
is lash them together with that and you'll have a minimum of DMD resolution
for scoring and graphics.>>

The basic stamp doesn't have a port per say to control outside
devices. (there is one for connection to a PC for programming
purposes though). However, there is a SERIN and SEROUT command and
you can send serial data out any of the 16 outputs and also the
converse is true, you can set any of the 16 lines to be a serial
INPUT. So that is how you can get more than one Basic Stamp to talk
to one another or other devices...such as the DC-16 I mentioned above.

So while the Basic Stamp can communicate on a serial connection...I am
not 100% sure that it is RS-232 compatible.

Well, you have your choice or parallel or serial LCD displays. Some with
serial ports probably accept TTL-lever serial data, and if you don't need any
hardware rate control, all you need is the serial out line anyway, assuming
the thing can do standard UART timing.


<<> > Again, I am looking for something simple, reliable, easy to set
up and
easy to program and reprogram.

<<> Well, the simplest method isn't cheap, so your budget may come in
to play.
If I wanted "easy to program", I'd use a PC and a PB-2000.>>

Show me a place where I can get it for $300 or less, and I will go
that route. But $500 is a bit much. I can buy a full PC for that.

Put in a double-
headed display card and the second display could be for the game.
The Basic Stamp series to have too many limitations.>>

I will agree with you there. But again, I am not going to create
something as ambitious as what the guys did with the AC/DC machine.
That is out of the question and it is out of the budget too.

But if I did stick with a system that is based off an EM game's
playfield or an early SS machine such as the early Gottliebs..would a
Basic Stamp (or two or three) work?

All I can do is repeat what I said in my first reply. The Basic Stamp
platform is too limited to do this without having to jump through lots
of hoops. All of this will make the system complex, which is not what
you wanted. And in the end, it may not even work because of the
speed of the Basic Stamp interpreter and possible I/O bottlenecks
caused by the I/O expanders.


<<> BTW, Visual Basic is OK, but it's a dead-end product. They are
migrating
to .NET (Microsoft has a free SDK) if you don't mind dealing with the dark side.>>

What do you suggest as a programming too for a PC based system then?

I can program in C and assembly, and I have experience writing real-time interrupt
driven software under Windows and for a number of microprocessors and DSP chips.
I can't make a tool suggestion for you unless I knew what your background is.
If you want to create a Windows executable, the free .NET SDK is probably
a good way to go. If you're comfortable with Linux and C, the programming
tools are already built in.

You might want to take a look at microcontroler evaluation boards and see if there's
one that suits your purposes. They are cheap (usually subsidized by the chip maker),
and the tools are good and almost always free. The AVR series from Atmel
has a very active developer community (http://avrfreaks.net) and there are lots
of choices for hardware and software. Almost any chip in the AVR8 family
will out-perform the BS platform by far, and could easily handle the job.


Thanx for the excellent discussion...this is getting veddy
interesting.

E.

Keep us posted!

-Mark
--
http://pinballpal.com


.

Relevant Pages

  • Re: Basic Stamp controlled pinball machine
    ... So this may expand your I/O, but it does it at the cost of latency. ... If you are using a Basic Stamp 1, ... But for output control, I don't think that a few milliseconds would ... DC-16. ...
    (rec.games.pinball)
  • Re: Explain this about threads
    ... Basically I'm trying to do synchronous communication with the parallel port. ... I cannot control the delays that other processes and task switching introduce so since its beyond my control I have to ignore it. ... The data transfer rate on a parallel port is a matter of handshake protocol between the port and the device, basically it's the device who decides the rate. ... You can't accurately time the IO transfer rate, all you can do is insert waits in your code user mode or in a driver driver) and as such define a top level rate but no lower rate! ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Power Management framework proposal
    ... A power policy management framework doesn't need a unified framework (I ... I can see that if things really are different then it's worth doing different things to control them. ... to have any ability to control the mode of anything at runtime requires that the code doing so must have specific knowledge of the driver in question. ... 50 35 quarter power to the backlight ...
    (Linux-Kernel)
  • Re: Motorist killed by cyclist?
    ... caused a motorist to loose control and crash and be killed, ... Because, as the driver, they are in control of a potentially lethal ... against vulnerable road users. ... blame when struck by a driver and I subscribe to that idea, ...
    (uk.rec.cycling)
  • Re: Busy painting her nails, strikes and kills motorcyclist.
    ... driver may and may not do while driving. ... fully control the vehicle. ... plus the added distraction of trying to type ... Spelling something out in the law doesn't help; ...
    (rec.motorcycles)