Re: Discovered the Hi-Res Basic!

On 10/31/2017 11:57 PM, Baltissen, GJPAA (Ruud) wrote:
> This has been mentioned before but to be very honest, I even don't
> understand this " representing 4-bit pixel coverage using block
> characters " thing. When I asked if there was something like a
> "lo-res" mode it was mentioned but not understood by me and waved away
> like "I see later". What is also a bit frustrating, I'm more a
> hardware guy and seeing the link with the hardware often makes me
> understand things. But in this specific case the result is written to
> memory and I even have no idea where in memory at all (look for labe
> A_A2BD).
> It seems that this "later" has come. So an explanation of this matter from you or somebody else would appreciated highly! An URL would do too of course. TIA!

The bytes in the table correspond to screen memory codes.  Here is an
image showing what all the possible screen codes look like, POKEd
directly into memory: https://i.imgur.com/vyOVoD8.png

The screen is 80x25 characters.  Imagine if you just used the space &
inverted space characters.  The screen effectively becomes a 80x25
bitmap with really chunky "pixels", each of which is 8x8 hardware
pixels.  Each chunky "pixel" would be independently addressable as a byte.

Now, scattered inside that font are 16 "block drawing" characters, which
the a2e9 table uses, which have independent coverage of each quadrant of
the character.  You can see from the source code that the first entry in
the table is $20, or a blank space.  The next one is $7e, then $7b,
etc.  You can see them in the grid to verify what I copied out to the
top middle of the screenshot matches the glyphs from the a2e9 table.

Using these characters, you could fake a 160x50 bitmap, with each
character byte representing 2x2 of those chunky "pixels", each chunky
"pixel" covering 4x4 hardware pixels by using these particular glyphs. 
So this isn't any special screen mode, it's simply utilizing the block
drawing font characters to cover evenly divided portions of character cells.

Seeing the a2e9 table visually like that, you can see that for the 0-f
offset into the table, each of the 4 bits represents 1 pixel.  Bit 0
implies the upper-left chunk is set, 2 is the lower-left chunk, and so
on.  Offset 0 has no pixels set, and offset $f has all 4 pixels set.

So if you want to set a pixel, since it shares a font character with 3
neighboring pixels, you need to change the entire character byte.  The
code does this by:

1) reading the current character on screen (a2a8)
2) find its place in the a2e9 table, which is a 4-bit pixel bitmask  (a2af)
3) set/clear one of the 4 bits (a2c5/a2ce)
4) read the character associated with that new 4-pixel bitmask from the
table (a2db)
5) and write it back to the screen (a2e0).

       Message was sent through the cbm-hackers mailing list