[comp.sys.amiga] mysteries of printer drivers

bryan@mothra.cs.utexas.edu (Bryan Bayerdorffer) (10/19/87)

	See, I have this IDS 460G (vintage 1980, back when 2K was LOTS of 
printer buffer), and I'm trying to write a driver for it.  I'm also working 
with the OLD RKM--the one published by Commodore, not Addison Wesley.  My
gratitude would be boundless if someone could answer the following questions
about the example drivers, since the explanation in the RKM is a bit sparse:

	1. Why do the various init.asm files open all those libraries?  As far
	   as I can see, none of the driver code references any library 
	   functions.  Specifically, why do the inits for the diablo, hp plus,
	   and okimate20 all open graphics.library, dos.library, and intuition.
	   library, while the epson init only opens graphics.library?
	
	2. Why does printertag.asm XREF _PrinterSegmentData, when this isn't
	   referenced anywhere in the file?  I'm just wondering if I'm missing
	   something deep here.

	And no, I can't use PrtDrvGen (author's name escapes me) to build the
driver, because this printer wants any 0x03s that it gets during a graphics
dump duplicated, because this is the command escape character.  PrtDrvGen 
doesn't support this, and it also means I have to make the buffer twice as long
as usually necessary, to support a potential stream of all 03s.  Sigh.


 ______________________________________________________________________________
/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/
|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|
_No dark sarcasm in the classroom|_____|_____|_____|_____|_____|_____|_____|___
|____Teachers leave the kids alone__|_____|_____|bryan@ratliff.cs.utexas.edu__|
___|_____|_____|_____|___{ihnp4,seismo,...}!ut-sally!mothra.cs.utexas.edu!bryan
|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|

andy@cbmvax.UUCP (Andy Finkel) (10/20/87)

In article <9312@ut-sally.UUCP> bryan@mothra.cs.utexas.edu (Bryan Bayerdorffer) writes:
>	1. Why do the various init.asm files open all those libraries?  As far
>	   as I can see, none of the driver code references any library 
>	   functions.

