25

Seems like VGA only has one background layer, it appears to be a typical bitmap screen like most home computers of the 80s (Amstrad CPC, Commodore 64 etc.) where each pixel's color is stored in a section of memory that can be written to directly. The closest I can get on DOS (I'm using DOSBox if it's relevant) is the mouse cursor, which seems to "eat away" a portion of the screen when it spawns, after which it can move over top of text without erasing what it passes over.

For an example of what I'm asking, please take a look at this screenshot of Chip's Challenge for MS-DOS. The yellow credits text scrolls over the background. Is it on its own plane somehow? Is every letter a "mouse cursor?" Or, is the screen constantly being redrawn with the letters in their new position? The movement of the text is so smooth it appears to be hardware scrolling like you would see on the NES or Super Nintendo but as far as I'm aware MS-DOS PCs don't have that.

Chip's Challenge on DOS

2
  • the C64 didn't really have a bitmap mode like that. It was more like a console or a hardware-accelarated ZX Spectrum with more modes, i.e. it had character cells or tiles or attributes, and sprites. 320x200 resolution, 16 colors, but any 8x8 cell could have only 2 colors, or 4 colors with double-wide pixels. And the whole screen could be fine-scrolled, and sprites could be layed over it. So it was not a directly "memory-mapped" "bitmap".
    – scrollbear
    Sep 13 at 20:11
  • Thanks for the info, but this question was about MS-DOS. Funnily enough I'm more interested in C64 at the moment, I found MS-DOS to be a bit frustrating. Sep 14 at 10:21
31

Seems like VGA only has one background layer, it appears to be a typical bitmap screen like most home computers of the 80s (Amstrad CPC, Commodore 64 etc.) where each pixel's color is stored in a section of memory that can be written to directly.

Most video cards of the day could theoretically have up to four pages of video memory, as they had 256 KiB of storage, and only 64 kB was needed per screen for a 320×200 resolution. There was only one displayed "layer" (or plane, to be technically correct) at a time, though. You couldn't render two different things and have one overlay the other, as you do with modern video cards.

The closest I can get on DOS (I'm using DOSBox if it's relevant) is the mouse cursor, which seems to "eat away" a portion of the screen when it spawns, after which it can move over top of text without erasing what it passes over.

This was a feature of the mouse driver software. It would store whatever was underneath the cursor when drawn, and then replaced when the mouse pointer moved. This was independent of video memory.

Some special video modes wouldn't work with this default behavior, in which case the programmer had to draw a custom cursor. The mouse driver would simply suggest where the correct position was in this case.

In fact, some games that updated the screen frequently would have the mouse pointer "hidden" until you moved it. The driver didn't know it needed to update the pixels on the screen. Programmers eventually got around to anticipating this and fixed it with custom cursors.

For an example of what I'm asking, please take a look at this screenshot of Chip's Challenge for MS-DOS. The yellow credits text scrolls over the background. Is it on its own plane somehow?

No, video cards of the day only displayed one plane at a time. The programmer could choose which plane to display in certain modes, however, in a method of page flipping. This allowed the next frame to be rendered ahead of v-sync, so when the page was flipped, it provided an instantaneous change to the display.

Is every letter a "mouse cursor?"

No, they were just normal bitmaps. Things like transparency and multiple layers were not yet possible at the hardware layer; they were managed in software entirely.

Or, is the screen constantly being redrawn with the letters in their new position?

Closer. Each frame is drawn either off-screen, and the displayed plane would be selected for each frame, or in a memory buffer, and then blitted to the screen during v-sync (e.g. with DMA or a simple "memcpy" loop).

The movement of the text is so smooth it appears to be hardware scrolling like you would see on the NES or Super Nintendo but as far as I'm aware MS-DOS PCs don't have that.

They didn't have hardware scrolling per se, but they could use double-buffering or plane swapping to provide a consistent framerate. One such article that appears to do a pretty good job of explaining it is this one.

The unchained/Mode X mode was incredibly useful, as it allowed full access to 256 KiB of video memory at the cost of some complicated algorithms to get pixels where you wanted them. However, for most games, this produced a very nice output at 60+ frames per second. Some of the best games used this technique for quite a while.

In summary, memory back then was at a premium, but developers had a lot of tools available to them provided by the hardware. In a sense, it was still "hardware accelerated", but in a very primitive form. As video memory expanded into megabytes and finally gigabytes of memory, entirely new APIs appeared, such as display lists and other techniques.

However, back in those days, every pixel had to be accounted for, and programmers came up with clever techniques to make those frames as smooth as possible.

