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...