Aeon Emulator Blog

October 30, 2009

Planar Video Memory

Filed under: Aeon, Graphics — Greg Divis @ 3:19 pm

In a previous post, I gave a brief overview of the components of a VGA card, but I didn’t talk about the two components that most affect how data flows from the CPU to video RAM. Let’s start with some background information.

In the early days of computing, monochrome displays were pretty common. Video memory for such a simple system could require as little as 1 bit per pixel if only one color intensity is needed. This means that to fit a 1-bit color 320×200 pixel resolution image in video memory, you only needed about 8 KB of dedicated video memory. When the time came to introduce color displays and what would be called the Color Graphics Adapter (CGA), the design would grow from this.

CGA extended the monochrome video model by adding a second “plane” of bits to represent the same pixels as the first, monochrome plane. Now, there are two bits used for each pixel on the screen, and they are used as an index into a 4-color palette. Although two bits are used to form one index, the bits are not contiguous in memory because they are in separate planes.

Eventually, the Enhanced Graphics Adapter (EGA) came along, and another two planes were added. Now, one pixel consists of a 4-bit index with one bit taken from each of the four planes, so 16 simultaneous colors could be displayed.

The Video Graphics Array (VGA) is compatible with EGA and CGA, but adds higher resolution 4-bit video modes and a low-resolution 8-bit video mode, finally making more realistic graphics possible with the ability to show 256 colors at once. On a CGA, EGA, and VGA card the video memory is still planar, and accessing video RAM in 2 or 4-bit color modes is quite a headache as a result. For 8-bit, though, IBM decided to give developers a break and not add another 4 planes; in fact, the default 256-color display mode on VGA hardware sets up some control registers to make video memory for this mode appear linear. For the first time, instead of complex masking and shifting, all you had to do to write an 8-bit pixel to the screen was to calculate its address and write to it:

pixelAddress = 0xA0000 + (y * ScreenWidth) + x

There was a drawback to this 256-color mode, and that’s that it locked you into a low-resolution 320×200 (which has a weird-looking aspect ratio), and did not leave any off-screen video memory available for page-flipping or hardware scrolling. A number of games disabled this linear addressing, placing the card into “unchained 256-color mode.” It added the complexity of dealing with multiple planes again, but allowed a measure of hardware acceleration that was otherwise impossible, and with further tweaking could allow better resolutions.

Aeon currently handles most of the 16 and 256 color standard EGA/VGA resolutions.


October 23, 2009

Emulating VGA

Filed under: Aeon, Graphics — Greg Divis @ 2:13 pm

On a normal x86 real-mode PC with a VGA-compatible video card, a 64k region of memory starting at segment 0xA000 is mapped to video RAM. For a DOS application, displaying an image on the screen may or may not be as simple as writing the pixel data to this area. DOS is pretty minimalist, and has no concept of a display driver, so any nontrivial graphical DOS program has to talk to the hardware directly. Ok, what is the hardware besides a region of reserved memory address space? These are the basic components of a VGA device:

  • CRT controller: generates display data and timing signals for the monitor.
  • Attribute controller: performs color palette mapping to maintain compatibility with CGA/EGA.
  • DAC: maps pixel data to RGB values stored in its 256-color palette.
  • Sequencer: generates input data for the DAC based on video RAM.
  • Graphics controller: controls the flow of data between the CPU and video RAM.

So basically, when you write a byte to video memory, the graphics controller decides where (or if!) your byte actually gets stored. Everything else comes into play when it’s time to actually show the data on the monitor. These components can be programmed by sending data to various CPU data ports, but why would you need to?

The DAC is probably the most straightforward component – VGA display modes usually have either 4 or 8 bits per pixel. Each pixel then represents an index into the DAC’s color palette, meaning a 4-bit mode allows no more than 16 colors on the screen at once, and an 8-bit mode allows 256. By programming new RGB data to the DAC, a program can change the current palette. Pretty useful, as otherwise everything would be locked to the same set of 256 colors.

The CRT controller is also pretty straightforward. At the time a CRT monitor was pretty much taken for granted, so this component could be programmed to alter the video output in some clever ways to achieve otherwise computationally expensive effects. It also allows some very low-level manipulation of the monitor’s electron gun behavior and timing.

The attribute controller is mainly there for compatibility and Aeon doesn’t emulate many of its functions at the moment.

There’s a reason I’ve left the graphics controller and sequencer for last; they are responsible for more headaches than the rest of the VGA emulation combined. I still don’t have them quite right, and trying to implement them completely turned my nice design into a tangled mess. I’ll talk about them at great length in another post.

Blog at