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

der Mouse mouse at Rodents-Montreal.ORG
Fri Aug 22 01:03:36 CDT 2008


> But, my point is, you can move to a different interface *if* you
> rethink what you expect *of* that interface.

True.  It's, perhaps, analogous to moving software to a different
language by rewriting rather than translating.

>> 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.
> But, that's just the "original PC XT implementation you're talking
> about.

Not _just_ that implementation.  Every "parallel port" I've tried has
actually been a parallel port, not just a printer interface.  I've
doubtless missed many of them, but, since I haven't used that as a
machine selection criterion, I see no reason to think my sample is
biased, which means that printer interfaces that are also parallel
ports are the rule rather than the exception (at least among machines
that have "parallel port" printer interfaces at all).

>> Because it doesn't support something the old one did, of course.
> But, the old one only supported it as a fluke.

I wouldn't call it a "fluke".  It supported it because the printer
interface implementation chosen was layered atop a parallel port, so of
course it also worked as a parallel port.

>> 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: [...]
> You would have had to move it to user-land and use the established
> device interfaces.

Right.  At a severe (crippling, I suspect - hm, I should measure this)
speed cost: at least two syscalls - user/kernel crossings - per byte,
instead of one for the whole string.

>> What someone, Gadi I think, recently said [...]

Wrong list.  It was Geoff.  *blush*

> You may find that you end up stuck with an old kernel/OS as new
> kernels move to embrace features that older machines won't support.
> Then you end up having to back-port changes, etc.

I know.  I've been doing that for years already.

> So, you're already bastardizing any approach you come up with to fit
> thowse constraints.  Why not pick a different set of constraints?
> And, use that to give you another set of *capabilities*??

Well, I think "bastardizing" is an unfair slant.  But, that aside,
there is no reason.  Trying different things - having different things
available - is good.  I'm not arguing _against_ the availability of
serial ports, Ethernet, USB, whatever.  I'm arguing _for_ the
availability of parallel ports - for more choice, not less.

Yes, this is motivated in part by my having done some things that fit
that particular choice.  So?  I've also done some stuff that used a
serial port instead of a parallel port as its interface to the host.

> Spend your time on something more constructive and useful -- design a
> parallel port replacement technology, etc.

Hm?  "Replacement"?  As in, design a PCI (or whatever) parallel port?
It may come to that.

But would that really be "more constructive and useful"?  You just
finished telling me all about how I didn't really _want_ parallel
ports, so I'm not sure how that'd be constructive or useful to design
parallel ports for current buses.  Or, if you mean something _not_ a
parallel port, then I don't know what you do mean....

> *Really*, look at some of the little MCU's out there.

I may.  Indeed, in a few cases I already have.  But that's not really
the style of design I enjoy when I want to hack digital logic; it's
just another computer, and a severely hampered one at that - its only
advantage, really, is the kind of direct interfacing to the world that
(surprise!) a parallel port gives.  (Well, okay, not _only_.  There are
things like size and power consumption.  But when paired with a "real
computer" to drive it, it loses those anyway.)

/~\ 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



More information about the rescue mailing list