Canon LPB-10 info sought.
ard at p850ug1.demon.co.uk
Sun Feb 22 13:13:12 CST 2009
> I put up the microcode and the printerdriver i have found in the
> meantime here :
OK, I'll take a look sometime, and see if I recognise anything.
> Basically the microcode implements some extra Mcode instructions that
> are then uses in the printerdriver.
> It does indeed look like there is a big bitmap being build in memory.
> I still have trouble understanding it,
This does not suprise me.
Rmemeber that with a laser printer, once you've started the page (got the
paper moving, etc), you can't pause midway through. You have to keep on
feeding data to the laser at the right rate.
So either you have to build up the entire bitmap before you start the
page, or be sure you can do so on the fly quickly enough. Some early
stand-alone laser printers with limited RAM did the latter -- they didn't
have enough RAM to store a full-page bitmap. So you couldn't print
full-page graphics. Text could be turned from ASCII codes to bitmaps on
the fly, ginen a itmapped font.
But anyway... These early workstations obvious worked with bitmapped data
in memory for the video display. In the case of the PERQ (which I am more
familiar with), there was hardware and microcdoe to do bitmap updates.
And it made sense ot use that for producing the printer bitmapped image,
rather than to use spearare hardware in the printer itself. Hence the
I can tell you a little about the CX-VDO interface, which may be somewhat
simuilar. There's a bit-serial comamnd/status interface, which is used to
do things like select the manual feeder, report errors (out of paper,
etc). At firt you cna probably ignore this.
There are 3 signals involved with starting a page. I forget the names,
but basicalkly they work like this :
1) A signal from the cotnroller to the printer causes the printer to
start the main drive motor and scanenr motor, and get the speed control
PLLs locked. Then the paper pickup clutch is engaged and the top sheet of
papepr is taken from the tray as far as the registration shutter
2) At this point the printer asserts a vertical synchronisation signal
back to the controller. The cotnrol has to respond within a certain
(short-ish) time, or the printer will time out with a paper jam (?) error
3) The controller asserts another signal. At this point the registration
shutter opens, and the paper starts moving towards the drum. The
controller waits a suitable time (actually counts Beam dectect pulses, I
think) to skip the top margin, and then starts sending the bitmap,
synchronsied by the beam detect pulses (which are sort of horizontal sync).
Hoiw much of this is done in hardware, how much in microocde, etc, is
down to the system. It's a great pity you don't have schematics of the
More information about the cctalk