"If you wish to make an apple pie from scratch, you must first invent the universe."
What a cool project if you want to build from the bottom up. Lately, I have been doing more with pi emulating the mainframe and minicomputers - but if I was retired this might be something to do for fun.
---
FTA :
Novasaur TTL Retrocomputer
* Dual Processor CPU/GPU (Harvard Architecture)
* 33 MHz dot clock, 16.5 MHz data path, 8.25 MHz per processor (~3.5 CPU MIPs)
> "Bitmapped Graphics: - Hi-res mode up to 416x240 with 8 colors and 4 dithering patterns"
I'm familiar with dithering as a multi-pixel pattern usually done by software to create the appearance of shades in between the colors that individual pixels can display - at the cost of spatial resolution (because it requires multiple pixels for the pattern). So I was thrown by what "dithering patterns" might mean in the context of a line discussing hardware specs like individual pixel resolutions and colors. My guess would be maybe some kind of hardware mode that addresses more than single pixels but that sounds like tiles. Does anyone know?
>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.
Thanks for the detailed explanation. If that's what it is doing then it would indeed be interesting and pretty unusual for a modern day homebrew system. I too wondered if maybe the dither pattern referred to something like the Apple II's artifact colors but dismissed it because artifact colors require composite video output to work and there was no explicit mention of composite.
Here is a sample image from the project site. I can't tell if this jives with your explanation. Also, I am not sure if dithering is the same as artifcating which is what I used to see on Apple II and Atari Hi-Res games sometimes to get extra "colours" out of monitors and tv sets.
What a cool project if you want to build from the bottom up. Lately, I have been doing more with pi emulating the mainframe and minicomputers - but if I was retired this might be something to do for fun.
---
FTA : Novasaur TTL Retrocomputer
* Dual Processor CPU/GPU (Harvard Architecture)
* 33 MHz dot clock, 16.5 MHz data path, 8.25 MHz per processor (~3.5 CPU MIPs)
* 256k ROM: 96k ALU, 64k native program, 64k cold storage, 32k fonts
* 512k RAM: 7 banks of 64k user, 60k display, 4k system
* 76 ALU functions including multiply/divide, system, and math functions
* Bitmapped Graphics: - Hi-res mode up to 416x240 with 8 colors and 4 dithering patterns - Lo-res mode up to 208x160 with 256 colors, double buffered
* Text Mode: - 8 colors FG/BG, 256 line buffer - Up to 104x60 using 8x8 glyphs - 80x36 and 64x48 rows using 8x16 glyphs
* Audio: 4 voice wavetable synthesis, ADSR, 8-bit DAC, 8Hzā4.8kHz
* PS2 Keyboard: Native interface built in
* RS232 Serial Port: Full duplex, RTS/CTS flow control, 9600 baud
* Expansion Port: 7 addressable 8-bit register ports, 4 interrupt flags
* Chip Count: 34 TTL (22 CPU, 12 GPU), 1 ROM, 1 RAM, 1 PAL, 4 analog
* Gate Count: 1,425 (935 CPU, 490 GPU)
* PCB size: 8" x 5" (200 x 125mm) double-sided board
* Power: 6v @ 1.6A (10W)
> "Bitmapped Graphics: - Hi-res mode up to 416x240 with 8 colors and 4 dithering patterns"
I'm familiar with dithering as a multi-pixel pattern usually done by software to create the appearance of shades in between the colors that individual pixels can display - at the cost of spatial resolution (because it requires multiple pixels for the pattern). So I was thrown by what "dithering patterns" might mean in the context of a line discussing hardware specs like individual pixel resolutions and colors. My guess would be maybe some kind of hardware mode that addresses more than single pixels but that sounds like tiles. Does anyone know?
>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!
Looks like this: ...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.
And I am on Mobile, so I will also ditch delimiters. I think it remains clear enough. Hope so! Ok, here we go! 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...