Eric Auer wrote to Usagi: (and I'm reposting it here, because I tend to repost things that are sent to me ... -jh)
I think I can translate all your C code to ASM and write the underlying TSR thing. However, I have to know more about PostScript and HP PCL, and I would even prefer not knowing it at all but just having some code to plug in.
I once wrote a printer driver to use a custom font, so at least I know how to drive EPSON in graphics mode.
The basic workings of the TSR are:
for each column (because screen is landscape, not portrait) translate the column, e.g. some 200 pixel one, into some, e.g. 600x3 (90 dpi case, I suggest using a minimum of 180 dpi for now, most 24 pin Epson / NEC can do that or even 360 dpi), black and white dithered image. Collect as many columns as easily fit into (number of pins) - which is usually 9 or 24 - in RAM (e.g. use only 6 pins of 9, which only takes 600 bytes of buffer).
Print the translation buffer contents (the more pins you fail to use, the more often the print head will have to move over the paper until the task is completed) loop (until e.g. severe printer error or user presses print screen again).
That is all. We can always optimize later, e.g. the tradeoff between size of the translation buffer versus speed of printing, or speed versus complexity and accuracy of dithering algorithm and grayscale translation: I think we can afford a buffer of gray scale versions of even a 256 byte palette (although the gray scale might be less than 8 bit deep: depends on proper dithering). I wonder if we could dare to swap out a bit of DOS (which one? Maybe it would be an idea to add a command line option that allows the user to select a segment or program name) to XMS while printing (during printing, interrupts must not stay off all the time, as printing takes quite long - however, we could leave interrupts off MOST of the time and suspend ourselves to XMS from time to time: that would allow the other programs to work almost as normal, but would need special care to circumvent DOS time skew and improper keyboard / printer timeout / whatever handling).
As you see, much space for improvement. I think for now, it would be the most straightforward idea to hook int 1c and, as soon as the user presses print screen in graphics mode, set a flag that would cause int 1c (timer tick) to print a few columns (at most N, just stop until the next tick if printer reports busy) each tick until the screen printout is done or aborted.
PS: Without smoothing, you only have 3 bit grayscale depth in a 3x3 dither, so sooner or later, we should add error distribution and real dithering. A 6x6 box still is only about 5 bits. Whatever. You can actually -scale- the palette to grayscale translation to use all those impressive 10 or 37 grayscale steps that 3x3 or 6x6 has to offer... Adding COLOR can be done at a later version.
PS Jose: Thanks for making this project reach the critical amount of supporters. I think with us 3 or more helpers, there is real hope for it for FreeDOS 0.9 ...
[ and now, everybody contribute something... printer language of HP and PostScript, easy to implement fast dithering / eerror diffusion, design comments, etc. etc. ]