[HN Gopher] Maximizing Compression of Apple II Hi-Res Images
___________________________________________________________________
Maximizing Compression of Apple II Hi-Res Images
Author : deater
Score : 19 points
Date : 2025-12-16 03:55 UTC (4 days ago)
(HTM) web link (deater.net)
(TXT) w3m dump (deater.net)
| ajross wrote:
| 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.
| kazinator wrote:
| > _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.
| Dwedit wrote:
| When you talk about maximizing compression, you usually move from
| simple binary data to predictors.
|
| A predictor is where you look at pixel above, and pixel to the
| left, and instead of coding a raw pixel value, you sort the
| values by how likely they are for the given "above" and "left"
| values. Most likely value becomes 0, second most likely becomes
| 1, etc... This changes the image into a different image where you
| have more 0 values than others. So you can encode the data as
| "number of 0s", like RLE, but with the zero count encoded in a
| variable-length way.
___________________________________________________________________
(page generated 2025-12-20 23:01 UTC)