The original DOOM and its derivatives (DOOM II, Heretic, Hexen) were early 90s 3D games released at a time when DOS PCs usually had ISA bus Super VGA graphics cards. In the following few years, PCs would be upgraded to PCI bus graphics cards. The difference was stark, with PCI bus running at 33 MHz and 32-bits wide.

But DOOM engine games not only run fine on newer PCI graphics cards, but seem to benefit from the added performance. Anecdotally, DOOM on a Pentium PCI machine is faster than on an 80486DX with ISA graphics by a margin that suggest to me it isn't just a result of the marginally faster CPU. So, I am speculating that the PCI bus graphics card is also leveraged somehow.

How does DOOM (specifically) use this newer bus and graphics card than what it was written for to get added performance?

  • 2
    Assuming you by "DOS" mean "MS-DOS", Doom certainly isn't a "DOS" game. It will only run on an IBM compatible machine with VGA compatible graphics. It only uses MS-DOS as a glorified boot loader and will not run on any other MS-DOS based machines like the NEC PC9801 series. – idrougge May 6 at 16:16

DOOM itself doesn’t do anything special to benefit from PCI graphics cards. It runs faster with PCI graphics cards (and VLB, AGP, and PCI Express cards) than with ISA graphics cards because the supporting bus is faster, so reads from and writes to video memory take less time.

PCI goes to great lengths to preserve backwards compatibility with ISA-based VGA, providing support for “VGA compatible” adapters so that they can appear in memory at the same locations and use the same I/O ports as ISA VGA cards. So accesses to the VGA registers and to the VGA buffer (at 0xA0000) go directly to the main PCI VGA compatible adapter in the system, with no change required in the operating system or programs running on it. (This is the reason why there’s a specific “VGA compatible controller” device type in PCI. Such shenanigans are impossible for other device types in PCI, which is why PCI sound cards have so much trouble providing compatibility with programs written for ISA sound cards.)

A faster bus and/or faster video memory immediately leads to higher performance in video-intensive programs because software doesn’t need to be careful about how it accesses video memory (except on CGA, and on all platforms with vertical blank synchronisation if it cares about tearing). So REP MOVSW or REP MOVSD with no waiting in software, once the program decides to write a frame, is perfectly fine, and will go faster and faster as the underlying hardware improves. On platforms where this can’t work in hardware (e.g. on an 8088 with a VGA card), the hardware takes care of specifics — for example on an 8088 the bus unit will split up 16-bit accesses.

Your question is specific to DOOM but other DOS games are in a similar situation. Later games tended to rely on VBE (often using UniVBE) to access video modes beyond those provided by VGA, but they mostly didn’t use anything beyond video-mode setup and framebuffer configuration (see also Were any DOS games (or software) known to use VBE/AF?), so improved video speed came mostly from bus speed increases, faster video memory, and speed increases in the cards themselves (which was already a factor in the ISA era, compare most Trident cards to Tseng cards for example).

For an excellent explanation of the intricacies of VGA programming and its memory layout, see Fabien Sanglard’s Game Engine Black Book series. The DOOM update loop is shown on page 185 of the DOOM book; it doesn’t use any assembly language (unlike the renderer, see pp. 290 and following), but it does have one perhaps surprising feature given the 32-bit nature of the code: VGA updates are done 16 bits at a time. Section 2.3 of the same book, pp. 59 and following, describes some of the improvements to VGA adapters around the time DOOM was released, in particular the switch to the VESA Local Bus on 486s. The benchmark table on page 287 shows the importance of the bus.

  • Comments are not for extended discussion; this conversation has been moved to chat. – Chenmunka May 6 at 8:20
  • I had an EISA VGA system and it was a little disappointing that Doom only had 16-bit accesses as it wasted half the capacity and effectively ran at the same speed as with quality ISA VGA. Still though, it was plenty fast... – Brian Knoblauch May 9 at 14:01

