Tricky behaviour reference

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 !

Tricky behaviour reference

Post by grinvader »

Here's a place where I'd like anyone with the knowledge and time to do it to note down the names of ROMs that don't work right if you don't emulate specific points precisely.

It is vague on purpose, so that anything can be stored - from incorrect mirroring to dma sync delays, oam invalidation and bg horizontal scroll registers updating.

There's no hurry, but eventually noting down every little thing will help. The more obscure the better, obviously.

As to the info itself, something like this is probably enough:
specific point to emulate precisely:
- rom name 1 - brief description of what part of the game demands it
- rom name 2 - brief description of what part of the game demands it
...
Thanks for participating.
皆黙って俺について来い!!

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 »

You really should have started this thread five years ago :P
I wish I had kept track of such things, myself.

Super Conflict: sprites at exactly X=256 count all tiles in range-tile over. Without this emulated, the title screen is missing one of the name tiles.
grinvader
ZSNES Shake Shake Prinny
Posts: 5632
Joined: Wed Jul 28, 2004 4:15 pm
Location: PAL50, dood !

Post by grinvader »

byuu wrote:You really should have started this thread five years ago :P
I wish I had kept track of such things, myself.
Yeah, but 5 years ago I was just trying to port chunks of asm into c and cpu stuff was wayyy over my face.

Anyway,

Writing to bg h scroll registers correctly: Theme park (iirc)
皆黙って俺について来い!!

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
Jonas Quinn
ZSNES Developer
ZSNES Developer
Posts: 115
Joined: Thu Jul 29, 2004 9:51 pm
Location: Germany

Post by Jonas Quinn »

Supporting OAM writes correctly (a word in the low table is only written on writes to the high byte): James Pond 3
grinvader
ZSNES Shake Shake Prinny
Posts: 5632
Joined: Wed Jul 28, 2004 4:15 pm
Location: PAL50, dood !

Post by grinvader »

Just scouring through bsnes' changelogs:

- initialise SRAM to 0xFF [stupid awful jr baseball game noone plays]

Some vague stuff that would be cool to rant about more in detail here:
- "corrected" HDMA processing [overhyped sport game that's not soccer '97 flickering]

hmm, need moar changelogs. Did anyone keep them ?
皆黙って俺について来い!!

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
tukuyomi
Rookie
Posts: 39
Joined: Mon Aug 02, 2004 5:14 am
Contact:

Post by tukuyomi »

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

Post by grinvader »

That ought to work. Thanks.
皆黙って俺について来い!!

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 »

- initialise SRAM to 0xFF [stupid awful jr baseball game noone plays]
Keep in mind that Powerslide FX only works if SRAM is initialized to 0x00, and one of KGJ Baseball's modes only work with 0xFF. Maybe Nach can find something in the headers to generate the correct value.
- "corrected" HDMA processing [overhyped sport game that's not soccer '97 flickering]
Bug in my code. Both DMA and HDMA have that CPU sync + DMA sync thing going on, but not when HDMA occurs inside DMA. When you trigger HDMA really close to DMA, I had HDMA calling cycle_edge() that would start the DMA, and then DMA would call the HDMA again while the previous HDMA didn't complete. Only happens when you report CPU revision 2, as this game actually includes a CPUr1 non-DMA transfer to work around the real CPUr1 hardware crash.

Fix was easy, don't call the cycle_edge() event from inside HDMA, so that if there's a one-cycle wait for DMA, it won't trigger.
Rashidi
Trooper
Posts: 515
Joined: Fri Aug 18, 2006 2:45 pm

Post by Rashidi »

byuu wrote:
- initialise SRAM to 0xFF [stupid awful jr baseball game noone plays]
Keep in mind that Powerslide FX only works if SRAM is initialized to 0x00, and one of KGJ Baseball's modes only work with 0xFF. Maybe Nach can find something in the headers to generate the correct value..
wait, does that mean certain cartridge was equiped with mechanism that would (re-)initialize the SRAM when battery was replaced ?
grinvader
ZSNES Shake Shake Prinny
Posts: 5632
Joined: Wed Jul 28, 2004 4:15 pm
Location: PAL50, dood !

Post by grinvader »

