🚀 go-pugleaf

[Pacman lives]

     Sounds familiar... I bought my atari, soldered up a parallel cable for my
old OKIData Microline 92 which was formerly speaking RS232 serial, tried to
print some things, swore a little, flipped some option settings, etc.  After
I got the basics to go, I tried a screen dump and got the same results as you
did (looks like blank bands between each print pass).

     I didn't have a better way to view the control stream, so I put the
printer in low-res mode for 480 bytes but gave it no data, and then started
a screen dump.  Decoding the pixel patterns, I found the following ugly
sequence at the end of the first line of graphics data (I don't know about
the other lines, but I assume they're the same; they *LOOK* the same):

ESC '3' 1	(theoretically, advance in 1/216" increments)
LF		(OKI/Epson stepper can only step 1/144", so does 1/144")
ESC '3' 1	(beats me why they do it again)
LF		(another 1/216" (IBM) or 1/144" (OKI/Epson))
LF		(and another)
ESC '1'		(set 7/72" mode)
LF		(travel 7/72" (everybody))

(The 7/72" mode is correct, but I'm working from memory on the ESC '1'
code, so that might not be the correct character sequence.)
This whole mess is supposed to advance the 8/72" height of the print head.
The stepper motors for the OkiData (and, I guess, the Epson series) step
in 1/144" steps instead of 1/216", so the printer goes 1/144" on a 1/216"
request to avoid the problems of not spacing at all.  The problem is
that after three 1/144" steps, we've gone 1/144" beyond 3/216" (1/72").
The printer corrects advances of 3/216" steps to 2/144", but it doesn't
have the smarts to correct them when they come 1 or 2/216" at a time.
If the 1/216" section had been replaced with
	ESC '3' 3
	LF
the problem would not have shown up (at least in screen dumps).

I have a call in to Atari to see if they already have a simple solution to
this (besides buying an IBM printer).  If not, I wrote an algorithm to
correct accumulative and local error on the fly.  If Atari doesn't have
an easy answer, I will also write the code to insert my algorithm between
the BIOS trap vector and the lst: output routine (it's an ugly scheme, but
what can you do when your *OS is in ROM?).

Anyone who is interested in the results should send me mail.  If I get a
large response, I'll post them.
-- Brian Katzung  (ihnp4!{laidbak,iwtpu}!katzung)