Re: [stella] 12 chars/line!? (was: re: optimizations; Call for suggestions)

Subject: Re: [stella] 12 chars/line!? (was: re: optimizations; Call for suggestions)
From: Greg Troutman <mor@xxxxxxx>
Date: Fri, 26 Sep 1997 10:17:19 -0700
Piero Cavina wrote:
> At 10:48 -0700 24-09-1997, Greg Troutman wrote:

> >You can't very easily re-use that RAM area
> >for drawing multiple lines of text in the same frame, because the loop
> >that would combine 12 4-bit characters into 6 one byte graphics data,
> >five scanlines high, would take well over a thousand cycles, I think,
> >producing as many as 20 blank scanlines while you busily reload that RAM
> >area...
> Are you sure it would take so much time?
> The font could be stored in this way...:
> ; letter "A"
> byte %01000100
>      %10101010
>      %11101110
>      %10101010
>      %10101010
> ie - the same 4-bit character twice in 1 byte, so that combining two of
> them into 1 byte can be done without shifting bits...

Yes, this will need just one mask operation (2 cycles) vs. 4 ASLs (8
cycles), or a savings of 6 cycles per byte written, or 180 cycles for a
30 byte transfer.  But still, at a minimum, you will be:

 	reading the first character (min. 4 cycles)
	reading the second character (min. 4 cycles)
	masking the second character (2 cycles)
	combining the characters (3 cycles)
	writing the combined character (min. 4 cycles)
	adjusting indexes (min. 4 cycles)
	looping (3 cycles)

The simple math for the most efficient algorithm possible here is 4 + 4
+ 2 + 3 + 4 + 4 + 3 = 24 cycles per byte, or 720 cycles.  This is a best
case cycle count where you are doing indexed, but not indirect, reads
and writes which would likely mean a great deal of additional ROM
overhead not necessary with a slower indirect method.  I can't see any
way to do all the above without some un-mentioned intermediate steps to
juggle the bytes/indexes in process, that will add significantly to the
cycle counts.  I doubt it would actually be possible to do it in under
1000 cycles, without eating up vast amounts of ROM by storing text in
unique-per-line tables rather than indirectly accessed font objects, no
matter how clever the code is.  

I'd sure like to see someone work out something that could do it in less
than 10 blank scanlines, though.  I started to actually write a routine,
but it seemed it would take way more thought than I have time for right
now to get anywhere near quick enough to look good...


Archives updated once/day at
Unsubscribing and other info at

Current Thread