• Please review our updated Terms and Rules here

Doom8088: Doom on a 286 / 8088

Frenkel

Frenkel

Member
Joined
Jan 1, 2022
Messages
46
Wanna have a laugh? Watch deatsaw run Doom on a real 286.

Doom8088 is a port of Doom for 16-bit PCs based on GBADoom.
Right now, it's only a proof of concept. It supports only Doom 1 Episode 1. There's no support for sound, music, multiplayer, mouse or PWADs. Demos are out of sync and there are lots of crashes due to memory issues. To decrease memory usage, only one texture is used for every wall.

GBADoom needs only 256 kB of RAM. A PC can have 640 kB of RAM. That's more than enough to run Doom, right? Well, in contrast to a Game Boy Advance, on a PC the code, graphics and level data all use that 640 kB. To make it fit, for every rendered frame, every image is loaded from the hard disk into memory and after it is used, it is immediately freed to make room for the next image. The lookup tables for sine, cosine etc. are stored on disk, so for every calculation a file on the hard disk is read. (Maybe using a RAM drive could speed this up?)
 
Cool!
Is it really playable on an 8088?
Seems to be painfully slow on what is probably the best 286 system one can get - 24Mhz + i287XL with 16 MB RAM (although, it is likely the game is not using that memory)
Just recently I ran Doom on my 386SX-33, and it was significantly faster. Very close to be being playable.
As far as memory goes, you could use EMS or XMS in case of 286 (maybe even run it in protected mode or use LOADALL to access that?)
 
I like this:

What's special?:
  • ........
  • Lots of crashes due to memory issues
:)

A bit more serious: I have been a fan of Doom since the beginning. I still sometimes play it, just for fun. I was thrilled when the source code appeared but then I found out it was written in C. I'm not a C fan, I favor Pascal and assembly. The thought still crosses my mind from time to time: would it be possible to convert the C sources into assembly? It will be a major project of course and that's way it stayed a thought, I have to many other projects of my own. But I still wonder, would it be possible?
 
Last edited:
I've wondered what it might take to make a vaguely playable doom-like game on an 8088 or 8-bit CPU. I'd think texture mapping would have to go, using some kind of wire-frame outline instead. but something that still has "2.5" dimensional movement. It would take a lot of tight coding, and probably a completely unique code base.
 
I have 8 bit vga cards but I would imagine on a slow 286 and 8088 the speed will suffer with VGA vs CGA or MDA
 
SomeGuy said:
I've wondered what it might take to make a vaguely playable doom-like game on an 8088 or 8-bit CPU. I'd think texture mapping would have to go, using some kind of wire-frame outline instead. but something that still has "2.5" dimensional movement. It would take a lot of tight coding, and probably a completely unique code base.
Click to expand...

People have managed to pull off "Doom-ish" games on pretty humble hardware; here's an example from years ago, a game called "Gate Crasher" for the Tandy Color Computer 3, a 6809 running at ~2 mhz. It doesn't have texture mapping but does manage to draw the walls as solid colors instead of wireframes, and emulates the "feel" of DOOM pretty well. (Or Castle Wolfenstein 3D, at least.)

How a 2mhz 6809 compares to an 8088 XT is the sort of subject that could no doubt trigger a massive fight, but it's probably fair to say it's at least in the same ball park. Granted the CoCo3 has some other hardware advantages over a CGA XT, like a video chip that lets you set up a custom "true bitmap" 128x96x16 color graphics mode that only takes 6K of RAM and allows double-buffering. The closest equivalent to this on an XT would be the CGA 160x100x16 pseudo-graphics text mode, but that's still takes 16K and there's no double-buffering.
 
Interesting. I have also been working on a similar project for a few months now. It's not really complete yet, but it is an actual port of the 32 bit codebase to run in 16 bit, and should be compatible with timedemos, etc of the original version. It has the same graphical fidelity and runs off the same WADs, etc. It uses EMS to make things work. Basically in its current state it runs in 32 bit mode using an EMS "emulator", and compiles to 16 bit, but the 16 bit version still doesn't have enough memory to get out of initialization. But in another week or two, it might.

https://github.com/sqpat/RealDOOM
 
I won't call this proof of concept playable. There are still lots of memory issues to be solved before it's playable. First I want remedy those problems and maybe then I'll add support for some wacky graphics modes like FastDoom, for example CGA and text mode.

This is actually more fourth attempt at a 16-bit Doom port. My first attempt came after the author of FastDoom pointed me to doomgeneric. My second attempt came when the source code of Vanilla Doom was reconstructed. Both attempts failed because the executables would require too much memory.
Then I came across nRF52840 Doom, a Doom port that needs far less memory. That attempt failed because the code was full of platform specific code. nRF52840 Doom is based on GBADoom. So for my fourth attempt I used GBADoom. GBADoom comes with a port for Windows. I was really surprised to see how easy it was to port that code to 32-bit DOS. That code is now the basis for Doom8088.

I was thrilled when the source code appeared but then I found out it was written in C. I'm not a C fan, I favor Pascal and assembly. The thought still crosses my mind from time to time: would it be possible to convert the C sources into assembly? It will be a major project of course and that's way it stayed a thought, I have to many other projects of my own. But I still wonder, would it be possible?
Click to expand...
Don't most C compilers have the ability to produce assembly code?
 
Frenkel said:
Don't most C compilers have the ability to produce assembly code?
Click to expand...
You mean creating ASM files before compiling them? Not that I know of. Executables are made out of Machine Language (ML), the stuff the processor understands.

Programs written in ASM and compiled to ML can be much faster and need less memory but are also harder to write. And just popped up: it doesn't have to be all ASM! I used to write Pascal programs were the Pascal part handled the files but where the I/O, for example exchanging data over the LPT port with other computers, was handled in ASM. Turbo-Pascal does support ASM instructions in their code. Does C that? If so, maybe you could think about mixing C and ASM as well.

