This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages) This article may require cleanup to meet Wikipedia's quality standards. The specific problem is: 300+ tangential footnotes and only a handful of sources. Please help improve this article if you can. (June 2021) (Learn how and when to remove this message) This article is written like a personal reflection, personal essay, or argumentative essay that states a Wikipedia editor's personal feelings or presents an original argument about a topic. Please help improve it by rewriting it in an encyclopedic style. (June 2021) (Learn how and when to remove this message) (Learn how and when to remove this message)

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

Home computers are 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 technically home computers are also classified as personal computers.

Examples of early home computers are the TRS-80, Atari 8-bit computers, BBC Micro, ZX Spectrum, MSX, Amstrad CPC 464, and Commodore 64. Examples of late home computers are MSX 2 systems, and the Amiga and Atari ST systems.

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 personal computer category, except for Early Macintosh PCs, are generally based on the VGA standard and use a video chip known as a Graphics Processing Unit. Very early PCs used one of the much simpler (even compared to most home computer video hardware) video display controller cards, using parts like the MDA, the Hercules Graphics Card, the CGA and the EGA standard). 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 and the Bally Astrocade, even though these systems could sometimes be upgraded to resemble a home computer.

Early home computers all used similar hardware and software, mostly using the 6502, the Z80, or in a few cases the 6809 microprocessor. They could have 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. The basic systems were quite similar with the exception of the video display hardware. As a result, the success of a system proved to primarily rely on the performance of the video display hardware, since this had a direct implication on the kind of games that could be played on the system.

The most important aspect of a home computer was how far programmers could push the hardware to create games. 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 on a home system.^[1] Additionally, specific machine language code exploiting quirks of the VIC-II chip allowed for special tricks to draw even better pictures out of the VIC-II chip.^[2] The comparatively large memory and the audio capabilities of the C64 also lent themselves well toward the production of larger games. An example of the opposite is the Aquarius by Mattel which had such incredibly limited video hardware that it was retracted from the market after only four months due to poor sales.

One major problem that early computer video hardware had to overcome was the video bus arbitration problem. The problem was determining a way to give both the video hardware (VDU) and the CPU continuous read access to the video 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 necessary to do so. 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 being said, one system, the Apple II, 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 Micro 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 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 were avoidable. 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, the 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.

There are two main categories of solutions for a home computer to generate a video signal:

• A custom design, either built from discrete logic chips or based around some kind of custom logic chips (an ASIC or PLD).
• 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 range of (sometimes unique) capabilities, but generally speaking, the second category could offer a much more complex system for a comparatively lower price.

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

• 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 a custom logic chip (a ULA) rather than a single-purpose commercial IC like the CDP1861. Dedicated Video shifter chips did have some use in very early game systems, most notably the Television Interface Adaptor 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 depends on the main CPU to feed them with picture data. They do nothing more than generating 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.
• 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.
• 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.
• 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/ECS/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.

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.

Video mode(s) [i.e. Text mode(s) and Graphics modes]

The numbers of characters per line and lines of text the system supported and the number of colors they could have. Sometimes more than one mode was possible: The number of horizontal and Vertical pixels the system could display in a high resolution mode and The number of colors each pixel could have in High-resolution mode, where several high-resolution modes exist each one is listed separately. Beginning with the Xerox Alto, systems forwent independent text modes and drew text on a high-resolution graphics screen. This required more video RAM, but also freed computer fonts from a fixed grid.

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 high-resolution 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. It's hard to call this a "high resolution" mode because the resolution could be as low as 80×48 pixels, but in any case, it was possible to draw pictures with them. In the 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 blocking graphics for an APA mode as well, often only for 2×2 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 high-res 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.

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 8×8 pixels large) shared the same "color attribute", so as to spare video memory, as an 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, the 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 two letters for each method.

BL

For blitter

DR

For hardware supported line drawing

SC

For hardware scrolling support

SP

For hardware sprite support

TE

For hardware Tile engine support in graphic mode

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 color mode is available each one is listed.

SP

For the fourth facet, is the number of sprites per scan line. Hardware sprites 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 scan line. 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.

For these systems, it is established that they are based on multiple technologies. The hardware chosen to be used by these systems may have a substantial or insubstantial impact on the video they output.

For these systems, it could not be established what technology they are based on, therefore, some information regarding them may be inaccurate.

• List of computer hardware palettes
• Semi graphical characters
• Semigraphics
• Video Display Controller