Need info on SPC Reset State

Strictly for discussing ZSNES development and for submitting code. You can also join us on IRC at irc.libera.chat in #zsnes.
Please, no requests here.

Moderator: ZSNES Mods

Post Reply
grinvader
ZSNES Shake Shake Prinny
Posts: 5632
Joined: Wed Jul 28, 2004 4:15 pm
Location: PAL50, dood !

Need info on SPC Reset State

Post by grinvader »

Ok, this is simple. In latest WIPs and v1.42 itself, resetting in Super E.D.F. will cause sound to become horribly distorted.

ROM info:

Code: Select all

NSRT v3.3 RC2 - Nach's SNES ROM Tools

---------------------Internal ROM Info----------------------
       File: Super_E.D.F.sfc
       Name: SUPER E.D.F.           Company: Jaleco
     Header: None                      Bank: LoROM
Interleaved: No                        SRAM: 0 Kb
       Type: Normal                     ROM: 8 Mb
    Country: USA                      Video: NTSC
  ROM Speed: 200ns (SlowROM)       Revision: 1.0
   Checksum: Good 0x01D1              CRC32: CA8FF946
--------------------------Database--------------------------
   Name: Earth Defense Force
Country: USA                    Revision: 1.0
 Port 1: Gamepad                  Port 2: Gamepad
Genre 1: Shooter                 Genre 2: Side Scrolling
This started happening since we implemented reset according to byuu's data.

Anyone know what happens to SPC RAM during reset?
皆黙って俺について来い!!

Code: Select all

<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)
Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

Edited for correctness.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
anomie
Lurker
Posts: 151
Joined: Tue Dec 07, 2004 1:40 am

Re: Need info on SPC Reset State

Post by anomie »

grinvader wrote:Anyone know what happens to SPC RAM during reset?
IIRC, nothing. But the bootstrap routine clears and resets the stack, and the ROM must be re-enabled if it had been disabled. And probably the registers ($f1 and $f4-7, which includes $2140-7f on the S-CPU side) get reset.

Feel free to correct me if i'm wrong.
byuu

Post by byuu »

...resetting in Super E.D.F. will cause sound to become horribly distorted.
Could be a problem with the game itself. Does the same thing happen on a copier?
This started happening since we implemented reset according to byuu's data.
Well, as far as I know, ZSNES only stopped clearing $7e:0000-$7f:ffff upon reset, which has been confirmed by Overload (?) as well. There's more to a real reset than that, of course; but this is a good start. It has also resulted in high score lists persisting upon reset, as they should; such as in SFA2.
Therefore, I'm fairly confident it isn't the RAM clearing that's breaking the game. It may be something else that got modified as a result of that fix, or some other change since v1.41... an easy way to find out would be to enable RAM clearing upon reset in the latest build and give the game a try.
Anyone know what happens to SPC RAM during reset?
Unfortunately, no; sorry. The SPC is one pitifully documented chip.
I would say it would at least -have- to enable IPL ROM and jump to $ffc0.
I do know that ZSNES starts the SPC at $ffc9, which is after the stack set/clear; but I don't know if that matters or not.
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

byuusan wrote:It may be something else that got modified as a result of that fix, or some other change since v1.41... an easy way to find out would be to enable RAM clearing upon reset in the latest build and give the game a try.
I tried that already, clearing that segment of RAM upon reset, and no more glitchy sound.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
byuu

Post by byuu »

I tried that already, clearing that segment of RAM upon reset, and no more glitchy sound.
Interesting... not sure what to tell you, then. You'll either have to special case Super E.D.F., or revert to clearing WRAM at reset, which would clear high score lists and the like. The latter sounds less important, but I don't know.