(When selecting an answer, use Stephen's - I just put this here because it is too much text for a comment)

Most Important: It's a Game of Raw Numbers.

We can ignore more complicated stuff and simply go for bandwidth:

  • ISA had at the time a bandwidth around 16 MiB/s (*2)

  • VLB (*1) and PCI offered up to 133 MiB/s bandwidth.

  • A 320 x 200 screen needs 64 kB (lets say 64 KiB) (*3)

  • With 30 fps, which can be considered good (*4), that adds up to ~2 MiB/s

  • 2 MiB/s is 17% of the raw ISA bandwidth

  • but it's only 2 % of VLB and PCI's bandwidth

That is worlds for a game like DOOM, that did in the days shined due its many ways to make 3D run on barely able hardware. Often forgotten today, Doom not only reduced detail, but as well screen size. It offered 9 sizes, from 320x200 down to 96x48 (*5), and having a letterbox around the action was common, not the exception.

Performance One Can Feel

Gaining 14% additional CPU time to operate is nothing for an application, but huge on a resource strapped game. It's the difference of running DOOM in at least one screen mode up.

And between an ISA system capable to use 320x200 and the same CPU setup with PCI of at least doubling the frame rate - that's from barely playable to lightning fast.

Either effect is quite visible. All without changing anything within the game.

Downward Compatibility is the Name of the Game

PCI (and VLB) were made to have (existing) I/O hardware appear to the system like before. VLB a bit more than PCI, as PCI. In either case VGA memory and control was mapped at the same addresses than on ISA. A worthwhile effort as all software would benefit right away without any modification. It would need no knowledge about the changed bus system - the same way a 8086 software does not need to know if it's running on a Pentium.

So it was downward compatibility of the new bus systems - made by its developers to be able to sell PCI systems. After all, who would buy an incompatible PC, one were the Flight Simulator doesn't work like on an 8088?

From Comments:

But how is this managed "automagically". How is this forward/upward compatibility implemented?

There is nothing magic. The VGA memory was with PCI available at the same real address as with ISA before: A0000h. No change in the (visible) HSI (*6), so no need to change the software.

Your [@StephenKitt's] improved answer implies to me that original VGA was designed with upward compatibility to a 32-bit system bus.

No, if at all, the other way around. The newer busses were the same, except faster and wider. And both changes are invisible to software. From a software PoV there is no difference on how fast a CPU runs and/or if an access is done in bytes or words. That's all covered by the CPU hardware. The only measurable difference is speed. Something software will only 'feel' in performance (which is what your question is about), but not in operation.

Also that faster busses are transparent because slower busses just introduce wait-states.

No, there is no relation between software and bus (or CPU) speed. That is, no other than over all performance. Software does not need to be rewritten for different clocked CPU's, bus width or speeds. It will just show in what it can crank thru in course of time. In case of your PCI/ISA question, DOOM is simply able to transfer a frame in less time, thus either producing more frames in a given time (aka fps), or frames with a higher resolution (selected in the option screen). Either way: Better Gaming.

Lesser but Related: Pentium and VLB Sucked.

I do not remember the full parts, but AFAIR Pentium chipsets and the VLB protocol did not go well with each other resulting in a meagre performance, making a Pentium-VLB slower than a 486-VLB, while Pentium-PCI did work well. This not only made VLB obsolete soon, but also added a lot of less than favourable DOOM results.

Carmack and Romero, the DOOM guys, did BTW think that VLB was the way of the future to go and PCI just a strange side development by Intel, as one of them stated at the time.

*1 - Never forget VLB, it was the go to for gamer at the time)

*2 - Well, ISA had no fixed defined bandwith, as it always depended on the system. Early PC managed 2 MiB/s, while original AT did 6 MiB, later AT 8 MiB. Bus clock was ties to CPU clock, so faster AT clones could apply 10..12 MHz, neting up to 12 MiB/s. Many I/O cards would comply. With later 386 passing 16 MHz CPU clock, Chipsets started to handle I/O clock as a integer, non binary fraction of CPU clock. Like 33 MHz Systems offering 6.66 MHz, 8.33, 11 or 16MHz. Again later almost arbitrary dividers were offered.

At the time of DOOM, most ISA cards worked fine at 12 MHz or above. This already brought a huge speed advantage and higher frame rates, all without VLB/PCI.

For the above calculation I use 16 MiB/s as it represents what a good ISA card could deliver when plugged into a state of the art 386/486 system. After all, while using 8 MiB/s might show an even higher speed up, I do not believe it be fair to compare the new PCI bus system with anything else than the top end of its predecessor.

*3 - 320x200 is full screen and was almost never played. Highest regular mode was 320x168 with the well known status bar at the bottom of the screen.Saving these 32 lines brought already a noticeable difference in frame rate, even on high end systems.

*4 - Looking back shows how much pampered we're today. Playing Doom at 20-30 fps was great.

*5 - Yes, way less than a Game Boy - not sure if anyone ever successfully played in that mode.

*6 - Hardware Software Interface - a fancy name for addresses by software and their semantics.

  • 3
    Doom at 20-30 FPS is still great - on a DOS PC. It helps that there's so little latency between input and output, and that the FPS is stable - almost all of the time is spent waiting for the writes to VGA memory to go through, which doesn't change much from frame to frame, due to generally low overdraw. Duke 3D is even better, and could support very high resolutions too (though obviously on far better hardware). But hey, I originally played Crysis at 15 FPS (dropping to 5 in the "frozen" part :D); the human brain is very able to adapt to low but predictable framerates. – Luaan May 5 at 5:02
  • Pentium had a 64 bit memory bus, VLB being based on 486 bus had only a 32 bit memory interface. This was the main difficulty to get both to work together. – Patrick Schlüter May 5 at 7:39
  • @PatrickSchlüter PCI was as well 32. – Raffzahn May 5 at 8:43
  • 1
    "not sure if anyone ever successfully played in that mode" - OK, it was on Quake, but I played that with about that size on a 68040 with AGA. :) – Zenzizenzizenzic May 5 at 19:45
  • 1
    ISA bandwidth numbers are a bit arbitrary, because there was never really a formal spec that nailed down the clock speed like with PCI. Historically it ranged from 4 MHz to 16+ MHz. Some cards just didn't work right on machines with a fast ISA bus, so more reliable early 90's ISA slots were often much slower than many 80's ISA slots. 8 MHz / 16 bit would be "theoretically" 16 MB/sec. (But good luck actually measuring exactly that on any given machine.) – wrosecrans May 7 at 18:53

