MOS Technology VIC-II
[7] Some of the graphics modes on the 64 are really strange, and they have no analogs to the Atari or Apple, like the ability to change color of the character basis across the screen.
The VIC-II is programmed by manipulating its 47 control registers (up from 16 in the VIC), memory mapped to the range $D000–$D02E in the C64 address space.
By reloading the VIC-II's control registers via machine code hooked into the raster interrupt routine (the scanline interrupt), one can program the chip to generate significantly more than 8 concurrent sprites (a process known as sprite multiplexing), and generally give every program-defined slice of the screen different scrolling, resolution and color properties.
Many demos and some later games would establish a fixed "lock-step" between the CPU and the VIC-II so that the VIC registers could be manipulated at exactly the right moment.
Adding an all-points-addressable bitmap mode was one of the Commodore design team's primary goals, as the VIC-I lacked such a feature.
In hi-res bitmaps, screen RAM is used to hold the foreground and background colors of each tile (high and low nibble of each byte).
Despite the high level of color detail and all-points-addressable capabilities of bitmap mode, it is generally impractical for in-game graphics due to requiring a high amount of system resources (8k for the pixel data plus considerable more CPU cycles to modify each tile) and normally cannot be scrolled.
In theory the maximum number of different sprites visible at the same time is 256 (assuming the VIC-II's entire 16k page was filled).
They are addressed by using a block number to refer to each sprite pattern in memory beginning with 0 and going to 255 ($FF) depending on their position in the video page.
Because the horizontal position register for each sprite is one byte and limited to a maximum value of 255, it alone cannot cover the entire 320 pixels of the VIC-II's screen area, so an additional register called the Most Significant Byte Flag provides a 9th position bit for all sprites.
VIC-II scrolling is a relatively complicated, CPU intensive task, although it is not uncommon for C64 game programmers to cheat by designing graphics so that the color RAM can remain static.
Another standard trick is to use a section of the screen (perhaps the bottom or top 4 or 5 character rows) as a game status area to display score, lives, etc.
Two 1k blocks of screen ram are reserved; one is displayed while another is written to, then during vblank they are quickly swapped through manipulation of the VIC-II registers.
In the computer's power-on default state, the first MOS Technology CIA chip generates a maskable interrupt (IRQ) 60 times per second (whether NTSC or PAL, this is unrelated to video refresh) which sends the CPU to the kernel IRQ handler at $EA31.
The handler acknowledges the CIA's IRQ, updates the clock, scans the keyboard, and blinks the cursor in BASIC.
The game remaps the IRQ vector at $0314/$0315 to its raster handler which performs these functions and then optionally executes a JMP $EA31 instruction to return control to the kernel.
The VIC-II may also generate a raster interrupt from the collision registers, but this feature is rarely used as it provides insufficient information to the program in most cases.
The fourth segment ($C000–$FFFF) is also a good choice provided that machine language is used, as the kernel ROMs must be disabled to gain read access by the CPU, and it avoids having discontiguous program code and data that would result from using $4000-$7FFF.
The screen RAM, bitmap page, sprites, and character sets must all occupy the same segment window (provided the CIA bits aren't changed via scanline interrupt).
The last six bytes of system memory ($FFFA-$FFFF) contain the IRQ, NMI, and reset vectors so if the top of memory is used to store a character set or sprite data, and the KERNAL ROM is switched out revealing the RAM underneath to the CPU, it will be necessary to sacrifice one character or sprite to avoid overwriting the vectors.
's Gazette's Basketball Sam & Ed, overlay two high-resolution sprites to allow two foreground colors to be used without sacrificing horizontal resolution [1].
[13] The full palette of sixteen colors is generated based on variations of YPbPr signals as shown below:
The 8564/8566 VIC-IIe in the Commodore 128 uses 48 pins rather than 40, as it produces more signals, among them the clock for the additional Zilog Z80 CPU of that computer.
The other extra register is for toggling between a 1 MHz and a 2 MHz system clock; at the higher speed the VIC-II's video output is merely displaying every second byte in the code as black hires bit-pattern on the screen, suggesting use of the C128's 80-column mode at that speed (via the 8563 VDC RGB chip).
[17] The earliest revision of the VIC-II was used in machines made during 1982 and early 1983; it had a ceramic shell for thermal reasons and generated 64 NTSC color clocks per line.
Later revisions had a lower cost plastic shell and 65 color clocks per line (for NTSC, 63 for PAL), as well as separated chroma and luminance, allowing for an early form of S-video.
Several revisions were made chiefly in the interest of improving video output quality, which was poor on the early units, and eliminating a bug that would cause random pixels to appear on screen (a few early games intentionally exploited this for graphics effects that consequently did not work on later C64s).
Commodore tried an impromptu solution for this by using the aluminum RF shield as a heat sink (on NTSC machines; PAL machines were sold in countries with less restrictive RF interference standards than the United States and so only used aluminized cardboard), however it was not entirely effective at preventing overheating and chip failure.
