26

I noticed back in the DOS gaming era that DOS games ran slowly in hi-res modes. I was surprised to discover that this could be true on a modern machine.

I booted a 2017 i5 7200u (I think) laptop into FreeDOS and loaded Quake; predictably no sound but otherwise okay. However, in 1280x1024, it ran slowly, which seemed impossible.

I was aware that the processor has to switch between real and protected mode quite a bit, but I doubt that's the problem because I created a virtual machine, running on the CPU, and got Quake to run well in that resolution.

So, what is the bottleneck? The graphics chip? The CSM?

Improve this question
12
  • 3
    Have you rebuilt it or is it the original exe? A lot of the original code for graphics and floating point arithmetic is in assembler. It will take a while to unravel what the code is doing. You will need to check what routine is being used for this is how I put a dot in a specified colour at a specified position on the screen
    – cup
    Dec 11, 2021 at 8:53
  • 6
    here are my guesses: 1. 1280x1024 on 2D ray caster is quite a lot we usually used 640x480 or 320x200 back in the days and as old games did not multithread number of cores does not matter 2. old MS-DOS style timing might be compromised on new machines (like for example CRT lib error) and also syncing might be compromised which might diminish performance 3. old code was usually assembly optimized for specific CPU architecture, but nowadays CPUs are very different ... 4. emulated VGA/SVGA might not be as fast as the real stuff... especially with low level IO techniques...
    – Spektre
    Dec 11, 2021 at 14:51
  • 8
    Not an answer, but you may try GLQuake instead. Based on the same sources, but modified for OpenGL, which might result in noticeable speed increase - and being almost resolution independent.
    – Raffzahn
    Dec 11, 2021 at 15:45
  • 2
    There is no switching between real and protected mode. Quake runs entirely in protected mode. It does not make calls to the BIOS during rendering or for any purpose other than mode switching, and I believe it uses the protected mode VBE for that anyway.
    – R.. GitHub STOP HELPING ICE
    Dec 12, 2021 at 13:16
  • 2
    @Raffzahn: There are no OpenGL drivers on DOS.
    – R.. GitHub STOP HELPING ICE
    Dec 12, 2021 at 13:17

3 Answers 3

Reset to default
29

The original Quake used software rendering directly to video memory, at that time in 320x200, and you are using a resolution with around twenty times as many pixels. In other words twenty times the frame size that Quake was designed for.

I would expect that what you see is that the CPU simply cannot push single pixel values to the video card any faster.

A virtual machine does not push pixels directly to the graphics card, but uses a highly optimized rendering in the host, which most likely uses 2D-graphics acceleration to get the pixels shown.

Improve this answer
26
  • 8
    GLQuake uses OpenGL for rendering which requires lot less bandwith between the CPU and the GPU especially for higher resolutions.
    – Thorbjørn Ravn Andersen
    Dec 11, 2021 at 16:26
  • 10
    @LeonSimpson yes, and more as today's PCs hardware in no way works like back then, even through is seems on a software size. For example a graphics cars is no longer a simple byte parallel memory interface (like ISA) but a complex layered multi lane serial interface like PCIe. Much of the speed gains in modern hardware are reached thru larger transmission size and asynchronous communication. Something that doesn't go well with reading a byte (or word) from a VGA and writing it back modified. On a classic memory based interface, these are very basic interactions, close to maximum I/O ...
    – Raffzahn
    Dec 11, 2021 at 19:34
  • 9
    @LeonSimpson ... speed. On a modern PCIe the same VGA access needs to be packaged into a request packet, then packaged in a data link layer framing, then stuffed with some PHY framing. then the transaction started. The same on the way back to deliver the requested byte. After getting modified it gets again packaged and send to the card. So while hidden for DOS applications, it still represents the absolute worst case pattern possible. Any virtual PC/emulator will handle that buffer in memory and only update once in a while benefiting from maximum packet size with minimum transaction number.
    – Raffzahn
    Dec 11, 2021 at 19:36
  • 3
    @LeonSimpson Code written for old computers very frequently makes assumptions about the hardware it will be running on, which were completely valid assumptions at the time, but modern computers, while mostly compatible, have very different hardware. Code written to make optimal use of specific hardware may not work very well on modern hardware. DOSbox emulates that specific hardware, to an extent, and translates all the functionality the game uses into something modern processors can handle more efficiently.
    – Hearth
    Dec 11, 2021 at 23:06
  • 4
    It's even worse that you think with many modern video cards no longer supporting legacy VGA modes. You should consider yourself lucky that it runs at all natively on 2017 hardware. See here for more information: vogons.org/viewtopic.php?f=7&t=85099
    – Zhro
    Dec 12, 2021 at 4:46
