A small article regarding ZSNES

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

byuu

A small article regarding ZSNES

Post by byuu »

First and foremost, this seems like the correct forum as this is related to the current and possibly future development of ZSNES; as well as related to other SNES emulators in general. If not, my bad.

I've written a small article detailing a semi-significant problem that is encountered with all present SNES emulators. I'm only posting the link here as Nightcrawler asked permission to do so, and I wanted to say some things beforehand.

The topic is the limitations encountered on real systems (ex: writing to VRAM outside of VBlank), their lack of appearance in emulators, and the mission statements of various authors. It is geared towards ZSNES primarily because it is the emulator I am most knowledgeable in, I am not targeting it explicitly.

As with any opinion piece, I expect it to upset many people whom will probably resort to personal attacks and such. I'm not going to bother defending myself on this article, so I'd just like to say this in advance.

The article is just a general observation me and a few of my colleagues have noticed. It is not making any accusations, merely raising questions. It has avoided being overly technical so that everyone could read it. I try and minimize the term 'ZSNES', because the purpose of the article applies to all emulation, not just ZSNES, and not just the SNES. I've tried to be fair, and cover all sides of this story. I've mentioned all the people I know about who are working on these issues, and all exceptions that I am aware of. I'm sure I've missed some things, as well. I'd be happy to followup the article if my information is incorrect, or missing key points. But ultimately, I'm still pointing out flaws in other peoples' free works, so it's bound to be taken offensively by others. I know how this feels firsthand, as I have been on the receiving end before. I'm not saying that anyone should have to fix anything I've mentioned, and I'm not saying I'm ungrateful for the amazing work anyone has done so far. We are very fortunate to have ZSNES and other SNES emulators at all. Lastly, the article has been proofread by Mr. D per the standards of articles on the2d.com, so it is not all 1:1 my exact wording. Some of the messages may be slightly misconveyed from my intentions. With that said, I apologize in advance to anyone I've offended with this article. I am also willing to work with you all on the issues I've raised. If you would like a more technical explanation of any of the bugs I've encountered, I'd be happy to work with you in seeing them fixed. Send me a message at: byuusdropbox@yahoo.com

Without further ado, the article in question: http://www.the2d.com/content/view/125/29/
Last edited by byuu on Wed Oct 13, 2004 3:26 am, edited 2 times in total.
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

Nice article, but quite a few things represented incorrectly.

Many limitations are not present in emulators because the developers don't know about them. A lot of the research is done by seeing what fails and what can correct the problem, if not emulating something doesn't cause some code to fail, chances are if will never be emulated.

Dark Force's BL patch for real hardware also runs on ZSNES. The reason why Dark Force made a special patch for ZSNES was so that certain areas with slow downs can be played faster in an emulator by using certain shortcuts that won't work on real hardware.

The SPC7110 and S-DD1 did not have encrypted graphics, they had compressed graphics. The chips also did more than decompression.

Just having packs is nowhere what is required to get an SPC7110 game running. Look at MDH and SPL4, we have packs for them, ZSNES can't run them anyway. Read this thread http://www.snes9x.com/forum/topic.asp?A ... IC_ID=4848 to see just how must research, work, and effort was required to get the SPC7110 anywhere near working despite having packs.

Your statement about Snes9x not decompressing S-DD1 till months after Andreas Naive figured out the decompression algorithm is very far from the truth. Snes9x had real time S-DD1 compression several days before Andreas Naive made his code and findings public.
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 »

Thanks, I'll correct this information as soon as I can. As far as I know with the S-DD1, Matthew Kendora added his code into SNES9x, but it was not released to the public for several months after the fact. Nonetheless I will correct this as well. I knew about the S-DD1 / SPC7110, too. This must have slipped past me in the editing phase...

