DOOM (SNES)

I've decided to work on a wishlisted game with PCM pack already done, DOOM.

I figured "oh hey here's an easy one, the source code is already released!"
Anyways, when it comes time to actually patch the rom ASAR -hates- the addresses I have to hook

As well as this game famously has 16 bytes free, but when I expand the rom the game seems to overwrite all the new areas too.

The code I have for the game should work in theory but I have not been able to test it in the slightest.

Anybody else have any advice?

Without having tested it, you need to use lunar expand to expand a rom:
https://www.smwcentral.net/?p=section&a=details&id=4599

Then, you hook in the ram:
org $7E51A3
jsl hooked

This isn't possible... if code is executed from ram (I had this with Star Fox and SMW2 for example), you must at init boot transfer your msu code to ram (I use MVN), then you need to look where the code in the rom is located that is executed in ram and hook there to your ram. Sorry I am not good at explaining.

I see..

I did use lunar expand to expand the rom, but everywhere I look in the memory viewer in bsnes plus is jittering between values anyways.. there doesnt look like there is a good place to put any of my code..

Is this code in ram because of compression, and regardless, how would I identify the original location of it..?

Yes... it is superfx, so you need to transfer your msu code to ram first
then you need to hook at this ram address 7e51A3.

you must somewhere hook at game initialization and transfer your msu code e.g., to 7e/e000 (with MVN)

Then you mst find the code youwant to hook in the rom (it is transferred to ram)
$7E/51A3 8C 40 21    STY $2140
And JSR to 7e/e000,
So it makes at 7e/51a3: 20 00 e0 (jsr to your injected msu code in ram at init).

the sty $2140 is at pc 0x1c31a3
so make a
org $ ?? (dunno at the moment how the org is calculated in xkas)
JSR $e000

Look maybe at the starfox or super mario world2 source code how I transferred into ram, but ... I can tell you, this is not easy if you start doing msu stuff

I was hoping to have this released by new years but I think I might work on other projects to improve my skills before tackling this one, then. I'll definitely have to look at your code for those hacks when/if I resume work on this, though

It's not so difficult.
You need a place to hook at init, look when the game writes the stuff to ram 7e51a3, and hook somewhere thereafter (be sure you hook where it only is called one time).

The mvn is easy, it always follows in this schema

PHB
LDA #$02FF ; A- transfer e.g., $300 bytes
LDX #$FD00 ; start address FD00
LDY #$E000 ; ram address E000
MVN $017E  ; bank 01 -> 7E
PLB

So in this example MVN transfers 300 bytes ($02ff) from rom 01/fd00 to ram 7e/e000

Then you only need to find the location of
0x1c31a3: 8c 40 21
and hook it to JSR to 7e/e000 (JSR $e000)

I see.. so this game might be copying to ram at instruction
$5f9f5f after the title screen, which is why the addresses change from 5c31a3 to 7e51a3 that i would need to hook.

A question then, if I write my code to 5c31a3, it should just get copied wholesale to 7e51a3? that would be fine, as the game uses the code before copying to ram to play the Williams logo song and the title screen song...

Here is an example code. I have problems addressing it beyond the 2MB, but maybe your place is enough.

What I did:

hirom
(I do a lot easier addressing this)

Code:

org $DC31a3
jsl $7ee000
   nop
   nop


