For fast scrolling DOS games, when was Mode13h preferred over Mode X?

Question

Back in the DOS days of gaming (more specifically, 80286 - 80486 era), developers typically needed to choose between using the chunky and easier Mode 13h or the more complex "Mode X" that provided hardware scrolling and VGA memory-to-memory copies.

From what I understand, Mode 13h has a simple memory layout where all 320x200 pixels are arranged in a linear fashion. While this mode was simple, it had a smaller resolution than Mode X and was limited to 64K of VGA memory. Which means the CPU must copy new information over the slower external bus (such as ISA).

Mode X was more complicated because it used planar graphics (bitplanes). But it also supported a higher resolution of 320x240 pixels. Which are also square vs. the slightly "stretched" pixels of Mode 13h. Another advantage of Mode X was it supported hardware panning (scrolling) across the entire 256K of VGA memory.

So it seems to me that Mode X would always be the mode to use when you want fast scrolling games like Jazz Jackrabbit. Despite the more complex memory layout it seems to be a superior mode.

Then I recently read that the VLB (VESA Local Bus) eliminated much of the advantages of Mode X because it supports a direct connection to a 486 processor. While the CPU would have to drive more pixels for scrolling, a mid-range 486 could easily handle the task. Which means that using a simpler graphics mode such as Mode 13h would now be preferable because it could greatly increase development productivity.

So my two-part question becomes, is there ever a circumstance where Mode 13h is a better choice for fast scrolling DOS games over Mode X? Second, how (if at all) did the VLB standard affect this decision?

Answer 1

[I]s there ever a circumstance where Mode 13h is a better choice for fast scrolling DOS games over Mode X?

Sure, to start with,

• any single pixel operation on in Mode X is slower than for Mode 13, as the desired plane needs to be set first (*1)

• Next, the latch-trick (*2) can only move horizontal by 4 pixels at once. So any horizontal scroller will be jumping in mode X - or slower than mode 13

• Copying from main memory (program) into a Mode X screen is slower than Mode 13, as the desired plane needs to be handeled (*1)

[rhetoric follow up question] But if Mode X is basicly worse than Mode 13h, why was it apraised so much and used as well?

Beside the attraction of using some 'hidden secret' that is?

Mode X did

• allow a resolution with square pixels, great for drawing without the need for pixel distortion compensation

• support double buffering and page flipping, which is quite handy for dynamic games as it

  • removes flicker (half drawn animation)
  • decouples drawing from displaying, thus
    • allocates the whole screen time to drawing in the non displayed page
    • allows skipping of a frame (*3) if drawing gets too slow due too many objects/details

• allows the usage of memory beyond 64 KiB (as in Mode 13h) for additional pages or icon/data storage

• speeds up copying objects between screen parts, screens and non displayed buffers (along the 4 pixel borders) by 4 compared to main memory to VGA moves

Especially the double buffering parts where what a game like DOOM desperatly needed.

Second, how (if at all) did the VLB standard affect this decision?

• It made the whole 256 KiB direct accessible by the CPU, without the need to set map registers or banks or whatsoever, no matter what mode is used. Thus effectivly making Mode X addressing like Mode 13h.

• It also removed the advantage of the 'latch-trick', as now VGA memory could be accessed by the CPU in 32 bit chunks without using that logic, making the improvement available to all modes.

• By doing so (CPU direct accessing) it allowed the speed up for horizontal scrolling with arbitrary distance, not just in steps of 4

Last but not least, VLB did speed up every thing with access at CPU bus clock instead of ISA clock. Not to mention larger screen modes due more memory accessible without banking.

---

*1 - When multiple pixels are to be manipulated, like in a block operation, this can be offset by splitting the operation in four consecutive ones handling each plane separate - this of course only works on blocks, less or not at all on other drawing operations.

*2 - The 'latch-trick' uses the plane buffers of the VGA to copy data around. Internally the VGA operates (in plane mode) on 32 bit wide memory when the CPU reads a single byte of any plane all 4 bytes got read and stored in 4 latches and the one marked by the read map register gets transferred to the CPU when writing, the byte writen by the CPU gets stored to all planes marked by the map mask register. Due the 32 bit nature all other planes get writen as well, sourced by the previous latched content

