While the preceding post was about generic video generation, this post will specify what is used by bitBox console for Video Generation.
First, the DAC : it will be a simple DAC made of resistors. A R2R ladder
could be used, it can be nice to only have few values of resistors when
manufacturing. Well, that’s nice but for now we’ll using less resistors
since we will manufacture by hand (duh) so a resistor DAC will be used. I
first tried a 8bit RRRGGGBB (as 8 bit).
That’s what the uzebox
(The 8bit homebrew console, it’s great and has been a great
inspiration) used with a 8 bit microcontroller, but here we have the
capacity (cpu and momory wise) to do a little more.
How much colors should we be able to display ?
It’s a question
of balance : more bits in the DAC looks better, but more bits mean more
CPU to build the signal and memory to store the nice graphics, as well
as a bigger RAM / Flash to store the graphics and more hardware complexity.
finally settled for 4096 colors, which is 4-4-4 = 12 bits + 4 unused
bits on a 16 bits output bus. The use of a palette will be defined by
the software, so let’s not talk about that now.
15 bits could also have been done, but I think 12bits will provide
nice colors anyway. The games won’t be photorealistic, so vivid colors
is aimed at, not realistic.
Then, how many pixels should we be able to output ? That’s a software thing ! Nothing in
hardware sets the number of pixels, as vertically it’s how often we fire
the h-sync, and horizontally is how fast we make the pixel vary.
Let's try defining a first video mode (all by software).
We should try to build on a standard VGA timings, which might be
easier for VGA screens to sync on because it’s a standard resolution, as
well as being compatible with many screens.
The universal resolution is 640x480, 60Hz, which is a resolution supported by quasi everything (even HDMI supports it - but of course we are not generating hdmi with a few resistors).
Note, however, that this will be the resolution the screen thinks it
gets. By example, there is no difference between varying the pixel levels
twice slower and having horizontally twice larger pixels : it’s the same thing.
As well, if you’re outputting the same line twice, it will effectively provide half the resolution. That will provide you by example 320x240 @ 12 bits if you vary the pixel clock for 240 pixels.
You can also "forget" to send anything for 20 lines after and 20 lines
before your signal, so you’ll have black lines and 320x200. Which has
the nice property of needing a 64k frame buffer if we use 1 byte per
pixel. 128k for double buffering… but more on that later.
Extra reading on that subject : http://www.diycalculator.com/sp-console.shtml