Ttdfjt

Early on, you had to explicitly code your game for each graphics card you wanted to support: Hercules, CGA, Tandy, EGA, VGA. You had to know how to put the card into graphics mode and you had to know the memory layout, palette, and so on. You had to figure out how to avoid flicker and how to prevent tearing. You had to write your own line drawing and fill routines, and if you wanted 3-D, you had to know how to project it onto a 2-D screen, how to remove hidden lines and so on.

Later when graphics cards started gaining accelerated functionality, SGI created the IrisGL API, which later became OpenGL, in order to simplify CAD (computer aided drafting/design) software development for those graphics cards by providing a standard API that video hardware manufacturers could support and developers could design their software against. OpenGL provided access to underlying hardware features, and if a feature did not exist on the hardware, OpenGL provided a software implementation.

The same problem existed in games development. Originally, graphics card manufacturers would work with game studios to create a version (release) of their game that would be accelerated by the specific graphics card. Early 3D games like MechWarrior 2 had different releases for 3dfx Voodoo, S3 Virge, STB Velocity, and so on. It was a bit of a mess. At around the same time, Microsoft created the DirectX library for Windows which was similar to OpenGL. Manufacturers would support OpenGL and/or DirectX, and game studios who were brave enough to abandon DOS for Windows as a platform could then program for one or both libraries instead of creating another release for each individual graphics card they wanted to support. Any relatively minor differences between graphics cards could be handled at runtime in the same release.

In DOS you had direct access to the hardware; so you grabbed some good source of information about the card you wanted to support, and got down to code your routines.

A book which was often cited as a good source was "Programmer's Guide to the Ega, Vga, and Super Vga Cards", by Richard F. Ferraro; I hadn't the luck to own it or read it, but it was fondly remembered by those who did.

Another invaluable source of information was Ralph Brown's Interrupt List; you can find a HTML conversion of the list here: http://www.delorie.com/djgpp/doc/rbinter/

The original was just made of (long) text files; and, if memory serves me correctly, there were some programs to navigate it more easily, at least in the later versions.

Another nice collection of infomation was contained in the "PC Game Programmer's Encyclopedia", or PC-GPE; a HTML conversion can be found here: http://qzx.com/pc-gpe/

You had at least three different ways to interact with a given piece of hardware; io ports, interrupts, and memory mapped registers. Graphic cards used all three of them.

The situation with audio cards was very similar.

Another thing to consider is that attached to the video card was an analog CRT monitor. The older/cheaper ones were only able to sync to a given set of vertical and horizontal rates; but the newer/best ones were basically able to sync to any signal in a given range. That means that with the right parameters written to the video card registers, you could create some custom (or weird) resolutions.

Games aimed for broad compatibility, so they rarely used weird ones, while in the demoscene it was quite common (and custom resolutions were the norm in arcade games too.)

But, for example, Mode X was very popular with games!

It was popularized by Michael Abrash on the pages of Dr. Dobb's Journal;
you got a 320x240 resolution, that, viewed on a 4:3 monitor, meant the pixels were square. So, for example, you could naively draw circles and they would look like circles; in 320x200 they were stretched, as the pixel aspect ratio was not 1:1, and you had to calculate and compensate for that while drawing.

It was a planar mode, so by setting a register you could decide which planes would receive a write in the memory mapped area. For example, for a quick fill operation you would set all planes, and a single byte write would affect four pixels (one for each plane). That also helped to address all the 256 KB of the VGA memory using only a 64 KB segment.

I am positive there was a little utility which let you explore the VGA registers, where you could put whatever values you fancied, and, when you applied your settings,
you could finally see if your monitor supported the resulting output. But my memory is too weak right now to remember the name or the author of this program.

Another common trick was to change a part of the color palette during the horizontal retrace; done correctly, you could have more than 256 colours on screen. There was not enough time to change the whole palette on each line, so you had to be creative.

(During vertical retraces instead there was enough time to change every colour, and it was done for example for fade in/fade out effects).

(The most popular palette trick was probably changing the background color during tape loading on 8 bit machines (C64 for example).)

One thing that is often overlooked, was that the VGA card was effectively a small three channel DAC; creative people found ways to use and abuse that as well.

To a similar effect, Tempest for Eliza used the radio waves emitted by the monitor to transmit a radio signal which could be listened to with a common AM radio.

Whoa! This was a nice trip on memory lane! :)