10

Your problem is almost surely that FreeDOS (rather DOS in general) does not really treat mediating of access to hardware as part of its role as the operating system, and thereby has not setup access to the video memory properly. In particular, it likely hasn't set the MTRR (memory type range registers) or whatever the most recent equivalent of them is to enable write combining for video memory, so each write of each pixel to video memory is going through an expensive synchronization process.

If you run the exact same Quake binary under DOSEMU on Linux (if DOSEMU is even still maintained enough to work) or even an actual emulator like Dosbox, you'll likely find that it runs perfectly well because the host OS has setup video memory access correctly. There are likely tools to do this on FreeDOS too; I recall there being stuff like that back in the 90s or early 00s, but not what the names were or whether they were ever updated to work with later CPU models.

Improve this answer
16
  • 12
    People may take exception to "is not a real operating system" and having that in your answer does not benefit anyone. FreeDOS not setting up VMEM properly is useful information. No judgement here. Many would say FreeDOS is an OS, just not a very sophisticated one.
    – Spud
    Dec 12, 2021 at 19:05
  • 4
    Some BIOSes used to have an option to make video memory WC (uncacheable, write-combining) instead of UC (fully uncacheable, strongly-ordered). IIRC, my early-2000s board with an AGP slot called it "UCSW" instead of WC, as in "UnCacheable Software Write combining". But yeah, if the modern laptop firmware didn't default to that for MTRRs, you'd be out of luck for store bandwidth to the framebuffer.
    – Peter Cordes
    Dec 12, 2021 at 22:06
  • 4
    I found vogons.org/viewtopic.php?t=59676 which shows video write bandwidth numbers with / without MTRRLFBE. If the hardware/firmware supports a linear framebuffer at all, running some DOS program to set up MTRRs before starting Quake might help. Apparently there's are programs called MTRRLFBE and/or fastvid; I guess google for download links? (For those not aware, MTRRs are actual CPU registers, Memory-Type Range Registers, which can just be set once before running some other program, and change how any stores work to that address range.)
    – Peter Cordes
    Dec 12, 2021 at 22:12
  • 7
    Not setting up MTRRs has nothing to do with FreeDOS not being a "real operating system", whatever that is supposed to mean. I'm fairly sure genuine MS-DOS wouldn't know how to set them up either (and that is a real operating system, isn't it?). IIRC MTRRs were introduced by the Pentium II, so most DOSes predate them. It is the job of platform firmware ("BIOS" back then) to set them up, and modern firmware probably defaults to the most compatible option (uncacheable) because performance during early boot rarely matters nowadays.
    – TooTea
    Dec 13, 2021 at 8:19
  • 2
    By a "real operating system" here I mean one that mediates hardware access. DOS (FreeDOS or otherwise) is not doing that. Since folks seem upset at the wording I'll try to reword it.
    – R.. GitHub STOP HELPING ICE
    Dec 13, 2021 at 14:29
0

Quake only having a software renderer (on the DOS release day version at least) doesn't mean that you could do away with caring about anything else too.

An Athlon XP cpu is 5 times slower than yours give or take for our intents and purposes (i.e. multiple threads and SIMD extensions aren't a thing), and with the lamest "video accelerators" of the day you could get into single digits framerates even in QVGA resolution. Despite otherwise being more than enough even for SVGA.

I don't really know the intricacies behind CSM emulation (is it just the thing existing at all with its thunking everywhere? or perhaps nobody really ever bothered to optimize its VBE driver for speed? ...could the obvious lack of a legacy vbios/oprom in such new PC entail some extra burden too?) but that seems the only explanation.

Improve this answer
1
  • 1
    This. CPU's today just aren't that much faster than they were back then as one is inclined to believe they are (in a single thread workload). Just full-hd is more than thirty times the pixel count of mode-x.
    – Haukinger
    Dec 14, 2021 at 14:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .