List of home computers by video hardware

This is a list of home computers, sorted alphanumerically, which lists all relevant details of their video hardware.

A home computer was the description of the second generation of desktop computers, entering the market in 1977 and becoming common during the 1980s. A decade later they were generally replaced by IBM PC compatible "PCs", although in actuality home computers are also members of the class known as personal computers.

Examples of typical early home computers include the Sord SMP80/X, Altair 8800, TRS-80, Atari 400/800, NEC PC-8801, NEC PC-9801, BBC Micro, ZX Spectrum, MSX 1, Fujitsu FM-7, Sharp X1, Amstrad CPC 464, and Commodore 64. Examples of typical late home computers include the MSX 2, Amiga, Atari ST, Sharp X6800, Fujitsu FM Towns, and NEC PC-9821.

Note: in cases of manufacturers who have made both home and personal computers, only machines fitting into the home computer category are listed. Systems in the PC category, except for early Macintosh personal computers, are generally all based on the VGA standard, and use a video chip known as a Graphics processing unit. However, early PCs used one of the much simpler (compared to most home computer video hardware) video display controller cards, using standards such as the MDA, Hercules Graphics Card, CGA and EGA standards. Only after the introduction of the VGA standard could PCs really compete with the home computers of the same era, such as the Amiga and Atari ST, or even with the MSX-2. Also not listed are systems that are typically only gaming systems, like the Atari 2600, Bally Astrocade, and Nintendo Family Computer, even though these systems could sometimes be upgraded to resemble a home computer.

The importance of having capable video hardware
Early home computers all had quite similar hardware, (and software) mostly using the 6502, the Z80, or in a few cases the 6809 microprocessor. They could have only as little as 1 KB of RAM or as much as 128K, and software wise, they could use a small 4K BASIC interpreter, or an extended 12K or more BASIC. So the basic systems were quite similar, except for one part of the system, the video display hardware. Some systems proved to be much more successful than others, and careful observers will see that the most successful systems had the most capable video hardware. The reason for that is that the success of the home computer was mostly determined by the kind of games you could play on it.

If you wanted to run a nice video game on a home computer, all the other specifications of the system, such as the CPU, the kind of BASIC, even to a degree how much memory the system had (if had at least 32K or more) did not matter much. What mattered most was what kind of picture could be put on the screen, and how easy or hard it was for a programmer to get enough capabilities out of the video hardware to create the effects necessary for the game.

A case in point is the Commodore 64. Its microprocessor lacked advanced math functions and was relatively slow. In addition, the built-in BASIC interpreter lacked any sort of graphics commands, as it was the same version that was developed for the older Commodore PET (a computer without any high resolution graphics capabilities at all). However, these drawbacks were of little consequence, because the C64 had the VIC-II chip. When accessed by machine language programs, the graphic capabilities of this chip made it practical to develop arcade-style games. Additionally, specific machine language coding exploiting quirks of the VIC-II chip allowed for special tricks to draw even better pictures out of the VIC-II chip. The comparatively large memory and the audio capabilities of the C64 also lent themselves well toward the production of desirable games. A negative example was the Aquarius by Mattel which had such incredibly limited video hardware (for the time period) that it was retracted from the market after only four months due to bad sales.

Video Arbitration Logic
One major problem that early computer video hardware had to overcome was the Video bus arbitration problem. The problem was to give the video hardware (VDU) continuous read access to the video RAM, while at the same time the CPU also had to access the same RAM. The obvious solution, using interleaving time slots for the VDU and RAM was hard to implement because the logic circuits, and video memory chips of the time did not have the switching speed they have now. For higher resolutions the logic and the memory chips were barely fast enough to support reading the display data, let alone for dedicating half the available time for the slow 8-bit CPU. That said, there was one system, the Apple II, that was one of the first to use a feature of the data-bus logic of the 6502 processor to implement a very early interleaving time slot mechanism to eliminate this problem. The BBC Microcomputer used 4 MHz RAM with a 2 MHz 6502 in order to interleave video accesses with CPU accesses.

Most other systems used a much simpler approach, and the TRS-80's video logic was so primitive that it simply did not have any bus arbitration at all. The CPU had access to the video memory at all times. Writing to the video RAM simply disabled the video display logic. The result was that the screen often displayed random horizontal black stripes on the screen when there was heavy access to the video ram, like during a video game.