byuu wrote:
- initialise SRAM to 0xFF [stupid awful jr baseball game noone plays]
Keep in mind that Powerslide FX only works if SRAM is initialized to 0x00, and one of KGJ Baseball's modes only work with 0xFF. Maybe Nach can find something in the headers to generate the correct value.
Geh. Hmm.
I'd think it would be more interesting to see which bytes each game expects to be 00 or FF and fill the sram with the corresponding pattern (if any).
皆黙って俺について来い!!

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
creaothceann
Seen it all
Posts: 2302
Joined: Mon Jan 03, 2005 5:04 pm
Location: Germany
Contact:

Post by creaothceann »

Rashidi wrote:
byuu wrote:
- initialise SRAM to 0xFF [stupid awful jr baseball game noone plays]
Keep in mind that Powerslide FX only works if SRAM is initialized to 0x00, and one of KGJ Baseball's modes only work with 0xFF. Maybe Nach can find something in the headers to generate the correct value..
wait, does that mean certain cartridge was equiped with mechanism that would (re-)initialize the SRAM when battery was replaced ?
Carts might have been released with the SRAM already set to FF, and replacing the battery wasn't taken into account.
vSNES | Delphi 10 BPLs
bsnes launcher with recent files list
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

This was brought up long ago in Snes9x development, and I also pointed out to several other people in the past few years, yet no one seemed to pay attention.

Different SRAM chips have different initial values. Not necessarily even a straight fill of just a particular value either, but a pattern of some sort.

Some game designers stupidly depended on the initial value, there's more Japanese only games with this problem than there are multi country games that exhibit this problem.

Snes9x has a list of game specific hacks to handle cases like this. The Snes9x Japanese developer hacks (UOSNES and the like) have even more game specific hacks to correct initial SRAM.

To really solve the problem, we'd need to get a list of which carts shipped with which SRAM (make and model).

I kind of doubt such info is in any way reflected in the header of a ROM image. I also can't really do any research on the subject without a better list of which carts came uniquely with which SRAM - and depended on it.
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 suggested that we distribute games with pre-initialized empty SRAM files known to work, and have tools like NSRT offer to generate them from a database. Free emulators from having to deal with it.

I would love a list of these games and the values needed, as many people keep insisting 0xFF is good enough, which is very annoying.

By the way Nach, I haven't seen you on AIM, so I'll post this here in case you missed it.

Image
(4-player Bomberman 2 with SNES multi-tap)

http://byuu.org/images/bs_345.png
http://byuu.org/images/bs_346.png
http://byuu.org/images/bs_347.png
http://byuu.org/images/bs_348.png

If you'd like, I can help get this merged into ZSNES. Only requires about ~2kb of code to link to my SGB+gambatte dynamic link library.
Rashidi
Trooper
Posts: 515
Joined: Fri Aug 18, 2006 2:45 pm

Post by Rashidi »

byuu wrote:I suggested that we distribute games ...
:lol:
byuu wrote: ... with pre-initialized empty SRAM files known to work, and have tools like NSRT offer to generate them from a database. Free emulators from having to deal with it.
i know you hate game-specific hacks on your emulator,
not everyone is NSRT savvy you know[size=0], well they should but some were totaly inept about it[/size].
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

Rashidi wrote:i know you hate game-specific hacks on your emulator,
not everyone is NSRT savvy you know[size=0], well they should but some were totaly inept about it[/size].
I hate game specific in anything.

I also don't have any game specific junk in NSRT either, and I'd like to keep it that way.

The only viable solution I can see right now without a ton of research is an SRAM DB, something which I really want to avoid.
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 wonder if the PCB IDs correlate, or if they tend to swap out SRAM chips on them. That would be pretty tacky to have two identical PCBs, where one game expects 0x00 SRAM and another 0xFF SRAM.

Rashidi, you know what I mean. Of course we have no influence over those sites anyway, as evidenced by the thousands of hacked up, header-variant games those sites tend to list so that "OMG WE HAVE THE MOST l33t warez RAWMz!!!1"
grinvader
ZSNES Shake Shake Prinny
Posts: 5632
Joined: Wed Jul 28, 2004 4:15 pm
Location: PAL50, dood !

Post by grinvader »

Nach wrote:I also don't have any game specific junk in NSRT either, and I'd like to keep it that way.
Before someone smartasses "wat aboot nsrt -fixable, lawl", mind the use of 'junk' in that sentence. ^^
byuu wrote:THE MOST l33t warez RAWMz!!!1"
Obviously, you meant teh moist RAWMZ !①!!
皆黙って俺について来い!!

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 »