I figured the VRAM write outside of VBlank was the most critical of all, and pretty well known. As for the other issues, would you like me to make sample code and ROMs that demonstrate the problems, and maybe we can figure out what's going on from there? I understand if you're busy on other things.
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:As far as I know with the S-DD1, Matthew Kendora added his code into SNES9x, but it was not released to the public for several months after the fact.
Hey give credit were credit is due, anomie rewrote S-DD1 decompression making it much faster immediatly after Andreas Naive gave the other Snes9x devlopers code privately. The Dumper and Andreas were also working on this for a while prior, and others such as neviksti, Lord Nightmare and myself all gave it a go. You can't expect every new feature to require an immediate release, we have our own time tables which require all the new code to be polished and tested. As such, we shouldn't be put into a bad light for not releasing what we had till a few months later. We did announce we had it implemented within a week however.
byuusan wrote: I figured the VRAM write outside of VBlank was the most critical of all, and pretty well known. As for the other issues, would you like me to make sample code and ROMs that demonstrate the problems, and maybe we can figure out what's going on from there? I understand if you're busy on other things.
I don't know so much what is and what is not well known at this point and couldn't really help you with that, as I'm not working on core emulation in any emulator. All I do is ROM loading code, dabble in some special chips, and work on the feature set.

Best to get in touch with pagefault, anomie, The Dumper, and Overload.
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 »

You can't expect every new feature to require an immediate release, we have our own time tables which require all the new code to be polished and tested.
Absolutely. My point was merely that it has been over a year now since ZSNES has received a public release, hence still no native S-DD1 in the official build. Not that you're under any obligation to go any faster.

I actually tried to figure out the S-DD1 as well using The Dumper's packs. Needless to say, I failed miserably. Andreas has some serious talent.

I've finished the above edits. Thanks again for your feedback, Nach.
Last edited by byuu on Wed Oct 13, 2004 3:57 am, edited 4 times in total.
Nightcrawler
Romhacking God
Posts: 922
Joined: Wed Jul 28, 2004 11:27 pm
Contact:

Post by Nightcrawler »

I'm interested to hear what Pagefault has to say about any of this.
[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.
neviksti
Lurker
Posts: 122
Joined: Thu Jul 29, 2004 6:15 am

Post by neviksti »

I am basically in agreement with you.
I started in SNES stuff to program the actual SNES. It was quickly apparent the emulators were not made for developers.
I've always seen it as this: The SNES emulators are to relive old games.

True, if the emulators were made accurate for developers, one would hope it should still be okay for games. Sadly, due to computer speeds ... often a choice was forced. If every possible glitch/side effect/limitation is emulated, the program will run too slow for gaming. (at least on my old computer it was, considering zsnes didn't even run full speed on all games)

I'd hope that computers are now fast enough that it can be done ... but at expense of the slower computers. Since I don't really use the emulators for gaming, I would prefer exactness over speed and one day computers will be fast enough for the gaming as well. It sounds like you feel the same way, obviously we're in the minority.

That's why I really like Overload's "Super Sleuth" ...
I see you mentioned it in your article. It's just been released publicly and is already better for developement (for my purposes anyway) and is improved constantly.

I see you mentioned SNEeSe.
I must admit I haven't tried it in a long while. I'll think I'll go check it out again :)
When you poll using the manual method, you get 1 bit from the register 12 times. The other 7 bits returned are of an undefined state. When most emulators poll, they return the top 7 bits as always being clear. If you don't set these 7 bits to zero before checking the status of the joypad, your program may end up thinking a button was pressed when it was not.
This is an open bus problem ... it's been researched quite a bit. You said Sleuth doesn't handle it correctly? Overload was one that looked into the open bus stuff. I guess he didn't have time to implement it yet.

As you mentioned...
This seems little to me compared to the "outside of VBlank or forced blank" writing to video registers problem (for some, H-Blank is okay as well). What you may not know, is there's a huge timing flaw as well. The SNES is actually halted during a significant portion of each scan line because it needs time to refresh it's DRAM memory. This was brought up awhile ago and probably isn't included yet (sorry, haven't checked).

I feel this is the cause of the "why does the SPC700 clock change?" problem. The SPC700 clock is constant and the SPC700 isn't stalled during this refresh time. This causes some emulated code communicating with the SPC to seem to need the SPC to run at different speeds to get the synching to work.

Often new snes programmers will write to me asking for help on info or problems in their code. Besides the problems already mentioned, many new programmers really have trouble letting go of multiplication and division and (over)use the console hardware for this (until they learn to let go a bit). Therefore, the fact that the emulators don't enforce the "you must wait x cycles for the hardware multiplier/divider to finish" is a problem ran into often.


Oh, wow, I just noticed you mentioned me. I'm flattered.
Anomie and Overload also work closely with the real hardware as well. (among others)

...

It still bothers me that Nach doesn't even own a SNES, prefers it that way, and looks to software before hardware. I'm not saying Nach's work isn't appreciated. But like byuu seems to be saying, the emulation seems to be approached differently that developers would wish for.

Nothing wrong with that. We all do this for fun. And we all see fun in slightly different places :)

