Doom8088: Doom on a 286 / 8088

[Frenkel]

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?)

 

Edited August 31, 2023 by Frenkel
Demo3 is in sync now

[dustarma]

Don't real 286s have the ability to address up to 16MB RAM?

[deathz0r]

This is absolutely wild to see, especially since I've been going through a tour of ancient map editors from 1994-1995 that are capable of running on 16-bit X86 CPUs on my trusty 24Mhz 286 with a Intel 287XL math co-processor! I'm always happy to help in any way for testing any performance improvements that will happen in the future.

14 hours ago, Frenkel said:

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?)

This is something that I can look in to - my previous attempts at setting up RAM disks on my Protech PM286 motherboard have not been particularly successful, trying to use Franck Uberto's RAMDISK with XMS in the past would not initialise for some unknown reason, but I only tested on FreeDOS and not MS-DOS 6.22. Sadly I don't have a working motherboard with a Headland HT12 chipset (which has built-in EMS) atm and using my ISA EMS card would offer no improvement over my CompactFlash card going through an ISA IDE controller.

 

14 hours ago, Frenkel said:

(I've only tried emulators, mainly DOSBox at 50000 cycles, which is like a 286 running at 90 MHz.)

If DOSBox-X is any indication with 3300 cycles = 25Mhz 286, then you're more or less testing it as if a 286 is running at 375Mhz - where the hell can I get one of those IRL? :D

 

12 hours ago, dustarma said:

Don't real 286s have the ability to address up to 16MB RAM?

Yes, but the primary factor in whether a 286 can access that 16MB of RAM is limited by the motherboard chipset support - there are only a couple of chipsets that allow addressing the full 16MB of RAM (the Headland HT18 chipset, which I have on my mobo is able to do this but there are only two known 286 models that use that chipset, as it was far more commonly used on 386SX mobos) and those motherboards are generally rare, on top of the fact that almost all motherboards from 286s up until the 486 w/PCI slots-era are suspect to VARTA battery leakage causing significant damage. The large majority of extant 286 motherboards don't even have SIPP or SIMM slots and only have DIP sockets, generally limiting RAM to 1MB.

Edited August 30, 2023 by deathz0r
DOSbox cycles

[Dark Pulse]

1 hour ago, dustarma said:

Don't real 286s have the ability to address up to 16MB RAM?

Technically, yes. In practice, it's not that simple.

 

Quote

The difficulty lay in the incompatibility of older real-mode DOS programs with protected mode. They simply could not natively run in this new mode without significant modification. In protected mode, memory management and interrupt handling were done differently than in real mode. In addition, DOS programs typically would directly access data and code segments that did not belong to them, as real mode allowed them to do without restriction; in contrast, the design intent of protected mode was to prevent programs from accessing any segments other than their own unless special access was explicitly allowed. While it was possible to set up a protected-mode environment that allowed all programs access to all segments (by putting all segment descriptors into the GDT and assigning them all the same privilege level), this undermined nearly all of the advantages of protected mode except the extended (24-bit) address space.

 

[deathz0r]

11 hours ago, Dark Pulse said:

Technically, yes. In practice, it's not that simple.

 

Realistically speaking, utilising EMS (followed by XMS, since that is only supported on 286 CPUs and does not work on 8088/8086/V20/V30/80186/80188 CPUs) is the obvious way to get past the 640KB barrier. The Wolf3D source code contains memory management with EMS and XMS.

[LoatharMDPhD]

//Ah the Glory days, of 2 MB matched SIMMs and on board memory... My 1990 Gateway 2000 Had an Intel 386 the Math Co-Processor and i think 8MB RAM on board, couldn't upgrade any further even though it needed it... single spped CD-ROM (Couldn't play Myst) 56K belkin fax modem, everything ISA, Soundblaster, and VGA graphics... Screamer...

Edited August 30, 2023 by LoatharMDPhD

[Dark Pulse]

5 minutes ago, deathz0r said:

Realistically speaking, utilising EMS (followed by XMS, since that is only supported on 286 CPUs and does not work on 8088/8086/V20/V30/80186/80188 CPUs) is the obvious way to get past the 640KB barrier. The Wolf3D source code contains memory management with EMS and XMS.

Yeah, though whether the port maker wants to go through doing that or if he just wants this to be a proof-of-concept and be done with it is up to him, of course :P

[LoatharMDPhD]

5 minutes ago, Dark Pulse said:

Yeah, though whether the port maker wants to go through doing that or if he just wants this to be a proof-of-concept and be done with it is up to him, of course :P

I Bet the Ti-83Plus port would run without incident...

[Redneckerz]

Obviously this needs a video. This is wild.

[viti95]

I also can provide some feedback on my 286. It also has 16Mb of RAM, but don't know if XMS or EMS are available (it uses the SARC RC2015 chipset). I guess EMS can be used as a RAM drive, swapping data on 8088/286 devices is slow, but not as slow as doing that from the hard drive. Maybe the idea here to reduce RAM pressure is downgrade asset quality, and reduce the rendering quality. By that I mean render flat visplanes (single color), and set resolution to something low (like FastDoom's potato mode, 80x200), and doing some compression on the IWAD itself. I think @Vic used this compression technique recently on D32XR:

 