In DOS world in the golden age of VGA (early to mid 90s), by far the easiest and most popular way to do graphics was the famous Mode 13h, a 320x200 pixel linear 256-color paletted video mode. The closest you would get to a standard video API was BIOS interrupt 10h, giving access to a handful of functions including switching the video mode and configuring the palette. A resolution of 320x200 (instead of 320x240 which has a 4:3 aspect ratio) was very convenient because the required video memory (64000 bytes) would fit in a single 64kB memory segment, making addressing individual pixels very straightforward. The drawback was that pixels were slightly rectangular instead of perfectly square.

The video memory was mapped to segment A0000h; in the real-mode environment of DOS you could simply form a pointer to that segment and treat it as a 64000-byte array, each byte corresponding to one pixel. Set a byte to a new value, a pixel changes color on the screen. Beyond that, implementing any higher-level drawing functionality was up to you or a 3rd-party library.

For accessing higher-resolution and/or higher color depth modes afforded by SVGA and later video cards, there was (and still is) VBE, or VESA BIOS Extensions, a standard API exposed by the video card's BIOS. But beyond switching the video mode, setting the palette (in paletted modes), and getting a frame buffer into which to plot pixels, you were still pretty much on your own.

Early PC computing was the age of banging hardware directly. Your (typically assembler) code wrote directly to control registers and video memory.

As far as supporting multiple video cards, real easy: we didn't. The supported hardware was directly stated right on the spine of the game box. You needed to have that hardware. This wasn't hard; generally nobody expected games to run on an MDA (Monochrome Display Adapter, no G for graphics since it had none). That left CGA and later, EGA.

It wasn't that we didn't want APIs. I even tried to write APIs. But this was an age when you were counting processor clock cycles. You had to get it done in the cycles available.

• You couldn't afford the cycles for the subroutine call and return!


• Let alone all the parameter passing (moving parameters into the standard locations the subroutine wants).


• Or the de-referencing needed for every iteration of the operation, since you have to use a memory location specified in a call parameter, instead of being able to hard-code it.

And mind you, those limitations applied to my personal API optimized for that game. If a third party entity wrote one all-singing, all-dancing API intended as the one API for all applications, then much more would be abstracted, and the above overhead would be much worse.

That's less of a problem today, because the graphics are so large and complex that API overhead is a smaller fraction. Also, there is CPU to throw at the problem; you can just let the playtesters bump the minimum CPU requirement. We couldn't do that because most of the market was 4.77MHz 8088’s.

Like any hardware, video card may have some address in I/O space and memory space.
They are physically connected to bus (ISA bus back in 1980th).
When CPU writes to some memory address, videocard answers this and accepts data.
When CPU writes to some IO, same thing happens.

That means software may access it if it is aware of it's memory address and IO address.

Accessing some hardware mapped to some memory address:

MOV SOME_ADDR, AX ; Move value of AX register to address SOME_ADDRESS
OUT SOME_PORT, AX; Move value of AX to some port

Same with C

int* data = SOME_ADDR;
data[0] = '1'; //write '1' to SOME_ADDR.
outp(PORT, '1'); //to io

IBM PC compatible computers had several types of cards:

• Monochrome Graphic Adapter




• Hercules




• CGA




• EGA




• VGA

Each card had its own standard which was documented. All of them were backward compatible (i.e. VGA may emulate CGA).
VGA was the most complicated standard, there were huge books about it!
Standard declares which address should you use to access video card and which data should you write to card to show something on CRT monitor.

So, first you need to find out which card do you have (you can try to read this data from memory area filled by BIOS or ask user).
Then, you use standard to talk to card.

VGA, for example, had a lot of internal registers. Developers wrote some data to IO port to select register, then wrote data to this register.

Card memory was mapped, so you simply wrote data to some address (in some modes some cards had several pages of memory which you can switch).

But memory was not always plane. There was a character mode (in which each 2 bytes represent letter and it's attributes like color and bgcolor).
There was 13h mode where each byte represented color of pixel.
There were modes with several planars to speed up the card (see
https://en.wikipedia.org/wiki/Planar_(computer_graphics) )

Video programming was not easy!
Some articles to read:

• https://wiki.osdev.org/VGA_Hardware




• http://www.brackeen.com/vga/

There was also high level BIOS api, but it was too slow to be used by games.

You may ask: "But how do I render 3D with all of that?".
The answer is: you can't.

In 80th and early 90th you had to render everything on CPU and then use video card API to show 2D image.

I really suggest you t read book about how they did it for Wolf3d:

http://fabiensanglard.net/gebbwolf3d/

The first video card that supported SOME 3D APIs was "Voodo 3DFX". It had API called "Glide".