>The GPU also supports a text mode where the bytes of video memory alternate between a color byte and a code point representing a text character. The color byte is used with the second video DAC to represent two 8 color values for foreground and background. The text mode can also support a high res graphics mode with two pixels per byte of video memory.
That explains a bit more. 2 pixels per byte and then here comes 416! That number is odd, meaning they have done some thing unique, IMHO.
So we get 4 bits per pixel. 8 colors uses up three of them, so that last bit must combine pixel data in some novel way.
4 dither patterns goes into 8 colors nicely, 2 colors per pattern.
It could mean each pixel can be one of 8 colors with no constraints.
Or, each pair of pixels is assigned a color, which would come from the 8 already defined. And maybe the order is toggled in some regular way.
Oh, wait! Maybe he did what Woz did on the Apple 2!
One byte has a data form like this:
DD_CCC_CCC
CCC = colors 0 through 7 for the even and odd pixel
DD = dither patterns 0 through 3 which make use of the scanline counter and pixel order in the byte
00 = pixels are assigned colors as given by their respective CCC fields.
01 = pixel color order swapped on odd lines
10 = pixel color order swapped on odd lines
11= both!
Looks like this: DD = 00
Pixels go by color at all times
0123456701234567 line 0
0123456701234567 line 1
A line looks like this:
00_CCC_CCC 00_CCC_CCC 00_CCC_CCC 00_CCC_CCC 00_CCC_CCC 00_CCC_CCC 00_CCC_CCC 00_CCC_CCC
...where the two zeroes are bits and the CCC fields are for the odd and even pixel in that byte.For brevity and clarity I am just going to write pixel color numbers 0 through 7 rather than all those bits.
00
01_23_45_67_01_23_45_67
And I am on Mobile, so I will also ditch delimiters. I think it remains clear enough. Hope so! 00
0123456701234567
Ok, here we go! DD = 01 -- Horizontal Dither Odd
0123456701234567 line 0
1032547610325476 line 1
.
.
.
DD = 10 -- horizontal dither even
1032547610325476 line 0
0123456701234567 line 1
.
.
.
DD = 11 Both odd and even dither!
1032547610325476 line 0
1032547610325476 line 1
.
.
.
Using just black and white pixels:
00
🟈0🟃0🟈0🟃0
🟈0🟃0🟈0🟃0
🟈0🟃0🟈0🟃0
🟈0🟃0🟈0🟃0
01
🟈0🟃0🟈0🟃0
0🟃0🟈0🟃0🟃
🟈0🟃0🟈0🟃0
0🟃0🟈0🟃0🟃
10
0🟃0🟈0🟃0🟃
🟈0🟃0🟈0🟃0
0🟃0🟈0🟃0🟃
🟈0🟃0🟈0🟃0
11
0🟃0🟈0🟃0🟃
0🟃0🟈0🟃0🟃
0🟃0🟈0🟃0🟃
0🟃0🟈0🟃0🟃
Frankly, if this is what they did, It is very expressive. I would get a lot out of a mode like this. Dithers can be pretty expensive either to compute dynamically, or in terms of stored images.These patterns can be applied on a byte basis! It is close to the next best thing if we can't have 16 colors.
What I meant by "he did what Woz did" was put those high bits to good use. On the Apple, Woz shifted pixels a bit to deliver a 6 color high resolution graphics screen. I am sure you all have seen how expressive Apple artifact graphics can be.
It is way more than what one can do on a 4 color screen, particularly given the pixels get fatter. One trades a lot of detail.
Now, this scheme has those same attributes! Resolution potential remains high, just like the Apple high resolution screen. Nice, small pixels.
But now the number of apparent screen colors goes way up! Those pattern variations will yield tons of fairly automated, consistent color impressions.
Instead of a 8 color screen, or a 16 color one, it is as if more like 24 or even maybe 32 colors are available.
This is all a big guess of course. But it is a somewhat informed one that takes TTL possibilities into account as I understand them.
BTW, if this ran at TV NTSC frequencies, and offered 320 pixels per line, or offered some combination of pixels that repeats evenly into the NTSC color cycles, given that odd number of pixels, it would be gorgeous! Just saying.
https://hackaday.io/project/164212/gallery#0f87e94323e101952...