Xref: utzoo comp.unix.i386:1597 comp.unix.xenix:8867 comp.sources.wanted:9676
Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!acorn!moncam!emmo
From: emmo@moncam.co.uk (Dave Emmerson)
Newsgroups: comp.unix.i386,comp.unix.xenix,comp.sources.wanted
Subject: Re: Fast parallel driver for Unix/Xenix AT?
Summary: Who me???
Message-ID: <301@marvin.moncam.co.uk>
Date: 5 Dec 89 19:56:37 GMT
References: <256ADBB5.19093@ateng.com> <289@marvin.moncam.co.uk> <25747D15.4126@ateng.com>
Organization: Monotype ADG, Cambridge, UK
Lines: 25

In article <25747D15.4126@ateng.com>, chip@ateng.com (Chip Salzenberg) writes:
> According to emmo@moncam.co.uk (Dave Emmerson):
> >Forget it, the printer itself is usually the bottleneck...
> 
> Bzzt!  You lose the answer-the-poster's-question contest.
> 
> When printing to an HP LaserJet II or a Printronix 600, the printer most
> definitely is _not_ the bottleneck.
> -- 
As I recall, the poster only said 'printer', not 'laserprinter'. Sure there's
a world of difference. 
If you use a dedicated board which you can make yourself in about 4 hours for 
<100 USD, you can do away with OS calls and 'print' at well over 100Kchar/sec
- if you can write your code tightly enough, that is - and leave your PRN:
port for more mundane tasks. A lash-up I tested recently for satellite comms
averaged 50Kb/sec including run-time packet generation, similar to Kermit.
For occasional (personal) use I would have no qualms about accessing the PRN:
port directly anyway, it may be dirty, but it's cheap and I can do it today...

NB It wasn't my software, if *I* were paying for satellite time, the data
would have been pre-packeted on disk, and spooled out directly from file.

ATB

Dave E.