Has anyone tested the game (the exact ROM image, not just the cart) on a real SNES to see if it has the same problem or not? I know that many PD ROMs wrongly assume that WRAM is initialized to 0x00 upon reset and refuse to work otherwise (Qwertie's Mode7 demo comes to mind). ZSNES resets WRAM to 0x55 upon power-on, so those PD ROMs don't run. Maybe there's a similar problem with this game -- I'm not saying ZSNES should power on with 0x00, but that there may be a problem with the game itself assuming WRAM is set to something after reset.

Edit: OK, I checked out the game. First off, no one said it was a BS game... I have no idea how BS games work. I've always noticed issues with BS games and initial WRAM values.
One major difference I see between ZSNES 1.36 and 1.42 is that 1.36 initializes WRAM to 0x55 upon power-on, 1.42 initializes it to 0xFF upon power-on. That could be what's causing the problem.
I don't know what the correct value should be, but I'm told the WRAM is filled with garbage at power-on.
I'm also unable to reproduce the bug. The sound in the game sounds like crap in 1.36 and 1.42. It sounds choppy. 1.42 seems to play the music faster. Nothing changes in either game when I reset.
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

byuusan wrote: Edit: OK, I checked out the game. First off, no one said it was a BS game...
That is correct, we're not working with the BS version of the game, although there is such a version. Note the NSRT info grinvader pasted.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
byuu

Post by byuu »

Ah, I didn't see a non-BS version where I was looking. And sorry, I don't use NSRT, nor any ROM databasing tools; although I should. I figured your tools just excluded the BS in the filename.
I'll check out the non-BS version then.
byuu

Post by byuu »

OK, I was able to reproduce the bug. Hopefully these notes will help you out some.
http://setsuna.the2d.com/files/edf_notes.zip
Included is some of the game disassembly, as well as a patch that fixes the game in ZSNES v1.42 and above, demonstrating that I have the correct problem area. If you don't want to use xkas, just use a hex editor and go to 0x0000a1 (0x0002a1 with header, 0x0080a1 ROM memory location) and overwrite 0xf0 0x51 with 0xea 0xea.

Essentially, it is in fact clearing WRAM thats breaking the game. More specifically, the following happens at the start of the game:

It starts at code location $00:8012 by clearing $7e:1f32 to 0x00. It then reads from $7e:1f34 and up to see if WRAM contains the string 'JALECO-SFX' or not. If it does, then nothing happens. Otherwise, the string is copied letter by letter from ROM at $00:8037 to that WRAM location, and $7e:1f32 is OR'ed with each letter in the string. So the end result is that at system power-up, $7e:1f32 equals the bitwise OR of the entire string 'JALECO-SFX', or $7e:1f32 = $6f. While the purpose of OR'ing the letters may seem strange, it basically makes $7e:1f32 non-zero if even one letter at $7e:1f34[...] doesn't match the test string. It's essentially a test to see if the SNES was just powered on, or reset.

This changes the way the game initializes later on in the code, specifically at code location $00:809e.

Code: Select all

00809E LDA $1F32     [001F32] A:FFFF X:FFFF Y:0000 S:1FFD DB:00 D:0000 P:06 e
0080A1 BEQ $80F4     [0080F4] A:0000 X:FFFF Y:0000 S:1FFD DB:00 D:0000 P:06 e
Upon power-on, the code will end up going to $00:80a3. After reset, the code will go to $00:80f4. Unfortunately, the code is wildly different, and spans several pages. I don't have a clue what it's trying to do. My guess is that it handles WRAM initialization differently in an effort to save the high score list, and like grinvader said when he started the post; it initializes the SPC700 differently, which would explain why the sound breaks.

So basically, I don't know what's wrong; but it's very unlikely to be the fault of just clearing WRAM. The quick fix would be to just add a hack that patches ROM $00:80a1 with { 0xea, 0xea }, the proper fix would be delving through the different routines at $00:80a3 and $00:80f4, finding out the differences, and fixing whatever is wrong; which is likely another difference between powering on the SNES and resetting it.

---

Unrelated: It would seem ZSNES 1.42 still clears WRAM to 0x55 upon power-on. I guess BS games are special cased to reset WRAM to 0xff? I don't care either way, just wanted to correct my error above.
grinvader
ZSNES Shake Shake Prinny
Posts: 5632
Joined: Wed Jul 28, 2004 4:15 pm
Location: PAL50, dood !

Post by grinvader »

If I told you that on power-on the Jaleco screen shows up, and not on reset, would that help you on guessing what the trouble is ?
皆黙って俺について来い!!

Code: Select all

<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)
Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
byuu

