SNES Doom source released under GPLv3

[taufan99]

19 minutes ago, D1m3 said:

Actually there's more stuff,like doomguy's unused mugshots

Now that somebody brings these up. I think the SNES' limited palette that makes the red color more pronounced makes his bloodied mugshots creepier than they have any rights to be.

Which makes for a good material for my new profile pic. Gotta love spooking out some fellow Doomworld users too at times. :P

Edited July 22, 2020 by InDOOMnesia

[RandalLinden]

4 hours ago, Dark Pulse said:

I have a feeling they were intended to be used, but with how little space is left in the ROM (16 BYTES, people!), there was literally no room to even add the code to display them, not without removing something else.

 

I'm reasonably certain, but not 100% positive, that I used them for multiplayer XBand support.

 

Rand.

[xttl]

19 hours ago, Tic said:

I dobut today many people destroy a winter gold cartridge to put a  doom rom :D. 

 

Why? Cheapest copy (cart only) on eBay is about 15€ (£13.56, ~$18 USD), the next cheapest (with packaging) is a bit over 30€ (£27.99, ~$36). That doesn't seem too bad considering what SNES game prices today can be, and it's a lot cheaper than buying a FXPAK Pro (I wish I had bought Rendering Ranger years ago, I actually like that game :D nowadays you don't even know if you get a goddamn repro cart after paying many hundreds...)

 

^{edit: actually found an even cheaper one (<10€), while Doom seems maybe 20-25€ minimum for a loose cart... (and I'd want the NTSC version since buying a PAL copy of a game that already has speed problems probably isn't a good idea, so I'd have to pay more for shipping from America, though I guess the PAL cart might work correctly in NTSC mode, but it'd still not have circlestrafing and I'd have to destroy a better game than Winter Gold if swapped the ROM...)}

 

Of course that's still a lot of money for a game that isn't very good, and FXPAK has more features, but if you just wanted a FX2 devcart relatively cheaply and were able and willing to do a little bit of electronics work I don't see why not...

 

Anyway, it isn't as easy as enabling circlestrafing or figuring out the map format to enable the ceiling/floor textures without rebuilding the whole ROM from Randy's sources I'm afraid. If you wanted to try, there's a define for it in rlinc.i (same place also has a define for eg. a high detail mode which might be playable with a overclocked GSU). There is also a define to disable XBand support (in rage.i), but I don't know if you'd reclaim enough space with that to fit the game with all floor/ceiling textures into 2MB/16Mbit.

 

I guess Randy's tools might not support building an oversized FX2 ROM out of the box though. I know it's possible to make larger FX2 games than Nintendo officially ever did, but why would Randy's tools support this?

 

With these oversized carts, is it even possible to still have more than 2MB visible at once to the SuperFX chip, and not just to the SNES CPU? (eg. this seems to imply no, this too). If it's something that will ever only work on a FXPAK, then you'd have to ask someone who owns such hardware to make a version of the game that utilizes it.

Edited July 22, 2020 by xttl

[Job]

I have little to contribute, except that I propose a motion: whenever this SNES sourceport is completed, the .exe icon should be @xttl's avatar (which I think is Hexen's Porkinator?).

[Revenant]

37 minutes ago, xttl said:

With these oversized carts, is it even possible to still have more than 2MB visible at once to the SuperFX chip, and not just to the SNES CPU?

 

The GSU-2 only has 21 ROM address lines, so 2MB is the maximum that it's physically able to address.

Edited July 22, 2020 by Revenant

[Tic]

@xttl well. That's depend really, in your case probably is cheap. But you need a welder skill, a good  jbc welder or similar. A eeprom/flash programmer. The flash chip, tilt, Flux,the entire pack.

 

Normally, if you don't have the material before. Or you don't have the skills, you don't want get into such a scrub. You prefer buy the sd2snes and drag and drop in the SD card. Much more simple :D. That's probably  the  most probable case. 

 

Insteresting the rlinc.i but first there need of know what  source files use it.

 

But can't be compiled now right?.  Even if you know the direction in rom where the compiler store it. (to try edit the global variable in rom with hex editor).

 

It probably crash, or does nothing how knows,Because it don't have the textures. 

 

About space I think he admit compressed textures and uncompressed. I have view that option in one of the source files. So how knows.

 

 

 

 

 

[xttl]

10 hours ago, Tic said:

Insteresting the rlinc.i but first there need of know what  source files use it.

 

useFLOORS (which also implies textured ceilings despite the name) is referenced in rldrawf.a, rldrawf2.a, rlfloorsdef.a, rltracef2.a It seems rldrawf.a is completely replaced with rldrawf2.a if floor/ceiling textures are enabled. If you download the sources you can do eg. grep useFLOORS * or find "useFLOORS" * in the directory to see all places it's referenced in. (same for useMULTIPLAYER and useXBAND).

 

10 hours ago, Tic said:

But can't be compiled now right?.  Even if you know the direction in rom where the compiler store it. (to try edit the global variable in rom with hex editor).

 

True, nobody has yet rebuilt the ROM from Randy's sources.

 

Does FXPAK Pro allow more than 2MB of ROM to be addressed from SuperFX GSU? Like posted above the original GSU2 doesn't have the address lines for it, but with external bankswitching hardware more could perhaps be added. I'd probably put the maps into memory areas that are swapped in and out and try to keep everything else always available.

 

also, I just read that SD2SNES / FXPAK Pro is apparently open hardware and anyone can try to build their own? Well that's pretty cool. I wasn't aware.

Edited July 22, 2020 by xttl

[Revenant]

20 minutes ago, xttl said:

Does FXPAK Pro allow more than 2MB of ROM to be addressed from SuperFX GSU?

Nope, as far as I can tell the addressing logic in the sd2snes GSU core is basically the same as the real thing.

[lunarmeadow]

Will the game data be getting added? No clue how to use ripdoom and how to convert music, idk how to even set everything up, it's been ages since I've dabbled with amiga emulation

[xttl]

If you don't know how to set everything up, what would you do with the game data? The whole build environment is Amiga-based. (note I don't really know anything either except how to convert levels from PC to SNES format and how to build ripdoom from the m68k asm sources, so this isn't intended as a jab)

 

Of course it'd be nice if the only thing needed to get a working ROM was to put files from SAS C and ACCESS to the right places in UAE and run smake.

[lunarmeadow]

Just now, xttl said:

If you don't know how to set everything up, what would you do with the game data? The whole build environment is Amiga-based. (note I don't really know anything either except how to convert levels from PC to SNES format and how to build ripdoom from the m68k asm sources, so this isn't intended as a jab)

 

Of course it'd be nice if the only thing needed to get a working ROM was to put files from SAS C and ACCESS to the right places in UAE and run smake.

Well, it'd probably be easier to build a ROM, given that Randy says ripdoom suffers archive rot, but I don't know. I presume ripdoom might be the better option if it could be made to work. Also, what's your UAE setup? What model Amiga should I use, what OS (such as AROS etc), and whatnot, I wanna try seeing what I can do, as I have had some limited success with old codebases in the past

[xttl]

10 hours ago, lunaark said:

What model Amiga should I use, what OS (such as AROS etc), and whatnot, I wanna try seeing what I can do, as I have had some limited success with old codebases in the past

 

I used the A4000 preset config, Kickstart 3.1 ROM, created a new 2GB hard disk image (in full disk / RDB mode) and installed OS 3.1 from original floppies. I couldn't get ripdoom to convert levels under AROS ("Error opening Display Picture"), so I don't know how well the rest of the tools would work there either.

 

Btw., I couldn't get the 3.1 installer & partitioning tools to detect the emulated hard disk until I changed controller type from uaehf.device to "Commodore A600/A1200/A4000 IDE".

 

Later, I heard from Randy that he originally used an A2000 machine (which he still has but it's not functional anymore). I don't think the machine config matters much as long as you select at least a 68020 CPU (ripdoom*.asm uses some instructions that only exist on 020 and up, according to warnings from SAS C's assembler) and don't use an OS version that's too old.

 

After the OS works, I recommend setting up Picasso96 to get an usable desktop resolution in the Amiga environment (these instructions worked) and putting the AmigaShell icon on the desktop (browse to workbench->system, select the shell icon and then icons->leave out from the top menu bar which appears with the right mouse button).

 

To get a compatible 68k assembler and make program, search the webs for "SAS C 6.58". If the LHA archive you find doesn't extract correctly with latest AmigaOS LHA or 7-zip, try lhasa on *nix if you can, or search for another one. One SAS C 6.58 LHA I found came with a readme with instructions how to set it up, the other one didn't. If you get the one wihtout a readme, I'll paste the instructions here:

 

Spoiler

Copy the SAS/C directory and icon file to your hard drive, and add the following
commands into your user-startup or startup-sequence. The first line needs to be
changed to point to where you copied the SAS/C installation.

 assign sc: sys:programs/sasc
 assign lib: sc:lib
 assign include: sc:include
 assign cxxinclude: sc:cxxinclude
 path sc:c add

 

 

After you have SAS C setup, you should be able to build all the Amiga-side tools (eg. smake ripdoom). For some reason, I cannot get the SAS C linker to accept any libraries that are stored on the "real" image-backed hard drive so I keep them on the second hard drive that's backed by a host shared directory. (keep this in mind if it complains about amiga.lib not being a valid object file)

 

To use ripdoom you'll need to create a directory called DOOMDATA under the root of the "drive" or volume you run it from in AmigaShell, makedir :DOOMDATA. Otherwise it will appear to work while in reality it's doing nothing. Then you can run ripdoom -r -w doom.wad and it rips all the contents of doom.wad there. After this you can convert levels from PC to SNES format: ripdoom -l :doomdata/e1m1 -o converted/e1m1. Again, you have to make the converted and e1m1 directories manually or it'll just fail silently.

 

Anything else, I don't know myself either.

 

also: good reference for AmigaShell commands (though not everything applies to 3.1)

Edited July 22, 2020 by xttl

[Redneckerz]

42 minutes ago, lunaark said:

Will the game data be getting added? No clue how to use ripdoom and how to convert music, idk how to even set everything up, it's been ages since I've dabbled with amiga emulation

That's analogus to putting the full game out, which obviously cannot happen because Randy has no rights to do so.

Most source (Barony, Delver) releases do not come with game data because either the game is still sold, its in a legal limbo, or the person who released it has no rights to do.

20 minutes ago, lunaark said:

Well, it'd probably be easier to build a ROM, given that Randy says ripdoom suffers archive rot, but I don't know.

One thing does not correlate with the other. Just because Ripdoom is subject to archive rot has nothing to do with adding in the game data.

 

[Tic]

@xttl you can speak with red guy(the guy that made the fx vhdl code) , about the posibility of add more rom if there is space in the fgpa. There  is a thread in discord where you can contact with ikari or he. 

 

Interesting yeah.

 

rlinc.i was used in rage.i that was used in rlfloorsdef.a that have memory direction of textures?. (ifn is if or if not?) 

 

I maybe try search in rom the rage.i. That cheats on was interesting. Converting the bunch of 1,0. to  hex data should be easy to found. 

 

 

[xttl]

10 hours ago, Tic said:

rlinc.i was used in rage.i that was used in rlfloorsdef.a that have memory direction of textures?. (ifn is if or if not?)

 

It's weird, but it seems here ife == #ifndef, and ifn == #ifdef, not the other way around.

^{(this is a convention some other assemblers besides Randy's uses too, though it's still weird. you can think of it as "if X equal to zero" or not)}

Edited July 22, 2020 by xttl

[Dark Pulse]

7 hours ago, RandalLinden said:

I'm reasonably certain, but not 100% positive, that I used them for multiplayer XBand support.

 

Rand.

Proof that it actually doesn't work exists - someone recorded an actual video of SNES Doom Deathmatch over XBand (literally the only existing videos of it that we have, now), and it shows pretty clearly what the MP experience was like.

 

 

 

As you can see, player sprites simply never animate besides the firing phase. Also, of course, no sound effects played, either.

 

Unless you needed them to support it for some reason, but then found out stuff wouldn't work with it - or unless the XBand guys rewrote the code in a patch on their end, or something.

Edited July 22, 2020 by Dark Pulse

[xttl]

I just tried to build at least the parts of the ROM that can be built without the game data ripped correctly. I put al ofl the ACCESS x* binaries released by Randy so far to a directory which I added to the path on my emulated Amiga and ran smake in the source directory.

 

First problem I encountered was that the bumprev tool from ACCESS is still missing (perhaps Randy will upload it later). I commented out all three lines that refer to bumprev from the smakefile and could get some files to assemble, though for some reason smake will think the xa commands fail (even though they succeed) so it only assembles one file at a time. I still got rlram0-3.o, random.o, vectors.o, bank00.o and monitor.o to build succesfully (without any real errors from xa) by running smake repeatedly.

 

Next file after those would be rlram7.o, but it fails due to a real error from xa:

 

@RandalLinden, any tips/comments?

 

edit: well, I just commented them out and that file assembled too. It looks like for the next file I'd need some data. The command smake runs wants files RLDATA:WALLIMG/BANK[01-0D].DEF

Edited July 22, 2020 by xttl

[Job]

That is some bona fide black magic right there. 

[lunarmeadow]

1 minute ago, xttl said:

I just tried to build at least the parts of the ROM that can be built without the game data ripped correctly. I put al ofl the ACCESS x* binaries released by Randy so far to a directory which I added to the path on my emulated Amiga and ran smake in the source directory.

 

First problem I encountered was that the bumprev tool from ACCESS is still missing (perhaps Randy will upload it later). I commented out all three lines that refer to bumprev from the smakefile and could get some files to assemble, though for some reason smake will think the xa commands fail (even though they succeed) so it only assembles one file at a time. I still got rlram0-3.o, random.o, vectors.o, bank00.o and monitor.o to build succesfully (without any real errors from xa) by running smake repeatedly.

 

Next file after those would be rlram7.o, but it fails due to a real error from xa:

 

@RandalLinden, any tips/comments?

 

bumprev is not needed, as far as I can tell it simply bumps the revision number of a given module. Also, what's the issue with ripdoom, I know the binaries are borked, but is the source code able to be used? If you can rip the data from a Doom wad, try assembling with some modified build flags. Also, looking at the limited ACCESS documentation available LTEXT is just a string evaluated at link time, try placing a regular string with dc.b

 

No clue why LTEXT wouldn't work though.

[lunarmeadow]

31 minutes ago, xttl said:

I just tried to build at least the parts of the ROM that can be built without the game data ripped correctly. I put al ofl the ACCESS x* binaries released by Randy so far to a directory which I added to the path on my emulated Amiga and ran smake in the source directory.

 

First problem I encountered was that the bumprev tool from ACCESS is still missing (perhaps Randy will upload it later). I commented out all three lines that refer to bumprev from the smakefile and could get some files to assemble, though for some reason smake will think the xa commands fail (even though they succeed) so it only assembles one file at a time. I still got rlram0-3.o, random.o, vectors.o, bank00.o and monitor.o to build succesfully (without any real errors from xa) by running smake repeatedly.

 

Next file after those would be rlram7.o, but it fails due to a real error from xa:

 

@RandalLinden, any tips/comments?

 

edit: well, I just commented them out and that file assembled too. It looks like for the next file I'd need some data. The command smake runs wants files RLDATA:WALLIMG/BANK[01-0D].DEF

Also, to add to my earlier statements, try adding the -v flag when assembling for verbose operation, output might be a little more useful

[xttl]

Yes, ripdoom can be built successfully from the asm sources (though you need to add string DoomWADDir = db 'doom.wad',0 yourself in ripdoom2.asm, otherwise the linker will complain about it, xref DoomWADDir must also be changed to xdef near the beginning of the file).

 

I think the bank?? files are supposed to be generated by mkwall which can also be succesfully built from the sources by just typing "smake mkwall" but it needs some graphics files I don't know how to generate.

 

Edited July 23, 2020 by xttl

[lunarmeadow]

1 minute ago, xttl said:

Yes, ripdoom can be built successfully from the asm sources (though you need to add string DoomWADDir = db 'doom.wad',0 yourself in ripdoom2.asm, otherwise the linker will complain about it, xref DoomWADDir must also be changed to xdef near the beginning of the file).

 

I think the bank?? files are supposed to be generated by mkwall which can also be succesfully built from the sources by just typing "smake mkwall" but it needs some graphics files I don't know how to generate.

 

PLAYA1 is one of the Doomguy sprites, you have to rip the WAD with ripdoom, then it'll automatically extract and organize all of the WAD data in raw lump format, as far as I can tell. This is probably the reason you got the "Error opening Display Picture!" on AROS as well, just run ripdoom on an IWAD, should theoretically work. Also, I'm pretty sure you won't be able to get music or sound in the game, as far as I can tell, there's no music driver source code. However, I might be wrong and it might export a compressed sound driver alongside the converted music, which would explain why there's unassembled SPC700 source code within the SPC RAM. If you wanna take a shot at converting music as well, I'm fairly certain the game actually uses BRR compressed rips of the GUS patches from the IWAD, even though alot of instruments are omitted, and as such most music uses different equivalent instruments, if you listen to a GUS recording of E1M2 the start sounds identical, except the samples are BRR compressed and it has that gaussian filtering the SNES plasters on. SPMUS and CONVGUS appear to handle this conversion.

[xttl]

10 hours ago, lunaark said:

PLAYA1 is one of the Doomguy sprites, you have to rip the WAD with ripdoom

 

Yes, this much I know myself. Problem is, how to do that. All the documentation we have is an incomplete txt file, random build scripts and M68k assembly. :(

 

10 hours ago, lunaark said:

This is probably the reason you got the "Error opening Display Picture!" on AROS as well

 

Except that I got the error on AROS while converting maps which works 100% ok on real AmigaOS without errors. The reason it appears is that ripdoom tries to draw an IFF image of the map while it's converting it, and that is somehow broken on AROS (and it's more difficult to just remove this feature from the program than it should be because it's written in M68k ASM and not C :P)

 

Map conversion working:

 

 

Picture which it cannot draw on AROS:

^{(which is also completely not even necessary to put the level in the game...)}

 

 

 

10 hours ago, lunaark said:

Also, I'm pretty sure you won't be able to get music or sound in the game, as far as I can tell, there's no music driver source code.

 

This I was also a bit worried about myself. I'm not sure if there's even any code in Randy's source dump to convert the actual MIDI sequences? (instead of just the GUS instrument samples)

 

make/MUS references some program called spmus which isn't included.

 

10 hours ago, lunaark said:

I'm fairly certain the game actually uses BRR compressed rips of the GUS patches from the IWAD

 

True, though they aren't from the IWAD (they were never distributed with Doom, they're from Gravis driver disks instead). Btw. I wonder did they get a license to use them? Some of the modern commercial console ports also use the original copyrighted Gravis patches for MIDI playback...

[lunarmeadow]

3 minutes ago, xttl said:

 

Yes, this much I know myself. Problem is, how to do that. All the documentation we have is an incomplete txt file, random build scripts and M68k assembly. :(

 

 

Except that I got the error on AROS while converting maps which works 100% ok on real AmigaOS without errors. The reason it appears is that ripdoom tries to draw an IFF image of the map while it's converting it, and that is somehow broken on AROS (and it's more difficult to just remove this feature from the program than it should be because it's written in M68k ASM and not C :P)

 

Map conversion working:

 

 

Picture which it cannot draw on AROS:

^{(which is also completely not even necessary to put the level in the game...)}

 

 

 

 

This I was also a bit worried about myself. I'm not sure if there's even any code in Randy's source dump to convert the actual MIDI sequences? (instead of just the GUS instrument samples)

 

make/MUS references some program called spmus which isn't included.

 

 

True, though they aren't from the IWAD (they were never distributed with Doom, they're from Gravis driver disks instead). Btw. I wonder did they get a license to use them? Some of the modern commercial console ports also use the original copyrighted Gravis patches for MIDI playback...

SPMUS is included in the DOOM-FX repository, with binaries and source. Not sure if the tools are fully there. As for the other stuff, not sure either.

[xttl]

Oh right, somehow I missed it. I guess it would be possible to rip the sound driver from the original ROM if all else fails?

[lunarmeadow]

18 minutes ago, xttl said:

Oh right, somehow I missed it. I guess it would be possible to rip the sound driver from the original ROM if all else fails?

 

maybe

 

probably not

[xttl]

I thought I'd try to reassemble only the modules which are different depending on if useHIGHDETAIL is enabled or not, then insert the object code into the ROM to have at least something interesting happening without spending too much time and effort trying to rebuild from scratch.

 

Unfortunately, that's a no go too:

 

 

(the rest I didn't even bother trying, rltrace.o, rltracef.o, rltraceo.o, rltraceo3.o, rltracew3.o would also be different with useHIGHDETAIL)

[lunarmeadow]

Just now, xttl said:

I thought I'd try to reassemble only the modules which are different depending on if useHIGHDETAIL is enabled or not, then insert the object code into the ROM to have at least something interesting happening without spending too much time and effort trying to rebuild from scratch.

 

Unfortunately, that's a no go too:

 

 

(the rest I didn't even bother trying, rltrace.o, rltracef.o, rltraceo.o, rltraceo3.o, rltracew3.o would also be different with useHIGHDETAIL)

Try changing the build flags to omit sound, and use the original makefiles

[Tic]

Wow. What knowledge. (I never had an amiga I jump from 8 bits to snes/pc.). I have try follow the source code with the source using these snes9x emulator with debugger, That first part fortunly uses snes cpu, to find   the global variables in the rom. 

 

I follow it +- first execute few lines from and unknown file of the sources. And then it call to the ini.a file. 

 

But when he executed  the "bne ColdBoot" and jumps in theory to the coldBoot part, that the first chek is the debugger. It change totally. I'm not sure if it's simply because the compiler generated alot big of code to made the ifn blocks or because the rom is a diferent version from the source code, but it's a lot of code not present directly in the init file.A lot of subroutines. So I try find where it made the check exactly. 

[xttl]

I am using the original smakefile (with commented out bumprev lines). rlplayer2.a wants to include RLMUS: files even with useSOUND = 0, though it seems to assemble ok if the include is commented out. I had to comment out all the lines which reference CACHE* macros because the assembler always fails on them...

 

 

That should be all of them, but there's something I didn't notice at first: some almost all offsets in rlram7 change depending on useHIGHDETAIL 0/1. This might make patching the ROM too annoying.

Edited July 23, 2020 by xttl