Previous thread: FPGA64 > VHDL 6567 > sort of a "TTL styled schematic"

This thread is for collecting some ideas\concepts about how to build something like a "TTL implementation of the VIC-II"
as a support for the C74 project.

Just in case we might try "pushing the envelope" at some point (by increasing the amount of colors or the screen resolution etc.),
maybe like in the C65, it would make sense to take a look at the VIC-III\4567 in the C65 manual.
Newer info about the C65 seems to be here.

;---

Edit:
Found a list of Commodore patents.
Interesting read from 1983:

Patent US4572506: Raster line comparator circuit for video game. //David W. DiOrio
Patent US4551682: Digital sine-cosine generator (for use in color television signal generators). //Albert J. Charpentier, et al.
Patent US4561659: Display logic circuit for multiple object priority. //James W. Redfield, et al.

Now to mention "system integration issues" before they start slipping from my mind.
// Sorry: that's a lot of text.

;---

Assuming that we have a CPU with a 24 Bit address bus (that's 16MB, or 256 pages 64kB each),
it would be nice to have sort of an 8 Bit register for selecting one of those 64kB pages
for the VIC-II.

But having additional registers inside the VIC-II would cause an incompatibility.
VIC-III was in VIC-II mode after a RESET, with CPU access to the additional registers\Bits blocked.
To enable CPU access to those registers, one had to write $A5, then $96 into the KEY register at $D02F.
Writing a different value into $D02F blocked CPU access to those additional registers\Bits again.

BTW: I'd like to mention, that the C65 had screen modes with a higher resolution than 320*200,
but IIRC the sprites always were displayed like in 320*200 mode (if we ignore where those
sprite pointers were located in memory).

;---

In the C64, we had a 1K*4 SRAM (2114) as color RAM, and 64kB DRAM for "the rest" of the video data.

The C65 had two 64kB blocks of DRAM, IIRC in the lowest resolution color RAM was in block 1
and "the rest" of the video data was in block 0.
The address bus was partially split for both blocks, and the data bus was 16 Bit.

This brings up an interesting question what would be better:
To go for a C65 like concept by having two 8MB blocks of memory with something like a partially split
address bus and a 16 Bit data bus, placing the color RAM somewhere into the odd 64kB pages.
Or to stick with the C64 concept, what means one 16MB RAM block with 8 Bit data bus,
then to use a 512kB SRAM as color RAM (as in "256 pages of 80*25 color RAM should do for everybody").

// I'd vote for the C64 like concept.

;---

I'd like to mention that there are two more concepts for "system integration",
but IMHO they don't look too practical for the C74 project.

Both concepts would require to have two identical character generator ROMs,
one for the CPU and the other "hidden" inside the VIC...
plus some address decoding logic inside the VIC because the character generator ROM could be turned off.

On the bright side, there probably would be more video bandwidth, and the possibility to run the VIC
and the rest of the system with separate\different clocks, making it possible to play PAL SID tunes
while displaying a NTSC picture, Genlock, etc.

The first concept would be using dual port RAM for the display memory, the 64kB IDT7008 seems to be available
with a PLCC84 package which still could be manually soldered. For the 128kB IDT7009, it's a little bit different...
But dual port RAMs tend to be expensive, they drain quite some current from the power supply,
they are somewhat exotic, and you don't know for how long they will stay in production.
So IMHO using a dual port RAM in a "mission critical" place of the design doesn't appear to be a bright idea...
besides that having 64kB display RAM in a 16MB system somehow sucks.
Not a good concept.

The second concept would be to have quite some RAM inside the VIC (unfortunately that would be up to 16MB),
then to passively snoop the CPU bus for write cycles and to keep them in a latch (or in a FIFO like IDT7200)
until the VIC is able to write/mirror them into the "internal" display RAM.
Point is, that the VIC-II doesn't _write_ display RAM (for VIC-III that's different because it has a Blitter),
and the 6502 won't do two consecutive writes to memory, except for the stack area when responding to an interrupt.
Unfortunately, for compatibility reasons it most certainly would be neccessary to mirror the memory below $0400
into the "VIC internal" display RAM too.
German C64 wikipedia mentioned that the Flash 8 accelerator card
didn't give the VIC access to zero page and stack what had caused some problems.
But FIFOs are exotic, too... and you don't know for how long they will stay in production.
Not a good concept, either.

