Have you ever run Doom below system requirements?

Ok, final thing for tonight (gotta sleep too :)

The screengrabber was VideoThief. Just tried it in dosbox.
It saves screenshots in it's own VTF file, then comes with vtfview to view these VTFs and save them to BMP. Anyway, after you see an image with the viewer and you exit you get some information. Unfortunatelly not enough. BIOS mode : 0013h always no matter if it's using mode x or not.

The difference, VTF files of DOOM had size 263168, while of Heretic 65024, a possible indication of ModeX (256k vram) vs 13h (64k vram). Also, I said i thought alpha 04 was doing 200fps in benchmark (I don't know) and maybe using 13h. But VTFs showed also 263168 there. Only doom alpha 02 showed VTF of 65024.

Still speculations :P

GoatLord said:

Man, I can't even begin to understand all the tech jargon from some of these posts.

Glad I'm not the only one. I just play the game. Although sometimes understanding how the game actually works can help your in-game performance, this shit is just over my head.

That gives me an idea for a topic.

So I was curious about this and got out the debugging version of DOSBox. If it can be used to display accesses to given I/O ports, I haven't figured out how yet... but I did manage to disassemble the following from the Ultimate Doom exe by setting a breakpoint when INT 10 is called and looking ahead a bit:

0170:192053  BAC4030000          mov  edx,000003C4 ;sequencer index register
0170:192058  B004                mov  al,04 ;index 4 = memory mode register
0170:19205A  890DCC941E00        mov  [001E94CC],ecx         [illegal]
0170:192060  890DD0941E00        mov  [001E94D0],ecx         [illegal]
0170:192066  893D20951E00        mov  [001E9520],edi         [illegal]
0170:19206C  EE                  out  dx,al
0170:19206D  BAC5030000          mov  edx,000003C5 ;sequencer data register
0170:192072  29C0                sub  eax,eax
0170:192074  EC                  in   al,dx
0170:192075  24F7                and  al,F7 ;clear bit 3 (disable chain4 mode)
0170:192077  0C04                or   al,04 ;set bit 2 (disable odd/even mode)
0170:192079  EE                  out  dx,al
0170:19207A  BACE030000          mov  edx,000003CE ;graphics controller index register
0170:19207F  B005                mov  al,05 ;index 5 = mode register
0170:192081  EE                  out  dx,al
0170:192082  BACF030000          mov  edx,000003CF ;graphics controller data register
0170:192087  29C0                sub  eax,eax
0170:192089  EC                  in   al,dx
0170:19208A  24EC                and  al,EC ;clear bit 4 (disable odd/even mode), clear bits 0&1 (use write mode 0)
0170:19208C  EE                  out  dx,al
0170:19208D  BACE030000          mov  edx,000003CE
0170:192092  B006                mov  al,06 ;index 6 = misc register
0170:192094  EE                  out  dx,al
0170:192095  BACF030000          mov  edx,000003CF
0170:19209A  29C0                sub  eax,eax
0170:19209C  EC                  in   al,dx
0170:19209D  24FD                and  al,FD ;clear bit 1 (disable chain odd maps to even)
0170:19209F  EE                  out  dx,al
0170:1920A0  BAC4030000          mov  edx,000003C4
0170:1920A5  B8020F0000          mov  eax,00000F02 ;write 0xf (enable planes 0-3) to index 2 (map mask register)
0170:1920AA  BB00000100          mov  ebx,00010000
0170:1920AF  66EF                out  dx,ax
0170:1920B1  A1D0941E00          mov  eax,[001E94D0]         [illegal]
0170:1920B6  31D2                xor  edx,edx
0170:1920B8  E8C35F0200          call 001B8080 ($+25fc3)
0170:1920BD  BAD4030000          mov  edx,000003D4 ;crtc index register
0170:1920C2  B014                mov  al,14
0170:1920C4  EE                  out  dx,al
0170:1920C5  BAD5030000          mov  edx,000003D5 ;crtc data register
0170:1920CA  29C0                sub  eax,eax
0170:1920CC  EC                  in   al,dx
0170:1920CD  24BF                and  al,BF ;clear bit 6 (disable dword mode)
0170:1920CF  EE                  out  dx,al
0170:1920D0  BAD4030000          mov  edx,000003D4
0170:1920D5  B017                mov  al,17
0170:1920D7  EE                  out  dx,al
0170:1920D8  BAD5030000          mov  edx,000003D5
0170:1920DD  29C0                sub  eax,eax
0170:1920DF  EC                  in   al,dx
0170:1920E0  0C40                or   al,40 ;set bit 6 (enable byte mode)
0170:1920E2  EE                  out  dx,al

(comments mine)
That's pretty much the textbook Mode X initialization right there. I haven't looked to see how it writes to video memory, though. And I have no idea how useful those addresses at the start of each line are for other disassemblers...

Yeah, it seems to fuck around with Mode X alright. Which makes me shudder....was it really worth it just for the page flipping? After making writing each pixel to the screen a chore? Dunno, man.

So maybe the WATCOM VGA comments in the SC are indeed closer to what was used....now if I could disassemble the R_DrawColumn and R_DrawSpan functions specifically....

Haha - this thread has Area51 potential.
I assume they used ModeX because everybody did and it was the hot thing to do... finally showing the console people that the PC was king.

The mode X thing discussed here needs it's own thread - kinda annoying to start a thread about Doom minimum specs and having the code people taking it hostage...

I like all these [illegal] brackets in the disassembly. Oh Doom code, you are so naughty...

Gez said:

I like all these [illegal] brackets in the disassembly. Oh Doom code, you are so naughty...

They look more like a problem with the disassmbler being used than with Doom.

Playing Doom on my brother's old computer from the mid-90s was a nightmare, and so was playing Doom 2 on my friend's computer in the late 90s. Thankfully, better computers were also readily available, so it wasn't a huge issue.

Looks like TeamTNT considered using page flipping in Mode X in Boom, but rejected for pretty much exactly the reasons Maes gives:

Lee Killough, in log_lee.txt, said:
Added wait for vertical sync, to prevent breaks in screen during
blit. Screen is much smoother now. Although page flipping is more
attractive, it is not supported by all video cards without using planar
pixels, which would slow Doom down, since we'd need to convert from Doom 8
bpp packed pixels to planar pixels during every frame. Therefore I've
decided not to use page flipping for 320x200 mode. When higher resolutions
are also supported, this issue can be reconsidered.

(I once hacked the Boom source to use Mode X -- specifically planar 320x200 or "Mode Y" or whatever it's called. I think my goal was to get it working in the tweaked video modes that Quake could use, like 360x480. I ripped off the blitting algorithm from the Quake source, which draws a whole plane at once so the mask register only has to be updated four times per frame. Still needs plenty of bit-shifting to find the right pixel in the linear buffer. I never did benchmark it against plain Mode 13, though...)

Edit: oh neat

Nice find!

Another thing that bugs me. So, rendering was even happening directly to the videoram (walls, sprites, flats, everything). But writting to the videoram no matter what mode should be avoided as much as possible and when you have rendering of the level (walls, ceiling, sky) plus additional rendering of the monsters and items more than 100% of the screen is filled depending on how close the monsters and items are. Needless to say about transparent textures. I'd expect it would be optimal the whole rendering to be happening on a buffer and then copied once to the vram. Not only a byte per byte rendering has to happen because of the way it renders to ModeX but more than 100% of the pixel coverage when there are monsters and items visible. I am wondering how this performs when you have several cacos in front of your face.

Ok, it is interesting about interleaving normal code with video ram writes, didn't thought about that before, but I believe much more than 10%-15% is lost with this direct to vram method than gained.

Optimus said:

Ok, it is interesting about interleaving normal code with video ram writes, didn't thought about that before, but I believe much more than 10%-15% is lost with this direct to vram method than gained.

It does hovever really help with low-detail mode thanks to the "free" extra pixel write. But yeah, a single access to VGA memory couldn't have been faster than a block memcpy if you had to set the plane register for each pixel -that would mean double the writes, unless you only needed to set it once for every column.

Otherwise it's simply like rendering to 4 separate 80x200 micro-screens instead of a single 320 x 200 one. There are ways to optimize that, but still, it's an extra complication (and of course it would not scale well to different horizontal resolutions).

These days, is it even possible to have specs below that of dooms system requirements?

Untamed64 said:

These days, is it even possible to have specs below that of dooms system requirements?

Embedded systems and console versions may help drawing a line. The PC version is hardcoded to not even try to run with less than 4 MB of RAM of heap space, even though it might be technically possible to run with less.

The absolute minimum amount of RAM to run Doom would be having just enough to hold all statically allocated structures (unless you cut down on their size, of course), current level data (that's decoupled from the disk lumps once loaded), plus dynamically generated composite textures, plus enough memory to temporarily hold the biggest "in flight" disk lumps that you need to have accessible at one time (e.g. within a function) without repeated calls to W_ReadLump.

At worst, this means that you will have to pay for one disk/external storage access for each sprite, flat and non-composite texture draw, though some special functions like e.g. status bar/finale loading may keep quite a lot of lumps "in flight" while active. In the general case you only need enough RAM to keep one or two of the largest lumps in-memory.

Even with all that crippling, I doubt that you could make do with less than 2-3 MB of RAM, unless of course you use ROM as a less-effective RAM. Console versions do all of the above tricks (smaller static limits, using ROM as RAM etc.) and the results are well known.

However most of these "Doom on a Camera/ARM/Arduino board! ZOMG!" projects you see popping now and then usually are attempted only when the hardware allocates more than enough resources, even compared to an average DOS machine in 1994 (e.g. the recent TI version actually has a CPU that's as fast as a Pentium 90 and 32 MB of RAM. Heh, I wish I had that back in 1994!)

If you want to see a "real computer" version that performs significantly worse than PC compatibles, look no further than the Amiga versions: even at complete CPU power parity, they are crippled by the planar display (unless they are using an add-on graphics card).

It would be interesting to see if a hacked doom.exe that removed the heap size checking could be persuaded to run with less than 4 MB...

John Carmack said:

It [ModeX] is still a lot of grief, and it polutes the program quite a bit, but texture mapping directly to the video memory gives you a fair amount of extra speed (10% - 15%) on most video cards because the video writes are interleaved with main memory accesses and texture calculations, giving the write time to complete without stalling.

OK, Dr. Carmack, that was QUITE a big assumption to make back in the day. The fact that video writes could be interleaved with main memory accesses wasn't by any means guaranteed by all mobo/CPU/VGA combos.

Only on fairly advanced CPU and motherboard designs, and then again only if you enabled God-knows-which black-magic tweaking mumbo-jumbo in the BIOS and on the card could this really work. If you had some scrubby low-end 386 or 486 mobo and stock VGA, you were pretty much fux0r3d. On the positive side, that pretty much ends the debate about whether Doom used ModeX/ModeY, and also explains why performance could be so uneven even between apparently equally powerful systems.

And, as Carmack said, VGA planar != bit planar ("THAT would stink"). There, Amiga users ;-)

I played on a 386SX 25Mhz with 4MB RAM yet I had the occasional "pause" (the blue disk) from time to time for like 15-20 seconds at a time. Once I had a 486DX 100Mhz with 16MB, I didn't have that issue but I played Quake on this setup with few issues.

Maes said:

And, as Carmack said, VGA planar != bit planar ("THAT would stink"). There, Amiga users ;-)

Stock A500 or something would be right out, but Doom would probably run okay with an A3000 (M68030 @25 MHz) expanded with 3rd-party graphics card. Which makes me regret buying a 486 instead, especially since I remember there was a dude selling his A3000 in my neighborhood for pretty cheap.

I think I had an Amiga 1200 with 2MB ram when Doom first hit. No way on God's green earth would it handle Doom. I remember a couple of attempts at Doom-clones but they were laughable, Amigas at this level just didn't have the processor speed or power for all those calculations.

At least this whole thing finally showed me that the future belonged to the PC and that the Amiga was headed straight for the dustbin of history.

It's no wonder, because a stock A1200 is no comparison to an A3000 or A4000 with a Zorro III graphics card. You buy a budget entry-level machine, and you get budget performance. ;) That said, your A1200 would have been a better all-around games machine than any of the low-end 386 or 486 that Maes was talking about. Not only that, but its OS was much better designed than any of the non NT-based kernels that Microsoft released (trivia: AmigaOS was part of the inspiration for the design of DragonFly BSD). Up through the mid 90's, there wasn't really any better deal for that kind of price, so consider yoursel lucky to have owned such a nice machine. My 486DX/33 VesaLB system costed me around $1500 in 1994 (and then it felt very gimpy only two years later when Quake came out...) But it turns out that the real future of gaming was in consoles rather than a-la-carte multipurpose PCs, so I'd argue that the Amiga really got it right from the beginning with its cheap but powerful entry level models which effectively were game consoles with keyboards attached (the CD32 just makes that more obvious, as its guts are identical to an A1200). Unfortunately, CBM had no Steve Jobs equivalent, so it floundered and got crushed mercilessly by the big gorilla in the room.

Yeah, the Amiga, including the AGA lines, was indeed better at certain tasks than a generic PC but so were the hundred of custom-designed arcade boards and game consoles that had popped up until then. E.g. a SNES could pull out Donkey Kong Country easily (a 256-color platformer with several levels of parallax scrolling and 8-channel digital music. Can't imagine that you could do that on a 286 or even on a 386 PC, and no PC game ever came close to that quality).

However it all worked so fine and dandy because all that hardware was designed around very specific assumptions regarding the kind of applications/games it would have to run -namely, platforming, scrolling 2D games, in an era where the terms "hardware sprites", "hardware smooth scrolling" etc. still made sense. Everything was tailor-made around these assumptions: video hardware was usually bit-planar, operated in terms of tiles/sprites etc. while the main CPU was -almost- secondary.

The Amiga took this approach to the extreme, as far as personal computers were concerned, and was clearly a child of the 80s design-wise. This was also the reason which led to its downfall: too hard to come up with backwards-compatible upgrades without limiting the amount of innovation (AGA didn't even include a single chunky 8-bit mode that could compete with VGA), and too hard to go forward without losing too much compatibility. Some companies like Apple chose to do the latter (and proved correct in doing so), Commodore tried the hard way of having both and lost. Perhaps if had they tried an approach similar to the PS2 (which included an entire PS1 hardware mode)...

PCs had nothing of the above though: "hardware scrolling" and "sprite collision detection" or even "hardware sprites" were unknown terms. Everything was done in software by brute force and so CPU was paramount. And guess what, traditional 2D games that need to move a lot of data around in the form of scrolling, sprites etc. are the most inefficient to run on such unspecialized hardware, while e.g. scrolling came almost for free on the Amiga.

However something like Doom changed the cards on the table: brute CPU force became important, and the visuals could be more impressive (hey, real-time textured 3D!) with the same or even less video bandwidth a 2D game (trying to scroll a platforming game at 70 Hz generated more VGA traffic than something like Doom). Of course this didn't work well at all with 16-bit era consoles and the Amiga, with their dedicated video circuitry, planar displays and VERY weak CPUs.

The Amiga in particular, whatever native FPS games it had, were Wolf3D-like in quality and not nearly as smooth on as on the PC, even at CPU power parity. Speaking of which, a 68030 could not keep up with a 486 clock-per-clock: with 11 MIPS@33MHz, it was nowhere near the 0.8 IPC performance of any 486. It was much closer to the performance of a 386 (11.4 MIPS@33MHz), with both being around 0.3 IPCs. A 68040 would be a closer competitor to a 486 (1.1 IPC) but then again it did not became standard on the Amiga until near the end and on accelerator boards. An stock A3000 from the standpoint of Doom would just be like a 386DX/25MHz with a very, very slow VGA.

Yeah, the stock video is a killer for Doom, but it would be interesting to see what kind of framerate an A3000 would get with Zorro III slot video card (32-bit bus). My guess is it would be equivalent to a 386DX/40 with ISA video (i.e. can run Doom fine in "low detail" mode, possibly with screen shrunk a notch or two). If anyone has a time machine, I'm willing to go back to 1994/1997 and find out. :)

The Playstation backwards-compatibility method would have probably worked well, and it need not even have been something built-into stock machines (leaving room for such an expansion card or chip would have done the trick).

Instead of the half-ass AGA, the next chipset should have been more along the lines of 3dfx Voodoo...

hex11 said:

My guess is it would be equivalent to a 386DX/40 with ISA video (i.e. can run Doom fine in "low detail" mode, possibly with screen shrunk a notch or two).

Why comparing it with a DX/40? A 68030 is not any faster than a 386 DX clock-per-clock. Factor in a 15 MHz clock speed gap (or worse, a 24 MHz speed gap if we're talking about a 16 MHz A3000), and I don't see how it could ever hope to come close to what was pretty much the top-of-the-line 386DX, unless we're talking about a seriously accelerated 68030.

Even then, even assuming that using a graphics card allowed using a proper chunky mode, it would (ironically) lack the free speedup afforded by ModeY in Low Detail mode on the PC, so the only way it could be slightly faster than the DOS version clock-per-clock would be in High Detail mode. Perverse, ain't it?

OTOH the Amiga would have a slight advantage on the sound code side (at least for playing back just sound effects, and then just up to 4 of them), with no software mixing necessary, but playing multi-track music along with them would be problematic. Some Amiga games used some super-simplified soundtracks with just 2-3 channels to accomodate for SFX, or otherwise employed channel muting or software mixing.

Of course all of the previous scenarios go out the window if you're stuck with nasty ECS/OCS and even AGA. I think that even back in the day, in order to put together an Amiga capable of running Doom as well as an equivalent PC (assuming an official port was available) would've probably cost you significantly more, as the cost of the computer+accelerator board+hard disk+add-on graphics card couldn't have possibly be competitive with a dime-a-dozen 386.

An A4000/040 would've been a more serious base with its 68040 CPU (but not the A4000/030 version which still had the 68030). You'd still need to add a graphics card capable of chunky modes for decent performance, though.

In any case, there are plenty of YT videos that show you exactly what to expect from such configurations. Anything with a 68030 is utterly unremarkable, and I think you also have to hunt for ports that are able to use chunky modes on add-on graphics, otherwise the nasty c2p conversion is a major bottleneck.

The bus should make up some (maybe even all) of the clock difference. The Zorro III bus is effectively like VLB, which was only available on "high end" 486 machines at the time.

There were some really awesome graphics cards made for the Amiga, but of course people with A500, A600 or A1200 didn't have that option (unless they transfered the guts of their machine into one of the 3rd-party cases, but those were expensive).

Then again, looks like there is a "flicker fixer" (de-interlacer) that actually solves some of the C2P issues for any Amiga model. No idea how it compares to a real graphics card, but it would probably be a helluva lot faster than stock Amiga:

http://aminet.net/package/game/shoot/ADoom-1.4

For those without gfx-cards, ECS support and 68040-optimised C2P are included. 68020/30-optimised C2P is blitter-assisted and uses double-buffering. Furthermore, ADoom supports the Indivision GFX mode, which provides native 256 colour chunky graphics on ECS Amigas equipped with Indivision ECS flickerfixer.

As far as sound goes, that's pretty easy: disable the music. I already play this way most of the time (and SDL Doom doesn't support music anyway).

WRT costs: I had the opportunity to buy a used A3000/25 system in 1994 for $700, so it's not like those machine were terribly expensive anymore. I'd have definitely gotten more mileage out of it than the 486. A lot of that is due to how efficiently the Amiga managed memory, whereas even Linux just kept getting more and more bloated (at least if you actually wanted to run X).

Having just a fast bus wouldn't have helped much if the CPU has a fraction of the power required. Even a 486DX/25 would not be anything too hot to begin with, and that's provided it had a decent VLB graphics card.

Now imagine somehow replacing that 486 CPU with a 386 at the same frequency while keeping the rest of the hardware intact.

How would a stock A3000@25MHz be any better than that even with the very best video card you could get it and the most efficient c2p routine available? Even if somehow you managed to reduce the overhead of video/c2p processing to zero, you'd still only have the power of a 386DX/25 to make the logic and in-memory rendering work.

Here's how a 50MHz 68030 board runs Doom:

Quite honestly, it's nothing to write home about. Even with all the hardware the guy threw at it, let's be honest, it would be smoked by a 386 DX/40 and even the lowliest 486 DX/25. The fact that PCs eventually became a dime a dozen while an A3000 has far more collector's value in the long term is of no relevance here (I mean, we ARE discussing if it would be a viable/reasonably priced Doom platform at the time, right?)

That video isn't remarkable because his accelerated 030 is still having to do the C2P conversion in software. This was the last line printed in the startup console:

Amiga_Video: Using C2P conversion with double buffering

Either the Indivision AGA doesn't support chunky pixels (maybe only the Indivision ECS does) or his Doom port doesn't take advantage of it. Effectively he's just running Doom on a 68030/50, with all the C2P overhead involved.

Btw, I should have also quoted this from the ADoom README:

The -directcgx option causes scene rendering directly to the gfx-card (instead of using a chunky buffer in fastmem). This can provide a significant speed-up with a fast gfx-card.

So with a decent Zorro III card, not only do you bypass the C2P overhead, but also that of in-memory rendering.

Anyway, I'm willing to bet that an A3000/25 with decent gfx card (or maybe just Indivision ECS) will get you a decent Doom experience, at least equal to that of a fast 386. The 386 may appear a better investment at first glance, but it doesn't have value in the long run due to the incredibly short half-life of hardware in PC gaming. It's no wonder Joe Gamer prefers consoles (besides not having to deal with Win32 drivers, viruses, and all that crazy stuff...)

Just as "decent" as you'd get with a similarly powered 386, which at 25 MHz would be anything but. The point is that at least on the PC Doom had a chance to make Mode Y worthwhile. Poor Amiga needed an exotic video card just to recoup the performance lost to planar.

Over at my friend scott's house he had an old 486SX that had two whopping 250 MB HDDs, one with win3.1 and one with win95. I think the computer finally died in 2004, but I remember playing doom2 from CD-ROM back at his house at lowest detail. good times. Choppy as a mofo though.

Maes said:

OTOH the Amiga would have a slight advantage on the sound code side (at least for playing back just sound effects, and then just up to 4 of them)

One catch, though. You can't pan the channels. You simply have 2 left channels and 2 right channels, thus you have to mix the proper stereo output in software anyway.

There are many videos of Amiga playing Doom, some terribly slow some smooth enough. Apparently one needs an 68040 to play smoothly as I understand from the description of the video below where it says in 68030 it's hardly playable. I don't much about the Amigas, what makes the 68040 much more powerful than the 68030 I got check it out.

a1200 doom attack

There are some interesting comparisons between 68030-40 and 286-386 here
http://www.faqs.org/faqs/motorola/68k-chips-faq (search for "Speed Comparisons")

p.s. how do you embed youtube vids with bbcode?

A 68030 is almost a 1:1 match for a 386DX, at clock parity. Both are 32-bit CPUs with optional external FPUs, have similar ICPs (0.3), and benchmark around the same. Any specific differences in application software at the time (in particular between e.g. PC and Mac desktop productivity apps) were more because of their different endianness: Little Endian supposedly gives an advantage when sorting/comparing strings, plus different addressing modes had different access penalties: supposedly it was easier, programming wise, to access non-aligned/odd memory works on Intel (it's illegal to even made odd-memory accesses on Motorola).

A 386SX however, with its crippled 16-bit external bus would be more comparable with a 68020 or even a fast 68000 in performance and functionality.

A 68040 is more comparable to a 486DX, if not for a weaker FPU. It has an ICP of 1.1 vs 0.8 of a 486 so it's actually faster clock per clock on pure logic and ALU operations, but it didn't come in as many speed configurations, and didn't have bus-multiplied variants (e.g. DX2/66, DX4/100, DX4/120). Plus, it was not comparable with any Pentium CPUs. You can consider is equal to an advanced 486 design/Pentium precursor.

A 286 is about on the par with a 68000 clock-per-clock, though it lacks the 32/16 architecture of the latter. There is no real pure 16-bit Motorola equivalent (the 68000 was a 32-bit CPU internally).

Answering to thread title:

Yes, I did.