[rescue] Parallel ports [was Re: Slightly OT: ?Bad Cap Saga]

[der Mouse]

>> In my particular case, no, largely because I have so few machines
>> with working USB.
> And those machines don't have parallel ports, either?  :>

Most of them have or can be given at least one, yes.

At present.

As these machines fail, I will gradually lose the capabilities they
provide.  Perhaps I have enough spares to last the rest of my life, but
perhaps not, too.

>> If someone has a real USB parallel-port interface, as opposed to a
>> USB printer interface that speaks parallel-port printer protocol out
>> the printer end, I'd be interested.
> What do you think "parallel port printer protocol" is?

My impression of it is, basically unidirectional output, pulsing STROBE
for each byte output, with rudimentary output flow control based on
signals like "out of paper".  But I don't use it, so that's quite
likely missing some important aspects.

Yes, it is a defensible position that I'm abusing printer interfaces
when I use them as parallel ports.  The traditional hardware is
actually both at once, by accident of history, and it's the parallel
port I'm talking about missing, not the printer interface.

> Centronics has defined how the interface is supposed to work.  If you
> are taking advantage of a particular bastardized implementation of
> that interface, then how can you complain that the "new interface"
> isn't as good as the old?

Because it doesn't support something the old one did, of course.

>> Not really; the application-facing interface presented by a USB
>> stack is substantially more complicated than that presented by a
>> serial port.
> You can't say?
>     mystring[] = "Aseriesofbytecodes\022\033\044\055"
>     print(mystring);

I've moved small fractions of my applications into the kernel, inside
the lpt driver.  This was feasible because I was talking to, y'know, a
parallel port: write bits here and they show up on these wires, read
from there and you get the signals from those wires.  If I'd had
something like USB getting underfoot, this would probably have been
somewhere between annoying and impossible, instead of trivially easy.

>> This goes back to my remark about the difference between a parallel
>> port and a printer interface that happens to speak parallel-port
>> printer protocol.
> So, you're not lamenting the loss of a parallel port but, rather, the
> loss of a particular *style* of parallel port implementation!  <grin>

No...it would be more accurate to say that I'm not lamenting the loss
of the printer interface (which, as various people have pointed out,
hasn't really been lost), but rather the loss of the parallel-port
implementation of the printer interface.

> Why should a manufacturer have to keep implementing their parallel
> ports the same way you want them?

They don't, of course.  It's not that any particular vendor doesn't
that bothers me; it's the apparently-total loss of them across the
board that bothers me.

What someone, Gadi I think, recently said leads me to think that it may
not be quite as total a loss as I thought.  This gives me some hope.

> E.g., when I put a parallel (printer) port in a piece of equipment,

If you're putting in a printer port, do it however you like as long as
it speaks printer.

If you're putting in a parallel port, make it a parallel port, dammit!

Just because the same hardware has served for both at once in the past
does not make them the same thing.  (Admittedly, it doesn't help that a
lot of people confuse the two, including many people selling USB
"parallel port" interfaces.)

>> whereas a real parallel port I can talk to even with discrete
>> transistors if I want to.
> Well, in a few years, you'll be stuck with a *computer* that doesn't
> have those things.

I don't think so.  I've got enough spares to last more than "a few
years", absent something catastrophic like a fire where most of them
are stored.  But yes, it'll suck if all my spares die before I do.
It'll _really_ suck if all my spares die before I do and nobody has
come up with a sane implementation of the parallel-port concept for
then-modern hardware.  (Which, as I remarked above, I now suspect may
not be quite as likely a possibility as I've feared.)

> So, the UART needs an oscillator.  Big deal!  Give it an oscillator.
> It also needs *power* -- you don't object to giving it *that*, do
> you??  :>

Not unless the power it needs is substantially different from what the
rest of the circuit needs.

So far, the stuff I've built to be driven off a parallel port has been
clockless, so a clock for a UART would be otherwise unnecessary.  Which
makes me view it as unnecessary complication, especially when parallel
ports are so simple.

> With the standalone UART, the receiveed data is present on a set of 8
> pins.  Always. You don't have to talk to the chip.  Likewise, the
> data being transmitted is accepted on ANOTHER set of 8 pins.

...which, actually, calls out a significant difference between the two:
a parallel port is "host push, host pull", whereas a serial port is
"host push, device push".  (The difference is which end initiates the
transfer of data in the device->host direction.)

> See above.  I can show you how to make a serial port driven PROM
> programmer *without* a microcontroller -- the biggest hassle is
> controlling the Vpp needed.  :>

I've considered building one, both in order to be able to burn PROMs
and because I think it'd be fun to design and build.

> A better approach, nowadays, is to have everything network aware.

Better in what respect?  Higher bandwidth and better availability of
the hardware are about the only advantages I can think of offhand.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse at rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B