I have no experience with creating graphics in ASM at all. But AFAIK for CGA and Hercules it is initializing the graphic mode of the 6845 and writing to the right places in memory. IMHO it can be the same for VGA-640x480 but for higher resolutions, I have no idea. Is there anybody who can shed some light on this, please?
 
Considering doom has been ported to a pregnancy test I’ve long wondered why it wasn’t ported to 16 bit 286 systems back in the day.

At that time a more serious effort could be made to balance speed vrs compatibility.

Ah well
 
You mean creating ASM files before compiling them? Not that I know of.
Click to expand...

Actually, most of them do support that, at least nowadays. For example (this is a ppc64le system running Fedora Linux),

Code: 
% cat hello.c
#include <stdio.h>

int main(int argc, char **argv)
{
        printf("hello world\n");
        return 0;
}
% gcc -S hello.c
% head hello.s
        .file   "hello.c"
        .machine power8
        .abiversion 2
        .section        ".text"
        .section        .rodata
        .align 3
.LC0:
        .string "hello world"
        .section        ".text"
        .align 2
% gcc -o hello hello.s
% ./hello
hello world
 
rmay635703 said:
Considering doom has been ported to a pregnancy test I’ve long wondered why it wasn’t ported to 16 bit 286 systems back in the day.
Click to expand...

FWIW, that was completely fake. They replaced the entirety of the guts of the thing; the original test had a mask-rom'ed CPU and an LCD screen with *4* symbols on it. Pregnancy Test DOOM runs on a tiny ARM CPU and OLED screen combo that happens to fit into the original shell...

Which, you know, is fun and all, but saying it was "ported to a pregnancy test" without slapping a big old asterisk after it is about as accurate as saying they've "Ported DOOM to the Sinclair ZX-81" because, you know, *plenty* of people have emptied those out and stuffed Raspberry Pi's into them.
 
Borland C++ 3.0 from 1991
"Generate assembler source"
 

Attachments

  • bc30.png
    bc30.png
    4.9 KB · Views: 20
The original DOOM codebase is all in C, yes, but theres inlined ASM and a couple of ASM functions where it matters, and it's pretty much the same for all the DOS era games by Id software. You can see the details here: https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.10/README.asm

I'm sort of making up numbers here (profiling DOS executables is not trivial) but imagine that around 70% or 80% of the application's runtime is either just copying memory from one place to another (which is going to be compiled to be fast as it can be already), or it is in a small handful of drawing functions that are called very often. These few drawing functions are already optimized in ASM. The vast majority of the rest of the codebase doesn't see a whole lot of runtime, relatively speaking. Your ROI is way better spent refactoring the existing C code a bit rather than rewriting it in ASM. (In fact, that's mostly what FastDOOM has done). Rewriting the whole codebase in ASM sounds like a pretty ineffective way to make the game faster for the overall time it would take. Of course, you can find expensive operations and write inline ASM for those or rewrite a few heavily-used functions in ASM but it's very much diminishing returns after that.

Of course, the aforementioned existing ASM improvements - whether they are the ones from the original DOOM source or FastDOOM - are all written with 32 bit x86 in mind. All of these will have to be rewritten for 16-bit compatible code. Personally, I don't really know a lick of x86 assembly myself. I'm putting off ASM improvements until much later. They are obviously nice, but there is generally more performance improvement to be gained by finding ways to free up more conventional memory and reduce EMS paging.

There do exist a lot of "DOOM ports" out there like ports to calculators and other obscure hardware that really share almost nothing with the original game or it's source.

EDIT: I want to add that a lot of runtime improvements have also been found over time in improving the existing ASM in the game, as well.
 
Last edited:
Eudimorphodon said:
FWIW, that was completely fake. They replaced the entirety of the guts of the thing; the original test had a mask-rom'ed CPU and an LCD screen with *4* symbols on it. Pregnancy Test DOOM runs on a tiny ARM CPU and OLED screen combo that happens to fit into the original shell...

Which, you know, is fun and all, but saying it was "ported to a pregnancy test" without slapping a big old asterisk after it is about as accurate as saying they've "Ported DOOM to the Sinclair ZX-81" because, you know, *plenty* of people have emptied those out and stuffed Raspberry Pi's into them.
Click to expand...
Genesis doom was on native hardware, there were 8 bit doom reimaginings as well alongside Amiga doom.

Seems like these aren’t outside the capabilities of a semi modern 286
 
rmay635703 said:
Genesis doom was on native hardware, there were 8 bit doom reimaginings as well alongside Amiga doom.
Click to expand...

To quote the GitHub for the Genesis Doom:

”This demo’s completely unplayable due the low fps and lack of palette transformation.”

I guess an interesting thing to keep in mind when comparing a Genesis or original Amiga to an XT or 286 of theoretically similar or even better performance (not that hard to achieve, given the design parameters of the original 68000) is even though the 68000 is “16 bit hardware” it programs like a 32 bit machine, IE, no 64K segment mumbo jumbo, etc. In principle given enough RAM these platforms can run the same DOOM core as a 68040, just at impossibly bad frame rates… which seem to describe the Genesis demo.

Edit: I guess to put it another way… the official DOS version of DOOM wanted a fast 386 with 4MB of RAM to run “decently“, but nothing was really stopping you from running it really badly on a 16mhz 386SX. This is basically like hacking the video drivers to run on, I dunno, a Plantronics ColorPlus video card, stuffed in a 386sx underclocked to around three or four mhz. If the bar is just “it runs” and not “it’s playable” then there’s really no surprise it ”works”,
 
Last edited:
You must log in or register to reply here.
Back
Top