Article 9844 of comp.sys.amiga: Path: mcdsun!noao!hao!ames!amdcad!sun!pitstop!sundc!seismo!uunet!mnetor!utzoo!utgpu!utfyzx!oscvax!rico From: rico@oscvax.UUCP Newsgroups: comp.sys.amiga Subject: Re: mysteries of printer drivers LONG! Summary: Here's an example Keywords: printer, driver, example, source Message-ID: <525@oscvax.UUCP> Date: 28 Oct 87 03:42:20 GMT References: <9312@ut-sally.UUCP> <518@oscvax.UUCP> <2594@cbmvax.UUCP> Reply-To: rico@oscvax.UUCP (Rico Mariani) Organization: Ontario Science Centre, Toronto Lines: 1090 In the spirit of previous GURU oriented postings, here's another one that I hope will help someone out there. It's a printer driver for the toshiba 3 in one printer in its Qume (best) mode. I hadn't ever seen the source for a printer driver posted before so hopefully this will make a good example for everyone out there. It's implemented in Aztec C + assembler but porting it to Lattice + assembler should be simple. The rendering function is a *minimal* graphics output generating function, no attempt was made to optimize out unecessary print passes etc. But this could be easily added. This code was developed by me here at the Ontario Science Centre as part of my work (i.e. we needed this driver) and I've been authorized to release it to the public domain. You may slice dice or whatever. Needless to say there's no warranty etc. etc. All usual disclaimers apply. Noteworthy items: - Aztec C doesn't preserve a6 across function calls. This is required in the printer driver code so special inline assembler was added to the render() and dospecial() functions. Look out for this Aztec users! - The toshiba is actually capable of printing 24 pixel rows at 360 dots/inch in a print pass however the printer.device didn't seem to cope with this very well. With these numbers in the printertag the printer device would simply call "case 5" (pre initialization) of the render function and then not send any other data. No fuss, no muss, no data. When I reduced the 360 to the next best print mode (180) all was well. Sigh. If anyone can shed some light on this I'd appreciate it. - I've stolen the debugging code from the dos handler that Matt Dillon recently posted and used this in my driver for debugging output. You folks out there should think about using it to get debugging output where you never dreamed it was possible. The debugging package is a really terrific little subsytem. Thanks Matt! - I've also stolen the flush program from the dos handler, you can use this for devoloping printer drivers as it will cause your Expunge code to be run. The next time you use the printer device your code will be re-loaded, hence you can make recompile etc. and test your new driver without resorting to preferences trickery. Not to mention testing your Expunge code... - Speaking of Expunge code, mine doesn't work when the debugging is enabled. Works perfectly in normal use though... oh well :-( If I ever figure it out I'll post the fix. Meanwhile if any of you figure it out... - If you're writing a printer driver do whatever it takes but get Carolyn's Cmd program. This lets you easily "see" your driver's output which is a must for testing. I used this for my debugging output before I installed Matt's code. If you're checking the output by eye then it sometimes helps if there's readable diagnostics intermixed. Thanks Carolyn! - To compile with debugging enabled just supply the -DDEBUG flag to "cc" and -EDEBUG to "as". Lattice people will have to use whatever flags it is they use to predefine symbols in the compiler/assembler. Enough babbling... here's the source + binary (uuencoded + shar'd) -- {watmath|allegra|decvax|ihnp4|linus}!utzoo!oscvax!rico or just rico@oscvax.UUCP if you're lucky [NSA food: terrorist, cryptography, DES, drugs, CIA, secret, decode] [CSIS food: supermailbox, tuna, fiberglass coffins, Mirabel, microfiche] [Cat food: Nine Lives, Cat Chow, Meow Mix, Crave]