On 04/20/2012 01:23 PM, Tony Duell wrote:
Depending on
what you mean by "driver", this may or may not be an
issue. I use SANE, which I think demands nothing from the OS but the
ability to send SCSI CDBs to the device and get responses (including
data) back. (Of course, adding that capability to an existing OS can
be a nontrivial effort....)
OK... suppose we pick the one machine I use regularly with a bitpmapped
display -- a classic PERQ.
I would have to make a SCSI interface (quit simple).
Write the microcode to drive it (all I/O has to be done from the CPU
microcode). Agian, I think I could manange that
Port the SANE stuff, presumably written in C, to PERQ Pascal, get it to
compile and run. I suspect that is decidedly non-trivvial
I'm not even sure what the SCSI protocol for driving a scanner is like -
anyone know? Is it treated like a mass storage device, where seeks will
move the head and read commands will scan a line of the image, or does it
use vendor unique commands to scan larger portions of the image and spit
them over the SCSI bus?
Either way, if you were designing your own trivial SCSI controller, then it
may be better to forget all about SANE and just code at a lower level only
for the particular scanner that you had; throw out SCSI commands and dump
the resulting data to disk/display RAM.
Find soem way to store the images and get them off the
machien onto
something mroe useful. 8" floppies or DC300 tapes anyone?
SCSI? :-)
Let's see, 8"x11" image @ 200dpi and 1bpp = 430KB approx. Maybe some simple
compression could get that down to 250KB. I think it was just about
possible to get 5KB/s reading *in* to a PC's parallel port, wasn't it? So
50 seconds for the transfer... that's perhaps acceptable for the odd image
which you've previewed and know you want to keep, but not really suitable
for doing a lot of pages in succession.
cheers
Jules