From here on, I will be creating schematics as I redo my boards since I have done enough testing, and know know what will work and what will not. Timing from 400x300 (20MHz) up to 640x480 (25MHz) may still be a bit of a pipe dream, but the circuitry remains the same either way.
Changing from 400 to 640 only involves swapping the master oscillator, and the rest is done by the VIC-20 on startup, since the Sync Generator is fully programmable. So if 25 MHz breaks my breadboard, I will go back to 400x300 resolution.
The schematic for VIC-2000 will be massive, so I am going to break it into segments as layed out in clusters of breadboard rows, and by general function. This will also help when I get to the point where it's time to hand wire the real "PCB". By PCB, I mean a hand made matrix of interlaced copper strips holding each IC, which is then hand wired point to point. more on that insanity later.
This is where I plan to start...
VIC-2000 Video Data Switcher (VDS) Schematic
This VDS lives at the very top of the board, and is responsible for several functions...
- Driving the 4096 Color Anaolog DAC as 3 sets of 4 bits to the VGA Monitor.
- Driving Horizontal and Vertical Sync to the VGA Monitor.
- Syncing all signals back into alignment with the Master Pixel Clock (CLK.25).
- Switching between two 12 Bit Video Data buses during the V.Sync Period.
The VDS is a simple circuit consisting of only 4 counters, 4 buffers, and 12 resistors.
Signals FLIP.A and FLIP.B turn on 2 of the 4 buffers. The signals are always 0,1 or 0,1.
"FLIP" is a memory mapped command to the VIC-20, and it swaps A with B on the next VSync.
The 12 bit output from the active buffers feed the load inputs on the 4 bit counters.
The counters are clocked by CLK.25, and pass their data to the DAC on the rising edge.
Signal A.LINE is a blanking signal that controls when pixels are allowed to be drawn.
if A.LINE is low, then all data entering the counters is cleared. If hi, then the data passes.
Signals H.SYNC, V.SYNC, and A.LINE come from the Sync memory, which is loaded by the VIC-20.
This circuit has been proven to work well, and should have no problem with the 25MHz clock.
One obvious question would be... why not use 15 bits (3x5) for the color DAC instead of only 12?
There are actually 2 good reasons for using only 12 of the available 16 bits on the VDAT bus.
First, I am using 3 bits of the data for very low level Sprite Generator control.
Data for Sprites includes signals to wrap the X and Y counters. An EOF signal is also included.
This allows the Sprite generator to run at maximum speed thanks to very low propagation.
With only 13 bits remaining, the next even split was 3 sets of 4 bits.
The other reason is because 12 bits compresses nicely into nibbles.
A 64 pixel wide sprite for instance, can fit into 48 pixels per row.
Even though I have 4MB available on this design, it is still important to conserve space.
I will be placing this circuit very soon, since nothing else can be tested until it is working.
This shall now become the first real step in the design of The VIC-2000 Project.
Up to this point, I have been in "smoke testing and learning" mode.
Luckily, there has been more learn than smoke so far, although I did power reverse one buffer!
Seems that bread-boarding with Captain Morgan is not always the best plan.
Cheers!
Radical Brad