Doom for 16-bit DOS computers | Hacker News Reader

Doom for 16-bit DOS computers

github.com

151 pointselvis7096 comments

For those that wonder how it looks, I found a video:

https://twitter.com/FOmmetje/status/1696266683756003451

or if you prefer:

https://nitter.net/FOmmetje/status/1696266683756003451

When I hear 8088 I'm picturing like an IBM PC original from like 1981, so seeing the video of this running on a 286 isn't as impressive in the end.

Doom barely ran on 386s and lower 486s, so running at all on a 286, let alone better than most any 386, is pretty impressive to me.

In the video it runs in an emulator clocked at 15x the clock speed of a real 286.

You can clock the 8088 to 10MHz, and the NEC V20 drop-in replacement ran up to 16MHz. I'd be curious to see one of those run this.

Looks just like the DOS Doom that I played in the 1990s

surprisingly smooth considering that its reading all the textures from disk every frame

Yeah, that's wild.

I imagine that on a physical vintage PC with a spinning rust hard drive (rather than in an emulator with storage presumably backed by an SSD) we'd be looking at a 1fps slideshow or less.

But, maybe I'm wrong! Maybe things would fit into the HDD's onboard cache and it would perform OK.

Ha ha ha onboard anything

PCs of a sufficient vintage had so little logic on the HDD that you could swap out the MFM controller card in your PC for an RLL one and get 50% more storage. The modulation of the signal written to the disk was the job of the controller card, not the board on the HDD. Turn your 20MB HDD into a 30MB with a controller change and reformat? Mighty tempting.

Hmmmmmm. I think they had some onboard cache around the time of DOOM? Now you got me interested....

This 4GB Western Digital AC-14300 with mfr date of 1995 seems to have 512KB of cache? Not sure if these specs are reliable though.

- https://stason.org/TULARC/pc/hard-drives-hdd/western-digital...

- https://www.ebay.com/itm/325794470911?hash=item4bdadd1bff:g:...

This 250MB Samsung from 1993 has 64KB of cache:

- https://www.directitsource.com/product-p/shd-3122a-ds2.htm

- https://www.youtube.com/watch?v=d-X2uYEx7tU

This WD Caviar 280MB from 1992 seems to have 8KB of cache.

- https://www.ebay.com/itm/154446527853

- https://www.priceblaze.com/WDAC280-WesternDigital-Hard-Drive

This 40MB Maxtor from 1990 has 32KB of cache.

- https://stason.org/TULARC/pc/hard-drives-hdd/maxtor/8051A-41...

So, I think any contemporary hard drive in those days would have some cache. Thanks for leading me down this nostalgic rabbit hole.

On a modern emulated 286 the entire HDD image would be cached in RAM, and sometimes maybe in L2/L3 cache.

But why is it doing that?

The video is running at 15x, though...

Looks about how wolfenstein 3d ran on my 286 Tandy 1000 rlx. Luckily you could reduce the graphics window size and dramatically improve performance

That's pretty good. There was another early 2.5D game that ran on my IBM PC that I played in around 1994 that this reminds me of. I'll go search for it now

Back, that was fast https://en.m.wikipedia.org/wiki/Catacomb_Abyss

I think the framerate was closer to like 5fps or so.

I was under the impression that this series running on an 8088 was a unique property but Wikipedia fails to mention it. I was a kid then so let's just presume I was wrong

> There was another early 2.5D game that ran on my IBM PC that I played in around 1994 that this reminds me of.

Catacomb Abyss was also a John Romero and John Carmack game.

This is sped up (look at the cursor blinking fast). This guy's experience on a 24 Mhz 286 is more like 0.1-0.2 fps. https://www.twitch.tv/videos/1911540009

> Super slow because for every frame every necessary image is read from the hard disk and for every calculation involving a lookup table the hard disk is also accessed

The 8086 was limited to 640k, a 286 could actually do 16MB with paging.

Is the problem simply the ram limit on the 8086? Is that why assets have to be reloaded off disk constantly?