Most systems avoided the problem by having a status register that the CPU could read, and which showed when the CPU could safely write to the video memory. That was possible because a composite video signal blanks the video output signal during the "blanking periods" of the horizontal and especially the long vertical video sync pulses. So by simply waiting for the next blanking period the stripes could be avoided. This approach did have one disadvantage, it relied on the software not to write to the screen during the non-blanking periods. If the software ignored the status register the stripes would re-appear. Another approach, used by most other machines of the time, was to temporarily stop the CPU using the "WAIT/BUSRQ" (Z80) "WAIT" (6809) or "SYNC" (6502) control signal whenever the CPU tried to write to the screen during a non-blanking period. Yet another, more advanced, solution was to add a hardware FIFO so that the CPU could write to the FIFO instead of directly to the RAM chips, which were updated from the FIFO during a blanking interval by special logic circuitry. Some later systems started using special "two port" video memory, called VRAM, that had independent data output pins for the CPU interface and the video logic.

The main classes of video hardware
There are two main categories of solutions for a home computer to generate a video signal.


 * a custom design, either build from discrete logic chips, or with some kind of Programmable logic device.
 * a system using some form of Video Display Controller (VDC), a VLSI chip that contained most of the logic circuitry needed to generate the video signal.

Systems in the first category were the most flexible, and could offer a wide ranges of (sometimes unique) capabilities, but generally speaking the second category could offer a much more complex system for a comparable lower price.

Note that for completeness, systems that did not really have "Video" hardware in the conventional sense, but used 7-segment displays as a visual output device have been included.

The VDC based systems can be divided into four sub-categories.


 * 1) Simple video shift register based solutions, have a simple "video shifter chip", and the main CPU doing most of the complex stuff. Only one example of such a chip for a home computer exists, the RCA CDP1861 used in the COSMAC VIP. It could only create a very low resolution monochrome graphic screen. The chip in the Sinclair ZX-81 also is a video shifter, but is not a dedicated chip but a programmable chip, a ULA. The CDP1861 however was specially designed for this task only. Dedicated Video shifter chips did have some use in very early game systems, most notable the Television Interface Adapter chip in the Atari 2600. Note that although one of the chips in an Atari ST is also called a "video shift register" it does not fall into this class, mainly because the IC's in this class depend on the main CPU to feed them with picture data. They do nothing more than generate the sync signals and convert parallel data into a serial video data stream. The Atari ST's chip used a DMA system to read out video data independent of the main CPU, and contained a palette RAM, and resolution/color mode switching logic.
 * 2) CRTC (Cathode Ray Tube Controller) based solutions. A CRTC is a chip that generates most of the basic timing and control signals. It must be complemented with some "Video RAM" and some other logic for the "arbitration", so that the CPU and the CRTC chip can share access to this RAM. To complete the design, a CRTC chip also needs some other support logic. For example a ROM containing the bitmap font for text modes, and logic to convert the output from the system into a video signal.
 * 3) Video interface controllers were a step up on the ladder, these were true VLSI chips that integrated all of the logic that was in a typical CRTC based system, plus a lot more, into a single chip. The VIC-II chip is probably the best known chip of this category.
 * 4) Video co-processor chips are at the highest end of the scale; Video interface controllers that can manipulate, and/or interpret and display, the contents of their own dedicated Video RAM without intervention from the main CPU.  These chips are highly flexible offering options and features with minimal CPU involvement that on other systems are impossible or at best difficult to produce, requiring extensive CPU overhead.  The Atari ANTIC/GTIA and Amiga OCS/ESC/AGA are well known examples of this high-feature category. But note that not all video co-processors are powerful, some are even simpler than many Video interface controllers, notably the primitive SAA5243 which is still technically a co-processor.

