Doom 32X: Resurrection

Mr^Burns

Staff member

"The goal of the project is to have a code base from which a playable version of DOOM for the Sega 32X platform could be compiled. It is primarily focused on preservation and education but also on fixing the original game's idiosyncrasies and improving performance."

Source: viciious/d32xr
 
Wow, looks fantastic for the 32x.

I always wondered, when you have both the mega cd and 32x plugged in, can a 32x game theoretically take advantage of the mega cd hardware? All the 32x CD games were FMV releases, so I was never sure if you could have both the 32x hardware and the Mega CD's hardware (like the sprite scaling stuff) used together (well, with any MCD usage limited to the Mega Drive layers of course), or if the Mega CD was relegated to purely cd streaming at that point.
 
You can, but iirc there's so much bus infighting that you'd have an easier time working with the Saturn.

Actually, the Sega system has very little bus contention compared to other consoles of the time... when you understand how to avoid it.

With the Sega CD, keep the code/game data in the program ram, and avoid the word ram unless you're generating shared data for the MD side.

With the Genesis/MD, keep the code/game data in the work ram, and avoid the cart as much as possible. This limits the amount of code the MD side can use, but you're better off moving most of the code to the SCD 68000 (which is almost twice as fast), or to the 32X SH2s (which can be up to 40X faster). Code on the MD should really only be enough to respond to requests by the 32X or by the SCD.

With the 32X, using the cart for code/game data isn't going to be as bad as you'd think since the SH2 has a very good and decent size cache. However, put critical code/data into SDRAM for best effect. This is fairly easy to do in gcc, and is used quite a bit in D32XR to put functions into SDRAM.

When you work to minimize bus contention, you can get really good results from the 32X. Look at Doom 32X Resurrection: remember that it's running on two 23MHz processors on a slow 16-bit bus. Now think about how Doom ran on the 386SX, which is about as close as you'd get for a hardware comparison.
 

TrekkiesUnite118

Established Member
Now think about how Doom ran on the 386SX, which is about as close as you'd get for a hardware comparison.
Another comparison would be how it runs on an IBM 486SLC2. That's technically a 386SX with the 486 instruction set added to it, some cache, and clock doubled up to 50Mhz/66MHz. So you still have no additional FPU and have to use a 387, and you're still on a 16-bit bus. I recorded some footage from my IBM PS/2 Model 50 with that CPU upgrade put in it:

 
Nice! I bet PC owners loved that. It's easy to see why it was faster, though. More than double the clock rate, four times the cache, only one processor (as anyone who's worked with SMP can tell you, two processors don't mean twice the speed), a faster bus, a nice video card, and Carmack's hand-tuned x86 assembly code for many of the critical sections of the code. 16MB of system memory means all the game assets are decompressed and waiting to go in a reasonably fast-to-access area, unlike the compressed assets in slow cart space D32XR has to deal with.

That's one of the worst aspects of the 32X: only 256KB of SDRAM. If they'd have bumped that to even just 1MB, the 32X would have been much better. Instead of picking and choosing what bits to have in SDRAM, the whole game and data could have been in SDRAM. More game assets could be cached in SDRAM for faster access.
 
The first official release of Doom 32X Resurrection is out at romhacking! Get the patch file at:


This is a patch file against the EU rom image of Doom 32X, but makes a region-free binary. There will be another patch against the US/JP image of Doom 32X posted at some point, as well.
 
Top