All that being said. I love ZSNES. I wish it well, and hope it lives long into the future.

EDIT: tons of spelling and gramatical errors
Last edited by neviksti on Tue Oct 12, 2004 8:36 pm, edited 5 times in total.
NoS Sr50
Rookie
Posts: 13
Joined: Thu Jul 29, 2004 5:58 am

Post by NoS Sr50 »

Wow way to nitpick
[b]Contact[/b]

[AIM] NOS SR50
[EMAIL] nossr50@gmail.com
illegal eagle
Savestate Pimp
Posts: 129
Joined: Thu Jul 29, 2004 2:15 pm
Contact:

Post by illegal eagle »

It's only nitpicking to those who are not affected.
"Other people can give you more suggestions as I just lost all my motivation to respond further to this post."
[i] - Nightcrawler[/i]

[url=http://www.geocities.com/illegal_eagle_2003/]vSNES v2.00[/url]: My SNES savestate viewer.
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

neviksti wrote: It still bothers me that Nach doesn't even own a SNES,
I had an SNES when I was younger, till my siblings made sure it no longer worked :cry:
neviksti wrote: prefers it that way,
I really have no need for an SNES anymore.
I have all my SNES games on my PC and can play them in an emulator and get more features than on the SNES I once had.

Today, I can easily go and buy another SNES on eBay or whatever, but really, what for? I need more stuff lying around? I don't play games that much anymore anyway.
neviksti wrote: and looks to software before hardware.
I'm a programmer, write software, manipulate software, think software, dream software...
I just see hardware as something that runs software.
neviksti wrote: I'm not saying Nach's work isn't appreciated.
I hope it's appreciated :(
neviksti wrote: But like byuu seems to be saying, the emulation seems to be approached differently that developers would wish for.
This dev actually wishes for what the doc is basically trying to suggest emulators should be. I approach emulation with doing what I am capable of doing. If someone would want to help me get started with working on core stuff and write me docs on how to do things correctly, I would. anomie helped me get started with the C4 and gave me a decent doc and C++ code, and I fixed up the x86 C4 to some extent. Help me the same with other stuff with the SNES, and I will try to do the same as I did with that.
neviksti wrote: Nothing wrong with that.
Don't misinterpet what some of us want though ;)
neviksti wrote: We all do this for fun. And we all see fun in slightly different places :)
Very true.
neviksti wrote: All that being said. I love ZSNES. I wish it well, and hope it lives long into the future.

Me too, I love ZSNES so much I decided to do some of the lighter stuff on ZSNES so pagefault should not have to worry about it and spend more time where others are less capable.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
Nightcrawler
Romhacking God
Posts: 922
Joined: Wed Jul 28, 2004 11:27 pm
Contact:

Post by Nightcrawler »

