How did older computers like the Commodore 64 output to a display?

Question

I've been wondering about this for a while now. I understand that graphics cards now days hold the pixel information in their dedicated memory and output that information through the card and onto the screen. The commodore 64 and most older computers, from what I understand didn't have these video cards with dedicated memory however. I suppose they could have reserved a portion of their system memory as a sort of frame buffer. The processor could calculate pixel values and store the data in this frame buffer and then output that information to the screen. Is this how those older computers worked or is it some other process completely different?

Answer 1

Yes that is basiclly how video outputs were done thoseadays. There were memory between 1 and 8 kB reserved as video buffer, the CPU calculated the output and saved it in RAM.

However there are some differences to a modern video card:

• There were no high resolution interfaces like HDMI or VGA. Usually composite video with NTSC or PAL color schema was used for home computers to be connected to a television.
• For text mode, only the ASCII code was saved byte for byte in the memory. The video circuit had a small ROM containing the 5x7 dot matrics of each character. In such way a screen of 40x25 characters can be saved in just 1 kB.
• There were special chips like intel 8275 that integrates everything (access to buffer memory, generation of pixel clock and sync for NTSC monitors, access to character dot matrics ROM and so on), but sometimes the whole video logic was built with TTL logic ICs (example: Apple II).
• Since RAM was shared, the video circuit used DMA or other method to interrupt CPU for RAM access. Video circuit almost always had higher priority since there were no pipelines to buffer the data, and the pixel output of the video signal was time critical.

Answer 2

I'm assuming you're talking about home computers of the late 1970s/early 1980s. Those computers did pretty much work as you conjectured. There were some complications, like hardware sprites, redefinable characters, and nonlinear memory layouts, but basically all those computers had at least a text mode where characters were stored as bytes in memory; and then later and fancier ones had color and bitmap graphics.

However, there was an older type of graphical display, the vector display, that only required the computer to keep the coordinates of visible points in memory. This was advantageous when manufacturers and consumers couldn't afford the memory required to hold even a very low-resolution bitmap.

Answer 3

The 6502 microprocessor needs to use its memory bus for half of each cycle; many computers of the late 1970s and early 1980s took advantage of this by constructing their memory system so it would connect the 6502 to the memory during one half of the cycle, and connect video circuitry during the other half. It's interesting to note that the Apple II, Vic-20, and Commodore 64, took different approaches to the video timing.

The Apple II fetched one byte of video memory per CPU cycle, which determined which character should be displayed. Characters were eight scan lines high, so each byte of character data would get fetched eight times per frame--once on each of eight consecutive lines. The six bits of the fetched character byte would then be used, along with the bottom 3 bits of a scan line character, as an address in a 512x5-bit ROM. The top two bits of the fetched character byte would then select normal, inverse, or blinking mode.

The VIC-20 used wider characters, and fetched a character every other CPU cycle; on the cycle after each character fetch, it would take the 8 bits of character data along with 3 bits of scan-line count, add that value to a value programmed in a register, fetch a byte from that address, and display that as eight consecutive pixels. This approach meant that character shapes could be stored in RAM rather than ROM, and reprogrammed as convenient (the character-memory address could also be set to ROM if desired, to save 2K of RAM).

The Commodore 64 needed to fetch two bytes per character like the VIC-20, but needed to output characters to the screen twice as fast (like the Apple). To balance these needs, while it's showing the first scan line of each row of text, it alternates between fetching characters and fetching their shapes while the CPU isn't allowed to do anything. As it is fetching the character data, however, the video chip also copies it to a 40-byte buffer. While the next seven scan lines of text are shown, the video chip fetches character data from that buffer rather than from RAM, thus allowing the CPU its share of cycles. This makes it possible for the system to show more text like the Apple while also allowing reprogrammable character fonts like the VIC-20. Unfortunately, it stalls the CPU 25 times each frame, for 41-43 cycles each time (starting/stopping the CPU adds 3 cycles of uncertainty)--a design decision which was reasonable at the time but had some unfortunate consequences (the worst of which was that the floppy drive to wait long enough after sending each bit that communications wouldn't get corrupted by having the video chip disrupt the CPU for 43 cycles).