This question is about the Commodore 64 and its graphics chip, the VIC-II.

Imagine that on a particular scanline, the VIC-II needs to fetch 40 bytes (the background tiles) and since it's a badline also it needs to fetch another 40 bytes (the color attributes). That's 80 fetches it needs to make. I know that this steals 40 cycles from the 6510.

Additionally, there are eight sprites, which are three bytes wide each, on that same line, so that's 104 bytes. Actually, the VIC-II must also have worked out that each of those sprites are on this scanline. From what I remember, that's 17 bytes of data for the sprite coordinates. So I think this scenario means the VIC-II has to fetch 121 bytes.

Is that the most a VIC-II will need to fetch in one cycle? If the VIC-II needs to fetch 121 bytes from RAM during one badline, does that mean that it will steal more cycles from the 6510 than the usual 40?

  • I just remembered that the sprites also have attribute data. That means that my calculations are wrong because I forgot to add probably around 2 bytes per sprite, but the question about how there's time to do all this still stands... – OmarL Jun 27 '17 at 12:49
  • 2
    You may also find interesting Missing Cycles by Pasi 'Albert' Ojala. It's about VIC stealing cycles from the CPU. – Adam Jun 28 '17 at 10:15

There are 63 to 65 clock cycles in a scanline, depending on the VIC model (PAL, old/new NTSC). Each cycle consists of two phases, the 6510 is only able to access memory in the high phase, the VIC-II can access it in both phases. So, a PAL VIC-II can read 63 bytes from memory, without disturbing the processor at all.

Sprite color and coordinates are stored in VIC-II registers, so they are always available, no memory reads are needed to access them.

The following accesses are made by the VIC-II in the low phase:

  • pixel data, 40 bytes
  • sprite data pointers, 8 bytes
  • 2nd byte of the sprite pixel row, when needed
  • 5 dummy reads for RAM refresh purposes

that's 62 bytes, but as I've said, it doesn't bother the 6510 at all.

The following accesses are made in the high phase:

  • color attributes (graphics mode) or character codes (text mode), that's a bad line
  • 1st and 3rd bytes of the sprite pixels, when needed.

That's 40 + 2*8 = 56 bytes in the worst case (when all 8 sprites are visible on a bad line), for which the processor has to be stopped. The 6510 must actually be signalled 3 cycles before a read access in the high phase, because it must first finish whatever it's doing. Unfortunately, the sprite and attribute accesses are not consecutive, therefore up 6 additional cycles can be wasted that way, meaning that the VIC-II can actually "steal" up to 62 cycles out of 63.

See this excellent document for more details than you'd ever want to know.

| improve this answer | |
  • Is the entire region from $d000 to $d02e stored inside the VIC-II and not in DRAM? – OmarL Jun 28 '17 at 8:57
  • 1
    Exactly. Everything between $d000 and $dfff goes to some peripheral controller instead of DRAM, unless you change the memory mapping bits at $0001. There is also the text mode color RAM between $d800 and $dbff, but it's different from the main DRAM. – followed Monica to Codidact Jun 28 '17 at 9:21
  • 1
    @Wilson: Reads and writes in the range $D000 to $d3FF are serviced by the VIC-II chip. In many cases, writes will update various registers, and reads of the same addresses will report the states of the same registers, but that doesn't mean the entire region is "stored" in the VIC-II chip, since in some cases (e.g. color registers) writes will only capture a portion of the byte written. and in other cases reads may report something completely different from what was written (I think the raster line count and compare registers work that way). – supercat Jul 30 '18 at 21:05
  • Also: the color nibble RAM is in a separate chip and the VIC-II has a separate bus to access it. So it can do this in parallel with accessing the character matrix, for instance. See c64-wiki.com/wiki/Color_RAM – Rhialto supports Monica Dec 1 '19 at 16:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.