Nach, I think you're generally excluded from these comments and/or being responsible for this. You're part in ZSNES has not included any of the things mentioned in the article.
Last edited by Nightcrawler on Wed Oct 13, 2004 1:25 pm, edited 1 time in total.
[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.
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

Nightcrawler wrote:Nach, I think your generally excluded from these comments and/or being responsible for this. You're part in ZSNES has not included any of the things mentioned in the article.
Well, I have worked on the SPC7110 packs. But yeah, otherwise it doesn't really comment on what I do.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
neviksti
Lurker
Posts: 122
Joined: Thu Jul 29, 2004 6:15 am

Post by neviksti »

Nach wrote:If someone would want to help me get started with working on core stuff and write me docs on how to do things correctly, I would. anomie helped me get started with the C4 and gave me a decent doc and C++ code, and I fixed up the x86 C4 to some extent. Help me the same with other stuff with the SNES, and I will try to do the same as I did with that.
I can try to help explain stuff.
The register access limitation is well documented, so if you still have questions about that, just let me know.

the standard register doc mentions it, if you don't have it already, you can grab it here ...
http://members.tripod.com/FDwR/docs/snesmap.txt

also some info here - http://cgfm2.emuviews.com/
(The doc says not to direct link it, so just click through.)

The big timing problem I mentioned above, specifics are so old I had to find them on the closed snes9x board :)

http://www.snes9x.com/forum/topic.asp?TOPIC_ID=7703
it's buried, so I'll just quote:
"Neill mentioned that the system is frozen for 40 master cycles each scanline, beginning at dot 128, at least for a NTSC system."

more info here
http://www.snes9x.com/forum/topic.asp?TOPIC_ID=8854

Here's general timing info that I'm not sure got implemented correctly yet
http://www.snes9x.com/forum/topic.asp?TOPIC_ID=7832


I'm having trouble finding Neill's doc.
I probably have a copy around here somewhere but I can't seem to locate it. Anyone have a working link?
Overload
Hazed
Posts: 70
Joined: Sat Sep 18, 2004 12:47 am
Location: Australia
Contact:

Post by Overload »

neviksti wrote:
When you poll using the manual method, you get 1 bit from the register 12 times. The other 7 bits returned are of an undefined state. When most emulators poll, they return the top 7 bits as always being clear. If you don't set these 7 bits to zero before checking the status of the joypad, your program may end up thinking a button was pressed when it was not.
This is an open bus problem ... it's been researched quite a bit. You said Sleuth doesn't handle it correctly? Overload was one that looked into the open bus stuff. I guess he didn't have time to implement it yet.
For registers $4016, $4017 all bits are defined. Bits 2-7 of $4016 are in fact Open Bus, Bits 0-1 contain the serial data for Joy0 and Joy3. Bits 5-7 of $4017 are Open Bus, Bits 2-4 are always set (1), Bits 0-1 contain the serial data for Joy2 and Joy4. All of this is implemented in my emulator.
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

neviksti wrote:
Nach wrote:If someone would want to help me get started with working on core stuff and write me docs on how to do things correctly, I would. anomie helped me get started with the C4 and gave me a decent doc and C++ code, and I fixed up the x86 C4 to some extent. Help me the same with other stuff with the SNES, and I will try to do the same as I did with that.
I can try to help explain stuff.
The register access limitation is well documented, so if you still have questions about that, just let me know.
That's still way over my head, and way too overwhelming and this point :S

Need an idea where to start in ZSNES, info on what is emulaed already and what needs fixing. I don't know what a lot of the lingo is either.

If you pointed out something specific (ex: such as look in execute.asm for Op 867) and not too difficult (ex: Fix a mask), I would work on that, and start to get a feeling from there what I'm dealing with.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
neviksti
Lurker
Posts: 122
Joined: Thu Jul 29, 2004 6:15 am

Post by neviksti »

So what was the complaint he had about Super Sleuth?
Rereading it, I'm still not sure.

Anyway..
Another frustrating problem is how all current SNES emulators handle the JSL command (Jump to Subroutine Long), a code to hop from one area of a program to another.

