Now for some thoughts on generating the video signal...
Oneironaut sure did some nice basic research in his
Lazarus-64 project.
BTW: I agree about his use of notebooks.
Another interesting source might be the
Apple 2 Redbook.
Unfortunately, all this only covers NTSC, and for PAL the game is a little bit more complicated.
Of course, we could be cheating and just use the
AD725.
;---
For resolutions with more than 320 horizontal, a composite video signal isn't quite the thing,
S-Video might give a better picture.
SCART accepts analog RGB what would be best.
Electrically, that SCART connector seems to be nicely engineered. Mechanically... well... err...
Nowadays TVs (2017) still seem to accept S-Video and/or SCART,
but I'm not sure if this still is the case when somebody eventually has success in building
a TTL implementation of the VIC-II.
Same thing for analog VGA.
BTW: for "simple" analog VGA, the horizontal frequency is about 30kHz,
about twice as much as for a TV video signal.
In theory, if one would be running the VIC-II at a 16 MHz dot clock frequency (and a 2 MHz PHI clock)
for generating the video at twice the normal speed and display every raster line twice,
it might be able to drive analog VGA, but this won't be timing compatible to the original C64.
That's why the 'scan doubler' was invented.
The basic idea is that one raster line is stored into RAM, then put on the screen
two times at twice the original frequency.
Original C64 has 16 colors, 1 Nibble is 4 Bit.
8MHz dot clock, 64us per scan line (PAL)...
that would be 64*8=512 dot clock pulses (PAL) per scan line. 4 Bit per clock pulse.
Double buffering required, what would make 512*2 = 1kNibbles.
Double buffering a full field then would take ca. 312kNibbles (PAL).
Hmm... in theory, with >1.22kNibbles of RAM, one could grab the pixel data
which "drops out of the hot end" of the VIC-II, then stitch 4 pictures 320*200
together to one 640*400 picture to be displayed on a VGA monitor...
I just doubt that this would be too useful... or too software compatible to anything...
If analog video signals eventually are extinct, there still might be chips like the
TFP410 TI PanelBus DVI transmitter.
But as usual, it's hard to tell how long they would be in production... again.
And I'm not sure if you might need something like a scan doubler when aiming for DVI...
but probably... yes.
The flow diagram for the 8 Bit to 10 Bit conversion in the DVI specification looks a bit evil,
if anybody would try to roll his own binary RGB to DVI "display port IMHO" it calls
for something like a bit_serial implementation plus a fast counter,
and I'm not sure if simple TTL would be going to be fast enough...
but back on topic.
;---
It's a pity, that the EF9369 color palette chip (mentioned above in this thread) is out of production,
same thing for all the other RAMDACs.
Ok, so my advice would be to build a color palette (like in the C65) by using fast SRAM,
feeding three 4 Bit DACs for generating RGB, then to feed this into an AD725 for generating
a video signal.
This way, you won't have to worry about generating the chroma clock for the VIC-II.
Of course, to be on the safe side I'm suggesting to make quite a few test runs with the
AD725 before actually using it in a design, and I'm also suggesting to have the color data
which goes into the palette, the digital RGB data which comes out of the palette,
clock signals etc. available on some connectors, so that others could build something
different for generating the video signal if required.
The problem when using a color palette here is, that the palette won't be initialized
after power_up, and in the worst case this would turn the picture on the screen unreadable.
So one either would have to patch the C64 Kernal for initializing the palette...
or to have some ROM in parallel to the palette RAM, the ROM then overrides the RAM
after a hardware RESET and generates the digital RGB until the CPU makes the first
palette write or such.
;---
Now about pushing the envelope of the colors:
IMHO nothing speaks about making the color RAM and the color registers 8 Bit.
In theory, together with digital 4 Bit RGB this would give us 256 out of 4096 colors...
except when using hires graphics mode, of course.
To maintain backward compatibility to the 16 C64 colors, I'd suggest to initialize
the palette with 16 colors 16 times so the upper 4 Bits of an 8 Bit color RAM
(or register) won't matter when using old C64 software.