This is hardocded to execute msu code in ram 7e/e000 (unused and not overwritten as far I can see

Code:

org $DEFFA5
JSL $5fff10

Hook to write the msu code into ram

Code:

org $DFff10
JSL $49FFD5 ; overwritten code for init
; then do the transfer to ram 7e/e000 stuff

Code:


org $DFff30 ;
hooked:

This is your msu code area. The place is highly limited ($C0 bytes) unless  you find a way to address beyond the 2 MB

Make a hook at $7e/e000 after compiling with xkas.

That's really illuminating!
I must thank you once again for your input and support. are you sure you're retired?? 

I really don't think I would have gotten anywhere near where i am now without your constant advice + code.

This is ready for a beta release now, all thanks to Conn.
It seriously would not have happened without his help.

I don't have the PCM pack arranged properly, but anybody that wishes to do so would be advised of at least a couple oddities.

1. The Williams logo plays the first bits (just a few seconds really) of track 3. 
    This is normal operation of the game.
2. The title screen song is track 0
3. Results screen is 1, putting e1m1 at 2.

Everything from there may just count up by level, I'm not certain about track numbering and I'm also not good enough at this game to beat it to test.

The currently playing track is in memory @ 06BF for anybody mapping tracks to this game.

This patch has not been tested for compatibility with the circle-strafing patch on romhacking.net but it is not likely to interfere, having looked at it.

PCM (not ordered or named properly) 
Doom (Andrew Hulshult IDKFA Remixes) (Thanks Relikk for converting these!)

Patch
https://mega.nz/file/iSxE3LLC#xF5mxs2zz_8EdLswwGJdoTCOaXmejhLvjkAyY7pKIQk

That's great, and nothing to thank me. The main hooks and msu code were already found by you. Writing the code transfer stuff only took me half an hour maybe But you really chose one of those unusual games with super FX which need special treatment...

Tracks are mapped. I've added the link below to the release along with an updated (named & numbered) PCM pack.

https://docs.google.com/spreadsheets/d/1mnPJH0wtLtNA29-pFzsIKNKiQ1P5QNJMPaaD_J6bbmM

Just because I saw that track 0 is no loop, and in case Cubear wants to correct:

Code:

;noloop tracks here
LDA $06bf
cmp #$00 ;track number 0 is no loop
beq noloop

This is little, as well as this:

Code:

LDA #$BF ;\raises volume
STA $2006;/

We usually make FF (full volume), but I guess Relikk adjusted his set to BF, so I'd say leave to bf now.

Let me know in case anything changes here (e.g., links for my backup):
https://www.zeldix.net/t2413-doom

I did notice a volume discrepancy between the stock ROM and the MSU1 patched ROM in BSNES, but weirdly there was no discrepancy in Snes9x.

I didn't have to edit the volume of the PCM pack, it sits nicely with the current levels and in comparison to the stock ROM, but it's no problem to edit the audio files accordingly if Cubear wants to update the value to $FF.

Just tested it and noticed that pcm-0 isn't part of the pcm pack ayways (spc fallback) and even if it was, it wouldn't make a difference if looped or no-loop since the title is autoadvanced.
So I think we are good with this patch

I didn't notice a difference between bsnes/snes9x, but I also don't have your ears Relikk

The difference was between the stock ROM and the patched ROM on their respective emulators. BSNES can be a bit funny like that, though. Even though this was not the case specifically, I remember finding out that if you had two instances of it running the volume of one would be lower than the other. I don't know if that was ever fixed.

Conn wrote:Just because I saw that track 0 is no loop, and in case Cubear wants to correct:
We usually make FF (full volume), but I guess Relikk adjusted his set to BF, so I'd say leave to bf now.

I just always found ff to be too loud compared to spc music lol. I can start using it in the future.

Even if this pack doesnt have a track 0, I should probably still update 0 to have noloop just in case somebody wants to include one in a future pack.
I also noticed that pausing does not stop the music and so I should include that before a 1.0 release as well. I should still fit within the 180 bytes or so that we have in our code area with both of those included.

Nice
We chose FF (max volume) after sd2snes had implemented a volume booster.
It's standard... It makes no difference if you use 80, bf or FF, since the amplitude can be adjusted in the pcm (so the volume of the set is adapted to the 2006 value you chose.

I'm happy that the Rom space is enough for this hack

Relikk wrote:The difference was between the stock ROM and the patched ROM on their respective emulators. BSNES can be a bit funny like that, though. Even though this was not the case specifically, I remember finding out that if you had two instances of it running the volume of one would be lower than the other. I don't know if that was ever fixed.

From what I have heard DOOM is a really temperamental game. I think it's just barely holding itself together at the best of times lol. Very impressive to even have it running on a SNES

Out of curiousity, the title-0 pcm is spc fallback since there is no substitute available, right?

Conn wrote:Out of curiousity, the title-0 pcm is spc fallback since there is no substitute available, right?

Yes.

Stopping the track on pause was too challenging for me to work out (same signal for fadeout as fadein) so I made it so it simply does not restart the track on unpause... it's a bit different from standard but I think it works as well, if not better imho.

I don't think setting track 0 to noloop has any bearing on the game at all. The game is not waiting for any signal or input from the player or the APU at that screen and just progresses to E1M1 automatically.

With that said I'm going to leave out the noloop code for now until it is specifically needed as the lighter this code is in the end, the less chance there is of it being broken.

The only thing I think is broken right now is turning off the music in the pause menu does not turn off the music in the hack.. but if you didn't want music, why would you play the hack with custom music support? I'm fine leaving that as-is as well.... but maybe i'll work on that nonetheless.

anyways expect a new version with very small fixes in the next day or so, which is likely to be the final version minus bug fixes

With that said I'm going to leave out the noloop code for now until it is specifically needed as the lighter this code is in the end, the less chance there is of it being broken.

I completely agree.

The only thing I think is broken right now is turning off the music in the pause menu does not turn off the music in the hack..

Code:


;Pause start
org $dfa416 ;hirom, just add it to your asm
JSL $5fffe0 ;pauseStart

;Pause end
org $DFA657
JSR $fff0 ; be careful, it is jsR!


org $dfffe0 ; pause start hirom = 5f/ffe0, pc 1f/ffe0
STA $2F
STA $2D ; native code
STZ $2007 ; stop music
RTL

org $dffff0 ;pause end hirom = 5f/fff0, pc 1f/fff0, should be less than 16 bytes
PHP
SEP #$20
LDA #$03
STA $2007 ;resume music (it is always loop)
PLP
LDA #$0006 ; native code
RTS

I didn't test

Here's the modified asm.

Note, to prevent restart of the music, I added

Code:

msu1:
lda $06BF ;track that is being requested.
cmp $7ef000
BNE $02
BRA alreadyPlaying
Sta $2004 ;store this to MSU1
STA $7ef000

So, the current played track is stored to 7ef000 so that the music resumes. Side effect, if you restart the level, it resumes the music without restarting

Oh that's a completely different solution than I had planned.
I have code in place to not pause the music during pause screen, but it DOES restart if/when you restart the level.

Code:

msu1:
lda $06BF ;track that is being requested.
cmp $06bd ;previously playing. may need to change later if theres bugs
beq stopspc ;dont restart track if it's already playing.
Sta $2004 ;store this to MSU1
sta $06bd ;save currently playing track to be compared to

and

Code:

stopspc:
pla
xba ;switch b and a again.
lda #$1A ;prevent SPC playback
xba ;switch it back
plp
sty $2140
sta $2142
rtl

What I was talking about adding was a means of muting MSU1 when you turn the music off on the pause screen... a bit pointless since if you're playing this hack you want to hear the music, but for completeness' sake...

I've found that muting is values 0000 on 0734 + 0735 and it seems like that would be easy to check for but when I do it it seems to break my stack...  while a bit of a pointless feature it's taunting me...