ZSNES board Forum Index ZSNES board
ZSNES and other SNES related stuff
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Tricky behaviour reference

 
Post new topic   Reply to topic    ZSNES board Forum Index -> Development
View previous topic :: View next topic  
Author Message
grinvader
ZSNES Shake Shake Prinny


Joined: 28 Jul 2004
Posts: 16777215
Location: PAL50, dood !

PostPosted: Wed Aug 19, 2009 11:39 pm    Post subject: Tricky behaviour reference Reply with quote

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:
Quote:
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:
<grinvader> static const struct { const char *const name; void *const ptr; } const lbl24[]

Pantheon: Gideon Zhi | CaitSith2 | Nach
Back to top
View user's profile Send private message
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2488

PostPosted: Thu Aug 20, 2009 3:28 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Visit poster's website
grinvader
ZSNES Shake Shake Prinny


Joined: 28 Jul 2004
Posts: 16777215
Location: PAL50, dood !

PostPosted: Thu Aug 20, 2009 1:05 pm    Post subject: Reply with quote

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:
<grinvader> static const struct { const char *const name; void *const ptr; } const lbl24[]

Pantheon: Gideon Zhi | CaitSith2 | Nach
Back to top
View user's profile Send private message
Jonas Quinn
ZSNES Developer
ZSNES Developer


Joined: 29 Jul 2004
Posts: 121
Location: Germany

PostPosted: Thu Aug 20, 2009 2:28 pm    Post subject: Reply with quote

Supporting OAM writes correctly (a word in the low table is only written on writes to the high byte): James Pond 3
Back to top
View user's profile Send private message
grinvader
ZSNES Shake Shake Prinny


Joined: 28 Jul 2004
Posts: 16777215
Location: PAL50, dood !

PostPosted: Sat Oct 31, 2009 10:08 am    Post subject: Reply with quote

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:
<grinvader> static const struct { const char *const name; void *const ptr; } const lbl24[]

Pantheon: Gideon Zhi | CaitSith2 | Nach
Back to top
View user's profile Send private message
tukuyomi
Rookie


Joined: 02 Aug 2004
Posts: 35

PostPosted: Sat Oct 31, 2009 10:12 am    Post subject: Reply with quote

More bsnes changelogs you ask?
http://snesemu.black-ship.net/misc/bsnes_changelog.txt
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
grinvader
ZSNES Shake Shake Prinny


Joined: 28 Jul 2004
Posts: 16777215
Location: PAL50, dood !

PostPosted: Sat Oct 31, 2009 1:36 pm    Post subject: Reply with quote

That ought to work. Thanks.
_________________
皆黙って俺について来い!!
Code:
<grinvader> static const struct { const char *const name; void *const ptr; } const lbl24[]

Pantheon: Gideon Zhi | CaitSith2 | Nach
Back to top
View user's profile Send private message
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2488

PostPosted: Sat Oct 31, 2009 8:06 pm    Post subject: Reply with quote

Quote:
- 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.

Quote:
- "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.
Back to top
View user's profile Send private message Visit poster's website
Rashidi
Trooper


Joined: 18 Aug 2006
Posts: 354

PostPosted: Sun Nov 01, 2009 1:47 am    Post subject: Reply with quote

byuu wrote:
Quote:
- 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 ?
_________________
- classic / retro / old / etc.. (something similiar) are beter than the new one!

Support emulator!
Back to top
View user's profile Send private message
grinvader
ZSNES Shake Shake Prinny


Joined: 28 Jul 2004
Posts: 16777215
Location: PAL50, dood !

PostPosted: Sun Nov 01, 2009 2:40 am    Post subject: Reply with quote

byuu wrote:
Quote:
- 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:
<grinvader> static const struct { const char *const name; void *const ptr; } const lbl24[]

Pantheon: Gideon Zhi | CaitSith2 | Nach
Back to top
View user's profile Send private message
creaothceann
Seen it all


Joined: 03 Jan 2005
Posts: 2841
Location: Germany