Leftovers from when each driver needed to read preferences (before we
had the driver pull in a copy of Preferences, as I recall.  I don't
think anything other than graphics.library is needed at the moment.

>	2. Why does printertag.asm XREF _PrinterSegmentData, when this isn't
>	   referenced anywhere in the file?  I'm just wondering if I'm missing
>	   something deep here.

Nope...you don't need it.  Pull it out.

-- 
andy finkel		{ihnp4|seismo|allegra}!cbmvax!andy 
Commodore-Amiga, Inc.

"Interfere?  Of course we'll interfere.  Always do what you're best at,
 I always say."

Any expressed opinions are mine; but feel free to share.
I disclaim all responsibilities, all shapes, all sizes, all colors.

rico@oscvax.UUCP (10/21/87)

In article <9312@ut-sally.UUCP> bryan@mothra.cs.utexas.edu (Bryan Bayerdorffer) writes:
>
>	See, I have this IDS 460G (vintage 1980, back when 2K was LOTS of 
>printer buffer), and I'm trying to write a driver for it.  I'm also working 
>with the OLD RKM--the one published by Commodore, not Addison Wesley.  My
>gratitude would be boundless if someone could answer the following questions
>about the example drivers, since the explanation in the RKM is a bit sparse:
>		... etc ...

I've also got a printer which is sufficiently 'different' that PrtDrvGen
can't handle it.  And  I'm now finding myself trying to figure out just
what makes a printer driver tick.  #1 on my 'boy is this annoying' list
is the case 5 stuff for the Render() function.  There's loads of SPECIAL_*
stuff "devices/printer.h" but what does it all mean and what am I supposed
to do with it?  Even the simple dump raster program from the RKM (the
one in the printer.device chapter) preceeds its dump with a call
to case 5 (SPECIAL_ASPECT|SPECIAL_FULLCOLS).  Then it doesn't send any other
info to the Render() function (presumably because I failed to do something
that I should have done).  What should I have done??  Similar behaviour in
DPaint (which I know is doing in 'right' since it works with other printer
drivers).

On the other hand, ProWrite does things differently again.  It seems
to charge on ahead even though there is no case 5 stuff implemented
can you say ' case 5: return(0) '?  

	Matt?  Carolyn?  Anyone?

	Thank God for kprintf...
	  -Rico
-- 
[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]

daveb@cbmvax.UUCP (Dave Berezowski) (10/24/87)

In article <518@oscvax.UUCP> rico@oscvax.UUCP (Rico Mariani) writes:
>In article <9312@ut-sally.UUCP> bryan@mothra.cs.utexas.edu (Bryan Bayerdorffer) writes:
>>
>>	See, I have this IDS 460G (vintage 1980, back when 2K was LOTS of 
>>printer buffer), and I'm trying to write a driver for it.  I'm also working 
>>with the OLD RKM--the one published by Commodore, not Addison Wesley.  My
>>gratitude would be boundless if someone could answer the following questions
>>about the example drivers, since the explanation in the RKM is a bit sparse:
>>		... etc ...
>
>I've also got a printer which is sufficiently 'different' that PrtDrvGen
>can't handle it.  And  I'm now finding myself trying to figure out just
>what makes a printer driver tick.  #1 on my 'boy is this annoying' list
>is the case 5 stuff for the Render() function.  There's loads of SPECIAL_*
>stuff "devices/printer.h" but what does it all mean and what am I supposed
>to do with it?  Even the simple dump raster program from the RKM (the
>one in the printer.device chapter) preceeds its dump with a call
>to case 5 (SPECIAL_ASPECT|SPECIAL_FULLCOLS).  Then it doesn't send any other
>info to the Render() function (presumably because I failed to do something
>that I should have done).  What should I have done??  Similar behaviour in
>DPaint (which I know is doing in 'right' since it works with other printer
>drivers).
>
>On the other hand, ProWrite does things differently again.  It seems
>to charge on ahead even though there is no case 5 stuff implemented
>can you say ' case 5: return(0) '?  
>
>	Matt?  Carolyn?  Anyone?
>
>	Thank God for kprintf...
>	  -Rico
>-- 
>[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]


	Under V1.2 the only SPECIAL stuff that you need worry about
is SPECIAL_DENSITY1 thru SPECIAL_DENSITY4; SPECIAL_TRUSTME; and
SPECIAL_CENTER.  All the other SPECIAL flags are for the printer device
and not you printer driver writters.  The flag meanings are:

SPECIAL_DENSITY1 to SPECIAL_DENSITY4
 - allows for a maximum of 4 different print densities.  DENSITY1 is the
   lowest density and the default.

    Excerpt from HP render.c case 5 source code:

    SetDensity(x & SPECIAL_DENSITYMASK); /* select density */
 

    HP density.c file source code:
/*
    Density module for HP_LaserJet
    David Berezowski - May/87
*/

#include <exec/types.h>
#include <devices/printer/printer.h>
#include <devices/printer/prtbase.h>

SetDensity(density_code)
ULONG density_code;
{
    extern struct PrinterExtendedData *PED;
    extern char StartCmd[];

    /* SPECIAL_DENSITY     0   1   2    3    4 */
    static int XDPI[4] = {75, 75, 100, 150, 300};
    static char codes[4][3] = {
        "075", "075", "100", "150", "300"
    };

    density_code /= SPECIAL_DENSITY1;
    PED->ped_MaxXDots = XDPI[density_code] * 8; /* 8 inches */
    PED->ped_MaxYDots = XDPI[density_code] * 10; /* 10 inches */
    PED->ped_XDotsInch = PED->ped_YDotsInch = XDPI[density_code];
    StartCmd[8] = codes[density_code][0];
    StartCmd[9] = codes[density_code][1];
    StartCmd[10] = codes[density_code][2];
}


SPECIAL_TRUSTME
    - do not do any printer resets.
    - WE STRONGLY RECOMMEND THAT YOU NO LONGER RESET THE PRINTER EVER
      DURING A GRAPHIC DUMP!

SPECIAL_CENTER
    - center the image horizontally on the page.
    - under V1.3 this flag will no longer EVER be set as the V1.3
      printer device takes care of centering the image.  ie. it is
      no longer the responsibility of the printer driver.

rico@oscvax.UUCP (10/28/87)

Ooops... I forgot the macros.i file.  Well here it is

****
*
* printer device macro definitions
*
****

XREF_EXE	MACRO
		XREF	_LVO\1
		ENDM

XREF_DOS	MACRO
		XREF	_LVO\1
		ENDM

XREF_GFX	MACRO
		XREF	_LVO\1
		ENDM

XREF_ITU	MACRO
		XREF	_LVO\1
		ENDM

CALLEXE		MACRO
		CALLLIB	_LVO\1
		ENDM

LINKEXE		MACRO
		LINKLIB	_LVO\1,_SysBase
		ENDM

LINKDOS		MACRO
		LINKLIB	_LVO\1,_DOSBase
		ENDM

LINKGFX		MACRO
		LINKLIB	_LVO\1,_GfxBase
		ENDM

LINKITU		MACRO
		LINKLIB	_LVO\1,_IntuitionBase
		ENDM

********  End of macros.i
-- 
{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]