VIC DMA - How?

[Schnurri]

Is the CPU halted when the VIC fetches its graphics data from memory? Are there any documentations available about this topic? I am looking forward to your answers, Schnurri

[lance.ewing]

No, the 6502 isn't halted. For the address and data lines that are shared, the VIC chip is using them during phase 1 of the clock cycle and the 6502 during phase 2. The VIC chip can get all the data it needs during that phase 1 window.

This is covered in enough detail in the 6560/6561 datasheet:

https://www.mdawson.net/vic20chrome/dis ... 61_vic.pdf

The timing diagrams towards the end make this clear.

Edit: The following document has a good description at the end of what is going on with the timing:

http://www.zimmers.net/anonftp/pub/cbm/ ... /VIC-I.txt

To quote this document:

As the dot clock on the VIC-I is only 4 times the bus clock, the video chip has time to read 2 bytes for every 8 pixels it outputs. All memory accesses are performed without blocking the processor, using the interleaved bus. The basic video timing is very simple. For every character the VIC-I is about to display, it first fetches the character code and colour, then the character appearance (from the character generator memory)

The fact that the dot clock is only 4 times the bus clock does mean that that phase 1 window is just enough opportunity to get the data it needs without affecting the CPU.

Edit 2: I've taken the VIC chip read timing diagram from the datasheet and extended it a few more cycles to make it clearer:

The only data that the VIC chip needs is the data from the video matrix memory and the data from the character memory and it accesses those in alternating turns as shown above. - Compare this with the VIC-II 6567 datasheet, which clearly says that there are DMA operations for that chip for which the phase 1 window is not enough. The VIC-I chip doesn't have such operations. Fetching the video matrix data and character memory data in the way shown above is all that it needs.

Edit 3: I just remembered that we've also got the foreground colour data for each character that the VIC chip obviously needs. This doesn't affect the CPU because it is fetched at the same time as the video matrix data (also during phase 1) via a special 4-bit dedicated data bus to the colour RAM. So the colour data doesn't go via the shared data bus. The same video matrix address "auto-magically" also addresses the relevant slot in the colour RAM, which triggers the colour data getting put onto the 4-bit colour data bus.

Here's another version of the extended timing diagram showing the colour data being fetched:

[lance.ewing]

It is also worth pointing out that the output drivers for the VIC address pins have an address output enable signal that is HIGH only when the current values of the vertical and horizontal counters are "within the matrix" (i.e. within the current text window area) and when the phase 1 clock signal is also HIGH. During phase 1 when outside the matrix, the address pins are floating and the VIC chip isn't reading any data at all, the reason being that it doesn't need to fetch any data when in the border or blanking areas.

The following is a Logisim diagram for the output driver for the address pins:

address_output_driver_with_enable.png (2.98 KiB) Viewed 3855 times

In this diagram, addr_out_enable is the current address output enable signal value, as described above. The i_address_out is the internally generated address line value to send out of the VIC. It is generated by the address computation logic in its inverse state, which is why I've put an i_ at the front. So the diagram above shows i_address_out currently LOW, which means that the address line value to be sent out is actually HIGH. We can see though that because addr_out_enable is LOW, the address_pin value is floating.

When addr_out_enable is HIGH, we get the HIGH value on the address_pin, assuming i_address_out is still LOW:

address_output_driver_with_enable_on_1.png (2.97 KiB) Viewed 3855 times

And if addr_out_enable is HIGH, and i_address_out is HIGH, then we get the expected LOW value on the address_pin:

address_output_driver_with_enable_on_2.png (2.97 KiB) Viewed 3855 times

What is curious to me then is what Marko says in the VIC-I.txt document I linked to above, about the VIC chip reading from some fixed address most of the time when the raster beam is outside the text window (e.g. $001c). This can't be the case according to what is at the silicon level. The address pins should be floating during phase 1 when outside the text window. The VIC chip in theory isn't intentionally reading anything, so the source of such an address on the address bus during phase 1 when outside the text window should in theory not be the VIC chip. - Remember that the same addr_out_enable signal is used to stop the VIC putting an address on the address pins during phase 2. So pretty sure it would be reliable.

[Schnurri]

Many, many thanks for the detailed explanation and further pointers! Best regards, Schnurri