10
  • 1
    Very interesting. I wasn't aware there was a "frame buffer." I suppose it's not a dedicated section of RAM and you have to allocate it yourself. I'll put it after the user variables (I'll see if I have enough room, I still have a lot to learn about MS-DOS. I'm more used to working with game consoles than traditional computers so a lot of the things I'm used to are handled by dedicated chips without my input. As for the mouse "eating away" at the screen, the best solution I've found is to hide it when drawing to the screen, silently move it then have it reappear elsewhere. Sep 4 at 12:20
  • 2
    You can have 4 semi-independent layers in 16-color modes and palette trickery youtube.com/watch?v=iSVAFEbB_j8 That runs smoothly on a 286/12 or even 286/10. Youtube isn't smooth of course. Those who got to see that back in the day probably remember it. And VGA allows setting the starting address of the video page, which allows for smooth hardware scrolling. Though still just one plane. And then there's a screen split which allows you to have a separate stationary part in the bottom of the screen, used for the score display here: youtube.com/watch?v=MSaohyJ_E2w&t=120s Sep 4 at 13:25
  • 4
    @puppydrum64 No, the frame buffer is a dedicated area of RAM, located on the graphics card. it's were the frame displayed is stored. Hence the name. Do not confuse with modern software managed frame buffers, this is about the real hardware.
    – Raffzahn
    Sep 4 at 15:35
  • 2
    A couple of minor quibbles... Regarding mouse handling, few DOS games actually supported the mouse, and games that did pretty much always had their own cursor handling (if they displayed a cursor at all). Early mouse drivers didn’t support VGA anyway. It was documented that the mouse cursor had to be hidden before screen updates, this was always a known problem and the only programmers that “got round to anticipating it” were those who didn’t read docs (which admittedly wasn’t unusual). Sep 4 at 16:57
  • 1
    Regarding double-buffering etc., it doesn’t help ensure a consistent framerate, it helps avoid screen tearing and seeing screen updates as they happen. Sep 4 at 16:58
10

Is it on its own plane somehow?

No, as you assumed, VGA has only one plane(*1).

Is every letter a "mouse cursor?" Or, is the screen constantly being redrawn with the letters in their new position?

The latter. Most likely it's composed of a background image moved into the frame buffer, overlaid by the text layer. (*2)

The movement of the text is so smooth it appears to be hardware scrolling like you would see on the NES or Super Nintendo but as far as I'm aware MS-DOS PCs don't have that.

No, it doesn't. Then again, note that the above runs at, in Dosbox terms, 3000 cycles. That's the rough equivalent of a 14-16 MHz 80286 (or 12 MHz 386) if not better. Such a machine (with upclocked ISA-bus) is able to redraw a VGA screen at rates past 100 Hz. More than enough to keep text smooth.

Dosbox isn't meant as an emulation to be as historically exact as possible, but to enable people to run games in an acceptable manner. Therefore it's not a historically exact emulation of a specific machine architecture/configuration, but a rather abstract approach to let games run for gamers, not historians.

Try fixing cycles to 350 and you'll get closer to what an original PC-XT would deliver :)


*1 - Though it has multiple pages, which could be used to smoothen animation by page flipping.

*2 - Well, EGA and most SVGA cards do provide a single 'sprite', usually used as mouse cursor.

14
  • ...though, as the 4.77 MHz page on the DOSBox wiki says, "DOSBox has only one speed control, and it slows down all computer instructions by the same percentage (more or less). It is therefore not possible to tell DOSBox to slow integer math by X%, floating-point math by Y%, and non-math by Z%, etc. Near-perfect 4.77 MHz speed will not be possible until someone builds an XT emulator specifically for this purpose." and it provides a benchmark tool for you to experiment with to find the best match for your host CPU.
    – ssokolow
    Sep 4 at 8:09
  • 2
    IIRC, my 286/12 was able to rep movsb at most something like a 320x50 area from main memory to mode 13h video memory at the 70 Hz refresh rate. 8 bit Magic VGA ISA card. Far from 320x200 x 100Hz. That machine was scrapped decades ago already, so can't test. Sep 4 at 17:18
  • 2
    @piiperiReinstateMonica it makes a huge difference if a 286/12 is using ISA at default 6 (or 8) MHz and one WS, or if that is as well run at 12 MHz and zero WS, doesn't it?
    – Raffzahn
    Sep 4 at 17:21
  • 3
    Pedantically: DOSBox is very accurate to the environment it emulates, a DOS computer being defined no more specifically than by its instruction set, the DOS services, and the hardware memory and IO map. It just doesn’t seek to be accurate to any specific DOS computer. So it’s because there’s no one DOS computer that DOSBox is accurate. … or, more likely, I’m arguing semantics.
    – Tommy
    Sep 4 at 17:29
  • 1
    @Tommy Kinda semantics, but not wrong either. Let's agree that there have been endless variations in real Hardware, while Dosbox is (as you describe) more of an abstract best case szenario.
    – Raffzahn
    Sep 4 at 18:19