Explanation of the terms used in the tables

 * System Name, the name of the system, or if there are many similar versions, the name of the most well known variant, see Notes.
 * Year the year that the first version of this system came on the market.
 * Chip name the name of the chip that was used as the basis for the video logic.
 * Video RAM the maximum amount of RAM used for the video display, depending on the resolution used the system may use less.
 * Text mode(s) The numbers of characters per line and lines of text the system supported. Sometimes more than one mode was possible
 * Font extras describes extra graphical possibilities a video system had because of optional features of their character sets, there are currently three categories:
 * LC Some systems could only display upper case characters in text mode because of their limited character set, If a system was able to also support lower case letters in a text mode, (in any highres mode it is of course always possible), then there is LC (for Lower Case) in this column.
 * BG Some systems used a matrix of blocky pixels instead of a letter in their font sets (or used dedicated hardware to emulate them, like the TRS-80 did), to support some sort of all points addressable (APA) mode. Its hard to call this a "high resolution" mode, because the resolution could be as low as 80x48 pixels, but in any case you could draw pictures with them. In case of systems that used such a system as its "APA" mode there is BG (for Block Graphics) in this column.
 * SG Some other systems used semi graphical characters like box-drawing characters dots and card symbols, and "graphical building block" geometric shapes such as triangles to give the system the appearance it could do high resolution graphics while in reality it could not, Systems like that have SG (for semi graphical characters) in this column. Many systems like the PET had a few of such characters dedicated to block graphics for an APA mode as well, often only for 2x2 matrix characters. Sometimes the system filled (or could fill) a reprogrammable section of the font set which such characters, these systems mainly fall under the "soft font" heading.  Note that the BG and SG entries are only used when the system relied on them, had them predefined in its default character set, or, (what often happened on early systems) had them printed on the keyboard keys for direct entry in combination with some kind of "graphic shift" key.


 * Soft Font when the system had a programmable font RAM instead of a static "font ROM", or when the video system did not have a hardware text mode, but painted text in the highres screen using software, the video display wasn't dependent on a permanent font set, in this case we are talking about a system with a "soft" font.
 * text colors The number of colors the characters could have. If more than one text mode is supported the text colors column also lists the same numbers in the same order.
 * Graphics modes The number of horizontal and Vertical pixels the system could display in a high resolution mode, where several high resolution modes exist each one is listed separately.
 * Graphics colors The number of colors each pixel could have in High resolution mode, If more than one high resolution mode is supported the graphics color mode also lists the numbers in the same order.
 * Color resolution in "high resolution mode" it was often the case that a certain pixel could not be given an arbitrary color, often certain clusters of pixels, (quite often 8x8 pixels large) shared the same "color attribute", so as to spare video memory, as a 8-bit computer only had a 64 KB address space, and the CPU often had limited capabilities to manipulate video memory, therefore it was often necessary to keep the video RAM size as small as possible, so a minimum of the address space of the micro was used, and also the video content could be changed relatively rapidly.
 * Palette Support If the system could translate a "logical color" into a (larger number) or true colors using a palette mechanism then this column lists the number of logical colors the palette could accept, and the number of colors it could translate to.
 * HW accel short for Hardware acceleration can take several forms, the most obvious form is "bit blitting", that is the moving of groups of pixels from one place in video memory to another without the CPU doing any of the moving, another often used technique is hardware scrolling which in fact emulates moving the whole screen in the video ram, a third form of hardware acceleration is the use of sprites implemented in hardware. Some systems also supported drawing lines (and sometimes rectangles) using special line drawing hardware. The entry in the column reveals which methods the hardware supported with a two letters for each method.
 * BL for blitter
 * SC for hardware scrolling support
 * SP for hardware sprite support
 * DR for hardware supported line drawing


 * Sprite details covers three facets of the sprite support hardware the system used. Each number in the table cell is preceded by two letters.
 * S# for the first facet, is the total number of hardware sprites the system could support, in hardware (not counting re-use of the same hardware). if the system doesn't support hardware sprites at all the table cell only contains "-" . If S# is 1 then the single sprite is most often used to support a mouse cursor.
 * SS for the second facet, is the size of the sprite in screen pixels'. A sprite could be displayed by the hardware, as a matrix of horizontal by vertical pixels. If more than one sprite size mode is available each one is listed.
 * SC for the third facet, is the number of Sprite colors, it gives the number of colors that a sprite could have. It is about the total number of colors that could be used to define the sprite (transparent NOT included), so if a sprite could only be displayed as a figure in a single color the number is 1. If more than one sprite size mode is available each one is listed.
 * SP for the forth facet, is the number of Sprites per scanline. Hardware spites use a kind of Z-buffer to determine which sprite is "on top". Availability of hardware to do this limits the number of sprites that can be displayed on each scanline. This number tells how many sprites could be displayed on a scanline before one of them became invisible because of hardware limitations.


 * Unique features If the video display has unique features (or limitations) they will be listed here, if space is a limitation the remaining special features are expressed as notes.

a "-" in a table cell means that the answer is irrelevant, unknown or in another way has no meaning, for example the sprite size of a system that does not support hardware sprites.

''a "?" in a table cell means that the entry has not yet been determined. if a ? follows an entry it means that other options than the listed ones may also exist''

"Mono" in a table cell means monochrome that is for example black on white, or black on green.

Systems that could not be classified
For these systems it could not be established on what technology they are based. If you know more about the actual hardware used by these systems, then please move them to the correct class.