I can't recall the technical specifics after all this time, but I do remember that my ISA SVGA card (Trident 8900-based) would default to 8-bit bus traffic and 8-bit video-BIOS access. Getting both to 16-bit took quite some BIOS, TSR, and boot-time utility twiddling.

Games were noticeably faster in fully 16-bit mode!

So I doubt many ISA cards were actually running at their full ISA capability, which would exaggerate the perceived performance boost seen with PCI/VL-bus cards.

(N.B. I intended this as a comment, but the site upgraded it to an answer whilst I was signing in!)

Edit: ... and of course then there was the separate palaver of trying to get the video ROM shadowed by the system RAM. Basically, there was a lot of tweaking by the user needed, which in turn made it near-impossible for the coders to know precisely what to expect.

The temptation is to assume people would use the extra bandwidth to push more pixels around, i.e. to move from MCGA to a "hi-res" SVGA (640x480x256) mode; but remember that there was no standard API for that until VBE took off - see the linked question - and by that time 3-d accelerators were on the horizon.

So for the OP's question: DOOM (on MS-DOS) wouldn't behave differently depending on the data bus; it would assume an IBM VGA card. Meanwhile, ISA cards were partly nobbled by backwards-compatibility issues: my old card was expected to be fully-functional even in an XT, whereas a PCI card knows it's in a 486 or better.

  • Odd. I never had any issue with my Trident 8900 ISA cards not taking advantage of 16-bit accesses. The only card I found disappointing was one particular low end EISA card which somehow only managed to run 50% faster with 32-bit accesses than it did with 16. I didn't keep that one around long, can't even remember the model, but it may have been Trident based? – Brian Knoblauch May 9 at 14:03
  • @BrianKnoblauch Trident made the chips, I don't know how much scope the card manufacturers had in terms of how the whole thing would behave in a particular PC. – Lou Knee May 9 at 21:13
  • 1
    @BrianKnoblauch My card didn't like 16-bit data-access in the 286, but worked straightforwardly in the 486. OTOH, I still recall feeling annoyed with myself when, having had it in the same 486 for a couple of years, I then finally hit on a simplistic tweak that sped things up a lot, probably the BIOS/ROM access thing. – Lou Knee May 9 at 21:20

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.