BTW it was insane to see Doom8088 running on @deathz0r 286 in the live streaming, what a time to be alive.

 

Edited August 30, 2023 by viti95

[Frenkel]

I've tried using one column of data and let the rest of the columns point to that data, but that still costs too much memory. So now I'm thinking about embedding a small texture in the executable and drawing that one when there's not enough memory for regular textures.

 

I'm trying to stay away from EMS and XMS for now. Maybe as the first two steps I'll try to use 64 kB of EMS and 63 kB of XMS without bank switching like in Commander Keen 4. It's possible to build a 32-bit version of Doom8088 with 640+ kB of zone memory. When that one runs without bombing, it's time to find ways for more free memory in the 16-bit version, like using EMS and XMS. But also using Mode X; Right now a back buffer of 240x160 = 38 kB is used.

 

I couldn't get huge pointers to work in Watcom. So now every lump needs be less than 64 kB. Only the preprocessed linedefs of E1M6 is too big with 73.94 kB.

[Gez]

How about Doom on an Atari 800, the computer so advanced that it never became obsolete?

 

[viti95]

@Frenkel Did you try to use the build-ia16 GCC? Don't know if it's better than Watcom for this stuff. Also maybe you can use https://github.com/fragglet/miniwad for now as a very simple way to minimize the RAM usage.

 

BTW if you need help with the VGA mode X code I've mastered it quite a lot, also some ASM tricks to speedup drawing in non-VGA modes. I'm pretty sure ASM tricks will be required to get somewhat good performance on the render part.

 

EDIT: Tested Doom8088 on my Pentium 100, it works but really slow (something like 0.3 fps). The IDE port light blinks like there is no tomorrow, so yeah, this needs more RAM available. Even with a fast SD card as HDD is slow.

Edited August 30, 2023 by viti95

[viti95]

Update: I tried Doom8088 on the same P100 as before, but running it from an EMS 3.2 6Mb RAMdisk (SRDISK). It's much slower than before, close to 0.05 fps. Same happens if I use the XMS version of SRDISK. I guess this will require native EMS zone memory caching support.

 

EDIT: Also tried TurboDSK, it's a bit faster than SRDISK but slower compared to the direct SD card.

EDIT2: Tried RDISK on XMS, same 6Mb device. Almost as slow as SRDISK.

Edited August 31, 2023 by viti95

[Frenkel]

I'm aware of GCC for 8088/8086. I remember it being released on an April Fools' Day. Can't remember the year. 2017 apparently. I haven't tried it yet, though. It was on my To Do list to use it and Watcom to recreate my Wolfenstein 3-D CGA demo and see if it would generate faster code than Borland. But if you wait long enough, someone else does something similar but way better. And in the case of Doom8088, there's already RealDOOM around the corner. :)

 

I've tried miniwad.wad, but sometimes it locks up FastDoom when in E1M1 I try to open the door of the room just before the exit. And when it doesn't lock up, the floor of the room looks weird. DJDoom and WCDoom crash with the message "R_TextureNumForName: COMPUTE2STEP6 not found". So it looks like it doesn't stop comparing after 8 characters. Further investigation needs to be done...

I did use the small map in miniwad.wad during development. Doom8088 doesn't crash with out of memory errors that way :). But for a first look at Doom8088, E1M1 is just so much more iconic than that small map. :) Even when just using 1 texture, E1M1 is still recognizable :)

 

It's really a pity using a RAM drive doesn't speed things up. I was really hoping it would be an easy way to have a flat memory model on a 286.

[slowfade]

This is something I've always wanted to see, and believed to be possible with modern tools and knowledge, assembly optimization, bruteforcing efficient bits of code and data, and so on. This is a start... of a long road.

 