;---

Decisions, decisions...

Some years ago, I did build my own (monochrome) TTL CRT controller, D04.
(Scroll down the page.)

Because generating the display address plus the control signals tend to take a lot of TTL chips,
I had decided to use a 27512 EPROM containing a "lookup table" instead.

The 8 MHz dot clock was divided down to 1 MHz by using a 74163 counter.
A 15 Bit counter (built from two 74393 counters) running at 1 MHz provided a 15 Bit address for the EPROM.
The EPROM then generated one 16 Bit word per microsecond which contained display address and control signals
(including sync signals and a RESET signal for the 15 Bit counter).

I'd say, that this trick also should work when it comes to building a TTL implementation of the VIC-II.



As a thumb rule, we could expect that the EPROM (one big EPROM or some small EPROMs)
would have to generate about 6 Bytes per microsecond.

Ok, maybe I had missed some control signals in this diagram...
on the other hand, the refresh counter value doesn't have to be generated by the EPROMs,
one could use a 74393 counter plus an inverting buffer like the 74240 instead.
Because when inverting the outputs of an up_conter, it _looks_ like a down_counter.

Because of the Y scrolling (and the 3 Bit comparator related to it),
the ROW and COLUMN counters would have to be implemented by using TTL chips, sorry.

BTW: we have 40 characters per line, that's $28 hexadecimal.
Interesting question is if we only need a latch for Bit 9..3 in front of the COLUMN counters.

When adding another address line to the EPROMs, one could have a switch on the front panel
to select for PAL or NTSC timing (that signal would have to go to the clock generator, too).

;---

Edit:
Dang: I just noticed that there seemed to be nothing about generating that AEC signal in FPGA64.
So the AEC generation is missing in my drawings, too.

From Christian Bauer's article about the 6567/6569:

Thanks for doing this Dieter! I'm sure it will prove an invaluable resource to better understand the internal workings of VIC II.

_________________
C74-6502 Website: https://c74project.com

Just trying to help.

BTW:
building something that has the functionality of the VIC-II won't be too difficult,
but building something that would be cycle and timing compatible certainly won't be easy.

All we could do here is to aim for sort of a 99% compatibility, and to hope this would do.

Using EPROM for generating most of the control signals plus X and Y feels like cheating,
but it gives us some flexibility in case we "misinterpreted" something there...

If we would be building the BA logic for the sprites like in FPGA64,
this probably would take one page of schematic with conventional TTL chips.

The interesting question here is:
If we would generate the Sprite2..0 signals one PHI cycle ahead with the EPROM,
would it be possible to generate the BA signals for the sprites with
a 74151 8:1 multiplexer by tapping into the sprite enable Bits ?

For the rest of the circuitry, we would have to delay Sprite2..0
by one PHI cycle, of course.



;---

Another thing is, that the VIC-II internally stores video data and color
for one line of text inside sort of a "shift register", that's 40*12 Bit.

Would suggest to use two SRAMs instead, with their address lines fed by the COLUMN counter.
Interesting side effect would be, that the text video plus color data for a complete frame
would be stored inside the RAM, what might be useful when it comes to interlaced...

There are some registers the VIC-II does modify:

$D011 MSB Raster Counter
$D012 Raster Counter
$D013 LightPen X
$D014 LightPen Y
$D019 Interrupts
$D01E collision sprite/sprite
$D01F collision sprite/data

For all the other registers, the CPU only would read values
which previously were written by the CPU.

After a reset, the C64 Kernal clobbers/overwrites all the VIC-II
registers...

So in theory, if this simplifies the layout, one could use 74273 or such
for those registers and to add a fast SRAM for "faking" register reads.
The idea is that register plus RAM are written by the CPU,
but that the CPU doesn't read the register itself but the SRAM "shadow" instead.

;---

Interesting part is, that the color registers are starting at $D020,
and that the CPU clock is supposed to be synchronous to the dot clock.
When tinkering with the RAM R/W timing etc., would it be possible
to have the color registers in that RAM only ?

BTW: it's a pity that the 74538 (AM25LS2538) went out of production,
else one would have been able to place $00 on the internal data bus
during a hardware RESET for loading all internal registers with $00.

Also, I'm worried about the availability of the 74670,
looks like it might be going out of production at some point.
Anyhow, I'm not sure if the 74670 could handle a 20MHz external bus...

