Path: blue.weeg.uiowa.edu!news.uiowa.edu!hobbes.physics.uiowa.edu!newsrelay.iastate.edu!vixen.cso.uiuc.edu!news.uoregon.edu!cie-2.uoregon.edu!nparker
From: nparker@cie-2.uoregon.edu (Neil Parker)
Newsgroups: comp.sys.apple2.programmer
Subject: Re: Hi-Res Printing
Date: 16 Dec 1994 03:20:14 GMT
Organization: University of Oregon Campus Information Exchange
Lines: 121
Message-ID: <3cr11e$4qp@pith.uoregon.edu>
References: <3cn94a$1fi@fishlab3.fsh.mtu.edu> <3cp3tv$4j3@pith.uoregon.edu> <3cpsgf$77d@fishlab13.fsh.mtu.edu>
NNTP-Posting-Host: cie-2.uoregon.edu

In article <3cpsgf$77d@fishlab13.fsh.mtu.edu> jponge@mtu.edu (Joshua P. Onge)
writes:
>Neil Parker (nparker@cie-2.uoregon.edu) wrote:
>
>: Dumping the hi-res screen to the printer requires a machine-language
>: program (actually, much of the work can be done in BASIC, but only if you
>: don't mind waiting five or ten minutes for one screen to print).  The
>: secret is to divide the screen into 8-pixel-high rows, and for each row,
>: transmit the graphics control code ("ESC G0280"), followed by the
>: dot-column data for the row.
>
>: I have source code that does this, if anybody's interested.  Unfortunately,
>: it's uncommented...if you want to see commented source code, that'll take
>: me a bit longer to prepare.  (As an extra-special bonus, the same source
>: code also prints double hi-res screens.)
>
>	I'd like to see that code Neil.  Also how wide is an 8-pixel-high
>row? (40 bytes?) and um, what is the format of the dot-column data.  Thanks.

OK...I'll work on getting it into a presentable form.

The width of the row is the same as the width of the screen in pixels--280
dot-columns for hi-res graphics, or 560 dot-columns for black and white
double hi-res graphics.

The format of a dot-column is just a single column of pixels, eight pixels
high.  Each pixel in the 8-pixel-high column corresponds to a different pin
on the Imagewriter print head.

After the Imagewriter is put into graphics mode (by sending it the ESC G
code), the next N bytes received by the printer (where "N" is the 4-digit
decimal number you transmitted immediately following the ESC G) are
interpreted as graphics data instead of text.  The low bit of each graphics
byte, if set, causes the top pin to fire, and the high bit, if set, causes
the bottom pin to fire.  The bits in between control the pins in between.

Suppose the printer, while in graphics mode, receives the ASCII code for
the letter "Q".  The ASCII code for "Q" is 01101001, so the printer will
produce the following image on the paper:

     X
     .
     .
     X
     .
     X
     X
     .

where "X" means a pixel is printed, and "." means no pixel is printed.  The
printer then advances to the next print position, and awaits the next byte
of graphics data.

A more complicated example:  Suppose we want to print a graphics image that
looks like this:

     . . X X X . .
     . X . . . X .
     X . . X . . X
     X . X . X . X
     X . . X . . X
     . X . . . X .
     . . X X X . .
     . . . . . . .

We start by looking at the first column of data.

     .
     .
     X
     X
     X
     .
     .
     .

This has pixels to be printed in positions 2, 3, and 4 (where 0 is the top
pixel).  Therefore we need to send a byte with bits 2, 3, and 4 set, i.e.
00011100, or $1C hex.  Likewise the second column is 00100010, or $22 hex.
Continuing like this, we find that the remaining bytes are $49, $55, $49,
$22, and $1C.  There are a grand total of 7 bytes, so we need to tell the
printer to go into graphics mode for 7 bytes by printing "ESC G0007".  The
complete data stream, in hex, looks like this:

     $1B $47 $30 $30 $30 $37 $1C $22 $49 $55 $49 $22 $1C
      |   |   |   |   |   |   \________________________/
      |   |   |   |   |   |          graphics data
      |   |   |   |   |   +-- "7"
      |   |   |   |   +-- "0"
      |   |   |   +-- "0"
      |   |   +-- "0"
      |   +-- "G"
      +-- ESCAPE

If you do this for a row that's 280 pixels wide instead of seven pixels
wide, you can print a band of hi-res graphics data.  Then move down to the
next row and do the same for the next band, and so on until the entire
screen is printed.


So you see, it's not really very difficult, just rather tedious.  Most of
the work can be done in a BASIC program, but machine language really is
better, because BASIC is just too slow.  (I know.  I tried to write a
hi-res screen dump program in BASIC once.  It was painful to watch.)

BTW, there are a couple of issues you need to watch out for.  First, the
Imagewriter's default line-feed distance is too big for graphics
work--unless you shorten it, you'll end up with ugly horizontal white lines
across your image.  Sending "ESC T16" cures this problem.  When you're
done, restore the default line-feed settings by sending "ESC A".

Second, if you leave the carriage in bidirectional mode, your rows won't
quite line up with each other, and the image will come out looking jagged.
Sending "ESC >" cures this problem.  When your done, restore the normal
bidirectional printing by sending "ESC <".

               - Neil Parker
--
Neil Parker                 No cute ASCII art...no cute quote...no cute
nparker@cie-2.uoregon.edu   disclaimer...no deposit, no return...
nparker@cie.uoregon.edu     (This space intentionally left blank:           )