> So currently you'd need to have 4 images before it is a net win.
That's from an external storage perspective (fitting more images onto a floppy, which is, IIRC around 140 Kb).
You are typically only going to be loading one image at a time. So if you save an additional 100 bytes, using more than 100 bytes of extra code, it's not a win from a RAM point of view.
Somewhat disappointing. The tl;dr is that the author uses an off-the-shelf 6502 compression library and just de-interlaces the Hi-Res framebuffer to improve spacial locality.
The reasoning behind the oddball framebuffer layout is handwaved away with "you can probably blame Woz for this" and "possibly to save a few chips on the motherboard".
Well, yes, to both. And the Apple II scan hardware is an absolute masterpiece of the era (surpassed only, IMHO, by the Disk ][ card he invented a year later). That's what we should be talking about.
> So currently you'd need to have 4 images before it is a net win.
That's from an external storage perspective (fitting more images onto a floppy, which is, IIRC around 140 Kb).
You are typically only going to be loading one image at a time. So if you save an additional 100 bytes, using more than 100 bytes of extra code, it's not a win from a RAM point of view.
Somewhat disappointing. The tl;dr is that the author uses an off-the-shelf 6502 compression library and just de-interlaces the Hi-Res framebuffer to improve spacial locality.
The reasoning behind the oddball framebuffer layout is handwaved away with "you can probably blame Woz for this" and "possibly to save a few chips on the motherboard".
Well, yes, to both. And the Apple II scan hardware is an absolute masterpiece of the era (surpassed only, IMHO, by the Disk ][ card he invented a year later). That's what we should be talking about.