This means a read of any byte in a group of four consecutive pixels fills the latches and a write to any byte of another 4 pixel group with a map mask register of zero will store the previous read pixels there.

That's the base for fast scrolling or data move. Instead of 4 single byte read and write operation, only one is needed, making moves that fit this scheme 4 times faster.

*3 - This ofc also needs a 'sense' by the game about time to advance all objects accordingly in the following frames.

Answer 2

For tile-based scrolling games of the "platformer" genre, it was certainly an advantage to use ModeX. This is especially true if you wanted to support slower 80286 or 80386SX CPUs with the early 8-bit VGA cards and which lacked VRAM. Here was a "triple whammy" of slow(ish) CPU, limited bus bandwidth, and limitations on shared access to the display DRAM.

I think you partially answered your own questions when you stated: Mode X was more complicated because it used planar graphics (bitplanes).

More to the point, planar graphics are more complicated and CPU intensive if you are rendering everything in real-time. But tile-based games rely on stamping down pre-rendered tiles, which can easily be encoded ahead of time for display in a planar memory.

Given the prerequisite of using tiles that are rendered ahead-of-time, the advantages of smooth hardware scrolling, VGA memory copies, and using all the available graphics memory become both easily accessible and highly desirable. You would want to leverage that, unless you knew you had plenty of CPU AND graphics memory BANDWIDTH to spare. Most games would seek to make the display update as efficiently as possible to achieve a "silky" high frame rate whilst leaving plenty of CPU cycles available between frames for the game logic, sound, player responsiveness, etc.

So ModeX is the way to go for tile-based games if you want/need to conserve CPU cycles or achieve a better frame rate. For everything else, Mode 13h allows for simpler real-time computation of byte-oriented pixel data, and would most likely offer the programmer less "friction".

It is also worth mentioning that rendering texture mapped 3D and compressed video frames (usually compressed with an expectation of chunky pixels) is a known challenge for planar bitmap display devices. The Amiga, well-known for excellent 2D and vector 3D graphics, needed a very fast CPU to render these sorts of graphics because the planar display hardware introduced computational overhead for transforming textures and FMV. Commodore specifically remedied this in hardware by inserting the "Akiko" custom chip into the Amiga CD32 console, which was intended to support the new breed of games that worked much better with a chunky frame buffer. Akiko removed the extra overhead by converting chunky pixels to planar pixels in hardware, similar to VGA Mode 13h.

Answer 3

On some video cards, using Mode X could be used to improve the performance of copy operations that take place within video memory, but techniques which would improve performance on some cards would severely degrade it on others. In particular, mode X made it possible to copy four bytes of memory using a single byte read and a single byte write. While that would seem like it should be faster than writing four bytes, that was only really true with early VGA cards. Among other things, copying 8 pixels with the parallel-load technique required the sequence "read a byte; write a byte; read a byte; write a byte", even when using a 16-bit card, while 16-bit cards could use "write 2 bytes; write 2 bytes; write 2 bytes; write 2 bytes". So the parallel write features of mode X no longer saved any operations.

More significantly, on most display cards it's only possible for the CPU to access memory at certain specific times. On older cards, any time the CPU wrote or read data, it would have to wait for the next access opportunity before it could do anything else, but newer cards could capture write requests into a buffer and allow the CPU to continue with other operations while the card held the data for processing at the next opportunity. Such buffering was possible with writes because the CPU had no reason to care about when data actually got written. Such a technique couldn't really be used with reads, however, because the CPU needed to know the result of a read request before it could ask for any other request.

Answer 4

It really depends on what/how you are updating. Yes, planar modes had some simple "coprocessing" advantages for copies/bulk sets. Plus the scrolling regions. However, simple sets incur extra setup overhead. For the types of graphics I did back in those days pure bitmap tended to outperform planar modes.