>> And it's kinda funny that both canon630u and niash have HP ScanJet >> 3300C backend at least partly defined, which one is the actually >> working one, or both? :-) > >The niash backend works, it was specifically written to support the >HP3300c.
OK, so I'll skip of looking into tthe canon630u for those bits. >> At least gl640/gl660 should be separated (and shared by backends >> mentioned above) so it would make it simpler to just #include >> necessary interface chip communication protocols, perfect example >> being lm9830.h (part of canon630u funnily enough) and niash_xfer.h >> that seems to be a partial GL640 implementation compared to >> canon630u-common.c or u12-io.c... > >lm9830.h? Seems highly scanner specific to me.... >I agree that it would be nice to have common code for the parallel- >usb bridges. My idea was of course to maybe make chip-specific .h-files instead of sca= nner-specific chip or chip-combo backends. It should be pretty straight forward to cut'n'paste chip-register stuff to .h files and just make #include lines on all effected backends. (?) >BTW, the HP3300c has a NIPEDC0804, not a GL640. >It has two rows of 20 pins along bottom and top edge. It has a 12.000 >MHz crystal mounted close to it. This chip was mentioned as an >'interface' chip on an electronics web page. Well, my interest on HP3300C was mainly as it was mentioned on both canon= 630u and niash, but if I understand HP3300C that NIPEDC0804 is just a USB-EPP converter chip, just like GL640/GL660, so no major differences. >When I initially wrote the niash backend, I wanted to mimic the >windows driver as good as possible, so I implemented its exact >behaviour. There seem to be some minor (but important) differences >between parallel-USB bridges. For example the 8-byte sequence that >is used to initiate a bulk transfer is a little different between >the HP3300c and HP3400c. Actually I have been admiring the niash-backend for the "wholesom" of the= port for some time, for example is the niash the only one even trying to implement those pesky front-buttons on the front of the scanner (CanoScan= 3000F also has four of them) as I can't seem to find any valuable code elsewher= e for such functionality (maybe haven't just digged far enought yet)? >> As far as I can see (up to looking into GL660's pins 24 and 26 to see >> it's hardwired to IEEE-1284 mode) that why CanoScan 3000 and some of >> the others do report themself's slightly differently is because they >> simply have slightly differently offsetted registers. ;-) > >What do you mean by offsetted registers? Which registers are they? Just register "blocks" that are shifted from one memory location to other= place, in blocks... ?!? >I think that the functionality to talk to the USB-parallel bridge >should be strictly separated from any scanner specific functions, >otherwise I foresee an #ifdef jungle.. :) I 100% agree, there is already some jungle-code, so clearing some of the stuff to usb2epp.h/usb2epp.c or similar grouping file(s) would be great. Or maybe even the scanner-chip drivers could be separated (similarry as in that lm9830.h)? -- amth