Now about horizontally\vertically "pushing the envelope".

A problem when trying to increase screen resolution is compatibility.
Since the picture requires more memory, and the VIC-II only can generate
a 14 Bit address, one would be forced to tinker with the generation of
A14 and A15 for the VIC-II memory address at some point if the picture
requires "too much" memory.

In the C64, the color RAM is 1kB in size, starting at $D800.
If the color RAM would be bigger than 2kB in size, it would conflict
with the Kernal ROM which starts at $E000.

When the picture takes more memory, it's also an interesting question
at which place in memory the sprite pointers will show up...

It would be nice to at least try to be compatible with "something",
and that's why I had to add a link to the C65 documentation at the start
of the thread.

;---

Increasing the horizontal resolution from 320 to 640 doesn't look too complicated.

For 320, we have a ca. 8MHz dot clock and a ca. 1MHz PHI clock (I'm simplifying things).
A 74163 working as a 3 Bit counter (those three Bits also go to the sprite X comparators)
divides the dot clock down to ca. 1MHz for that 15 Bit counter feeding the control ROM
address inputs.

When doubling the horizontal resolution to 640, we need a ca. 16MHz dot clock,
and the external bus has to run with a ca. 2MHz PHI clock for feeding the shift registers.
If the 74163 works as a 4 Bit counter, we still could run the 15 Bit counter for the
control ROM with ca. 1MHz.
Sprites are still displayed like in 320 mode, so the sprite shift registers
still are clocked with ca. 8MHz, and the uppermost three Bits of the 74163
have to go to the sprite X comparators.

The COLUMN counter would have to run at PHI speed (ca. 2MHz), and needs to have an additional Bit.

;---

Increasing the vertical resolution from 200 to 400 does look complicated indeed,
because we need to go interlaced.

Now about interlaced, and about increasing the vertical resolution from 200 to 400.

First:
That odd looking vertical sync pulse train sure looks a little bit confusing in the specs,
but I'd like to point out that when the specifications for the video signal were made,
the basic idea was that a TV receiver built with technology from ca. 1960 should be able
to detect the vertical sync even if the TV signal received per antenna shouldn't have
a too good quality.

If you don't stick too closely to the specifications, the TV still might properly trigger
to vertical sync, and generating the vertical sync pulse won't be "rocket science".

From my own experiments: if you just want to send that video signal from the computer
on your desk to the monitor on your desk, hammering out one "monolithic" vertical sync pulse
with the length of 5 raster lines should do for PAL. (For PAL, one raster line is 64us.)

So for the rest of my text here, I assume we are out to generate something like that.
Out of convenience, I'll also stick with the numbers for PAL...
because I'm more familiar with PAL than with NTSC.

;---

// Interlaced for dummies.

Conceptually, interlaced mode is a kludge (as in 'dirty hack') for increasing the resolution
of a picture without that the overall frame rate drops...
But of course, you can't fake bandwith that isn't there.

For non_interlaced PAL, we have one frame per picture, 50Hz display rate (20ms),
containing one vertical sync, raster line counting would be 0, 1, 2, 3, etc.

For interlaced, the trick is to split the picture (frame) into two fields.
Each field (20ms) contains one vertical sync, but in the second field the vertical sync
is delayed by half a raster line.

This has the effect, that raster lines of the second field end up with a slightly different
vertical position on the screen. Means the raster lines of the second field are displayed
"between" the raster lines of the first field.

So for the first field, raster line counting would be 0, 2, 4, 8, etc. (lowest Bit always 0)
For the second field, raster line counting would be 1, 3, 5, 9, etc. (lowest Bit always 1).

So if pixels would be only present in one field, they would be displayed at 25Hz (PAL),
and for the human eye they would appear to be flickering.

This probably won't cause epilepsy, but I'd say in the long run trying to do something
like coding or CAD layout on an interlaced PAL screen would tire the eye of the end user.
I'd say, in the long run end users most certainly would prefer non_interlaced.

IMHO interlaced might be "a nice gimmick" for the one or other video game... but that's it.

;...

For modifying that VIC-II to display interlaced, I think some creative tinkering
has to be done with the ROW counter and with the Yscroll comparator.

Would suggest to leave Y as it is in non_interlaced, for displaying the sprites like
in non_interlaced mode...
also to get around "compatibility issues" with the raster count register etc.

COLUMN counter would need an additional Bit.

One trick would be to give the EPROM that generates the vertical sync an additional
address line, fed by a 7474 flipflop which toggles when a field was displayed
in interlaced mode. For non_interlaced, the flipflop is forced to zero.

A BadLine is, if the VIC-II has to fetch text and color data for one line of text,
and in this raster line the CPU won't have much bandwidth on the bus.
Since characters vertically have 8 dots, a non_interlaced display mode usually means
to have one BadLine followed by 7 "normal" lines.
For interlaced, as a thumb rule expect to have twice as many BadLines per field.

If we would happen to have enough RAM inside the VIC-II which can hold the text and color
data which was fetched from external memory during the first field, in theory we could
use it to get around having "BadLines" that would slow down the CPU in the second field.

;---

Now for just a few links:

Wikipedia on interlaced
About interlacing
Video signal standarts

A German search term would be Zeilensprungverfahren.

Also, there is an old ST databook containing info about the EF9345 and EF9367 at Bitsavers.
EF9345, page 23 of the PDF (page 22 of the scanned document).
EF9367, page 152 of the PDF (page 151 of the scanned document).

Hmm... that transistorized RGB amplifier from the EF9369 application note in the ST databook looks nice,
we might need this later, page 259 of the PDF (page 258 of the scanned document).

VIC-II has 5 valid display modes
(and 3 invalid display modes in which the screen is supposed to be blank).

Tried to do sort of some flow diagrams about what to do with the pixel data
at the output of the video shift registers.

BTW: "visible" in those flow diagrams means the pixel isn't inside the border
(and the pixel isn't inside the retrace blanking periods).

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.

Now for the "hot part" of the design:
The circuitry that converts parallel video data to serial 4 Bit pixel color data.


Schematics are just provided as a concept of what to do with the data,
nothing more, nothing less. And it all probably contains some errors...

Notation looks a bit odd... mainly because I did this stuff in 2016,
before trying to dig into FPGA64, I just found the time to clean them
schematics up a little bit...


Note that 74670 'color register' block starting at $D020 in memory,
first color register would be Register32 of the VIC-II.
(One probably won't be building it by using 74670, but... well...).

Also note that 4 Bit address bus labeled ACOL3..0 for selecting the color register.

The block labeled 'Conv.' "somehow" converts the 4 Bit color data to digital RGB,
could be a ROM, a palette RAM, or both.

An interesting new mode might use the upper 4 Bits of an 8 Bit color RAM to map in any of 16 different display RAM blocks (at the same 8x8 pixel block size that the colour also applies to). This will allow the use of high resolutions without using extra address space, 16 x the amount of pixels might be overkill, you only need 4x to double the res in both directions, perhaps use 6 Bits for colour and 2 Bits for display RAM mapping, giving the 4x required to double the resolution.

Edit: This would also require a means of mapping each display bank into the CPU address space for writing the graphics data in the first place, perhaps re-purposing the address of a Light Pen register to act as a bank select for the display bank accessed by the CPU.

Thanks, Cray Ze:
Using the upper 4 Bits of an 8 Bit color RAM for displaying something _different_ than color with them
is a nice idea, and I haven't noticed that possibility for "compacting" a picture.

Would be nice, if you could elaborate this more into detail...
I'm just going to need to post two more schematics pictures now to prevent some details from "slipping from my brain".

The bad thing when trying to implement the video data shift registers is,
that they shift one Bit per clock cycle when there is no multi_color,
but two Bits at every second clock cycle when there is multi_color.

An approach "according to the school books" would tend to result in quite some circuitry,
the circuitry probably would look a bit ugly, and it won't be too fast.


Inspired by the Air inlets of the SR-71, I decided to tinker with a concept
that pre_formats the 8 Bit data stream from the external data bus by using
two 74157 multiplexers into a 16 Bit bus, feeding two 74166 shift registers
(labeled H and L for a reason I don't exactly remember now) for shifting
the 8 Bit data.



IMHO this simplifies the circuitry fed by the shift registers a lot.

I'm not sure, if that AND gate for data\sprite collision detection
is placed correctly there, you better check.

/SGOT are signals from the 8 sprites, indicating that the sprite got display priority.

That 74257 feeding ACOL3..0 just increments a 2 Bit value by 1.
(74283 probably would have been slower... and without output enable.)