Couldn’t a 286 with enough memory handle it (if you were emulating that processor)?

I’m curious what the issue is.

Even an 8088 could use more than 640kB through paging with EMS add-on cards. A 286 doesn't even require paging to use up to 16MB.

Adding EMS support is on the issue list. https://github.com/FrenkelS/Doom8088/issues/1

EMS only let's you have a 64kb frame, I don't think it matters if it's 286 or not.

A 286 doesn't need EMS though. You can use XMS or a 16-bit DOS extender and run in protected mode to access all memory.

You mentioned EMS that's why I brought it up.

On a 286 sure you can go to protected mode but AFAIK that tended to be more involved than most people would like.

In the case of XMS, that could help but still requires moving data to/from EMB.

Frankly EMS would be the best option to keep it workable on an 8088. At the very least the 64k frames could be used for some of the data that I'm guessing are streamed (belched?) from disk.

QEMM was created for the 286 (see QRAM) https://en.wikipedia.org/wiki/QEMM

But wasn’t Doom originally developed for “16-bit DOS computers”? That’s the way I originally played it, by installing it from 3.5” floppies as a DOS program on my Windows 3.11 PC, although it was a 486/33 IIRC. I could play the entire game, save my progress, and I had sound via SoundBlaster. In fact, I even installed Doom II on that same computer.

Doom used a DOS 32 bit extender called DOS/4GW: https://en.wikipedia.org/wiki/DOS/4G.

I thought it was originally developed on 32-bit 68k NeXT workstations, no? I would be interested if there was anywhere to learn how the porting to x86 went, especially with regards to different strategies for block transfers/etc.

It wasn't really "ported", is was developed on NeXTStep, but the target was X86/VGA/DOS"

Apparently they just cross-compiled it. Also, the NeXTStep version of Doom didn't have sound.

"We wrote all of DOOM and Quake's code on NeXTSTEP. We debugged the code in NeXTSTEP with DOOM and Quake's 320x200 VGA screen drawing in a little Interceptor window while the rest of the screen was used for debugging code. When all the code ran without bugs we cross-compiled it for the Intel processor on NeXTSTEP then turned over to our Intel DOS computers, copied the EXE and just ran the game. The DOS4GW DOS-Extender loaded up and the game ran. It was that easy."

http://web.archive.org/web/20140310124554/http://rome.ro/200...

In case, like me, you wondered what an "Interceptor window" was:

"NeXT also have an internal kit called Interceptor Kit, which allows a privileged application to punch a hole through the Postscript windowserver directly to the display card."

https://www.paullynch.org/NeXTSTEP/NeXTSTEP.TechReview.html

Id Software's history at that point (commander keen, wolfenstein, catacomb, doom) was entirely on x86 MS-DOS and they were exploiting all the tricks to achieve decent performance for games thought to not be possible on that platform.

So it seems very unlikely (to me) that they would develop the games first for a different platform, using a different OS, on a different CPU, with a different endianness.

That is exactly what they did. It's discussed in the Masters of Doom book, as I recall.

The difference is that the id devs had already come from the Apple II world first, so they had written plenty of 6502 assembly and were aware of the cycle counting types of optimizations, but chose to give some of them up to use C when they started on x86. That was, at the time, a relatively bold move.

By the time Doom was being made they definitely had a sense of what a high-level approach brought to the table, and that they could focus on just the "hot loops" for micro-optimization when targeting a 386. The process they were using to build their engine was ultimately iterative in nature, building some tools and some rendering and some assets, then gradually pushing each a little further: the introduction of the BSP algorithm came relatively late, for example.

They developed Doom on NeXT with highly portable C code. The reason for that is they were more productive on NeXT workstations (development and map design). Doom has been easily ported to every platform because they designed it to be easily ported. Recommended reading: https://fabiensanglard.net/gebbdoom/

It is the highly portable cross-system C code that makes it so easy to run doom on everything.

Because they were running ut on such different systems, almost all porting bugs were caught in development.