It will require great knowledge of the old hardware and rewriting many parts of the code using alternative algorithms, bringing in new data compression techniques. Might work best as a team effort. Too bad I don't have any skills in this area. But I have no doubt an excellent port could be made if people set their sights on it.

 

Probably it will require some sacrifices to the quality of video; a bit lower resolution and tricks used in FastDoom. But I wouldn't mind that at all!

 

What's the RealDOOM port (other than the github)? Any info on that?

 

It's possible this might work best by not trying to be an exact copy, but by trying to be in spirit of Doom. Like the new Sega 32X port -- it has some compromises in textures and map geometry, but it is and feels very much like Doom.

 

Regarding textures... It might be worth investigating new approaches, especially if not trying to make it a 1:1 copy. Some suggestions would be:
1. Algorithmically generated textures. Perhaps some more complex textures here and there could be stored in memory and drawn from there, but most of them would be stored as snippets of assembly: instead of reading from memory, a function is called with x and y parameters, and it returns a pixel. One of the simplest examples would be the XOR texture: https://lodev.org/cgtutor/xortexture.html Generally there's so much knowledge and expertise to this area that I have no doubt amazing things could be done with it.
2. Smaller floor/ceiling textures. In many places a redesigned 16x16 would suffice. Quite a few (16) could be kept in memory in a 64x64 area. Generally ceilings could be monocolor, too.
3. Careful map redesign with a hybrid of these techniques, and consideration of what and how many textures are loaded into memory. Some areas might benefit from a real texture and others might look great with just a monocolor ceiling.

Edited September 4, 2023 by slowfade

[Plerb]

This is extremely cool! I've been wanting to see something like this for a while.

Maybe solid colors could be used for all textures barring important ones like switches and doors.

I'd love to see a CGA version of this and see it running on an IBM 5150 or Tandy 1000 :D

[Darkcrafter07]

I haven't read a single letter here but this is absolutely mind blowing sirs, I'm really glad that coding masters like @viti95 have already made Doom run almost as fast as Wolfenstein 3D and other games like Dune 2 which are unplayable on the lowest machine I could emulate in PCem (386dx 16mhz) and now this thing pops up. Will be really nice to witness if Doom will ever run on something like nesticle lol, I mean on true 1.7MHz, 2kb RAM "board".

[viti95]

10 hours ago, slowfade said:

What's the RealDOOM port (other than the github)? Any info on that?

 

Patrick has updated the README, it is a WIP Vanilla Doom port for 16-bit x86 processors (8088 / 8086 / 286).

 

3 hours ago, Darkcrafter07 said:

I haven't read a single letter here but this is absolutely mind blowing sirs, I'm really glad that coding masters like @viti95 have already made Doom run almost as fast as Wolfenstein 3D and other games like Dune 2 which are unplayable on the lowest machine I could emulate in PCem (386dx 16mhz) and now this thing pops up. Will be really nice to witness if Doom will ever run on something like nesticle lol, I mean on true 1.7MHz, 2kb RAM "board".

 

Oh thanks for the kind words. I'll try to help in any way I can, as I now have a good understanding of what is necessary to make Doom run better. Right now the main issue with 16-bit x86 is the memory segmentation and the limited amount, solving this issue is nowhere easy. For me @Frenkel and Patrick are the true dev gods for being able to make Doom run at all with those limitations.

Edited September 4, 2023 by viti95

[Redneckerz]

On 9/1/2023 at 12:38 AM, Frenkel said:

WCDoom

Where i get Doom8088 and RealDoom, what is WCDoom? Watcom Doom? You mentioned this in the FastDoom thread also.

[Frenkel]

https://github.com/FrenkelS/Doom8088/releases
https://github.com/sqpat/RealDOOM

 

DJDoom and WCDoom are based on the same code. The first one is compiled with DJGPP and the second one with Open Watcom. So yeah, it means Watcom Doom.

https://github.com/FrenkelS/djdoom/releases

Edited September 5, 2023 by Frenkel

[Redneckerz]

9 hours ago, Frenkel said:

https://github.com/FrenkelS/Doom8088/releases
https://github.com/sqpat/RealDOOM

 

DJDoom and WCDoom are based on the same code. The first one is compiled with DJGPP and the second one with Open Watcom. So yeah, it means Watcom Doom.

https://github.com/FrenkelS/djdoom/releases

Oh lol apologizes. You probably have thought that i was asking where to find Doom8088/RealDoom when i mean't Whilst i understand what Doom8088/RealDoom are,

 

So WCDoom was right, haha. Good to know, thank you!

[Dark Pulse]

