How did graphics processing for old 8/16bit consoles work & what are the differences between an FPU/maths co processor & a graphics card? [closed]

Question

When looking at information on the Internet about old consoles it's rather easy to find information on CPUs like the 6502, 65816, 68000 & Z80 used in retro computers & consoles like the NES, SNES, Megadrive, Mastersystem, Atari 2600, Atari 8 bit family, Apple IIGS, etc. However, I find GPU information much harder to come by. Things like how the PPU (picture processing unit) in the NES/SNES worked or the TMS9918-based video display controller/video display processor in the master system & Megadrive worked.

Furthermore, do these processors used for graphics processing have any similarities to FPU(Floating point units) & maths coprocessors of the time period such as the x87 & Motorola 68881 & 68882 & how do these chips differ from modern graphics cards?

Answer 1

The video circuitry was a lot simpler in those days and there was no true GPU as we have today. The video memory was part of the CPU memory space and any video circuitry merely converted it into a video signal. There was no graphics processing outside of what the CPU did.

Some, particularly earlier systems use discrete components to produce a simple video display such as the Apple II, the early Commodore PETs, and the TRS-80.

Some systems had a PLA (Programmable Logic Array) such as the Sinclair ZX-81 and Sinclair ZX Spectrum.

Some systems had a video shifter such as the TIA on the Atari 2600 but the 6502 did most of the work.

Some systems had CRT controllers such as the Motorola MC6845 on the BBC Micro and Amstrad CPC and the MDA, CGA, and EGA adapters on the IBM PC.

Some systems had a Video Interface Controller, such as the VIC in the VIC-20 and the VIC-II in the Commodore 64. and the Motorola MC6847 in the Tandy Color Computers.

The more powerful graphics chips were the ANTIC/GTIA on the Atari 8-bit computers, the TMS9918 on the TI-99/4(A), MSX, and ColecoVision, and the Agnus/Denise on the Amiga 16-bit computers.

Answer 2

A standalone processor, such as the ones you have listed, would usually only be able to perform some basic operations on integer data. This would typically be add and subtract because those operations can be trivially implemented with minimal amounts of logic (see Ben Eater's series on building a CPU on a breadboard as an example).

Earlier versions of the 68000 (for example) could only perform multiply or divide on "words" - that is 16 bits. A math co-processor would enable the CPU to perform multiply and divide on "longs" (32 bits) or perhaps even bigger numbers. If the math co-processor also included an FPU (likely), then it would be able to perform such operations on floating point numbers too.

A math co-processor is intended to help a standalone CPU perform more, or more complex operations than are implemented in its silicon, and without one, you are left to perform these operations in software which is naturally much slower.

A modern GPU, which is built to be a number crunching powerhouse, can very likely do a lot of what a math co-processor can do, but it is not necessarily considered a general purpose math co-processor. People have used GPUs to do math intensive work in specialised applications (e.g. crypto currency mining), but that is not an every day thing to do. In general, they are built to process large amounts of numerical data in a graphical sense to draw textures on screen, stretch and contort them around objects, apply visual effects, etc. If you like, you could consider them an application specific math co-processor, offloading all of that intensive computation from the CPU.

Math co-processors these days are more or less a thing of the past - all of the functionality they provided is now built-in to CPUs, so there is no need for external hardware to provide this kind of functionality.

As for 8-bit era hardware and how it worked, this is going to differ wildly from maufacturer to maufacturer, just as computer systems in general did. Back then, it was anyones guess as to how the computing landscape would evolve, and what would eventually become "normal". A lot of techniques and architectures were tried, some succeeded and others didn't.

But given the capabilities of technology at the time, the operations the hardware performed was likely very simple, limited to applying colour palettes to sprites and positioning sprites on the screen, perhaps with some simple collision detection, and drawing to essentially a bit mapped screen.

You're likely to find some videos on YouTube explaining how to use this hardware (I know there are some channels like The 8-bit Guy who have made their own modern games for things like the Commodore 64) which may give away some clues as to how it works, but finding definitive and specific information on how it actually functions beyond what datasheets are available is going to be difficult.

Answer 3

Not really an answer, but...

...The phrase "co-processor," can mean two different things.

When you're talking about a "floating point co-processor" or "FPU," you're probably talking about a chip that extends the capabilities of the main CPU. In a very real sense, it becomes part of the CPU when it is installed. It adds functional units, and it extends the CPU instruction set. This type of closely coupled "co-processor" can not function independently of the CPU for which it was designed.

When you're talking about a typical "graphics card" or "graphics co-processor" or "GPU," you probably are talking about a more loosely coupled sub-system of the computer. It runs its own software, different from the software that runs on the main CPU. I haven't actually done any GPU programming myself, but I'm reasonably certain that the communication between GPU and CPU happens at some significantly higher level than the op-code-by-op-code communication between a CPU and its FPU.

---

Also, when you say "graphics card," you could be talking about a range of different things. It could be as simple as some RAM, and some hardware that generates a video signal from the contents of the RAM, or it could be that plus a GPU to make a complete, autonomous computing sub-system, or it could be somewhere in-between (e.g., a video frame buffer plus a hard-wired "raster-op" engine that can perform a few, specialized operations on the VRAM content.

Answer 4

Broadly speaking, all these systems worked in the same way. The base system is always the same — generate the lines and synchronisation pulses needed to build display frames.

The video circuit (could be a single chip or not) knows when it starts a single frame and has somewhere access to memory (which can be private or shared with the microprocessor). It starts to read memory and uses the read data to generate a video stream, line per line, and frame per frame.

Implementations can use a single byte to represent 8 pixels (monochrome), use several bits to represent colour (possibly through a fixed or configurable palette), or use a single byte to represent a character (which is then looked up through a ROM table (fixed font) or RAM (configurable font)).

Part of the functionality is the generation of interrupts when (or just before) the horizontal and vertical video pulses are generated so that the processor can do meaningful work for the video picture during those times that there is no output, e.g. moving objects in the video memory, reconfiguring the palette, ...

Additions to the video circuits were things like the sprites for VIC-20/C64, which made it possible to have (some) moving objects completely done by the video circuitry so that the processor could do other work or collision detection. The NES PPU is an example of a circuit with a private address space and additions for sprites and colour palettes.

With the advent of very high-level integration, it became possible to create processors that worked alongside the main microprocessor and could manipulate objects by applying linear algebra (matrix computations) in the graphics memory itself. This led to the development of graphical processing units with their extremely large performance.

Before this was possible, the addition of a floating point unit (or other specialised math coprocessors) helped speed up the work of the main microprocessor to manipulate graphics (30 years ago, adding an 80387 to a PC helped with using AutoCAD or running Doom), in the same way, by performing and speeding up linear algebra operations.