Not only that but it was due to their portable software architecture which was by design. Carmack isolated the platform dependent stuff so that you can port it to any other platform without too much effort.

Correct.

The great majority of platform dependent code is video output, keyboard handling, sound and network.

The functions for that that call dos/x86-specific code are neatly separated by the rest in appropriately named files, so it’s really easy to know what you will need to modify, without a million other distractors.

The 486 is a 32-bit CPU, like the 386 before it. Doom’s official minimum system requirement was a 486/66MHz.

Mobygames has a scan of the packaging:

https://www.mobygames.com/game/1068/doom/cover/group-1549/co...

"System Requirements: PC compatible 386 or greater"

But unofficially, you needed a fast 486 to run it properly. On a 386 you have to switch to low detail mode and/or shrink the view area to get an acceptable frame rate.

I seem to remember having a good time with it on a 386SX 20mhz. If I am remembering correctly (I have about 75% confidence in these memories) I just dialed down the view area by a notch or two which worked well for most of the game until I got to an area with a looot of monsters.

It was pretty tolerable since quicksave and quickloads were so fast. If you stumbled into an area where you took a bunch of damage because your frame rate dropped to 5fps you could just quickload, downsize the viewport, and try again.

Only if you somehow time traveled and brought a FAST DOOM source port with you.

386SX 20MHz no cache: https://youtu.be/osgld_uynl8?t=95

486SX 8KB cache: https://youtu.be/osgld_uynl8?t=151

386DX 40MHz 8MB RAM: https://youtu.be/9_2qGaIOvjs

386DX 33MHz 8MB RAM ET4000: https://youtu.be/KQDEKoRcXZc?t=140

386DX 40MHz 4MB RAM 256KB cache (probably bullshit), full viewport: https://youtu.be/L6U8fyEgRH4

Notice how it's fine in the corridors but starts to lag at any open space. There was a reason DOOM/2 got it map design.

HAH! Wow, I'm glad I didn't say I had 75% confidence instead of 100%.

That's really cool. Thank you for posting that, it's super interesting.

I guess I was playing it on my 486SX 33mhz then.

That's about how I remember my 40MHz 386 playing it. At the time, it was mind-blowing anyway. I would usually play it with the window shrunk a couple notches.

What's bullshit about that last one? I had a 386DX40, AMD made them, they were a popular budget option in the early 90s and the first time I played Doom was on that PC. It ran better than that video demonstrates, even at full res, though I ran it half-res and with the window downsized a notch. I presume they're using a particularly crappy video card.

The amount of cache. I'm not sure why but my BS-meter went off on that one.

One thing I remember was that DOOM did not run well on the 486SX. You needed the 486DX which had an FPU. Maybe there was a 486DX with 33mhz but most were 66mhz I think?

I played Doom in my 486sx 25mhz..

I played it a little in a 386SX40. I had to reduce the rendered screen size, and even then it struggled in open or complex scenes and/or when there were a lot of enemies active.

Doom uses fixed point math so it doesn't matter if you have an FPU. But the fastest 486SX was only 33MHz, which isn't really fast enough for Doom, and they were typically used in cheaper systems with slower graphics cards/buses, which also made a big difference.

One of the biggest contributor to performance differences was the implementation of the L2 cache on the motherboard.

More expensive chipsets tended to have better cache implementations... Assuming the system even had cache installed, those cheaper systems often paired a 486SX with a cheap motherboard and zero L2 cache.

When installed on the same motherboard, same cache/memory config, with the same graphics card, same bus speed, a 486SX should run Doom identically to a 486DX.

I remember it being the case that Doom was aggressively tight-loop optimized, so the small amount of L1 cache was more significant especially on clock-multiplied 486s. Though you are right that the SX/DX distinction wasn't meaningful for Doom as it was all done with internet mathematics.

Yeah, the clock multiplier will also make a large difference.

Which might actually be a fair comparison, The DX2 and SX were launched at the same time, so there is a decent chance the "fast 486 DX" someone is talking about is actually a DX2.