6

Geenimetsuri's answer about colour cycling is a very good point that deserves a demonstration. :)

Here's a GIF taken from the end of the first level of Episode 1 of Jazz Jackrabbit.

enter image description here

Jazz Jackrabbit uses Mode X for the main gameplay screen. Mode X is a 256 colour mode which provides a single bitmapped layer of indexed colour pixels, like mode 13h. However, unlike mode 13h, it allows the programmer to use the panning and memory offset configuration fields of the VGA hardware to scroll the screen over a region of video memory to provide a large 'virtual screen'. This means that as the camera moves around the 2D world, only new tiles coming into view on the edges of the visible screen need to be drawn, instead of the entire contents of the screen being redrawn every frame†.

There seems to be a number of independent layers used in the Jazz Jackrabbit animation above:

  • The static status bar that does not scroll with the rest of the screen.
  • The large landscape graphic that moves freely.
  • A coloured gradient sky in shades of blue.
  • Jazz himself appearing on top of the landscape.
  • The static sun sprite disappearing behind the cloud on the right.

Despite Mode X only allowing a single bitmap layer, these five elements all exist on top of one another. Let's look at them in turn.

The static status bar is implemented using the automatic split-screen feature of the VGA that uses the Line Compare configuration fields to show a non-scrolling horizontal region beginning at a given screen line. This feature lets the programmer split the screen into an upper freely scrollable section, and a lower fixed section.

The upper section is the normal scrollable Mode X bitmapped indexed colour screen, so all the 'layers' you see in that region are either software sprites drawn onto and later erased by redrawing the landscape at that location, or effects created by manipulating the palette.

Look very closely at the blue sky gradient. Notice how it moves at a different rate to the camera when Jazz jumps - it's properly parallax scrolling! If you don't believe me, watch how the lightest bar of the sky matches the height of the green platform on the left when Jazz is standing, but descends slower than the landscape does when he jumps.

Notice how the bands of colour are perfectly horizontal. The way Jazz Jackrabbit allows the sky to seemingly move vertically independent of the rest of the level graphics is by altering the current sky colour on every scanline. The sky itself is part of the scrolling Mode X screen - it's part of the landscape graphics like the cloud is. The graphic tiles that are copied to the screen use a single colour (let's say index 0) to represent 'sky'. Anywhere on the Mode X screen containing index 0 will show the current sky colour at that pixel. It's possible to detect the horizontal blank period in the display when programming bare-metal PC games. Jazz Jackrabbit detects when each scanline ends as the screen is displayed and alters the colour at that instant, reading it from a table of sky colours generated at the end of every frame. The indices in the screen RAM aren't changing as the sky 'moves', but the colour in the palette that those indices represent does change. You might know this effect by the name of 'Raster bars'.

To make the sky 'move' independently of the camera, take note that the relationship between the colour values in the table and the camera's position is entirely the programmer's choice. If the colours shift positions in the table at a 1:1 ratio with the camera motion, the sky will look flat against the scenery since they'll move at the same rate. If it's 1:2, it will look like the Jazz GIF does, with the sky colour moving slower than the camera motion.

The static sun appears to be another layer, doesn't it? Unlike the Amiga, there are no hardware sprites for VGA to use for this. It's a software sprite drawn onto the Mode X screen (masked behind the existing scenery - reading, comparing, writing) and then erased and redrawn in a new position on the next frame. Jazz himself is drawn the same way, but not masked since he appears on top of the landscape. (When you jump, sometimes you can see Jazz and the sun disappear together when he crosses certain Y values in the world. I think that's to do with the Mode X screen coordinates vertically wrapping, meaning a whole new screen needs to be assembled from tiles and the sprites being ignored for that one costly frame (deliberately or otherwise).)

I haven't reverse engineered the game - this is my best understanding of the effect I'm seeing.

If you set Jazz to NO COLOR ANIMATION in the Options menu, the sky is static and scrolls with the camera like it's a striped wallpaper on the same plane as the rocks, which it essentially is. (In this mode, I'm guessing the game has a static set of sixteen colours dedicated to the sky background instead of one index whose palette entry changes constantly. I'd expect that Jazz preprocesses the tiles as they're loaded into video RAM: the background tiles could be stored on disk with a flood-filled index 0 sky by default for the raster bar sky, with the permanent stripes painted in during loading if the colour effects are disabled (or vice versa). Notice that you can only toggle NO COLOR ANIMATION on the main menu, not during gameplay.)

† Most versions of Jazz support an optional /VGA command-line switch that uses an alternate renderer that bruteforce draws the entire VGA display instead of using Mode X though. :D

See also this question: What DOS games used Mode X as described by Michael Abrash?