On 9/4/2023 at 1:45 PM, Darkcrafter07 said:

Will be really nice to witness if Doom will ever run on something like nesticle lol, I mean on true 1.7MHz, 2kb RAM "board".

I mean, Nesticle was an emulator, the system was the NES. And I really, REALLY doubt that'd be possible.

 

Even stuff that was trying to bring stuff like the Wolf3D engine to the NES (i.e; the famous aborted Hellraiser game) was basically using all sorts of extra processors and chips to do the actual crunching and game and then just blasting it to the NES - basically pretty much what the SuperFX would do a few years later.

Edited September 6, 2023 by Dark Pulse

[LoatharMDPhD]

56 minutes ago, Dark Pulse said:

I mean, Nesticle was an emulator, the system was the NES. And I really, REALLY doubt that'd be possible.

 

Even stuff that was trying to bring stuff like the Wolf3D engine to the NES (i.e; the famous aborted Hellraiser game) was basically using all sorts of extra processors and chips to do the actual crunching and game and then just blasting it to the NES - basically pretty much what the SuperFX would do a few years later.

// "All hail thefecal ShitLord!!!!"

[LoatharMDPhD]

57 minutes ago, Dark Pulse said:

I mean, Nesticle was an emulator, the system was the NES. And I really, REALLY doubt that'd be possible.

 

Even stuff that was trying to bring stuff like the Wolf3D engine to the NES (i.e; the famous aborted Hellraiser game) was basically using all sorts of extra processors and chips to do the actual crunching and game and then just blasting it to the NES - basically pretty much what the SuperFX would do a few years later.

// those carts had additional Z80's onboard  to do various witchcraft type things in tandem to the main chipset right? emulating multiple CPU architectures on a third cpu and yet again in virtual machine  is some "Inception" type shit...

[Dark Pulse]

2 hours ago, LoatharMDPhD said:

those carts had additional Z80's onboard  to do various witchcraft type things in tandem to the main chipset right? emulating multiple CPU architectures on a third cpu and yet again in virtual machine  is some "Inception" type shit...

It was a Z80 set up with PAL chips and 4 Megabytes (yes, MegaBYTES!) of RAM. Per Lost Media Wiki:

 

Quote

This cartridge came to be known as the "Super Cartridge". This special cartridge contained a Z80 processor, programmable array logic chips, and an additional four megabytes of RAM. It was also capable of intercepting the NES processor's ROM and RAM accesses so it could manipulate video in real time, as well as allowing pixel-by-pixel manipulation of the screen, some sprite manipulation, and also supported panning and zooming in on hardware such as fully animated backgrounds. Essentially, this meant that the game could switch colors between scans of the TV in real time and increase the effective number of colors on the screen. While the cartridge itself worked fine, the palette switching effect wasn’t working as intended as it didn’t switch between colors fast enough.

Ironically, their license for the Wolf3D engine is precisely what allowed them to legally create Super 3D Noah's Ark on the SNES.

 

The article definitely gets a few things wrong though - obviously, Wolf3D didn't exist until 1992, so the "improved" engine means this must really be around 1993-1994 or so, as opposed to the 1990 that this article claims.

[Frenkel]

On 9/4/2023 at 12:47 PM, slowfade said:

Regarding textures... It might be worth investigating new approaches, especially if not trying to make it a 1:1 copy. Some suggestions would be:

1. Algorithmically generated textures. Perhaps some more complex textures here and there could be stored in memory and drawn from there, but most of them would be stored as snippets of assembly: instead of reading from memory, a function is called with x and y parameters, and it returns a pixel. One of the simplest examples would be the XOR texture: https://lodev.org/cgtutor/xortexture.html Generally there's so much knowledge and expertise to this area that I have no doubt amazing things could be done with it.

 

That's a cool idea. It reminds me of the textures in Ken Silverman's labdemo2.

[Frenkel]

New version

No textures and no status bar, but sprites are cached and the lookup tables are in memory all the time.

Benchmarking is possible by running DOOM8088.EXE -timedemo demo3.

 

P.S. I haven't run it on a real computer.

Edited September 11, 2023 by Frenkel

[Biz!]

i can't wait to run this on my Tandy 1000RLHD!

[Frenkel]

The release has been updated. It now includes optimized versions for 286 and 386 processors. It also includes a 32-bit version.

When I run timedemo 3 in DOSBox, only the 8088 version optimized for space can run the whole demo without crashing due to memory issues :(

(BTW, the 32-bit version can also run the whole demo, because it can use more memory than the 16-bit versions.)