Post by byuu »

Wow, I'm surprised I missed that, heh. Sadly, no. But that does explain why the code paths are so wildly different.
Sorry, I don't really (want to spend/have) a lot of time (to work) on this; and even if I did, I wouldn't be able to help much because I know nothing about the SPC700. Hell, I don't even know how to enable/disable the IPL ROM, let alone if it's force-enabled at reset. I'd recommend playing around with clearing out the SPC RAM/DSP regs and not clearing them until it works right.
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

byuusan wrote:It would seem ZSNES 1.42 still clears WRAM to 0x55 upon power-on. I guess BS games are special cased to reset WRAM to 0xff?
That is correct.

BTW, have you tried this game on your copier and tested reset?
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
byuu

Post by byuu »

No, I haven't. I don't have a lot of room at my desk (two PCs, two CRTs, 25" TV, stereo... yes, the CRTs cause interference when the TV is on), so I usually box up my copier when it's not in use; which makes it kind of a pain to drag out often. I've been planning to do some more DMA timing tests for a week now, as soon as I drag out the copier for that, I'll give it a try. I strongly suspect that it'll work, though.

I just realized that I can test clearing/not clearing SPC RAM/DSP regs from the ZST at reset, I'll give that a try.

Edit: Ok, I tried a few tests with ZSTs.
http://setsuna.the2d.com/files/edf_zsts.zip

Basically, I played the game to the first in-game screen, and saved edf_ingame.zst, then I went into the debugger and modified 0x8000/0x8001 to { 0x80, 0xfe }... a poor man's breakpoint since ZSNES doesn't support in-game ones. I then went back to ZSNES and reset, went into the debugger and saved edf_reset.zst. I then copied the SPC RAM from edf_ingame.zst, ignoring the IPL ROM (0x30c13-0x40bc9, 0xffc0 bytes) and saved it to edf.zst
edf.zst has the game reset, and has the WRAM full of in-game values, but the sound works fine now. So my theory is that the game figures some (all?) of the samples/sound effects are already in SPC RAM and skips loading them. So to fix Super E.D.F., don't clear SPC RAM 0x0000-0xffbf at reset. Or more likely, don't clear any SPC RAM. 0xffc0-0xffff is probably still there, but hidden since the IPL ROM was re-enabled. EDF definately disables the IPL ROM during gameplay.

Please note that I have absolutely no idea if a real SNES does this or not, but it does work for this game. Perhaps you can make a WIP and have people test it thoroughly? Or can someone who's good with the SPC700 confirm/deny SPCRAM not getting clear upon reset? Note that I didn't try clearing DSP regs or not, since this seemed to work. It seems logical that registers would be cleared, and RAM not; just like the CPU RAM/PPU regs are.
pagefault
ZSNES Developer
ZSNES Developer
Posts: 812
Joined: Tue Aug 17, 2004 5:24 am
Location: In your garden

Post by pagefault »

Nach wrote:
byuusan wrote:It would seem ZSNES 1.42 still clears WRAM to 0x55 upon power-on. I guess BS games are special cased to reset WRAM to 0xff?
That is correct.

BTW, have you tried this game on your copier and tested reset?
This is interesting. Perhaps the BSX bios resets the WRAM to this state when it starts a new game.
byuu

Post by byuu »

This is interesting. Perhaps the BSX bios resets the WRAM to this state when it starts a new game.
Very possible. I have no way to confirm or deny this. A lot of copier BIOS' do the same thing (which is probably to hide their presence from copy protection code).
Best bet would be to take a look at a disassembly of the BSX BIOS, or a trace log as it loads a game to start. But I don't think any emulators can emulate the BIOS that far yet.
BTW, have you tried this game on your copier and tested reset?
It works on my Super UFO 8.3j, no sound distortion at reset. I am using the US/non-BS version of the game.
Overload
Hazed
Posts: 70
Joined: Sat Sep 18, 2004 12:47 am
Location: Australia
Contact:

Post by Overload »

byuusan wrote: Please note that I have absolutely no idea if a real SNES does this or not, but it does work for this game. Perhaps you can make a WIP and have people test it thoroughly? Or can someone who's good with the SPC700 confirm/deny SPCRAM not getting clear upon reset? Note that I didn't try clearing DSP regs or not, since this seemed to work. It seems logical that registers would be cleared, and RAM not; just like the CPU RAM/PPU regs are.
SPCRAM isn't initialized on reset.
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

I had ZSNES not init SPCRAM on reset, and I'm still getting the sound problem. There might be code somewhere else not doing what it should...
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
byuu

Post by byuu »

Hmm, have you tried the ZSTs I posted? All that does is copy the SPCRAM over from an in-game save state at reset, and it seems to work fine for me... are you still re-enabling the IPL ROM and setting the SPC700 PC register to it?
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

I haven't tried your ZST.

What I did was remove the set of memset()'s on SPC RAM, and tried removing some pointer magic being done to it which I didn't follow anyway.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
Dreamer_Nom
Rookie
Posts: 12
Joined: Sun Sep 05, 2004 1:06 am

Satellaview

Post by Dreamer_Nom »

[quote]
Best bet would be to take a look at a disassembly of the BSX BIOS, or a trace log as it loads a game to start. But I don't think any emulators can emulate the BIOS that far yet.[/quote]

http://sourceforge.net/tracker/index.ph ... p_id=19677
Nightcrawler
Romhacking God
Posts: 922
Joined: Wed Jul 28, 2004 11:27 pm
Contact:

Post by Nightcrawler »

Byuu:

Have you taken a look at THIS yet?

http://geigercount.net/crypt/gsd00.png


You can downoad it here:

http://geigercount.net/crypt/

Evil Peer has recently done an overhaul to his 'tracer'. It's now a full featured kick ass debugger. It's now 'Geiger's SNES9x debugger'. Definitely worth a look for the type of things you're doing.
[url=http://transcorp.romhacking.net]TransCorp[/url] - Home of the Dual Orb 2, Cho Mahou Tairyku Wozz, and Emerald Dragon SFC/SNES translations.
[url=http://www.romhacking.net]ROMhacking.net[/url] - The central hub of the ROM hacking community.
byuu

Post by byuu »

Byuu:

Have you taken a look at THIS yet?

http://geigercount.net/crypt/gsd00.png
First time I've seen it. He definately has the advantage of using a much faster and more compatible emulator as a base. I think mine looks better, though. I'm planning to add a lot more to the debugger, I just wanted to get a good portion of games running first. The biggest problem is going to be what gets added, and what doesn't. As there isn't infinite screen space, I can never add all the ideas I want.

Still, I love "competition". Hopefully me and Evil Peer can share ideas to make the best debugger possible.
Nightcrawler
Romhacking God
Posts: 922
Joined: Wed Jul 28, 2004 11:27 pm
Contact:

Post by Nightcrawler »

Hey.. after years of having fairly crappy SNES debuggers, having *TWO GOOD* ones is a godsend! :)
[url=http://transcorp.romhacking.net]TransCorp[/url] - Home of the Dual Orb 2, Cho Mahou Tairyku Wozz, and Emerald Dragon SFC/SNES translations.
[url=http://www.romhacking.net]ROMhacking.net[/url] - The central hub of the ROM hacking community.
OptiRoc
Rookie
Posts: 18
Joined: Mon Jan 10, 2005 12:31 am

Post by OptiRoc »

Don't forget Super Sleuth. Comes closer to the timing of a real SNES than any other emulator right now, as well as providing the cleanest code tracer. I gotta send Overload those thanks+suggestions soon! :)
Post Reply