DOOM 32X WAD Converter

Minor update to the WAD converter -- http://www.4shared.com/file/190290264/cebadbf3/wad32x_100.html

Version 1.00 features checksum and ROM size corrections to ensure it will work on real hardware. If the file is bigger than 4MB, it will still save, but will warn you about the size. This update should solve any issues people have had with not being able to get their imports working in an emulator.

Also included is the source code

You can also still use the old version of his tool, but use a Genesis Checksum fixer - it works with 32X roms (if NTSC, rename .32X to .BIN or .SMD). At least that's what I ended up doing.

saxman said:

The YM2612 is an OPN2 chip. It's actually two YM2203's in one, with the added ability to replace channel 6 with DAC. It's very closely related to the Yamaha DX/TX family of FM synthesizers. It's on the lower end of the scale in terms of quality and abilities, but it is definitely capable of doing better music than DOOM 32X.

Probably because they had to rewrite their own music playing routine from scratch (damn DMX sound library...), and just stuck with whatever the 32X SDK had as a default/run-of-the-mill FM music tracker, and whatever timbres happened to be there by default (which sound suspiciously similar to the Yamaha's Waveforce default FM timbres if used in Windows XP as an FM synth, the infamous "distorted guitar that sounds like a squarewave banjo" effect).

Just bothering to reprogram the operators ONCE with the instrument definitions found in the GENMIDI lump would yield practically identical sound to the PC version, without changing anything else -unless the music playback routine and/or the chip are so broken that they need the operators to be explicitly reprogrammed at every note played or something. If there's ONE lump of data/code in the 32X cart that has those damn op definitions, the sound will be automagically be enhanced... but we need someone expert in raw music ripping :-/

I can find the operator definitions but only dynamically as the YM2612 generates it. I can try to do a channel dump - I'll have a log uploaded to my server in an hour or so to share with you guys. But I can definitely find out more than we know currently.

I know where the entire list of voices is located, as well as the sequence data for each song. I don't have my notes with me at this time, but I'll post them next time I'm around. Each voice in the ROM is made up of 41 bytes. I haven't even attempted to figure out what registers are affected by these bytes. I'm more concerned with the sequence data myself as it appears to make use of macros (probably to cut down on size and repeating of data.)

I'll post more on this as I get it, along with the addresses to all these things.

Again, not related to my program, but since it's the subject of some discussion, and because I said I would, here are some updated notes:

http://www.4shared.com/file/188795040/6033867e/doom32x_notes.html

I added several things about the music in there.

Awesome work, keep it up!

Also, have there been ways to insert new code into the 32x rom? Like for example, getting the codepointers from Doom2 so Doom32X can support the Doom2 monsters?

Kaiser said:

Awesome work, keep it up!

Also, have there been ways to insert new code into the 32x rom? Like for example, getting the codepointers from Doom2 so Doom32X can support the Doom2 monsters?

Without being familiar with the specifics of the 32X code, without the actual SC and having only a fixed size space for both the code and the data to play with, whatever can be done will ultimately result in a more or less elaborate "ROM hack".

Changing map and graphics data...trivial (thanks to the converter). Injecting new non-code data...limited both in size and type.

Changing actual code...definitively possible, at assembly/hex edit level.

Injecting new code and pointers....VERY hard to fit within the code segment without recompiling the whole ROM AND the starting position of the data. I'd only attempt something like that with the source code and 32X SDK in my hands.

I did lots of that kind of stuff with 16-bit Sonic games years ago, before the Sonic the Hedgehog 2 disassembly was created. If you know enough about what certain parts of the code are doing, you can branch to new sections of code that you append to the end of the ROM and start writing brand new code. It's a round-about way of reprogramming things without dealing with size limitations. Though it would be limited to machine code without some tool to make it do otherwise, it could very well make porting new monsters possible.

It's especially helpful that there's a DOOM source code to look at. All we need to do is figure out how DOOM 32X handles the other monsters, and then use that as a template for creating new ones.

Of course I make this sound easy -- we're probably a couple years away from doing that realistically. With the Sonic games, I had already been hacking those for several years and understood most of the inner workings of the code.

saxman said:

I did lots of that kind of stuff with 16-bit Sonic games years ago, before the Sonic the Hedgehog 2 disassembly was created. If you know enough about what certain parts of the code are doing, you can branch to new sections of code that you append to the end of the ROM and start writing brand new code. It's a round-about way of reprogramming things without dealing with size limitations. Though it would be limited to machine code without some tool to make it do otherwise, it could very well make porting new monsters possible.

It's especially helpful that there's a DOOM source code to look at. All we need to do is figure out how DOOM 32X handles the other monsters, and then use that as a template for creating new ones.

Of course I make this sound easy -- we're probably a couple years away from doing that realistically. With the Sonic games, I had already been hacking those for several years and understood most of the inner workings of the code.

If action routines are still executed through a function pointer in the state, it should actually be easier than usual. This means you can append code to your heart's content and simply put the addresses of the new compiled routines into the state table.

saxman said:

If you know enough about what certain parts of the code are doing, you can branch to new sections of code that you append to the end of the ROM and start writing brand new code.

For that matter, the ROM has some empty space at the end (if you must stay within the 4 MB boundary) but I don't know about the 32X's address scheme, and if arbitrary code jumps to any memory location are really that easy to do. Heh, imagine appending the IWAD data with new, 32X executable code lumps, which could be called/used with the usual IWAD lump pointers :-p

Turing-complete Doom? :-D

Maes said:

For that matter, the ROM has some empty space at the end (if you must stay within the 4 MB boundary) but I don't know about the 32X's address scheme, and if arbitrary code jumps to any memory location are really that easy to do. Heh, imagine appending the IWAD data with new, 32X executable code lumps, which could be called/used with the usual IWAD lump pointers :-p

Turing-complete Doom? :-D

That would be quite neat, and could allow hacking the ROM to be easier if people can insert lumps instead of learning how to use a hex editor.




Also...

http://www.4shared.com/file/192955239/c20aafd2/DOOM_Spinball.html

Just for fun to see if it would work -- Sonic Spinball music in DOOM! It wasn't a hard hack, it was all a matter of knowing the addresses (which I got from a post Mikel made back at Sonic Retro.)

And for those who haven't seen this -- http://forums.sonicretro.org/index.php?showtopic=18892&hl=GEMS

It's information on the GEMS driver. This of course could open the door to making better music for DOOM.

Version 1.10 is now available -- http://www.4shared.com/file/198175058/d230...wad32x_110.html

I am not expecting to have any newer releases unless something major changes, like supporting Genesis-native 4bpp graphics editing or something like that. Until then, here's what's new with this latest release:

Version 1.10 -- 01/15/2010
- Bug fix: import lump count corrected.
- Import sorts textures in ABC order, fixing MAP15 texture errors as a result.
- Null texture AASHITTY inserted in exports to fix problems viewing ASH01.
- COLORMAP converted to PC compatible format on export, and vise-versa.
- The _32X_ lump now contains version info used to dictate import behavior.

This release was aimed at trying to make both imports and exports look correctly when played. For example, the ASH01 texture actually shows in 32X maps played through the PC version of DOOM now, and likewise, walls with incorrect texture names will now display ASH01 (as they should) in the 32X port since texture names are now sorted in ABC order. COLORMAP conversions now work, so you don't have to delete that lump when playing the 32X data through the PC port.

My program's isn't designed to be perfect, but it is designed to try and make porting data back and forth as painless as possible. This version also imports WAD exports from v0.99 and v1.00 of my program using the _32X_ lump as a way to guide it to ensuring backwards compatibility.

This isn't a major release, but I felt it was worth making as I feel these were some vital issues that needed to be solved. And as with the previous release, the source code to this version is included in the zip file.

Here's something to make porting maps to the 32X MUCH easier (effortless in many cases):

http://www.4shared.com/file/200725236/6bc239e4/d2conv_32x.html



It's a response file for D2CONV. If you don't have D2CONV, I have uploaded a copy of it here:

http://www.4shared.com/file/200725078/eb920589/dm2cnv32.html



Just run D2CONV from the command prompt using the following arguments:

"D2CONV.EXE [in file] [out file] @32x.txt"

Obviously, you should replace "in file" and "out file" with the appropriate file names. My response file will change any unsupported thing numbers to those that are supported by DOOM 32X. It also changes any unavailable floor textures to those used by DOOM 32X. Sector types 11 and 17 are changed too since they're not supported.

What my response file does NOT do is modify linedef types or wall textures. These do not cause DOOM 32X to crash in any way. Unavailable wall textures are changed to ASH01 automatically by DOOM 32X. Unsupported linedef types may be a problem in certain maps (e.g. fast opening/closing doors don't function in DOOM 32X.)

The response file can always be improved. If you want to add to it, feel free to do so.

you should keep the first post updated with the newest version

saxman, I sent you a PM. Just posting here in case you missed it.

Is it just me or are those 32x levels actually more fun to play than the "real" doom levels? The 32x ones look cleaner, more professional and they are also a lot shorter, which I like the most because I always get sick of levels that are too big and confusing.

After using this utility to extract the game contents in WAD form, I noticed the the main menu graphics, and sound, were non-existant in zDoom. The WAD was recognized as Doom II (because of the naming format), and the GFX for the weapons were also way off center.

1) Is there any way to get this to work somewhat properly in a port?

2) There's no music at all in the converted WAD, let alone it not just being a unrecognized type. Anyone know what they used for music in this console port?

The reason I ask is that I have no flash cart for my 32x to load any modifications, but I would like to load the 32x version in a source port.

E.J. said:

After using this utility to extract the game contents in WAD form, I noticed the the main menu graphics, and sound, were non-existant in zDoom. The WAD was recognized as Doom II (because of the naming format), and the GFX for the weapons were also way off center.

1) Is there any way to get this to work somewhat properly in a port?

2) There's no music at all in the converted WAD, let alone it not just being a unrecognized type. Anyone know what they used for music in this console port?

The reason I ask is that I have no flash cart for my 32x to load any modifications, but I would like to load the 32x version in a source port.

Shameless plug