PostPosted: Sun Nov 01, 2009 3:55 pm    Post subject: Reply with quote

Rashidi wrote:
byuu wrote:
Quote:
- 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
MKV to AVI
Back to top
View user's profile Send private message Visit poster's website
Nach
ZSNES Developer
ZSNES Developer


Joined: 27 Jul 2004
Posts: 4588
Location: Solar powered park bench

PostPosted: Mon Nov 02, 2009 8:23 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message Visit poster's website
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2488

PostPosted: Mon Nov 02, 2009 9:17 pm    Post subject: Reply with quote

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.


(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.
Back to top
View user's profile Send private message Visit poster's website
Rashidi
Trooper


Joined: 18 Aug 2006
Posts: 354

PostPosted: Tue Nov 03, 2009 11:44 am    Post subject: Reply with quote

byuu wrote:
I suggested that we distribute games ...
Laughing

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, well they should but some were totaly inept about it.
_________________
- classic / retro / old / etc.. (something similiar) are beter than the new one!

Support emulator!
Back to top
View user's profile Send private message
Nach
ZSNES Developer
ZSNES Developer


Joined: 27 Jul 2004
Posts: 4588
Location: Solar powered park bench

PostPosted: Tue Nov 03, 2009 12:55 pm    Post subject: Reply with quote

Rashidi wrote:
i know you hate game-specific hacks on your emulator,
not everyone is NSRT savvy you know, well they should but some were totaly inept about it.


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
Back to top
View user's profile Send private message Visit poster's website
byuu
bsnes Developer
bsnes Developer


Joined: 12 Oct 2004
Posts: 2488

PostPosted: Tue Nov 03, 2009 6:42 pm    Post subject: Reply with quote

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 ROMZ!!!1"
Back to top
View user's profile Send private message Visit poster's website
grinvader
ZSNES Shake Shake Prinny


Joined: 28 Jul 2004
Posts: 16777215
Location: PAL50, dood !

PostPosted: Tue Nov 03, 2009 7:15 pm    Post subject: Reply with quote

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 ROMZ!!!1"

Obviously, you meant teh moist RAWMZ !①!!
_________________
皆黙って俺について来い!!
Code:
<grinvader> static const struct { const char *const name; void *const ptr; } const lbl24[]

Pantheon: Gideon Zhi | CaitSith2 | Nach
Back to top
View user's profile Send private message
Nach
ZSNES Developer
ZSNES Developer


Joined: 27 Jul 2004
Posts: 4588
Location: Solar powered park bench

PostPosted: Wed Nov 04, 2009 12:11 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message Visit poster's website
whicker
Veteran


Joined: 27 Nov 2004
Posts: 709

PostPosted: Wed Nov 04, 2009 5:45 am    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
Rashidi
Trooper


Joined: 18 Aug 2006
Posts: 354

PostPosted: Wed Nov 04, 2009 12:40 pm    Post subject: Reply with quote

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?
_________________
- classic / retro / old / etc.. (something similiar) are beter than the new one!

Support emulator!
Back to top
View user's profile Send private message
franpa
Gecko snack


Joined: 21 Aug 2005
Posts: 2176
Location: Australia, Brisbane

PostPosted: Wed Nov 04, 2009 1:04 pm    Post subject: Reply with quote

I doubt anyone would care really (except noobs). Good-sets already contain a lot of crap so adding more shouldn't matter to anyone.
_________________
Core2 DUO e6750 @ 2.66GHZ, ASUS P5KC mb, 2 gig DDR2 800 RAM, 500g SATA2 HDD, X-FI Extreme Music, Nvidia Geforce 8800gt 512MB PCI-E, Windows Windows 7 RTM x64, Thermaltake 750watt Toughpower Power Supply, Thermaltake Armor+ MX case.
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
paulguy
Trooper


Joined: 02 Jul 2005
Posts: 449

PostPosted: Wed Nov 04, 2009 2:52 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    ZSNES board Forum Index -> Development All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group