Path: utzoo!utgpu!attcan!uunet!lll-winken!ames!pasteur!ucbvax!dewey.soe.berkeley.edu!oster
From: oster@dewey.soe.berkeley.edu (David Phillip Oster)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Text Drawing at speeds greater than 1200baud
Message-ID: <27585@ucbvax.BERKELEY.EDU>
Date: 18 Jan 89 21:08:14 GMT
References: <2243@uokmax.UUCP> <27572@ucbvax.BERKELEY.EDU> <6336@hoptoad.uucp>
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster)
Organization: School of Education, UC-Berkeley
Lines: 21

In article <6336@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes:
>Sounds good, but when you do the math, the characters are too wide.
Thanks Tim, you are absolutely right.  The idea can still be salvaged by
keeping eight copies of your font around, each one preshifted by a
different numbr of bits, with enough leading white bits that you can
always draw the character in at most two OR instructions.  Than use three
versions of your hand-tuned bit slammer code:
(o) version 1, uses OR.Bs, as the MOVE.Bs before, for when the character fits
in a single byte.
(o) version 2, uses OR.W for characters that span two bytes, but the
destination is on a word boundary.
(o) version 3, uses two OR.Bs for characters that span two bytes, but the
destination is odd.

Note: the third case can be eliminated by using 16 copies of the font
and always using OR.W instructions to slam those black bits to the screen.

a "copy of a font" is 9 scan lines*256 characters*2bytes per scan line per
character = ~4.5k. 16 of them is ~72k.  Naturally, you build them at run
time rather than wasting disk space for this stuff.  Quite reasonable for
a 512k machine.