Frenkel

Watching @deathz0r playing my Doom port Doom8088 for the first time.

Doom8088 is a port of Doom that runs on 16-bit DOS computers. It's based on @Doomhack's 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. Only demo3 is in sync and there are lots of crashes due to memory issues. To decrease memory usage, only one texture is used for every wall. That said, @deathz0r was brave enough to run it on a real 286. (I've only tried emulators, mainly DOSBox at 50000 cycles, which is like a 286 running at 90 MHz.) 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 a RAM drive could speed this up?)

Mode Y is now supported. In 86Box emulating a 286 @ 25 MHz running timedemo 3, I get 5.940 frames per second with Mode 13h and 7.991 with Mode Y. The keys for weapon switching are now [ and ]. IDDQD, IDKFA, etc. are supported. IDRATE shows the current frames per second and IDROCKET gives every enemy a rocket launcher.

Adding new features while keeping the memory usage down is becoming a balancing act. That's why I'm holding off redefinable keys for now. But hardcoding new keys is doable. For example, I could add WASD if there is demand for it. BTW, Changing the switching weapons keys is on the to-do list. I get a higher score in timedemo 3 in 86box when compiling with gcc-ia16 optimized for size than for speed. All because of the memory footprint. And with the Watcom 16-bit build I get random freezes.

"I like to see you modern speedrunners attempt to do that at 3 fps." LOL If you could change the keyboard keys, which keys would you use? It looks like there's still some code that tries to divide by zero. That needs fixing. I'm working on getting E1M6 to run by reducing it's file size. compdj.bat is for building a 32-bit version with DJGPP. I use this build of DJGPP and that one doesn't come with make. It's nice to see the Watcom version running on a 286 with an SSD. The executable is smaller than the gcc-ia16 version, which means the Watcom version has about 45 kB more free memory to store the graphics. I use an old 100 MB hard disk and it really slows the game down. When there's not enough free memory for a texture a single color is used instead. When the sky texture is replaced by a single color, I like to think it's thunder and lightning. So it's actually a feature. :P

To celebrate Doom's 30th anniversary, here's a version of Doom8088 with PC speaker sound effects. Did you have a 286 with a sound card 30 years ago?

This is actually my fourth attempt at a 16-bit Doom port. My first attempt came after viti95 mentioned 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. "Although it is based on prBoom, most of the engine enhancements (dehacked, limit removing etc) have been reverted back to Vanilla. This is either for memory or performance reasons." It's too bad GBADoom has removed multiplayer support and demo compatibility is broken. FastDoom replaced lots of C code by 386 assembly code written in Watcom's dialect. Rewriting that to support a 286 would take a lot of time.

Texture mapped walls, and the color of the floors and ceilings is based on the texture of the floors and ceilings. E1M1 is playable, sort of. E1M2 is a slideshow. I've made a topic about Doom8088 on the Vintage Computer Federation Forums. There are demosceners there, right? I haven't made a topic on Vogons yet. There are still some features I want to add first.

The zero divide error has been fixed in the mean time. I get almost 11 frames per second in timedemo 3 in 86box with the Mode X version and these colors. The version in which every wall is texture mapped with the same texture everywhere gets 7.5 frames per second. There are still some calculations in R_DrawColumn that use 32-bit variables and I want to replace those with 16-bit variables.

I've decreased the horizontal resolution from 120 to 60 pixels and I've made some performance improvements, but now it crashes sometimes because it's trying to divide by zero. Here are two videos of Doom8088 running in 86box emulating a 286 @ 25 MHz.

I've refactored FixedMul so it doesn't use 64-bit integers and I've replaced FixedDiv in the drawing routines by FixedMul(a, 1 / b) so it also doesn't use 64-bit integers. And now I get more than 10 FPS in timedemo 3 in 86box emulating a 286 @ 25 MHz.

Using 16-bit variables instead of 32-bit helps, but I'm not sure about 8-bit though. I've looked at some disassembled code and I've seen that it converts bytes to words. Using 32-bit variables as indices into arrays sometimes causes the compiler to crash :). I got a nice speed improvement by not bit-shifting 64-bit variables in FixedMul and FixedDiv. Not using FixedMul/FixedDiv, and thus not using 64-bit variables, also helps performance. I'm now working on potato mode in Doom8088. The view window is 240x128 pixels, but every 4 horizontal pixels are the same, so you get a 60x128 graphics mode. Using flat walls, flat sky, flat floors and ceilings I get 6.5 FPS in 86Box emulating a 286 @ 25 MHz. What's next for Doom8088? Replacing info.c by getters ;)

I think it would be funny if someone makes a pull request to add the source code of the DOS version of Doom, including the source code of DMX.

So, who's gonna make a pull request to add the recently found DOS Doom source code? :P

To celebrate 40 years of PCjr, here's a quick hack of Doom8088 with 160x200 16 color PCjr graphics. It's running in DOSBox with machine=pcjr and cycles=3000.

"Good nonsense is not bad. Edwin from Asylum writes: I've invented for the game Doom, it doesn't matter which Doom, cheats on how to fill everything up and you'll never die. You have to type HOLDA when you are playing. If you type FATTY you'll turn into a Tyrannosaurus Rex. And if you shoot a guy to death you have to type DMXXXXPIS, then you can pick up his corpse and put dynamite in the place of his heart, then the whole level will explode and you go to the next level. Type PLAYFULNESS and Cookie Monster and Big Bird will help you fight. And if you type HRTPIS you can piss on a guy, which will scorch him completely. If you type MUTANT the Teenage Mutant Ninja Turtles will help you. When you are playing, type CANDY, then you can select a picture with the mouse, then close Doom and go to Word or another program. Then type PASTE DADDY SUPERGLUE and you can print or edit the picture (depending on which program you have). Don't worry Edwin, the men in the white coats are coming."

Power Unlimited is a Dutch gaming magazine. In June 1996 it published some wacky cheats for Doom involving a tyrannosaurus rex, Cookie Monster, Big Bird and the Teenage Mutant Ninja Turtles.

I got gcc-ia16 to compile Doom8088. In DOSBox at 50000 it gets 50 fps, Watcom 40. On a real computer it looks like this:

doomfps: Calculate Doom shareware FPS from gametics/realtics in video memory for lazy people

The Doom Wiki suggests Doom started as a real mode DOS program.

Commander Keen 4

The code is still there for textured column and visplane rendering, and sky and status bar rendering. It's just disabled, see macros FLAT_WALL, FLAT_SPAN, FLAT_SKY and DISABLE_STATUS_BAR. Digital Mars C/C++ doesn't support int64_t, so that compiler is out for now, or I'll have to rewrite FixedDiv and FixedMul now to not use int64_t. These functions probably will be rewritten anyway, in assembly.

There are a couple of things I want to do: * Try different compilers. According to dccb Microsoft C/C++ and Digital Mars C/C++ produce faster code than Watcom (if you run it in DOSBox. So only the number of instructions is benchmarked.) I also want to try gcc-ia16, but as far as I can see it doesn't support the large memory model. So first I'll have to rewrite the code so it runs in the medium memory model. * Optimize the WAD by using some ideas of WADptr. * Replace variables of type int32_t in r_draw.c by int16_t or int8_t. I also want to replace functions in r_draw.c by assembly routines. And I want to replace the back buffer by Mode X style page flipping. And EGA, Tandy, CGA...

A few frames per second. Actually, it has a cheat that changes the ammo counter into a frames per second counter. Too bad the status bar isn't rendered. :D

I've tried Doom8088 on the slowest computer I have that has a VGA card. It has a 386SX processor running at 20 MHz and a 100 MB hard disk. For every lump the game read the directory in the WAD file and then jumped to the lump's filepos. So the hard disk head had a lot of work to do. Those loading times aren't fun. So now Doom8088 caches everything.