On 11/09/2012 08:41 PM, ben wrote:
On 11/9/2012 6:15 PM, allison wrote:
On 11/09/2012 07:50 PM, ben wrote:
On 11/9/2012 5:30 PM, Alexandre Souza - Listas
wrote:
> Tell me what toner does a P112 use or is that
used to color the
> 1MB of
> ram??
Well, a 64-K CPM system will not print raster graphics with
ease on
a Laser Printer...You need more RAM!
:oD
Well, at least I tried :D
Well if you could access the toner drum directly from the host cpu, I
am sure you could emulate a generic mono-spaced printer like a TTY in
16K including the printer fonts.
Ben.
Actually no. To do that you need to be able to process the data rapidly
enough to lay down dots
as the drum rotates.
That is a mechanical issue, not the idea of charging a drum with a laser.
You are not serious.
The drum rotates slowly but each line of pixels is the length of the
printed area
(8") times the 300line per inch of the circumference and at 8PPM the
average
drum in small printers turned several times to print the whole 11 inchs.
It's a raster scan system. Character printers could compose at a rate that
was one cell height at a time so they use band buffers that often allowed
typically 8 or 16 lines on the drum to be buffered at a time while the next
lines were being processed. That scheme was good to a point but there were
pathological cases that resulted in page to complex and imaging failures.
often overstrikes were the likely culprit.
For 8PPM that means moving 7920000 pixels in about 7.5 seconds without
much dead time. You cannot stop the drum during the process.
The laser does not charge the drum, it's used to discharge it, you can
do it with
LEDs as well but they were slow back then.
The typical cycle is charge corona, writing (laser, or led raster scan),
developing (toner)
transfer(transfer corona) and cleaning (discharge corona sometimes), and
doctoring
(scrape the remaining toner off with a silicone rubber blade). Repeat as
eneded.
Polarities and what optical range this are done are dependent on if the
drum was
selenium coated or the organic photoreceptor that Cannon wrapped the
cartridge
around.
The old, cheaper hardware, faster software problem here. I don't think
software has yet to solve the real problem of modern printers,
is that text on the screen does NOT match the printed page, but that
is off topic.
That belongs back with one of the threads that had NAPLPS in it or
maybe
WYSIWYG
when WYGINS is the reality.
No one prints at under 100 DPI. Maybe now with very high resolution
color displays
we see what we get but then the best CRT I ran in color was 1280x1024 and
.27 dot pitch (about 70-80dpi) which is still coarse by then 300DPI
standard.
That meant the tube could not display (even in B&W) what the printer could.
New we have displays that are easily better than 300dpi but printers can do
600dpi and maybe more. That doesn't even cover color.
The key thing for Laser printing (or any page
printer) is the bit image
need to exist before
the paper moves or at least be preprocessed so that the raster image
processor can fill
a "band buffer" . The Video dot rate for a DEC LN01 (xerox 12PPM
engine) was about 7mhz.
The early character only version use a 12mhz 80186 with 8089 to keep up,
The system IO
to the host was handled by the 8089. Oddly the 8PPM LN03 Ricoh based
engine was not much
slower on the video clock. In the late 80s there were two lasers often
those that were
band buffer and generally limited to text and limited graphics and a
higher priced version
that had enough ram to buffer the page so the image could be composed
before the paper
was even moved.
I think history of Time-Sharing computers had a big impact here. You
needed
BIG fast page laser printer to share between users, so high speed
printer was
needed. Speed I don't think changed much over the years, but build
quality HAS dropped.
No build quality is better. We ( I was part of the team that developed
the LN01, LN03 and
LPS40 and LPS20 series at DEC) found that getting engines that could run
at speed for 90 days
without breakdown was a mechanical impossibility, we had customers prove
it repeatedly.
Back then the choices were Cannon, Ricoh, Xerox and in about that order
of durability.
Getting 200,000 to 300,000 pages between failure was the challenge and
price was the
other.
To get to 40PPM (LPS40) a microVAX in the printer pushing a custom
bitslice processor
and a even more custom bitbliter so that a reasonably complex page set
could be printed
at 40PPM. That's what it took then. But the printer took postscript
directly and printed
up to B size pages with no page too complex issues. Now we have cheap
fast cpus that
can do that.
This development was in the time frame of the "workstation" so the big
VAX in the back
was not always the factor. However the cost of even slow printers was
high enough
Then that shared resource was what the customer said. The price of a
8PPM printer
then is far higher than a 20ppm color printer now.
So the existence of timesharing was and is a red herring as big systems
printers
printed less graphics and small single users wanted all the printing
capability..
Often the single user was a workstation of even then a PC with Hercules or
early CGA video.
Actually I use
my CP/M-80 system to lay down images on a real
Laserjet4L. The price is that
I need to run the system for a long time to create bit images to
transmit. That takes hours
even with ram and bit of buffering to hard disk. Even then the printer
is doing much of the
heavy lifting.
Custom software, or using a driver for a text processing package?
Very custom, in assembler as excess overhead was painful and I had one
of the uncommon
10mhz z80s. I did it mostly to prove a point but waiting hours per
page was not practical.
Doing hi res text only documents was easy and people were doing it tot
he limits of what
printers were available. Graphics just wanted more of everything by
many orders of magnitude.
Large ram was cost and speed issues but doable then. Code can overcome
a lot of things
but raw CPU speed was and is the prime solution (enter GPUs).
FYI I still run that LJ4L as its durable and parallel interfaces to all
my systems directly save
for the latest PC with no IO save for USB ( PIC24 programmed for USB to
parallel solution).
Allison