VIC chip - Dot to TV output timing

[lance.ewing]

I'm not sure if this has been discussed before but I was reading the MOS 6560/6561 specs document recently and I started thinking about the timing of the output of the dots leaving the colour decode block on its way to the television.

It is well known that the VIC chip, while the raster beam is within the currently defined video matrix, alternates between fetching the char cell index from the video matrix memory and then fetching the char bitmap line segment from character memory using the index fetched in the previous cycle (the first step also fetching the foreground colour and mode from colour RAM).

Obviously this means that for every 2 cycles, 8 pixels are written out to the television.

What I started wondering is how those dots/pixels end up leaving the VIC on their way to the TV? Does the VIC send one dot every 1/4 of a cycle? Or does it send all 8 pixels at the completion of the two cycles?

If it is the former, then how can it start sending pixels if it doesn't yet know what pixels to send? It doesn't know what pixels to send until the end of the second cycle. So what is it sending to the TV during that time? Is it sending the pixels from the previous set of 8 pixels? For example, does it have some sort of pixel queue that is always 8 pixels behind? And if that is the case then what does it do if it is the first character on a row? i.e if it has only just hit the video matrix area? Does it still send border coloured pixels for those 8 dots? And if so then does this mean that the video matrix area is drawn 8 pixels to the right of where it should be?

[Mike]

For example, does it have some sort of pixel queue that is always 8 pixels behind?

If you look closely at the video signal, you see that VIC already fetches screen and character data in the column before the display area begins, there are two distinctive vertical lines running through the left border, which repeat during the display area, but are missing in the rightmost display column and beyond, in the right border.

And if so then does this mean that the video matrix area is drawn 8 pixels to the right of where it should be?

Or it means the VIC fetches the data early enough.

[lance.ewing]

If you look closely at the video signal, you see that VIC already fetches screen and character data in the column before the display area begins, there are two distinctive vertical lines running through the left border, which repeat during the display area, but are missing in the rightmost display column and beyond, in the right border.

Are you saying that these two distinctive vertical lines are an artefact of the VIC fetching the data? And that the presence of the artefact in the column preceding the display area, and its absence from the final column of the display area, is proof that the VIC has fetched the data within the two cycles prior to when it needs it?

Or it means the VIC fetches the data early enough.

So does it ignore changes that have happened within the relevant positions in the video matrix, colour RAM and character memory that have occurred during those previous two cycles?

And what happens if within those previous two cycles the CPU has changed the register that determines the position of the left edge of the display area, such as moving it one column to the right?

More importantly, what happens if the right edge is moved one column to the right during the two cycles prior to the right edge of the display area? The VIC then wouldn't have fetched the data it needs in time. Maybe at that point it ignores changes to the right edge until the next scan line. Thinking about it, I assume that that is what it must do. It must trigger the left edge and right edge of the display area only once per scan line and ignore any other changes to those edges once they've been triggered/hit for that line.

[Mike]

It is possible to write code so it runs in sync to the raster beam, cycle exact.

You might take a look at the raster code in the thread 'VIC 20 in Black and White mode', where (for example) the background/border register of the VIC chip is written several times in a raster to get a border colour independent of the %01 multicolour source. On real hardware, changes of the colour registers happen one pixel late with regard to (half) character boundaries.

Similar code could be employed to check the exact dependence between VIC fetches and pixel output. In summary, you'll arrive at this:

Code: Select all

BUS DATA                     DISPLAY

VIC fetch (screen data *)    ...
CPU cycle                    ...
VIC fetch (character data)   ...
CPU cycle                    pixel-columns 1/2 of character
...                          pixel-columns 3/4 of character
...                          pixel-columns 5/6 of character
...                          pixel-columns 7/8 of character

*) includes colour RAM data

Changes of the display-position and -length registers surely are employed within certain demos for stretching effects, etc. Again, demo coders use similar cycle exact code to test out the resulting effects, relying mostly on empirical facts.

[lance.ewing]

Changes of the display-position and -length registers surely are employed within certain demos for stretching effects, etc.

I can see how the left and right edges of the pixel/text area could be altered to achieve a stretched effect, or maybe a rippling flag effect on the edges or something like that. But I'd imagine that it isn't possible to create two separate pixel areas with border colour between them, i.e. not possible to do something like: border-text-border-text-border on the same line where there are effectively two right and left edges to the text area. Would this be a correct assumption?

Again, demo coders use similar cycle-exact code to test out the resulting effects, relying mostly on empirical facts.

I was looking at the www.visual6502.org web site a few days back. Since then I've been staring for long periods at the die shot of the 6561 that they have on that site. I found a labelled version of the same die shot elsewhere on the Internet that makes it a lot easier to see where things are. It is fairly easy to spot where the address lines and data lines are, where each of the memory mapped registers are and how they are selected based on the address line values, and roughly where things like the the address computation, colour decode and tone generation are, but trying to get in to the detail of what is happening within those regions is going to need someone with expertise in digital electronics and integrated circuit design. For example, I'm guessing that the registers are some sort of flip flop but I've got no idea how you recognise something like a flip flop or even a logic gate on a die shot. It is easy to see connections but beyond that it is a mystery.

It occurs to me though that if someone with the necessary electronic/IC expertise were to create a simulation of the 6561 that is similar to what they have done for the 6502 on www.visual6502.org then all our questions would be instantly answered.

[Mike]

But I'd imagine that it isn't possible to create two separate pixel areas with border colour between them. [...] would this be a correct assumption?

That'd be a fun idea at least to try. For the moment though, my VIC-20 is away at ~600 km distance, so that will have to wait for a few days.

OTOH, it is possible to fill a redefined character with all bytes 85 (%01010101), which - when displayed in multi-colour - will inherit the border colour as display colour, even to the point that it faithfully reproduces in-line colour changes.

MINIPAINT uses a variant of this method to display the three frames of the editor display as if they were all surrounded by the exterior border. Also, the colour 'source' 3 as shown in the status window is painted from the border colour, and displayed in the correct way at no extra cost.

[Witzo]

I came across this thread through google, and was happy to find that Lance Ewing is posting here!

What I was looking for, is a complete version of "THE 6561 VIC CHIP Video Interface Chip (VIC)
Written by Lance Ewing"

I found two incomplete copies of the text:
http://cd.textfiles.com/230/EMULATOR/CO ... E/6561.TXT
http://vic-20.appspot.com/docs/6561.txt

As you can see, both end halfway in a sentence.
Mr. Ewing, can you point me to a complete version of your work?
Thanks in advance!