The SX2 was launched later, with the same 2x clock multiplier and same size L1 cache, so would preform identically to the DX2 (in non-fpu tasks like doom). But the DX4 was launched at the same time, now with a 3x multiplier and L1 cache doubled to 16KB....

There were the 50 and 66MHz 486SX2's as well

486DX2/66 checking in

486DX2/66 with VLB S3 Vision864 checking in

If I recall, the 486-SX was a DX with the FPU disabled (or it was defective). There were 25,& 33MHZ versions.. I think the 66MHZ were "DX2"

IIRC AMD put out a chip that officially ran at 66MHz without clock doubling, though obviously you needed a motherboard (and RAM) capable of running at that rate.

You are confusing Doom with Quake.

Doom run okish on 486SX.

"okish" by 1993 standards, but not a solid 35fps with full detail and full viewport size. Of course, that didn't stop people from enjoying it.

OFFTOPIC TANGENT

Hi moderators, please consider not downvoting me here; I'm resorting to commenting in this newer thread where replies are still enabled in an attempt to reach mrob (whose profile has no contact info).

---

Hi mrob, I just wanted to thank you for your extraordinarily helpful comment about harmonics in music. I've been playing guitar for about 30 years and make regular use of harmonics in my playing (and tuning), but when a nonmusical friend recently asked me to explain why those sounds were so different when lightly touching strings above the 5th, 7th and 12th frets, I had little to offer by way of a coherent explanation. Favorited and bookmarked / added to my PKM. Have a great day and thank you for such a great comment! You're a great example of what makes HN such an awesome community.

PS This is the comment: https://news.ycombinator.com/item?id=37047142

I played Doom on my 486DX 33MHz.

IIRC the fastest base 486 (out of the box without trickery) was 50MHz. There was a DX2-66 (and DX2-50, which ran clock doubled with the rest of the motherboard at 25MHz). There was also the DX4 which despite the name was only click tripled, running as fast as 100MHz of a 33.3MHz. Other manufacturers produced faster clocked i486 compatible processors: I had an AMD 5x86 which was actually quad-clocked, running at 133MHz internally. For tight loops where the code and enough data for a fair few cycles fitted into its on-chip cache (something like 8K code & 8K data?) these were surprisingly speedy compared to Intel's 486s and even low-end (66MHz, and in some artificial tests 75MHz) Pentiums. Cyrix had some similar models that were quicker still for integer work, and IIRC cheaper so even better VFM for sure tasks, but had abysmal floating-point performance which was rapidly becoming pretty important for games around that time.

Doom used integer maths throughout, so would not benefit from and FPU, but did get a boost in complex maps from the faster internal clocks of doubled/tripled/quadded chips. The Quake era (maybe a little earlier for some more niche games like certain fight simulators) is when the FPU became a massively significant factor for home use (though it didn't exclusive use it: the original Pentiums' FPU wasn't trials fast enough so only something like 1/16th of the work was done there and integer approximations starting from those values were used between - improved further by the FPU being able to work on its next bits while the CPU ALUs could do there part, a hack somewhere between pipelining which 486+ units did naturally (& Pentiums more so due to extra ALU circuitry) and hyperthreading).

I had a 486DX 33MHz (4MB IIRC).

Doom ran well on it.

I believe I had to start the machine with a boot floppy that configured the system before I run the game though.

How can multi-player be ported to https://dos.zone/ ? WebUDP ??

According to another comment, this is based on GBA doom. Dos.zone seems to already support multiplayer, so it should be as simple as implementing (probably copying in) the multiplayer part to replace the link cable functionality.

My first computer was an IBM 486DX@33Mhz. My father had an Apple Macintosh Quatra (Ferrari) and I had this IBM (hooptie). I remember vividly trying to get DOOM to run on it. It would but at 6fps. With the turbo switch on, 66Mhz, I got 12fps on low settings.

My father and I tried everything we could to overclock that IBM into 133Mhz but the CPU was holding it back. Later that year, he bought Marathon by Bungie (precursor to Halo) for me on his Mac. I think he felt bad that I was so disappointed. I loved it. He saw this and for Christmas that year, I had a new motherboard with a new Pentium chip capable of ripping Martian marine mutant faces.

> My first computer was an IBM 486DX@33Mhz. > With the turbo switch on, 66Mhz

That’s not how a turbo button works, it doesn’t make the pc “go faster” [1] :)

