Re: VIC-2000 Expander. Modern Power Using Retro Parts!
Posted: Thu Nov 23, 2017 7:06 pm
Well, it ain't pretty but I have shown that the IO system does function as intended.
The World's first dual display VIC-20?...
The basic program shown on the NTSC monitor draws the pattern shown on the VGA monitor by poking the X and Y location as well as color value through the IO system on the logic board. The resulting image is using the lower resolution of 400 x 300, and only 64 of the 4096 available colors.
The reason for the digital noise is due to the way I slapped this all together for testing.
When the VIC does "POKE 38917,0", it is triggering the WE line to go low on the frame buffer SRAM.
That same line attempts to disable the counters that are actually generating the video frame.
Because of the few nanoseconds of bus turnaround time, the memory gets the odd glitch.
In my real design, there will be no such quirks, and everything will be double buffered.
Double buffered means the VIC is drawing a screen at its leisure while the SyncGen is displaying another.
When the VIC (or GPU) is ready, it simply issues the command to flip the buffers.
Oh, and that simple pattern took VIC Basic more than 10 minutes to draw!
I wouldn't want to raytrace a complex scene in basic, that's for sure.
Ok, now I have some serious decisions to make so that I can move forward.
Seeing this cool "Dual Display VIC-20", I almost think this is the way to go.
.. run the IDE / Assembler on the original VIC display, and let the assembled program run on the VGA display.
I will have my decision by tomorrow.
Later,
Radical Brad
The World's first dual display VIC-20?...
The basic program shown on the NTSC monitor draws the pattern shown on the VGA monitor by poking the X and Y location as well as color value through the IO system on the logic board. The resulting image is using the lower resolution of 400 x 300, and only 64 of the 4096 available colors.
The reason for the digital noise is due to the way I slapped this all together for testing.
When the VIC does "POKE 38917,0", it is triggering the WE line to go low on the frame buffer SRAM.
That same line attempts to disable the counters that are actually generating the video frame.
Because of the few nanoseconds of bus turnaround time, the memory gets the odd glitch.
In my real design, there will be no such quirks, and everything will be double buffered.
Double buffered means the VIC is drawing a screen at its leisure while the SyncGen is displaying another.
When the VIC (or GPU) is ready, it simply issues the command to flip the buffers.
Oh, and that simple pattern took VIC Basic more than 10 minutes to draw!
I wouldn't want to raytrace a complex scene in basic, that's for sure.
Ok, now I have some serious decisions to make so that I can move forward.
Seeing this cool "Dual Display VIC-20", I almost think this is the way to go.
.. run the IDE / Assembler on the original VIC display, and let the assembled program run on the VGA display.
I will have my decision by tomorrow.
Later,
Radical Brad