8
  • 1
    If disabling the color animation disables the background sky stripes, it most likely is not a "raster bar" effect where you need to update a single palette entry after every few scanlines. It would be extremely difficult to make it look stable, with all of the keyboard, timer and soundcard interrupts happening asynchronously. Most likely it really uses the same color stripes of 16 colors, and depending on the player Y offset you simply update all color entries of the stripes to make it look like stripes move up or down at different speeds.
    – Justme
    Sep 7 at 6:37
  • That's possible :) Though the size of the stripes (the period of the pattern) in the main game window would indicate that they'd have to dedicate 32 or 64 colours to the parallax sky alone to achieve that. There's no way there's only 16 colours used, since 16px is the size of Jazz and period is longer than that. If the background had 32 colours, the background landscape tiles would have to be somehow processed to work with that system - the diagonal line tiles would have to have a 0-15 and 16-31 version somehow.
    – knol
    Sep 7 at 18:06
  • It could be waiting for every 16 lines to copy a block of colours, I suppose, but that would be even more fuss! I'll have to take a dump of the VGA ram at some point and see for sure. The NO COLOR sky definitely looks a lot different to the parallaxed sky. i.imgur.com/ijfkwHE.gif
    – knol
    Sep 7 at 18:15
  • Mistake in my comment: Jazz isn't 16 either he's 32. :)
    – knol
    Sep 7 at 19:45
  • 1
    Excellent answer! The lack of good platformers for PC (well, sans Commander Keen & few others) was noticeable until the mid nineties (perhaps ~1993ish onward) when PCs began to be in the high end 386, 486 range with multiple megabytes of RAM and could actually do smooth scrolling without all the demoscene wizardry! Sep 8 at 8:23
2

The movement of the text is so smooth it appears to be hardware scrolling like you would see on the NES or Super Nintendo but as far as I'm aware MS-DOS PCs don't have that.

To add a bit on the above excellent answers and comments...

You had several other tricks you could employ on a PC to "emulate" smooth scrolling.

First one, and very widely used in DOS games, was color cycling (aka palette rotation, palette shifting).

Instead of repainting pixels you changed the color they represent. You could do fantastic effects for what was essentially free compared to proper full screen animation. The technique has made a bit of comeback with HTML5 (see this page or e.g. YouTube for examples).

The other option was bit more arcane and related to video memory paging discussed above. You didn't have to flip the entire page, but you could also just shift where the "view-port" begins, and do various masking operations, such as splitting the screen into two halves (as already mentioned in the comments), or even literally scroll the pixels.

The real fun was in managing the process.

You could access most of the functionality from swapping video mode to modifying palette using hardware interrupts (mostly tied to int 10, see e.g. this list), but as the name implies they interrupt whatever the CPU was doing to serve the request. Therefore the preferred for most tasks was to write directly to video memory and access all the other video card functionality using hardware ports as those generally took much less time to process.

In case you're interested in what the inner workings are, I suggest you take a look at the Free VGA website.

In the end, beyond color cycling and page flipping (I think most often this was done from system memory, i.e. you drew the next frame in memory and copied that after vertical sync as accessing system memory was much faster), I suspect the other available techniques were much less used as redrawing a full screen just didn't take that much time for it to matter.

2

An EGA or VGA game that used 16-color graphics mode could exploit those cards' bit-planar architecture to create either a 7-color foreground and 2-color background, a 3-color foreground and 4-color background, or 1-color foreground and 8-color background, without having to do any save/restore operations on the background. I don't know to what extend games did this, but some styles of games could benefit from such ability. On the VGA, a game that used 4-color backgrounds would also be able to do a smooth cross-fade between two background designs if no foreground content was being shown.

-2

The very idea of hardware full screen bitmap layer overlays in the Amiga OCS was based on the software layer compositing done by game developers for Apple II and early MSDOS games (Budge's Pinball Construction Set, Artwick's Flight Simulator, et.al.) Budge's blit routines, in turn, were influenced by bitblit concepts that propagated to Apple Lisa group from U.Utah and Zerox Parc research. All originally done in (clever) software for hardware that supported displaying only a single bitmap per video frame (most early personal computers with bitmap graphics capabilities, including the the Apple II and the first 8088 PCs).

A Singer Link flight simulator could do large hardware overlays, but could not run DOS games.

3
  • 2
    The question is only about MS-DOS. Discussing the issue on other platforms does not answer the question.
    – DrSheldon
    Sep 5 at 18:53
  • The question assumes layers, which is independent of OS, and not universal, and concepts that existed in software predating MS-DOS (this is a retro tech forum).
    – hotpaw2
    Sep 5 at 18:58
  • 2
    This is a retro computing Q&A site, but not all questions in it require a history of the features they discuss... Sep 5 at 21:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.