The Apple II hi-res screen sits on 8KB of memory, so it should be possible to erase it quickly. The Applesoft
HGR command is slow enough that the "Venetian blind" erasure is clearly visible. Clearing the screen to a color with
CALL 62454 feels even slower. Why is this?
If you look at the screen clear code in the Applesoft BASIC ROM, you'll find this:
f3f6 lda $e6 ;put base address of current hi-res page sta $1b ; into $1a/1b (will be $2000 or $4000) ldy #$00 sty $1a f3fe lda $1c ;get color value sta ($1a),y ;store it in frame buffer jsr $f47e ;update color value iny ;advance, looping... bne $f3fe inc $1b lda $1b and #$1f bne $f3fe ;...until we get to $4000/$6000 rts f47e asl ;lose the hi bit, now $00/$fe for black/white, cmp #$c0 ; or $54/$aa for green/purple/orange/blue bpl $f489 ;branch if black or white lda $1c eor #$7f ;invert color bits for odd/even sta $1c f489 rts
This is a ROM routine, so size is at a premium, and self-modifying code is not allowed. It's optimized for space, not speed.
The most significant impact of this optimization choice is the code at $f47e, which tests the color value and potentially updates it for every byte. This code is necessary because of the rather strange hi-res graphics layout, which (among other oddities) represents an odd number of pixels with each byte. So while a solid black line is
00 00 00 00 ..., a solid green line is
2a 55 2a 55 .... The high bit doesn't change, hence the exclusive-OR with $7f. (The code at $f47e is shared with other routines, e.g. the line-drawing code, that must update the color when moving across the screen.)
The total time required to erase the screen to black is 271,121 cycles. Clearing to green would require 328,465 cycles.
The fastest possible screen clear would write a byte to 7680 addresses -- it's not 8192 because we don't need to overwrite the "screen holes". On a 6502, that requires 4 cycles per byte, or about 30720 cycles. The code to do that would fill about half of available RAM on an Apple II though.
A 192-byte unrolled loop can do it in about 39480 cycles. That's ~5x the code, for ~8x the speed.
While these approaches are faster, they still have the "Venetian blind" look. While that's something of an Apple II hallmark, not everyone wants that, and it may not be possible to simply show page 2 while you're erasing page 1. In a mere 127 bytes, for ~41,300 cycles you can erase the screen from right to left, using a clever function written by John Brooks.