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

[Curious George]

--- On Thu, 8/21/08, der Mouse <mouse at Rodents-Montreal.ORG> wrote:

> >> Give me a nice simple breadboard full of TTL.  No clocks, no CPUs,
> >> no tri-state buses, no RAM or ROM.  I've got one such circuit in
> >> production use right now, controlling the relays I installed into a
> >> 12-outlet power bar.
> >
> > But, can't you get a "USB printer cable" (USB connector on one end
> > and centronics connector on the other) and treat *that* as if it were
> > your printer port?
> 
> In my particular case, no, largely because I have so few machines with
> working USB.

And those machines don't have parallel ports, either?  :>
I.e., you're lamenting a solution that you don't even need!  :>

> That aside, I don't know; it depends on what the host
> interface looks like.  If it means doing a dance with some
> USB interface, then it is substantially less convenient,
> because of that;

That's why I suggested doing everything "in band".
In that case, you just pass an endless array of bytes
to the print() routine and let *it* figure out how
to pass those bytes out the cable through *whatever*
USB controller you happen to have in *that* machine.

The problem with this is you lose all temporal control
over the byte stream (i.e., you will be guaranteed
that byte 1 always precedes byte 2 .. but, the driver may
elect to put a 1 millisecond or 20 second pause between them!)

> one of the things I did was to diddle the parallel-port driver so I
> could pass in an array of bytes and have it shove each one onto the
> output lines, then replace the byte in memory with the resulting values
> of the input lines.  This was easy because the thing is, after all,
> just, well, a parallel port.

Yes.  I did similarly in my Pertec driver.  (you have to be able
to read the tape while writing)

> My understanding of the USB devices is
> that they aren't parallel ports, except at the
> device-interface end;

They are sort of "virtual parallel ports". "Endpoints"

> they're actually printer interfaces that happen to speak parallel-port
> printer protocol out the printer-interface end.

But, the parallel printer port (centronics) is (roughly)
defined.  If you use the port as it was designed, then
your device will work just the same regardless of
whether there is a real "printer port" talking to it or
a USB printer port (i.e., there are the same signals
on the "business end" of the cable).

The big caveat is that you lose temporal control (which,
in theory, you also have no control over with a "real"
parallel port *unless* you are using an RTOS that makes
timing guarantees *or* are just disabling interrupts
and comandeering the machine for your own abuse while
you drive the I/O)

> 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?
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?

That's sort of like complaining that you can't use a nickel
and three pennies to get a free game on a pinball machine
because they replaced the coin mechanisms with *better*
coin mechanisms  :-/

> (It would still be substantially less
> convenient than a real parallel port, but it probably would
> have uses nevertheless.)
> 
> > The potential problem I see there is you can't just push a
> > nice byte stream out an I/O port and have those values appear
> > sequentially on a set of pins -- you're now stuck going
> > through the USB driver (which at least solves *that* problem)
>
> 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);

> > and whatever limitations it places on the sequencing of
> > control pins (i.e., you can't toggle any pin at any time,
> > arbitrarily).
> 
> 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>

Why should a manufacturer have to keep implementing their
parallel ports the same way you want them?  E.g., when I
put a parallel (printer) port in a piece of equipment, I
often put a microcontroller in *just* to manage the printer
port.  I.e., deal with all the handshaking, paper out
detection, etc.  So, my application software can't twiddle
individual control lines -- any more than I can twiddle
a particular data/control line on the SCSI bus arbitrarily
(i.e., outside of the protocol -- though some devices with SCAM
support effectively give you this control)

> > Note that you can also easily fabricate a serial-parallel converter
> 
> I can?  How?  I'll need _at least_ a clock, and quite probably at least
> two or three other chips I don't have and don't have documentation on,
> 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.  *Then*, you can either live with
that limitation (like living with the limitation of not
having the "three other chips", etc. now!) or find a way
to work around it.

I'm suggesting a way to work around it.

A standalone UART does need a clock.  But, what do you
care as long as you don'[t have to interface to that clock?
I.e., a "5V only" RS232 transceiver pair has an internal
oscillator that it uses to run a charg pump to synthesize
the higher voltage to drive the line.  But, *you* don't
have to deal with that.  It's magic!  (this isn't true of
all chips)

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??  :>

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.

When a character is received, a signal informs any external
logic that data is available on the dataout leads.  Likewise,
when the chip sees you stroke the control input, it samples
the data on the datain lines and begins transmitting that
"character".

A simple hack is to tie the DAV (data available) line to the
"send" input so each time the UART receives a character, it
automatically *sends* the data present on its inputs.

There!  8 in and 8 out over 3 wires.

Realistically, doing this with anything other than an
MCU is silly.  There are literally HUNDREDS of different
MCUs in the $5 range that can do this with 50 lines of code.

> I think you'd also have trouble finding a serial port that
> could run at parallel-port speeds.  My ROM reader can grab
> 64KB of ROM contents through a parallel port faster than
> you can send 64KB over a 115.2Kbaud serial line (I think
> - it's been a while since I tried it, but I think
> it's only something like two to three seconds).  And
> that's with a completely clockless flying-wire rat's-nest
> breadboard circuit.  The serial-line version requires
> substantially more complexity (at least a UART, implying a
> clock, and probably some kind of microcontroller).

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.  :>

You would find that PROM programmer a real kludge, though.
(I worked with one at a "financially challenged" client :< )

Serial and parallel ports are the wrong interface for things
like PROM programmers.  My UniSite uses a serial interface.
It's annoying.  Most times, I just put the images that I
want to burn on floppies (720K... ugh!) and let the machine
read them directly.

OTOH, if I am burning 10 copies of a PROM, I only have to
send the image over *once* (there's 8MB of RAM in the programmer
for holding images).

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

E.g., have you looked into print servers that might give you
the interface you want "on the wire"?

Again, this comes across sounding much harsher than it
is intended.  I really *do* think there are lots of
solutions to this problem -- especially for a curious
hacker!  You should investigate some of the inexpensive,
low end MCU's available.  Many have development kits
that are practically free.  And, the parts aren't very
expensive, either.  E.g., I use an MCU to run a printer
interface because it is almost cheaper than the latches,
buffers, decoding logic, etc. needed to implement a
"dumb" printer port!

You might get a kick out of the PIC MCU's.  They are
incredibly brain-damaged!  But, once you get over the
shock (e.g., no pushdown stack, subroutine nesting
limited to 16? levels, etc.) you can find the challenge
of applying them quite amusing!