When I was a kid, the "real" computers in movies looked so cool with that 80-column monochrome green text.

My first computer was a VIC-20 it always felt very "toy" to me because of its 22 columns of fat text. Later my C64 was a better 40 columns, but still not the cool 80-column text I'd see on "real" computers in movies and TV.

I recently started playing with the VICE Commodore emulator and I discovered that the Commodore PET had a cool 80-column screen! I was very surprised to see that.

Question: Why did the VIC-20 and C64 only have 22 & 40 columns when the earlier PET had 80 columns?

  • 5
    The price of memory? Mar 30 at 0:37
  • 9
    Just a comment as I don't have time to properly research a full answer: VIC-20 was "very low end" in certain respects and one way to seriously cut costs was for both RAM/circuitry to support 40 (ignore 80) columns, plus it provided a difference from the C64. As for the C64 40 column, that was actually common on a lot of low-end computers designed for display on ordinary TVs via RF-modulators - 80 column generally required real "computer monitors". Mar 30 at 0:45
  • 1
    VIC-20 has 22 columns.
    – Tim Locke
    Mar 30 at 1:00
  • 2
    There is frustratingly little information online about the 80-column PETs, which were an improvement launched in 1980 (and, pedantically, therefore at the same time as the VIC-20, not before). But, at a guess: because they don't need to fetch pixels from RAM, being a pure text-mode machine, and therefore have a lot more bandwidth for fetching character codes, and possibly even carried across the earlier PETs' limitation of requiring the programmer manually to avoid intersecting with video fetch. The Vic-20 and C64 are self-regulating, at a cost of halving theoretical video bandwidth.
    – Tommy
    Mar 30 at 2:41
  • 3
    Short answer: TV. Mar 30 at 11:28

Space on a chip die was very limited - you couldn't just put an unlimited amount of functionality into one chip.

If you have a closer look at video chips used in 8 bit computers, they either feature an 80 column mode (PET, Amstrad CPC, later Apple IIs, C128 VDC) or a lot of game related functionality like sprites, hardware scrolling, raster interrupts etc. (C64, Atari 8 bit). There's not a single one I know of that does both.

Additionally, Commodore's 8 bit computers run their CPU and the video chip at about 1 Mhz. That is not fast enough to display 80 characters per line, so to get an 80 column display on the PET, they had to use tricks (see here for more details) - there was probably no space left on the chip to support that.

And the C64 is probably the only Commodore computer where somebody at Commodore did actual market research and put down a list of targets they wanted to reach with their machine. Since the machine was targetting the consumer market not the business market and since it was supposed to be a more powerful follow-up of the VIC-20 (which had only 22 columns), I don't think anybody ever really worried about 80 columns.

  • 1
    A note, Amstrad CPC supported both 80 columns and hardware scrolling, I don't know if it utilized two chips for this, like C128 did.
    – Krackout
    Mar 30 at 7:31
  • 1
    @OmarL: Increasing the horizontal resolution of the VIC-20 to 40 columns while keeping reprogrammable character shapes and without effectively halving the CPU speed would have required at minimum adding 40x12 bits of storage within the VIC chip to hold character and attribute data (as was done in the VIC-II). That's a fair bit of die space. It might have been possible to move a couple more of the VIC-20's SRAM chips onto their own data bus (as was done with the color memory) and arrange to have data from them get fed to the VIC-II chip, but that would mean adding a minimum of two more chips.
    – supercat
    Mar 30 at 15:11
  • 1
    @OmarL: Adding an 80-column mode on the VIC-II while keeping the existing memory-interface architecture would have required doubling the text-line buffer from 480 bits to 960, and even with the extra buffering, such a mode would only be usable if there were a blank scan line for every text row, and would gobble enough memory bandwidth to cut CPU performance in half. Memory speeds might have allowed the VIC-II to perform double fetches from consecutive bytes in each of its time slots, but even if the VIC-II took over every available cycle leaving nothing for the CPU...
    – supercat
    Mar 30 at 15:36
  • 1
    ...that would only get up to 177 per scan line. Practical 80-column systems need to either use a pair of memory banks, fetch character-shape data from somewhere other than the CPU bus, or put display memory on its own bus separate from the CPU. None of those choices would have been particularly cheap in a design where the same chip generates video addresses and handles video signal generation. If the roles of address generation and video output had been split, interposing a character ROM between them would have been much more practical.
    – supercat
    Mar 30 at 15:40
  • 1
    @OmarL: For every scan line of every character position, the VIC-II needs 20 bits of data, twelve of which will be the same for the eight scan lines in each row. Fetching 80 character bytes would be possible, but the VIC-II would also need 80 shape bytes to go with them.
    – supercat
    Mar 30 at 16:20

