9 Jun
2000
9 Jun
'00
10:48 p.m.
You'll have to sell me on this one, Tony. blinking the lights in sync with
a simulator via EPP is dirt-simple and very fast. I2C requires either
hardware or time-consuming software to generate, and generating and
debugging the software will consume a lot of time too. Further, it requires
lots of specialized ( I haven't got any of those parts here . . .) hardware
at the receiving end, and I have lots of parts . . .
The EPP is infinitely extensible, i.e. it's possible, though unrealistic, to
build a system with 64K 64K-bit ports all controlled by a single PC from its
parallel port. The thing thats beautiful about that is that it's possible
to build the system as wide, or deep, as you like without using any
different hardware at the PC end.
More below ...
Dick
----- Original Message -----
From: Tony Duell <ard(a)p850ug1.demon.co.uk>
To: <classiccmp(a)classiccmp.org>
Sent: Friday, June 09, 2000 4:07 PM
Subject: Re: Wirin' up blinkenlights
You don't need a bit-level definition beyond the standard, since all EPP
ports are defined/characterized in IEEE standard 1284. There are dozens of
sites that provide details and code examples on the web.
I'm not familiar with the 11/45 FP. Does it have receivers that can get by
with the less-than half milliamp source and little more than a single
milliamp sink current of these devices ( one port may drive 2 mA . . . ??)
I don't know how well the 6821 or 8255 like driving cables. I've never
tried it because they always were buffered in applications I've studied. In
fact, I've found the buffers normally work more conveniently than the LSI's
they serve, so I normally do things with TTL/CMOS logic and leave out the
fancy LSI's unless there's a specific requirement (in writing) for them.
>
> There are plug-in boards that provide an extra SPP/EPP/ECP port, which
is
> safer than simply using the motherboard-resident
one. That would be
less
> trouble if you were to break it than would be the
one on the
motherboard.
>
> The EPP port is more desirable, IMHO, simply because it isolates your
> "hobby-project" from the inards of the computer. It also provides a
handy
> connector, and a simple protocol by which to
provide yourself with up to
256
> I/O ports in either direction, without having to
open the box except to
plug
The other possibility (which is _very_ easy, and fast enough for
human-readable lamps and switches) is to bit-bang I2C over a couple of
lines of the printer port (you need 1 input (data in) and 2 outputs (data
out and clock out) -- you don't need the clock input for most common
devices). Then hang a few PCF8584 and PCF8584A chips off it (each is a
single 8 bit I/O port, and you can have 8 of _each_ on a single I2C bus).
> in the parallel port card. If one happened to come with a DLL with
which
you can write
WINDOWS code for your port, so much the better!
Well, if you _must_ use that so-called OS, I suppose so... Personally,
I'd rather have a linux system, a copy of gcc and a bit-level definition
of the registers on the card....
>
> One rather important aspect, of course, is that the printer port can
really
> drive the properly terminated cable, while a
"normal" MOS LSI for
parallel
That is, alas, not always the case. A lot of printer ports have pretty
poor drive characteristics. Maybe some modern ones (particularly
high-speed/EPP/etc ones) are better.
I think you may be misinformed, here, Tony. The original port (LSTTL) was
CERTAINLY able to drive a cable of up to 20' length, though it wasn't
recommended. The extremely popular 82C11 that occupies about two thirds of
the pre-IEEE-STD-1284 port boards I have lying about, drives harder than the
original TTL version after which it is patterned. The TTL used by the
original PC was probably the least hefty driver set ever used on the PC
printer port.
I/O, e.g. 8255, 6821, etc, can't.
Yes, but for this application (driving an 11/45 panel) you need to drive
normal TTL loads not that fast.
-tony