How did old MS-DOS games utilize various graphic cards?

Question

Nowadays each graphic card has some driver in operating system that translates some (typically) standard API such as OpenGL, so that programmers use some standardized API code to tell graphics cards how and what they want to render. (Actually that's already a bit hard-core most programmers really use various game engines that do this for them).

In times of old computers - how was this done? Did every programmer of every game implemented all possible various API's that old graphic cards supported? Or did the old game studios from MS-DOS times had their own "game engines" that provided some abstraction when it came to these graphic cards?

I remember there were many various card vendors and I remember old games asked me which one I have - so I suppose these games contained code / drivers for all these cards?

Answer 1

Did every programmer of every game implemented all possible various API's that old graphic cards supported?

Yes - but it went even deeper than that. Early graphics cards had virtually no callable code associated with them at all, the concept of "drivers" had not quite become a reality yet. There was the concept of a Video BIOS, which were extensions to the INT 10h BIOS video services, that were effectively limited to initialization and switching video modes.

Instead, graphics cards, at least in DOS land, all had memory mapped display RAM, and extensive documentation was available about exactly how setting various bits in display RAM would affect the pixels that appeared on the screen. There were no drawing APIs to call, if you wanted something to appear on the screen (whether it be a pixel, a character, a line, a circle, a sprite, etc) you would write the code to move the bytes into the right places in display RAM. Entire books were written about how to write efficient code to draw graphics.

There were some systems like the Borland Graphics Interface that abstracted graphics drawing primitives into an API with different drivers that one could call to draw things on different graphics cards. However, these were typically slower than what would be required for building action type games.

An action game would typically be optimized for a particular graphics display mode on a particular card. For example, a popular display mode was VGA 640x480 with 16 colors. This would be listed in the software requirements, and you needed to have the right hardware to support the game. If you bought a VGA game but you only had an EGA card, then the game would not work at all. As you said, some games would ask what you had and you had to know what the right answer was, otherwise the game would not work.

Answer 2

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.

Answer 3

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! :)

Answer 4

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.

Answer 5

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.

Answer 6

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".

Answer 7

Yes, pretty much. Those who needed to access the video beyond what the ROM and MS-DOS provided had to provide their own drivers for the devices past the standard ones.

So all those drivers or different versions of the game all sat in the directory on the floppy or HDD. There were different strategies for managing that. One was to have multiple programs and the setup or loader program would ask you questions and then either create the batch file to run to launch the appropriate main EXE. Or, it would have the various program versions backed up and would overwrite the main file. Another was to ask at the beginning and have different drivers or libraries sitting in the directory, and it would use the appropriate external files with the program.

And newer standards were reverse compatible. For instance, VGA monitors would use CGA compatibility. So the analog outputs were made to have the same intensities as the various CGA colors. Of course, there was also the MDA mode. Also, basic capabilities were defined in CMOS or jumpers, so programmers could read a "register" (maybe in the BIOS parameter block) to get a rough idea of what was attached. So mono, CGA, or unspecified (often EGA/VGA).

Often, folks did run into incompatible software. For instance, if you have an MDA monitor and not Hercules if the program used it, the code could hang, or at least the monitor would lose sync. A Herc monitor could connect to an MDA board without any problem between the 2. The monitor would use be underutilized and will not change syncs to the hires mode. So a Herc monitor could replace an MDA monitor without problem, but not the other way. And of course, if the software supports Herc and the adaptor doesn't, then the code would either bail or hang the machine, no matter what monitor is attached.

Now, in coding, some coders did come up with tests for some types of machine diversity and provided separate coding paths. An example was testing for the CPU type. Before CPU-ID functionality in the CPU, coders tested for quirks unique to each CPU. For instance, how registers and flags worked. For instance, even in a program designed to be XT compatible, it would be helpful to test for a V20 CPU, since if you knew you had a V20 installed, you could use some 186 and V20-specific opcodes and speed up parts of the code. I tested for the CPU type when I wanted to manipulate the keyboard lights because the XT and AT locations for that were different. You wouldn't want to attempt to change the keyboard lights and end up turning off the DMA refresh. That would trash memory for sure.

This sort of thing even tied in with video since the framebuffer could be in a different location than expected, so reading the BIOS parameter block would be good to do to avoid surprises. So if in doubt, ask the computer if you can, and beyond that, ask the user. And users tried things by trial and error. If many video cards were listed and they had one that wasn't listed or a generic one, they'd try all of the options until they find one that doesn't hang the machine or attempt to put the monitor into a mode it could not support.