Either you had a 486@66Mhz, or you set your multiplier to 2x instead of just pressing the turbo button.

[1] I mean, you could by default power your pc with turbo in “slow mode”, and activate it for hyperspeed, but you’re still using a 66Mhz CPU that is being normally slowed down

https://en.wikipedia.org/wiki/Turbo_button

I know the chip was a 66mhz chip. Without the button pressed, it was useless. I also know this was about CPU timing. Having it "on" slowed down the timing. But having it on (to slow the CPU timing) and trying to overclock the CPU (to make it faster), resulted in nothing more than a few fps. After the upgrade to Pentium, it was 60fps.

The turbo button is a 3-pin switch. Some wired it so that "off" was full-speed. Some wired it the other way. I believe mine were wired for "on" = fullspeed.

Sweet, I can run it on my new book 8088 laptop

https://www.aliexpress.com/item/1005005534146618.html

I can't easily tell; does it still require VGA or MCGA to run?

While i haven't tried it, there is code that sets it to mode 0x13 [0][1] so it would be VGA.

[0] https://github.com/FrenkelS/Doom8088/blob/2001f8c2576a2e99f3...

[1] https://en.wikipedia.org/wiki/Mode_13h?useskin=vector

I was wondering that as well since Wolfenstein got a CGA port: https://github.com/jhhoward/WolfensteinCGA

The CGA mode is playable, but pretty bad looking as would be expected. It looks much better with the Tandy graphics mode enabled. It'd be cool to be able to run Doom on my Tandy 1000 as well.

Does anyone know of any compact Doom wasm examples? Looking for the tiniest Doom that could run in a web browser.

> It's based on GBADoom

I wonder why. The GBA has a 32-bit ARM processor.

Not all projects have #defines for pointer and type sizes, or hardcode values for these sprinkled through the code. So probably to port to GBA they had to go through the code and fix these. Now this specific codebase of Doom is better suited for other ports as well.

Probably better matches the makeup of RAM and processor speed. The GBA only has 384KB and runs at 12.5MHz.

Also a quick background and the GBA port is a port of the jaguar port which is a port of the SNES port.

So somewhere in that heritage is the SNES version of doom. A 16bit version.

Correct. It's actually not even Doom:

The game does not use the Doom engine, but features a custom engine, known as the Reality engine, programmed by Randy Linden.

The Jaguar port is not a port of the SNES port. It was built in-house at Id and was developed by Carmack himself. See Doom Wiki: https://doom.fandom.com/wiki/Atari_Jaguar

The SNES port runs on a bespoke engine written by Randy Linden. Whereas the Jaguar Doom is the basis for many console ports, SNES Doom is something of an (incredibly impressive!) dead-end on the Doom family tree.

I took this to mean the assets rather than the code.

Doom will soon have been ported to more hardware than NetBSD!

It's interesting that a not very optimized port of DOOM was available for m68k Macs where DOOM runs at an almost playable framerate on a Mac LC or LC II with 15 MHz m68020 or m68030 on a 16 bit memory bus. It's worlds faster than DOOM on a 24 MHz 80286.

Doom ran on the 16 bit SNES console

But it needed an additional coprocessor to do it, which shipped within the cartridge (Super FX 2)

SuperFX was 16 bit too, no 32 bit registers.

Yeah, thanks. I went to investigate and was baffled to find that it was speedier but still, 16 bits. Insane stuff!

Maybe I am missing something but are all the wall textures replaced by the door texture?

Finally

Reply on news.ycombinator.com