Canon LPB-10 info sought.

OK, I'll take a look sometime, and see if I recognise anything. 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. -tony