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_at_p850ug1.demon.co.uk>
To: <classiccmp_at_classiccmp.org>
Sent: Friday, June 09, 2000 4:07 PM
Subject: Re: Wirin' up blinkenlights
> >
> > 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....
>
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.
> >
> > 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.
>
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.
>
> -tony
>
Received on Fri Jun 09 2000 - 21:48:56 BST