On an actual SNES, if this is the first code in your program and it switches banks, the program will die and cease to play after returning from the routine. It will only work after you press the reset button.
Actually, the system starts up in "emulated" mode. Therefore the stack pointer is set to somewhere in $01xx. This happens to be WRAM on the SNES. Therefore stack operations will work okay. Are you sure JSL fails here?

I see no reason to believe so.

What does changing banks have to do with anything? The stack is always accessed from bank $00.
Am I misunderstanding your meaning here? Sorry.
byuu

Post by byuu »

For registers $4016, $4017 all bits are defined. Bits 2-7 of $4016 are in fact Open Bus, Bits 0-1 contain the serial data for Joy0 and Joy3. Bits 5-7 of $4017 are Open Bus, Bits 2-4 are always set (1), Bits 0-1 contain the serial data for Joy2 and Joy4. All of this is implemented in my emulator.
Ah, I haven't actually tested Super Sleuth out myself. I only really use ZSNES, I've grown way too attached to the debugger. Mr. D went through and tried out our Tekkaman Blade translation on your emulator, as well as Snes9x. Basically, they would all play the game right. But on the SNES, it failed. I had assumed since ZSNES returns bits 7-3 as always being clear, and because qwerty's doc doesn't even mention this, that I didn't need to mask the bits. I just did 12 adc $4016's to see if any buttons were pressed. I'm only sure that he tried the automatic polling method I used first ($4218, etc.) For some reason, it doesn't always return that the button is pressed down on a real SNES, even if you have the button held down on the controller. I have a few ideas as to why this is, but I'm not sure. Overload, do you know if Super Sleuth gets much closer to the actual SNES timings? I always run into problems with running out of vblank cycles, and stuff doesn't get drawn on my copier. I've been meaning to give it a try for a while now.

neviksti: Let me give you an example, get a hold of any commercial game. For example I'll use Der Langrisser. The rom begins execution at $8000, then jmp's to $8020. Once here, is the code: cld : sei : clc : xce.
Overwrite these four opcodes with: jsl $408000.
Now go to the end of the rom (DL is 2mb), and add in the code: cld : sei : clc : xce : rtl

As an asm file:
---
org $008020 : jsl test
org $408000
test:
cld : sei : clc : xce
rtl
---

When you load this ROM up in any emulator, it will play fine. But if you load it up on your copier (I have a Super UFO 8.3j in case this turns out to be a copier issue), it will take the jsl, but when it hits the rtl, it just dies. Hence, my splash screens showed up on the screen, but when they finished, the game wouldn't start. Oddly enough, if you reset the game, it will then work. But it happens every time I load the game for the first run. I figure it may be a UFO issue, but what could it be? If the UFO is failing to initialize something, or setting some information wrong, then surely it would break some commercial games. I've never heard of that being the case before.
neviksti
Lurker
Posts: 122
Joined: Thu Jul 29, 2004 6:15 am

Post by neviksti »

byuusan wrote:I'm only sure that he tried the automatic polling method I used first ($4218, etc.) For some reason, it doesn't always return that the button is pressed down on a real SNES, even if you have the button held down on the controller.
Hmm... strange.

Are you remembering to wait for the SNES hardware to read the serial data in, such as looking at reg $4212 bit0? ... I don't remember which value means its done (0 I believe), is it possible you're waiting for the wrong value?

I haven't really had problems with this on a real SNES, so I'm not sure.

