More is less

Somewhat paradoxically, the tile data for 2BPP mode is actually less than that required for 1BPP mode.

Why? Because in 1BPP mode, 2 bytes are required per scanline to store 10 pixels (10 bits) of tile data. In 2BPP mode, 3 bytes - only 50% more - are required to store 10 pixels (20 bits). Note however that whilst four (4) copies of the tiles are required for 1BPP mode (corresponding to shifts of 0, 2, 4 & 6 pixels), only half as many copies (2) are required for 2BPP mode (shifts 0 & 2 pixels only). Hence the smaller data requirement.

This is also somewhat fortuitous because the title screen data has increased in 2BPP mode, and now it fits without having to beef up the compression.

I've imported the 2BPP mode tile data and hacked the rendering routines just enough to get the left-most 16 pixels of each tile displayed. Results below:

WIP modification of the rendering routines for 2BPP mode

The remainder of the modifications to the rendering shouldn't take too much time - I've already been through this with the TRS-80 Model 4 (Z80) port when implementing the pixel-doubling, which is actually equivalent from a memory-usage perspective.

At this rate I might even have the next beta - in colour - available for release in a few days!