RealDOOM is a port of vanilla DOOM (forked from PCDoomv2) made to run in Real Mode for x86-16 processors. The goal of RealDOOM is to maintain timedemo level compatibility and visual quality equivalent to the original game. The application has been fully rewritten in assembler and it uses EMS to use memory beyond 640kb.

RealDOOM has been worked on for a little over 3 years and is finally entering beta so I'm hoping to find people willing to play through the DOOM games in the engine to try and help find remaining bugs and compatibility issues, even if not doing so on a 286 machine or anything like that. A pentium class machine will run the engine great, just like the original. A 386 will also have a much better time running this than vanilla DOOM.

The engine is quite stable now - most of the known bugs involve some render glitches in specific situations. Random crashes do seem to happen maybe every 2-3 hours. So I hope players can expect a good time.

You can download the binaries for the beta release here and the sources are on the repo at https://github.com/sqpat/RealDOOM

Minimum System Requirements:
- Hard Disk
- 2 MB of RAM with Pageable Conventional EMS Memory
- 8088 or compatible processor
- VGA Display Adapter

Recommended System Requirements:
- 3-4 MB of RAM (for larger texture and sound caches)
- 20 MhZ or faster 286 processor

RealDOOM supports:
- PC Speaker and Sound Blaster SFX
- Adlib, Sound Blaster, and MIDI music
- Mouse (with modified input control to use only left/right and not up/down)
- RealDOOM currently supports Shareware DOOM, commercial DOOM 1&2 and Ultimate doom.

RealDOOM does not support:
- Custom WADs (but support is planned)
- Netplay
- Joystick

Notes on RealDOOM and EMS
The initial version of RealDOOM (0.10) supported using just a page frame, but current versions require pageable conventional memory. Specifically, memory from the 256kb-640kb range must be pageable in addition to the page frame. 386 and newer machines can run EMM386 to support this easily. Earlier machines need a chipset or memory card capable of paging conventional memory. The popular LoTech EMS board does not do this. Boards such as the Intel Above Board support this type of pagination. Compatible 286 chipsets supporting this include VLSI SCAMP and TOPCAT, Headland HT-18 and up, and C&T SCAT. I have also written EMS drivers to support all these chipsets.

It's possible a version in the future may eventually be built supporting running from just a page frame again, but I am not in a hurry to do that as first I'd like to finish fixing bugs and add a few features custom wad support, faster lower fidelity renderer support and FPU acceleration.

Running RealDOOM
There are several builds of RealDOOM optimized for different processors (such as 386, 286, 8088). The application might crash on startup if you run an incompatible version - especially on the 8088.
- Make sure you have your doom WAD in the same directory as the game
- Make sure you have at least 562 kb of conventional memory available.
- Make sure your EMS driver is loaded. I'd recommend SQEMM if your hardware supports it as it is lightweight and fast.
- Sound, etc configuration must be done via the default.cfg like with Vanilla DOOM. Set Sound/Music device to 3 for sound blaster, for example.
- Chipset builds currently only support page frame as D000
- The included readme.txt has some more information

Performance
A fast 25 mhz 286 machine runs RealDOOM faster than a 40 mhz 386DX runs the original DOOM in default settings. Framerate in low (not potato) detail and default screen size is around 15fps. I have played through most of the entire games on a 286. Larger levels with lots of monsters (Doom 2 MAP13 especially) can face really low framerates. A 5150 can run the game with the right hardware, but of course the result isn't really playable. Makes for a great benchmark I suppose.

In general, RealDOOM will run with 50-60% higher framerate on a 386DX than vanilla doom and 80-90% faster on a 386sx on higher graphical settings. On systems with cache on the cpu (486, pentium, even 486SLC type chips) the performance is about equal so there's not too much reason to run it, but it can still be an easier way to run the engine while getting max framerate if you are curious.

I have a spreadsheet with various benchmarks on RealDOOM on different hardware over time.

Notes on Building RealDOOM

Currently, RealDOOM uses OpenWatcom 2.0 and TASM 2.51 to build. While the main application has no C code left in it, there is a build step which packages code into a 'library' and this build step is written in C. I tend to build from DOSBOX for convenience. Install and set up your TASM 2.51 and Openwatcom 2.0 directories and then set your variables (WATCOM, INCLUDE, PATH, etc) to point to the right directories if the installers did not already do this for you.

Download the source code and run "makeall 286" to build the application for a 286, "makeall 386" to build the application for 386 targets, etc. There are targets for various chipset builds that allow EMS driverless operation where the application will hit chipset registers directly to page memory. These builds run a tiny bit faster and uses a little bit less memory. The 8088 build avoids use of 186/286 instructions and the 386 build uses 32 bit instructions in several spots to increase performance.

Some Known Issues:
- I've been made aware drive overlays steal memory from the 0x9c000 ish region from MS-DOS. This will be incompatible with RealDOOM which needs all the high pageable conventional memory regions.
- RealDOOM is a bad DOS citizen and does not ask for permission to use memory ranges. This is generally fine and it generally cleans up after itself, but if you have some other services running at the same time then I don't know if it will work out. I have seen some heavier EMS drivers which try and ask dos for memory while they are running and that is no good for example. Eventually I suppose I should communicate with the OS
- There are graphical glitches that exhibit themselves as junk vertical lines from time to time. I'm aware of this but they are fairly uncommon and I didn't think it had to prevent a beta release
- MAP30 seems to mess up the adlib engine
- There are some texture cache corruption bugs, which results in some large outdoor walls sometimes rendering incorrectly
- 22 Khz sfx mixing (namely, the super shotgun) can produce garbage sound from time to time.

Future Plans/Possibilities:
- Fix Bugs
- Support Custom WADs (but there are some size limits, so I dont think TNT/plutonia in their entireties will be possible)
- Re-implement untextured renderer
- FPU support for FixedDiv, which should be a little bit faster
- ASM rewrites of physics code to improve performance a little more.
- Maybe create a self booter and MS-DOS stub implementation to increase resources to run the game.
- EMS Page Frame Version

I'll do my best to answer questions on anything related to the project.