byuu wrote:I wonder if the PCB IDs correlate, or if they tend to swap out SRAM chips on them. That would be pretty tacky to have two identical PCBs, where one game expects 0x00 SRAM and another 0xFF SRAM.
They don't.
If you remember this is why I told you PCB ID is simply not enough, and the PCB ID itself can be generated 99% accurately, and the other 1% accurate enough.

It's also why I told you to review the old proposal which covered all the needed cases.
grinvader wrote:
Nach wrote:I also don't have any game specific junk in NSRT either, and I'd like to keep it that way.
Before someone smartasses "wat aboot nsrt -fixable, lawl", mind the use of 'junk' in that sentence. ^^
Yes of course, that is indeed an exception which I felt was needed. Although I've been dumping entries from -fix as I realized over time those hacked dumps disappeared. It's certainly not something we're forced to keep.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
whicker
Trooper
Posts: 479
Joined: Sat Nov 27, 2004 4:33 am

Post by whicker »

byuu wrote:I wonder if the PCB IDs correlate, or if they tend to swap out SRAM chips on them. That would be pretty tacky to have two identical PCBs, where one game expects 0x00 SRAM and another 0xFF SRAM.
The SRAM doesn't do anything but store data. If you're saying that game 1 might expect a location to be FFh and game 2 expects it to be 00h, this is entirely possible.

1) system powers up
2) game code diddles the save-ram looking for whatever.
3) sees something it doesn't like.
4) re-initialize the battery RAM by writing default pattern to it.
5) halts.

6) confused person power cycles and starts up game again.
7) game code diddles the save-ram looking for whatever.
8) if it sees something it doesn't like: go to step 4
9) title screen appears.


if the game is missing the code for step 4, to re-initialize the SRAM, however, there's nothing an emulator author can do, except write a hack or distribute the initialized .SRM with the game like those in this thread are saying.

This is strictly a game-code issue. The only hardware issue is mapping. If the code for step #4 writes to mirrored addresses that ultimately go to the same SRAM cells as step #2 or #7, and you're not correctly emulating that, then the game will exhibit the lock-up symptoms as well.

The tenuous point is, if step #4 is buggy, and doesn't even work on the real cartridge, would it be ethical to issue a patch and bump up the revision number?
Rashidi
Trooper
Posts: 515
Joined: Fri Aug 18, 2006 2:45 pm

Post by Rashidi »

whicker wrote:The tenuous point is, if step #4 is buggy, and doesn't even work on the real cartridge, would it be ethical to issue a patch and bump up the revision number?
well, some just want to keep their rom(z) collection 'clean', myself included.

surely, we don't want to invokes any new "[f]" on good-xxx would you?
franpa
Gecko snack
Posts: 2374
Joined: Sun Aug 21, 2005 11:06 am
Location: Australia, QLD
Contact:

Post by franpa »

I doubt anyone would care really (except noobs). Good-sets already contain a lot of crap so adding more shouldn't matter to anyone.
Core i7 920 @ 2.66GHZ | ASUS P6T Motherboard | 8GB DDR3 1600 RAM | Gigabyte Geforce 760 4GB | Windows 10 Pro x64
paulguy
Zealot
Posts: 1076
Joined: Sat Jul 02, 2005 2:01 am
Contact:

Post by paulguy »

I'd likely more go for the game specific .srm files as a separate downloadable set apart from the emulators. It keeps the emulators from having game specific stuff, and lets people play their games and avoids the absolutely horrible possibility of hacked up "fixed" ROMs.
grinvader
ZSNES Shake Shake Prinny
Posts: 5632
Joined: Wed Jul 28, 2004 4:15 pm
Location: PAL50, dood !

Post by grinvader »

Speedy gonzales green button thingie:

cycle edge open bus reset to 0 during h/dma.

[i'm not exactly against relevant posts, so i'll keep yours ↓]
Last edited by grinvader on Fri Mar 26, 2010 7:25 am, edited 1 time in total.
皆黙って俺について来い!!

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 »

Verified that the Speedy Gonzales thing is actually DMA and HDMA updating the MDR, not NMI as first suspected.

http://byuu.org/temp/test_mdrhdma.zip

It brings up entirely new problems by exposing that HDMA is asserting MDR after an opcode's read cycle from which the HDMA triggers; which is going to require a ground-up rethink of the MDR and HDMA sync subsystems. But anyway for right now, even without that, just let H/DMA update the MDR and Speedy will work.

grinvader, if you don't mind, go ahead and delete this post and update yours. The test ROM won't be up for long anyway.
Post Reply