DOS/V graphics text modes and scrolling

I recently ran into an interesting difference in the way various DOS/V versions manage VGA memory. DOS/V of course refers to the Japanese versions of DOS which are capable of running on standard "Western" hardware.

Microsoft has a very long history of supporting the Far East (how they used to be called) markets, especially Japanese and Korean, going back to the early 1980s. At that time, standard PC hardware was simply not capable of displaying Kanji ideographs; MDA had no user-definable fonts, and CGA had woefully low resolution. Systems tailored to the Japanese market used custom hardware, more or less incompatible with IBM PCs.

Once the VGA appeared, the technology was capable of emulating text modes using a relatively high resolution (for the time) graphics mode. MS-DOS/V versions 5.0 and 6.2 (released in March and December 1993, respectively; further referred to as DOS/V) both used a 640×475 graphics mode, slightly unusual but logical. The character cell was 19 pixels high and 8 or 16 pixels wide (Kanji ideographs, usually encoded as two bytes, were also displayed twice as wide as standard ASCII characters). To display an 80×25 text mode using a 19 by 8 pixel character cell, a 640×475 resolution is required. That’s not quite the same as the standard 640×480 VGA resolution, but it’s the closest lower resolution usable for relatively detailed glyphs and 80×25 grid.

One of the challenges of emulating a text mode on top of graphics mode was performance, especially for scrolling. For true text modes, scrolling traditionally involves redrawing the entire screen; however, the amount of data involved is small enough that even very slow PCs can scroll text sufficiently fast.

For graphics modes, that wasn’t the case even in the early 1990s. Redrawing an entire 16-color VGA screen would take too long, especially on slower systems with ISA bus, very common at the time. DOS/V therefore used the capabilities of VGA hardware to scroll without having to copy large amounts of data. However, the approach taken by DOS/V 5.0 differs from DOS/V 6.2, even though the end effect is the same.

DOS/V 5.0 used scanline pitch of 80 bytes (single plane), which means scanlines were tightly packed in video memory without any intervening space. DOS/V started drawing text at the beginning of video memory (offset 0) and printed new lines of text until the entire screen was filled. Once the screen was full and the text needed to be scrolled up, DOS/V simply drew the next line in the same way and reprogrammed the CRTC start address (registers CR0C and CR0D) to position the display at the beginning of the second line. The screen scrolled up but no existing data had to be moved.

But what happened when the bottom of the screen went past the end of the available video memory? DOS/V 5.0 took advantage of the fact that VGA has a 16-bit CRTC address counter which simply wraps around once it goes past 64KB. The wrap-around would occur in the middle of a scanline with DOS/V, because 65,536 is not a multiple of 80; but that did not matter to the hardware. DOS/V simply continued drawing at the beginning of video memory, effectively mirroring the hardware.

In DOS/V 6.2, the scrolling method was changed. DOS/V 6.2 took advantage of a different VGA feature called split screen. The VGA hardware can be programmed to split the screen at a specified scanline. At the top of the screen, content is displayed from the given CRTC start address. At the split point (determined by the line compare register CR18, with overflow bits in CR07 and CR09), data begins to be taken from the start of video memory (address zero).

When DOS/V 6.2 started displaying text, the method was the same as with version 5.0. Scrolling also worked the same way (modifying the CRTC start address) as long as the entire displayed screen was contiguous in video memory. The difference was in handling the situation where the displayed content needed to wrap to the beginning of video memory.

Rather than relying on the CRTC circuitry chopping off high bits of the display address and wrapping around automatically, DOS/V 6.2 created a split screen. That in effect forced the same kind of wraparound to occur, though not necessarily at the end of video memory. To that end, DOS/V 6.2 used a larger scanline pitch, 128 bytes. That meant the video memory had unused "holes" at the end of each scanline, but contained an integral number of scanlines, a requirement for the split screen technique to work.

The split screen method need not utilize the entire video memory buffer; it can choose to use any subset large enough to display the entire screen plus one line, perhaps to reserve a portion of video memory for offscreen fonts. However, DOS/V 6.2 utilized the entire video memory.

In essence, DOS/V 6.2 did the same thing as DOS/V 5.0, only explicitly programming what DOS/V 5.0 expected to implicitly happen. I can only speculate why the scrolling method was changed in DOS/V 6.2, but I suspect that some VGA clones did not correctly implement the CRTC address wraparound. Most likely those were Super VGAs with more video memory than the original VGA (i.e. more than 256K). Software relying on the address wraparound was very rare and therefore the functionality was not necessarily correctly implemented in hardware. On the other hand, the split screen technique was relatively well documented and well understood, and commercial software (especially games) sometimes used it. It was therefore likely to be tested and properly implemented in hardware.

In fact the DOS/V 6.2 code may have been deliberately crafted such that the implicit wraparound and the explicit split screen setup did exactly the same thing. Thus as long as the hardware correctly implemented either the automatic address wraparound or split screens, DOS/V would display correctly. That led to increased compatibility at the cost of negligibly higher overhead (programming the split screen address once every time the screen needed to scroll).

This entry was posted in DOS, VGA. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.