VIC-II
The VIC-II is the Commodore 64 video controller. In its C64 use, the 6567/6569 family supplies a 40×25 character display, a 320×200 pixel bitmap display, a fixed sixteen-colour palette, and eight hardware sprites; it also arbitrates access to the memory needed to keep the raster running. [1][2] It is therefore both a display generator and a time-sensitive participant in the C64 bus, rather than a device that the CPU can treat as a passive framebuffer. [3][2]
Registers, modes, and the display inputs
[edit | edit source]The CPU reaches the VIC-II register block at $D000–$D02E. Its controls include the raster counter and comparator, display enable and scroll settings, colour registers, sprite controls, and a memory-setup register at $D018. [1][4] A raster interrupt can be requested when the counter reaches the programmed value, while sprite–sprite, sprite–graphics, and light-pen events have their own status and enable bits. [4][2]
Three control bits select the graphics-mode combination: extended-colour, bitmap, and multicolour. The useful documented combinations are standard character, multicolour character, extended-background character, standard bitmap, and multicolour bitmap; the remaining combinations are not normal display modes. [4][2] Character modes interpret the screen matrix as character codes and fetch glyph rows from the selected character-data area. Bitmap modes instead fetch picture bits, while screen and colour information supply attributes according to the selected mode. [1][2] This division explains why a mode change can make the same RAM contents mean something different on screen. [1][2]
The controller has a 14-bit video address space, so it reads one 16 KiB video bank at a time. CIA 2 selects which of the C64's four 16 KiB regions is presented to the VIC-II, and the relevant CIA port bits are active low. [1][5] Within that bank, $D018 selects the screen-matrix location and either a character-data location or the bitmap half of the bank. [6][2] The CPU's own ROM/I/O banking is a different mechanism, so CPU visibility of an address does not by itself show that the VIC-II is fetching from it. [5][6]
Colour RAM is a separate, fixed 1 KiB store with four-bit entries. The CPU accesses its window at $D800–$DBFF, whereas the VIC-II receives its colour bits through dedicated connections while it reads the screen matrix and graphics data from the selected video bank. [1][3][5] In the conventional layout the screen matrix has 1,000 entries; its final eight bytes serve as sprite pointers, each selecting a 64-byte-aligned sprite slot within the current video bank. [1][2][7]
Sprites
[edit | edit source]A VIC-II sprite is a separate 24×21-pixel image, with 63 bytes of picture data; the pointer convention places the image in a 64-byte slot. Eight sprite channels are directly available. [1][2][7] Each channel has position, enable, colour, multicolour, expansion, and display-priority controls. The chip also records sprite–sprite and sprite–graphics collisions, which may be enabled as interrupt sources. [4][2] Sprite data is not simply read once when software changes a pointer. The VIC-II fetches pointers and image bytes as part of its per-line schedule, so enabling a sprite changes the available bus time as well as the image that may be displayed. [2][8][7]
Raster time and CPU constraints
[edit | edit source]The chip's memory traffic follows a fixed schedule within every raster line. Besides display and sprite data, it performs DRAM refresh and accesses needed to maintain the video state. [2][8] On selected display lines, commonly called bad lines, the VIC-II must load a row of forty screen/colour entries. The condition is tied to the active display region, display enable, vertical scroll, and the raster-line position within an eight-line character row. [2][7] These matrix fetches consume bus time that the CPU would otherwise use. [8][7]
Bus Availability (BA) signals an impending demand before Address Enable Control (AEC) removes the CPU from the shared bus for the required phase. A CPU write may initially continue after BA changes because the 6510's ready input stops reads rather than writes; when AEC is low, the VIC-II owns the address path. [2][3][8] The practical consequence is not a constant processor speed: the instruction time available between raster events depends on the line, display state, and active sprite DMA. [8][7] Raster-interrupt code that changes display registers consequently has to budget the particular line rather than merely count nominal CPU cycles. [2][7]
PAL and NTSC machines require separate timing assumptions. The 6569 PAL arrangement described by the measured references has 312 lines of 63 cycles, while the documented 6567 revisions have 262 lines of 64 cycles or 263 lines of 65 cycles, depending on the revision. [2][8] VICE's timing source likewise separates PAL and NTSC line-cycle and sprite-fetch parameters, which is a useful implementation cross-check rather than evidence that one regional timing budget can be substituted for another. [9][2]
For C64 programming, the important model is therefore a coordinated one: select the VIC-visible bank and data locations, select a display mode whose data interpretation matches that layout, and reserve enough raster time for the chip's matrix and sprite fetches. [1][2][8] This model accounts for both ordinary graphics setup and the timing-sensitive display techniques that change VIC-II state at chosen raster positions. [2][9]
See also
[edit | edit source]- Commodore 64
- Commodore 64 memory map
- MOS Technology 6510
- Commodore 128
- Commodore 128 operating modes
References
[edit | edit source]- ↑ 1.0 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 “Commodore 64 Programmer's Reference Guide, graphics overview and locations”. Commodore Business Machines; transcription hosted by devili.iki.fi. pp. 100–104, 131. Accessed 2026-09-21.
- ↑ 2.00 2.01 2.02 2.03 2.04 2.05 2.06 2.07 2.08 2.09 2.10 2.11 2.12 2.13 2.14 2.15 2.16 2.17 2.18 Christian Bauer. “The MOS 6567/6569 video controller (VIC-II) and its application in the Commodore 64”. Christian Bauer; preserved by the University of Waterloo(1996-08-28). §§2.3, 3.7, 3.8. Accessed 2026-09-21.
- ↑ 3.0 3.1 3.2 “C64C Service Manual”. Commodore Business Machines; archival copy at Retro Kit. “C64 Circuit Theory”: clock circuits, I/O address decoding, and RAM control logic. Accessed 2026-09-21.
- ↑ 4.0 4.1 4.2 4.3 “VIC-II 6567/6569/856x reference”. Oxyron. register table for $D000–$D02E. Accessed 2026-09-21.
- ↑ 5.0 5.1 5.2 “VIC-II for Beginners Part 1 – When Visibility Matters”. Dustlayer(2013-04-22). “The Limited Power of Sight of the VIC-II”. Accessed 2026-09-21.
- ↑ 6.0 6.1 “Commodore 64 memory map”. STA C64 Technical Archive. $D018 memory-setup entry. Accessed 2026-09-21.
- ↑ 7.0 7.1 7.2 7.3 7.4 7.5 7.6 “vicii-fetch.c — VICE VIC-II fetch implementation”. VICE Team. handle_fetch_sprite(): screen-base + $3F8 pointers and pointer × 64 source addressing. Accessed 2026-09-21.
- ↑ 8.0 8.1 8.2 8.3 8.4 8.5 8.6 Marko Mäkelä. “The memory accesses of the MOS 6569 VIC-II and MOS 8566 VIC-IIe Video Interface Controller”. Marko Mäkelä; preserved by the University of Waterloo(1994-06-03). timing diagrams and legend, pp. 1–4. Accessed 2026-09-21.
- ↑ 9.0 9.1 “vicii-timing.c — VICE VIC-II timing implementation”. VICE Team. PAL/NTSC cycles-per-line and sprite-fetch-cycle constants; vicii_timing_set(). Accessed 2026-09-21.
Automation and sourcing note
[edit | edit source]This candidate was independently synthesized from the cited sources under c64.wiki publication policy. It contains no copied or lightly paraphrased source prose, no source-code extracts, and no images, scans, or screenshots; cited historical manuals and schematics are used as citation-only evidence.