* the bitmap squeezer in the first part uses screen mode that has previously been used in pernod's bitmap squeezer from Codeboys & Endians . the screen is laid out in this pattern:
+--------------------------------------------+ \
| First char line of bitmap 0 (0-7 pixels) | |
+--------------------------------------------+ |
| First char line of bitmap 1 (0-7 pixels) | |
+--------------------------------------------+ |
| First char line of bitmap 2 (0-7 pixels) | |
+--------------------------------------------+ > Chunk 0 with shared $d800 colors: $d800 - $d827
| First char line of bitmap 3 (0-7 pixels) | |
+--------------------------------------------+ |
| First char line of bitmap 4 (0-7 pixels) | |
+--------------------------------------------+ |
| First char line of bitmap 5 (8 pixels) | /
+--------------------------------------------+ \
| Second char line of bitmap 0 (0-7 pixels) | |
+--------------------------------------------+ |
| Second char line of bitmap 1 (0-7 pixels) | |
+--------------------------------------------+ |
| Second char line of bitmap 2 (0-7 pixels) | |
+--------------------------------------------+ > Chunk 1 with shared $d800 colors: $d828 - $d84f
| Second char line of bitmap 3 (0-7 pixels) | |
+--------------------------------------------+ |
| Second char line of bitmap 4 (0-7 pixels) | |
+--------------------------------------------+ |
| Second char line of bitmap 5 (8 pixels) | /
+--------------------------------------------+
| Third char line of bitmap 0 (0-7 pixels) | \
+--------------------------------------------+ |
| ... | :

this is achieved by creating a badline condition every 1-7 pixels and setting $dd00/$d018 appropriately. after 5 of these, we do not trigger a new badline condition, but wait for 8 rasterlines. this will cause the vic chip to move on to the next char line of data. char lines that are 0 pixels high are skipped.

the memory layout looks like this:
+-------------------------------------------------------+
| $2000: bitmap 0 | $3c00 screen 0 |
+-------------------------------------------------------+
| $4000: bitmap 1 | $5c00 screen 1 |
+-------------------------------------------------------+
| $6000: bitmap 2 | $7c00 screen 2 |
+-------------------------------------------------------+
| $a000: bitmap 3 | $bc00 screen 3 |
+-------------------------------------------------------+
| $c000: bitmap 4 | $dc00 screen 4 |
+-------------------------------------------------------+
| $e000: bitmap 5 | $fc00 screen 5 |
+-------------------------------------------------------+

the effect of this is that each charline is stretched out over chunks that are a maximum of 43 pixels high.

the picture is spread out over 6 different bitmaps, with 7 pixels of bitmap data in each bitmap, except for the last bitmap that has 8 pixels of bitmap data per charline. each of these 7 pixel or 8 pixel charlines can have their own screen colors, but the $d800 colors are the same for each chunk. because of these novel color restrictions, the picture must be tailored specifically for this screen mode.

we can now control the height of each of these chunks by changing how often we trigger the badline conditions. a chunk can be as small as 8 pixels high and as large as 43 pixels high. but because the last char line of each chunk always must be 8 pixels high, there are very visible visual artifacts in the lower ranges.

we can also scroll the screen up and down easily by either doing a linecrunch or an fld. no data copying is needed.

as can be seen in the memory layout, we are using a portion of the bitmap memory for the color screens. this allows us to use the full 6 bitmaps, except for the last 4 char lines of each picture. in total, this allows to use a maximum of 21 * (5 * 7 + 8) = 903 pixels for the picture.

(if we were to avoid using that portion of the bitmap memory for the screen, we would have to use the last 4 char lines of each bitmap too, but this would have allowed us to use only 4 bitmaps in total. the total height of this would be 4 * (3 * 7 + 8) = 725 pixels. it would also limit the amount of squeeze that we could achieve.)

in this demo, the picture uses only 400 lines and only 3 bitmap areas are used.

Thx for the explanation Adam. So it’s like line doubling but for bitmap, right?