EDIT: [ Oh, I vaguely remember once that I needed to wait a few cycles after vblank before checking if the serial read was done. Because the reading didn't start until a little into it and therefore my "wait till it's done" loop just waltzed on by. I don't remember being fully convinced of this interpretation of the problem at the time though.]

I ran into an issue once where the auto-joyread didn't work in zsnes unless I enabled NMI. I haven't checked if this is fixed now. Is this what you meant?

byuusan wrote:Oddly enough, if you reset the game, it will then work. But it happens every time I load the game for the first run. I figure it may be a UFO issue, but what could it be? If the UFO is failing to initialize something, or setting some information wrong, then surely it would break some commercial games. I've never heard of that being the case before.
This is just an educated guess, but:
- the copier BIOS is running and like most SNES programs runs in "normal" mode and has the stack around $1Fxx
- the copier loads up a game and attempts to put SNES "back to power-on state" by turning off screen, etc.
- in this process it probably sets the "emulation bit"
- then it runs your program

If the stack happens to be $xx02, $xx01, or $xx00 before JSL. That will result in an error after clearing the emulation bit and trying to return.

Since all comercial programs should setup the stack before using it, I believe this would explain all the details you noticed.

Can you run a quick test where the program saves the stack value on initial load from the copier, and then prints it to the screen? (Or just write to SRAM or whatever is easier with your setup.)
Last edited by neviksti on Wed Oct 13, 2004 5:05 am, edited 1 time in total.
byuu

Post by byuu »

Yes I can. I'm going out to eat dinner. I'll make a small program to get all the default states of registers and print them to the screen. I'll have the results in a few hours with any luck.

As for $4212, no I didn't do that. I realized that was probably my problem, but ZSNES allows you to read from $4218 regardless of the state of $4212. All of the problems I've mentioned were my own fault for not doing things properly. >_<
Overload
Hazed
Posts: 70
Joined: Sat Sep 18, 2004 12:47 am
Location: Australia
Contact:

Post by Overload »

I was curious so I wrote a little test program, a little while ago.

http://users.tpg.com.au/trauma/temp/emode.zip

It's interesting to notice that none of the registers are changed when the reset button is pressed, so the stack is decremented progressively each time the reset button is pressed.

As far as timing goes Super Sleuth is a little faster than the SNES. But I'm sure i haven't added timing for HDMA and the pause in execution that Neviksti mentioned earlier. It is guilty of letting in VRAM writes during the drawing period though.
byuu

Post by byuu »

Bingo. Overload is correct.
I wrote this before I checked here...
http://setsuna.the2d.com/files/intro.zip
Included files:
- intro.asm - Source in xkas format
- font8.bin - Simple 2bpp font
- font.tbl - Table for font8.bin / xkas
- intro.smc - ROM image with no header
- INTRO.FIG - ROM image with header for UFO8 created by InSnest.
- xkas.exe - Cross-assembler
- as.bat - Batch to assemble intro.smc

I started off by setting the system to native mode (clc : xce), I then set the processor m and x flags to zero. I then stored A, X, Y, the stack pointer, and a word in memory ($7ec000) into RAM. I then initialized the SNES, and wrote these variables to the screen. After this, I set A to 0xDEAD, X to 0xBEEF, Y to 0x0123, pushed one byte onto the stack (decrementing it by one), and finally incremented $7ec000 by one. Then I locked the system in a loop with no interrupts enabled.

Here are the results in ZSNES on every run. Resetting has no effect on the displayed numbers.
A:0000 X:0000 Y:0000 S:01FF
MEM.7EC000:5555

However, here are my results running the same ROM on my Super UFO 8.3j copier:

Power-on:
A:0000 X:0000 Y:0000 S:0100
MEM.7EC000:0000
Reset 1:
A:DEAD X:00EF Y:0023 S:01FC
MEM.7EC000:0001
Reset 2:
A:DEAD X:00EF Y:0023 S:01F8
MEM.7EC000:0002

What I'm noticing is that all registers keep the states they had when the SNES is reset, HOWEVER, since p.m/p.x get set back to 1, the high 8-bits of x and y are cleared. The stack starts off at 0100, which may be a bug in the UFO. I've always believed it started as 01FF. Is it possible it's really supposed to be 0100? Memory starts with 00's, at least in the 7EXXXX region. Resetting the SNES does not reset the memory back to its initial state. I might add that I also came across this issue with BS Zelda. ZSNES initializes memory to all 55's, which breaks the game. I was able to get it playable by taking a zst save immediately and setting the RAM back to 00's. I don't know if this is related or not. Lastly, the interesting thing is the stack pointer. I only pushed one byte onto the stack, so if it was holding a value, it would reset with 0100, then 01FF, then 01FE, etc. So I decided to do an additional test. This time, I didn't actually change the stack at all. In ZSNES, the program starts with SP:01FF, and hangs with SP:01FF.
Now, when I play the game on my UFO, each reset decrements the stack by 3.
Run 1: 0100, Run 2: 01FD, Run 3: 01FA, etc.

For the sake of emulation, I took 3 years life off my SNES and reset it ~80 times to see what happens. After 0101, it decrements by 3, and becomes: 01FE. So the high byte is always 01.

I figured those top 3 bytes getting pushed on the stack were the address of the program right before reset.

Here is the data, in word format that was on the stack. From left to right is: power on, reset 1, reset 2. More resets didn't affect anything.
01fc:0000,0000,8103
01fe:0000,0000,0000
0100:0000,0081,0081

Or in an array
power[0x01fc] = { 0x00, 0x00, 0x00, 0x00, 0x00 }
reset1[0x01fc] = { 0x00, 0x00, 0x00, 0x00, 0x81 }
reset2[0x01fc] = { 0x03, 0x81, 0x00, 0x00, 0x81 }

The program ends its execution at 00811f. So that's not correct.

I also set D and DB in a separate test to 0123, and 7e. Upon resetting, both registers are in fact reset to 0000 and 00.

Any ideas, anyone?
Last edited by byuu on Wed Oct 13, 2004 10:30 am, edited 8 times in total.
byuu

Post by byuu »

By the way, it -may- be possible that some games take advantage of this. Think about it like this: When the SNES first powers on, you check $7ffffe, if it's set to #$1337, then you know that the SNES was reset. If it's not, then you know the system was just powered on. Then you store #$1337 at $7ffffe. Now you can display, say, the company logos and all that junk upon powerup. But when you reset, rather than show all that again, you can just jump directly to the title screen. Just a thought...

Edit: I've figured out the problem now with the JSL thing. Neviksti is correct, since the stack starts at 0100 in emulation mode, my first JSL pushes the address to: 0100, 01ff, 01fe. I then switch to native mode in my routine, so when I go to issue rtl, it pulls the address from 0100, 00ff, 00fe. It works after reset because for whatever reason, the stack is decremented by 3 when the system is reset, so after one reset, a high-byte wraparound will not occur for approximately 80 more resets. The reason I couldn't initialize the stack or set native mode first, was because I needed to add in the jsl as soon as possible on top of the existing game. The solution was as I did: use a jml, set native mode, and then set the stack properly.

Is there any way to confirm that this is a problem with the UFO, and that the stack should be 01ff instead? I have serious doubts that a real SNES would initialize the stack to 0100. Maybe we can disassemble the UFO BIOS, if it's available?
Last edited by byuu on Wed Oct 13, 2004 1:42 pm, edited 1 time in total.
Nightcrawler
Romhacking God
Posts: 922
Joined: Wed Jul 28, 2004 11:27 pm
Contact:

Post by Nightcrawler »

I think it's been previously noted that there are several games which can detect that the SNES has been reset and not powered on. I forget which ones they are offhand though.
[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.
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

Nightcrawler wrote:I think it's been previously noted that there are several games which can detect that the SNES has been reset and not powered on. I forget which ones they are offhand though.
It's quite obvious that certain areas of memory are not reset when hitting the power button. If someone could find out which areas of memory are not cleared on reset, it should be pretty easy for me to have ZSNES follow that on 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 »

I'll do it. I realize I could've just used SRAM for this, but hey: this was more fun, and I get to try out using $4218/$4219 properly this time!

http://setsuna.the2d.com/files/reset.zip

I'm going to load it up on my UFO now and I'll document my findings here.
Post Reply