One reason was likely that the VIC-20 and C64 did not have their own displays, but were designed to be connected to a television set. The interface between the computer and the television was not sufficient to display 80 column text (it would have been almost unreadable). However, the PET had its own integrated display so it did not have this limitation, and they were able to offer an 80 column option.

  • 6
    BBC-b mode 0 and mode 3 were 80 character on a tv. (it was a bit hard to read, but not really "unreadable")
    – James K
    Mar 30 at 9:43
  • 2
    I think this answer needs more detail: first, TV's had poor resolution - see @Patrick Schlüter answer - and then at this time home computers were niche and VCRs barely existed, so domestic TV's wouldn't have any 'Video IN' connection; the display signal would also have to go through an RF modulator and the TV's tuner, the latter not being optimised for text.
    – Lou Knee
    Mar 30 at 14:51
  • 3
    @LouKnee RF modulators do not add much distortion (as could be seen by watching TV :). The main problem is that the composite video signal (where colour and brightness is in the same wire, whether RF modulated or not) places a hard limit on the horizontal resolution. The PET display was likely a green screen (i.e. monochrome), with no need to conform to the broadcast TV standards such as PAL or NTSC that the VIC-20 and C64 did. Mar 30 at 15:36
  • 1
    @ReversedEngineer: RF modulators can be designed so as to generate clean broadcast-quality video signals, but RF modulators can be made much more cheaply if dirty signals are acceptable.
    – supercat
    Mar 30 at 17:14
  • 1
    @JamesK “It was a bit hard to read” — for large values of ‘a bit’ :-)  It probably depended on your TV, of course, but I think most Beebs were connected to relatively small screens, where MODE 0/3 could be deciphered but IIRC wasn't really suitable for sustained use.
    – gidds
    Apr 1 at 0:30

Use of TV as monitor is the reason for these low resolutions.

The issue is that the color resolution of TV is very low. While B&W TV could resolve pixel small enough for ~400 to ~600 pixels, color resolution was much much lower, barely around 200 pixels. Some computers exploited this, such as Apple II and CGA/composite. It also shows the limits of that system as Apple was only able to display 140 pixel columns in 6 colours (16 colours in lores and double hires) and CGA which showed 160 pixels in 16 colours. So, if a computer wanted to display text without colour interference, it could not afford more than that number of pixels per line.

Further reading on color artifacts: Wikipedia article, and The 8bit Guy's video on CGA on composite output.


The monitor is physically attached - part of the unit

enter image description here

There's no video port. You have to use the built-in monitor.

As such, Commodore simply chose a monitor fit for 80 columns. That wasn't hard, since NTSC monochrome composite video has unlimited horizontal resolution. And 7 vertical scan lines per character form (+1 scan line for spacing) is enough to be readable and allow 24-25 lines of text.

RF-modulated NTSC has its resolution limited by RF bandwidth. Color NTSC has its horizontal resolution limited by the color clock frequency.

Note that the above is a 40-column PET, but it shows how the monitor is permanently attached.


Somewhat of a side note - The Atari 8 bit series (400 | 800 | 65XE | 130XE - 6502 based, running at 2Mhz), normally displayed 40 characters per line on a color TV. There are some terminal type programs that horizontally scroll the 40 line display to get a virtual 80 character per line terminal, or use a 3 by 5 font (with 1 pixel between characters) (from such programs, it wasn't native to the Atari) to get 80 characters per line, but it is difficult to read.

The terminal programs were used for some modem based bulletin board programs, and also for the somewhat rare ATR8000, which had a Z80 for CP/M, and option an add-on board with an 8088 + 512MB ram, that could run MSDOS 2.11. The ATR8000 could also work with a standard ASCII terminal.

I'm wondering if the C64 could have use a 3 by 5 or similar font to get 80 characters per line.


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.