Canon LPB-10 info sought.

Tony Duell ard at
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 
low-level interface.

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 
Lilith interface.


More information about the cctalk mailing list