View unanswered posts | View active topics It is currently Tue Sep 17, 2019 2:58 am



Reply to topic  [ 24 posts ] 
Tricky behaviour reference 
Author Message
ZSNES Shake Shake Prinny
User avatar

Joined: Wed Jul 28, 2004 4:15 pm
Posts: 5615
Location: PAL50, dood !
Reply with quote
Post Tricky behaviour reference
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:
<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)

Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54


Thu Aug 20, 2009 12:39 am
Profile
Reply with quote
Post 
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.


Thu Aug 20, 2009 4:28 am
ZSNES Shake Shake Prinny
User avatar

Joined: Wed Jul 28, 2004 4:15 pm
Posts: 5615
Location: PAL50, dood !
Reply with quote
Post 
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:
<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)

Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54


Thu Aug 20, 2009 2:05 pm
Profile
ZSNES Developer
ZSNES Developer

Joined: Thu Jul 29, 2004 9:51 pm
Posts: 115
Location: Germany
Reply with quote
Post 
Supporting OAM writes correctly (a word in the low table is only written on writes to the high byte): James Pond 3


Thu Aug 20, 2009 3:28 pm
Profile
ZSNES Shake Shake Prinny
User avatar

Joined: Wed Jul 28, 2004 4:15 pm
Posts: 5615
Location: PAL50, dood !
Reply with quote
Post 
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:
<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)

Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54


Sat Oct 31, 2009 11:08 am
Profile
Rookie
User avatar

Joined: Mon Aug 02, 2004 5:14 am
Posts: 39
Reply with quote
Post 
More bsnes changelogs you ask?
http://snesemu.black-ship.net/misc/bsnes_changelog.txt


Sat Oct 31, 2009 11:12 am
Profile WWW
ZSNES Shake Shake Prinny
User avatar

Joined: Wed Jul 28, 2004 4:15 pm
Posts: 5615
Location: PAL50, dood !
Reply with quote
Post 
That ought to work. Thanks.

_________________
皆黙って俺について来い!!
Code:
<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)

Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54


Sat Oct 31, 2009 2:36 pm
Profile
Reply with quote
Post 
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.


Sat Oct 31, 2009 9:06 pm
Trooper
User avatar

Joined: Fri Aug 18, 2006 2:45 pm
Posts: 515
Reply with quote
Post 
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 ?


Sun Nov 01, 2009 2:47 am
Profile
ZSNES Shake Shake Prinny
User avatar

Joined: Wed Jul 28, 2004 4:15 pm
Posts: 5615
Location: PAL50, dood !
Reply with quote
Post 
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:
<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)

Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54


Sun Nov 01, 2009 3:40 am
Profile
Seen it all
User avatar

Joined: Mon Jan 03, 2005 5:04 pm
Posts: 2302
Location: Germany
Reply with quote
Post 
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 | Delphi 10 BPLs
bsnes launcher with recent files list


Sun Nov 01, 2009 4:55 pm
Profile WWW
ZSNES Developer
ZSNES Developer
User avatar

Joined: Tue Jul 27, 2004 10:54 pm
Posts: 3901
Location: Solar powered park bench
Reply with quote
Post 
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


Mon Nov 02, 2009 9:23 pm
Profile WWW
Reply with quote
Post 
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.


Mon Nov 02, 2009 10:17 pm
Trooper
User avatar

Joined: Fri Aug 18, 2006 2:45 pm
Posts: 515
Reply with quote
Post 
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].


Tue Nov 03, 2009 12:44 pm
Profile
ZSNES Developer
ZSNES Developer
User avatar

Joined: Tue Jul 27, 2004 10:54 pm
Posts: 3901
Location: Solar powered park bench
Reply with quote
Post 
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


Tue Nov 03, 2009 1:55 pm
Profile WWW
Reply with quote
Post 
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"


Tue Nov 03, 2009 7:42 pm
ZSNES Shake Shake Prinny
User avatar

Joined: Wed Jul 28, 2004 4:15 pm
Posts: 5615
Location: PAL50, dood !
Reply with quote
Post 
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:
<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)

Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54


Tue Nov 03, 2009 8:15 pm
Profile
ZSNES Developer
ZSNES Developer
User avatar

Joined: Tue Jul 27, 2004 10:54 pm
Posts: 3901
Location: Solar powered park bench
Reply with quote
Post 
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


Wed Nov 04, 2009 1:11 am
Profile WWW
Trooper

Joined: Sat Nov 27, 2004 4:33 am
Posts: 479
Reply with quote
Post 
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?


Wed Nov 04, 2009 6:45 am
Profile
Trooper
User avatar

Joined: Fri Aug 18, 2006 2:45 pm
Posts: 515
Reply with quote
Post 
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?


Wed Nov 04, 2009 1:40 pm
Profile
Gecko snack

Joined: Sun Aug 21, 2005 11:06 am
Posts: 2372
Location: Australia, QLD
Reply with quote
Post 
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


Wed Nov 04, 2009 2:04 pm
Profile WWW
Zealot
User avatar

Joined: Sat Jul 02, 2005 2:01 am
Posts: 1076
Reply with quote
Post 
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.


Wed Nov 04, 2009 3:52 pm
Profile WWW
ZSNES Shake Shake Prinny
User avatar

Joined: Wed Jul 28, 2004 4:15 pm
Posts: 5615
Location: PAL50, dood !
Reply with quote
Post 
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 ↓]

_________________
皆黙って俺について来い!!
Code:
<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)

Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54


Last edited by grinvader on Fri Mar 26, 2010 7:25 am, edited 1 time in total.



Thu Mar 25, 2010 11:00 pm
Profile
Reply with quote
Post 
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.


Fri Mar 26, 2010 6:31 am
Display posts from previous:  Sort by  
Reply to topic   [ 24 posts ] 

Who is online

Users browsing this forum: No registered users and 1 guest


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

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software.