bsnes v0.037a released

Archived bsnes development news, feature requests and bug reports. Forum is now located at http://board.byuu.org/
Locked
RedDwarf
Rookie
Posts: 37
Joined: Thu Jan 27, 2005 7:28 pm

Post by RedDwarf »

byuu wrote:I've no problems with this, so long as I'm consulted before any source code is changed. If you're patching something broken, I'd like to know so I can fix it, too.
Aparently now rpmlint (rpm checker) checks also the code¿? Well, in any case a new openSUSE package has been built with this patch:

Code: Select all

--- src/lib/nall/dictionary.hpp  
+++ src/lib/nall/dictionary.hpp  
@@ -52,6 +52,7 @@  
       index_input[n]  = part[0];  
       index_output[n] = part[1];  
     }  
+    return true;  
   }  
   
   void reset() {  
--- src/lib/ruby/input/sdl.cpp  
+++ src/lib/ruby/input/sdl.cpp  
@@ -97,6 +97,7 @@  
       XUngrabPointer(display, CurrentTime);  
       return mouseacquired = false;  
     }  
+    return true;  
   }  
   
   bool acquired() {  
--- src/lib/ruby/ruby.cpp  
+++ src/lib/ruby/ruby.cpp  
@@ -12,7 +12,7 @@  
 void VideoInterface::driver(const char *driver) {  
   if(p) term();  
   
-  if(driver == "") driver = default_driver();  
+  if(driver[0] == 0) driver = default_driver();  
   
   if(0);  
   
@@ -134,7 +134,7 @@  
 void AudioInterface::driver(const char *driver) {  
   if(p) term();  
   
-  if(driver == "") driver = default_driver();  
+  if(driver[0] == 0) driver = default_driver();  
   
   if(0);  
   
@@ -216,7 +216,7 @@  
 void InputInterface::driver(const char *driver) {  
   if(p) term();  
   
-  if(driver == "") driver = default_driver();  
+  if(driver[0] == 0) driver = default_driver();  
   
   if(0);  
   
  
 
I didn't made the patch, I don't really know what rpmlint was complaining about... but I suppose it will avoid some gcc warnings.
byuu

Re: Breath of fire 2 german translation

Post by byuu »

PiCiJi wrote:Breath of Fire 2 german trans doesn't work with 37a. The screen keeps black before playing the intro

game works in 35
It works, I always test that game before release (it has the most sensitive timing requirements of all SNES games.) Go to settings->configuration->advanced and reset smp.ntsc_clock_rate to the default value. It should become 24,607,488; restart the emu after that and it'll work. The config file is caching an older value.
RedDwarf wrote:Aparently now rpmlint (rpm checker) checks also the code¿? Well, in any case a new openSUSE package has been built with this patch:
Oops. Would be nice if GCC had a warning about missing return values. And the driver one is my mistake from using my string class too much. It really should be if(!driver || !*driver), but bsnes never passes it null strings, so it doesn't really matter here.
PiCiJi
New Member
Posts: 7
Joined: Fri Dec 30, 2005 11:42 pm

Post by PiCiJi »

byuu wrote:It works, I always test that game before release (it has the most sensitive timing requirements of all SNES games.) Go to settings->configuration->advanced and reset smp.ntsc_clock_rate to the default value. It should become 24,607,488; restart the emu after that and it'll work. The config file is caching an older value.
thank you, it works now
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

Wow, that's a huge problem. Good luck to the average user figuring that one out.

Here's a weird bug I discovered today. Try loading and then resetting the game "Super Buster Bros." and the much of the graphics in the game will disappear.
85cocoa
Hazed
Posts: 55
Joined: Sat Jul 22, 2006 8:43 pm
Location: USA

Post by 85cocoa »

FitzRoy wrote:Here's a weird bug I discovered today. Try loading and then resetting the game "Super Buster Bros." and the much of the graphics in the game will disappear.
This may need testing on real hardware. What is the full GoodSNES name of the ROM you are using? I seem to remember something similar happening in SNES9x, but only with the v1.0 ROM (not v1.1 - so perhaps this is a bug in the game code?).
[url=http://en.wikipedia.org/wiki/Pocky]Pocky[/url] & [url=http://en.wikipedia.org/wiki/Rocky]Rocky[/url]? [url=http://en.wikipedia.org/wiki/Pocky_%26_Rocky]Pocky & Rocky[/url]? [url=http://en.wikipedia.org/wiki/Sonic_the_Hedgehog_%28series%29#Animals.2FMobians]Pocky & Rocky[/url]?
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

85cocoa wrote:
FitzRoy wrote:Here's a weird bug I discovered today. Try loading and then resetting the game "Super Buster Bros." and the much of the graphics in the game will disappear.
This may need testing on real hardware. What is the full GoodSNES name of the ROM you are using? I seem to remember something similar happening in SNES9x, but only with the v1.0 ROM (not v1.1 - so perhaps this is a bug in the game code?).
Right you are, doesn't happen in v1.1. What an enormous cockup, how does something like that get past beta testing?

The game also uses hi-res mode for everything. Makes the pixels look blurry in bsnes point mode for no reason. The bug doesn't happen in zsnes, but I think zsnes' reset is actually a power cycle.
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

FitzRoy wrote:The bug doesn't happen in zsnes, but I think zsnes' reset is actually a power cycle.
It isn't.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
gllt
NO VOWELS >:[
Posts: 753
Joined: Sun Aug 31, 2008 12:59 pm
Location: ALABAMA
Contact:

Post by gllt »

Offtopic sort of, but its funny that we will all be looking to the these bsnes release threads being locked.

(If you don't know why, think for a moment.)
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

Nach wrote:
FitzRoy wrote:The bug doesn't happen in zsnes, but I think zsnes' reset is actually a power cycle.
It isn't.
Oh, so it just fails to emulate reset correctly.
ZH/Franky

Post by ZH/Franky »

gllt wrote:Offtopic sort of, but its funny that we will all be looking to the these bsnes release threads being locked.

(If you don't know why, think for a moment.)
Because a new version gets released? That's the pattern I see; one bsnes thread for a version, then a new version is released and a new thread created, with the other one being locked.

The big reason I suppose is from the lesson learned from the old idea; the idea of having one, 200+ page monster thread, with the realization that it makes the server almost choke to death.
franpa
Gecko snack
Posts: 2374
Joined: Sun Aug 21, 2005 11:06 am
Location: Australia, QLD
Contact:

Post by franpa »

a 200+ page thread is also hard to navigate through and find something your after.
Core i7 920 @ 2.66GHZ | ASUS P6T Motherboard | 8GB DDR3 1600 RAM | Gigabyte Geforce 760 4GB | Windows 10 Pro x64
gllt
NO VOWELS >:[
Posts: 753
Joined: Sun Aug 31, 2008 12:59 pm
Location: ALABAMA
Contact:

Post by gllt »

franpa wrote:a 200+ page thread is also hard to navigate through and find something your after.
Exactly, which is why I like the lock and move on thing.
Panzer88
Inmate
Posts: 1485
Joined: Thu Jan 11, 2007 4:28 am
Location: Salem, Oregon
Contact:

Post by Panzer88 »

franpa wrote:a 200+ page thread is also hard to navigate through and find something your after.
a better search tool on the forum would enhance that tremendously.
[quote="byuu"]Seriously, what kind of asshole makes an old-school 2D emulator that requires a Core 2 to get full speed? [i]>:([/i] [/quote]
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

FitzRoy wrote:
Nach wrote:
FitzRoy wrote:The bug doesn't happen in zsnes, but I think zsnes' reset is actually a power cycle.
It isn't.
Oh, so it just fails to emulate reset correctly.
I have it following the reset details byuu worked out like two years ago, and posted in our reset discussion back then, more than that I couldn't say.

You'll notice it does work fine for dozens of games.

But it'd be propper to do hardware tests on that one game before jumping to any conclusions.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
franpa
Gecko snack
Posts: 2374
Joined: Sun Aug 21, 2005 11:06 am
Location: Australia, QLD
Contact:

Post by franpa »

Panzer88 wrote:
franpa wrote:a 200+ page thread is also hard to navigate through and find something your after.
a better search tool on the forum would enhance that tremendously.
I know, but chances of that happening are pretty slim, most forums I visit don't search for the exact string of characters you enter when using quotes (like google does)...


Search for any terms or use query as entered
Search for all terms

can't the top one be changed to just search for the query as entered?
Core i7 920 @ 2.66GHZ | ASUS P6T Motherboard | 8GB DDR3 1600 RAM | Gigabyte Geforce 760 4GB | Windows 10 Pro x64
byuu

Post by byuu »

Nach wrote:But it'd be propper to do hardware tests on that one game before jumping to any conclusions.
Seconded.

And regardless of who gets it right or wrong, we should both work together to figure out why and get it working correctly in both emulators.

My current thoughts are that it could be related to the reset behavior of certain PPU MMIO registers.
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

Apologies for thinking zsnes was wrong based on 1.1 working. I have the 1.0 cart and was unsuccessful in trying to trigger the bug on real hardware.

It's actually a miracle I ever found this bug, I was only loading the game to confirm the title for my database and I reset it after being distracted by my cat.
byuu

Post by byuu »

In response to previous questions ...

I'm looking to start on the dot-based PPU after FEoEZ is translated, and some of the unemulated S-CPU errata are supported.

Turbo keys are on the very long-term to-do list, but there's so many other things in front of it that I'm afraid it will probably be quite a while before I have time for that.
FitzRoy wrote:Apologies for thinking zsnes was wrong based on 1.1 working. I have the 1.0 cart and was unsuccessful in trying to trigger the bug on real hardware.
Thank you for confirming this on hardware. I'll look into it this week.
85cocoa
Hazed
Posts: 55
Joined: Sat Jul 22, 2006 8:43 pm
Location: USA

Post by 85cocoa »

FitzRoy wrote:Apologies for thinking zsnes was wrong based on 1.1 working. I have the 1.0 cart and was unsuccessful in trying to trigger the bug on real hardware.
I presume you dumped your cart to confirm that it is 1.0?

Perhaps version 1.0 had trouble on reset on some, but not all, hardware revisions of the SNES, hence necessitating the release of a new revision?

As I mentioned previously, I have also seen this issue in SNES9x (it exists as of v1.51 and probably a few versions back). Should someone bring it up on the SNES9x forums? I would do it myself, but do they delete accounts due to inactivity?
[url=http://en.wikipedia.org/wiki/Pocky]Pocky[/url] & [url=http://en.wikipedia.org/wiki/Rocky]Rocky[/url]? [url=http://en.wikipedia.org/wiki/Pocky_%26_Rocky]Pocky & Rocky[/url]? [url=http://en.wikipedia.org/wiki/Sonic_the_Hedgehog_%28series%29#Animals.2FMobians]Pocky & Rocky[/url]?
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

85cocoa wrote:I presume you dumped your cart to confirm that it is 1.0?
Yes.
byuu

Post by byuu »

I started looking at this bug a bit more in advance.

It's adding some reset detection code at 7ffe20-7ffeff, which is compared to ROM at 03817f-03825f.

Code: Select all

0001817F 2031 3939 3220 4341 5043 4F4D 2020 2020  1992 CAPCOM    
0001818F 2042 6972 7468 2044 6179 2020 2020 2020  Birth Day      
0001819F 2020 2031 3936 3720 3320 3236 2020 2020    1967 3 26    
000181AF 2070 686F 6E65 2020 2020 2020 2020 2020  phone          
000181BF 2020 3036 2D39 3531 2D39 3035 3720 2020   06-951-9057   
000181CF 2030 3739 322D 3435 2D31 3131 3220 2020  0792-45-1112   
000181DF 2030 3739 322D 3436 2D30 3036 3420 2020  0792-46-0064   
000181EF 2031 3939 3220 4341 5043 4F4D 2020 2020  1992 CAPCOM    
000181FF 2050 726F 6772 616D 6564 2020 2020 2020  Programed      
0001820F 2020 2020 2062 7920 2020 2020 2020 2020      by         
0001821F 204D 6173 6174 7375 6775 2020 2020 2020  Masatsugu      
0001822F 2020 2053 6869 6E6F 6861 7261 2020 2020    Shinohara    
0001823F 3139 3932 2043 4150 434F 4D2E 494E 4320 1992 CAPCOM.INC 
0001824F 2020 2020 2055 2E53 2E41 2020 2020 2020      U.S.A      
A simple, but lengthy, signature check. When the check matches, it's doing something screwy that breaks the tiledata transfer to VRAM. Break the detection, and everything works fine.
Nach wrote:I have it following the reset details byuu worked out like two years ago, and posted in our reset discussion back then, more than that I couldn't say.
It seems there's a very odd bug involving ZSNES reset behavior. When I reset from inside the emulator and let it run normally, the bug doesn't present itself. But if I reset things through the debugger, the graphics bug manifests itself.

Here's an example ZST by doing the above:
http://www.megaupload.com/?d=F0H2ZSCJ

No tricks here: the ZST starts at the reset vector, so the fact that the bug appears means we're getting two different behaviors based on how the reset is performed, and that whatever causes the GFX bug is also in ZSNES.

You'll notice that it should skip the "Licensed by Nintendo" text when you reset, and it does in my ZST; but through the GUI ... it shows up again, as if it were a power cycle ... very strange.

That ZST is 100% equivalent to saving a ZST at the exact instant the reset action occurs. How I made it was by running DOS ZSNES -d, wait for the title, enter into the debugger, set $8000 (reset vector location) to db (STP opcode), reset. The game freezes on the first op. Enter into the debugger, save the state and change the code back to 9c (STZ, what it was originally) -- upon resuming emulation, you can see the bug.

You can also use my above ZST to see it. So ... it looks like the GUI isn't resetting something properly. I'm not really sure, since there's no way to grab a savestate fast enough under the GUI reset to see where the code paths split.

If you can run the trace logger in ZSNES outside the GUI, I'd recommend starting there. Once you see the paths diverge, you should be able to tell what's different.

In the mean time, I'll keep trying to figure out what causes the graphics bug itself.
Last edited by byuu on Sun Nov 23, 2008 4:57 pm, edited 2 times in total.
byuu

Post by byuu »

Logs are trace masked.

Power:

Code: Select all

008f3f lda $7ffe00,x [$7ffefe] A:03ff X:00fe Y:0000 S:1cff D:0000 DB:03 nvmxdizC V: 26 H: 852
008f43 cmp $815f,x   [$03825d] A:5555 X:00fe Y:0000 S:1cff D:0000 DB:03 nvmxdizC V: 26 H: 900
008f46 bne $8f51     [$008f51] A:5555 X:00fe Y:0000 S:1cff D:0000 DB:03 nvmxdizC V: 26 H: 946
008f51 phb                     A:5555 X:00fe Y:0000 S:1cff D:0000 DB:03 nvmxdizC V: 26 H: 968
008f52 ldx #$815f              A:5555 X:00fe Y:0000 S:1cfe D:0000 DB:03 nvmxdizC V: 26 H: 990
008f55 ldy #$fe00              A:5555 X:815f Y:0000 S:1cfe D:0000 DB:03 NvmxdizC V: 26 H:1014
008f58 lda #$00ff              A:5555 X:815f Y:fe00 S:1cfe D:0000 DB:03 NvmxdizC V: 26 H:1038
008f5b mvn $03,$7f             A:00ff X:815f Y:fe00 S:1cfe D:0000 DB:03 nvmxdizC V: 26 H:1062
008f5e plb                     A:ffff X:825f Y:ff00 S:1cfe D:0000 DB:7f nvmxdizC V: 36 H:1134
008f5f sep #$30                A:ffff X:825f Y:ff00 S:1cff D:0000 DB:03 nvmxdizC V: 36 H:1162
008f61 ldx #$00                A:ffff X:005f Y:0000 S:1cff D:0000 DB:03 nvMXdizC V: 36 H:1184
008f63 txy                     A:ffff X:0000 Y:0000 S:1cff D:0000 DB:03 nvMXdiZC V: 36 H:1200
008f64 lda #$0a                A:ffff X:0000 Y:0000 S:1cff D:0000 DB:03 nvMXdiZC V: 36 H:1214
008f66 sta $22       [$000022] A:ff0a X:0000 Y:0000 S:1cff D:0000 DB:03 nvMXdizC V: 36 H:1230
008f68 lda #$0d                A:ff0a X:0000 Y:0000 S:1cff D:0000 DB:03 nvMXdizC V: 36 H:1254
008f6a sta $20       [$000020] A:ff0d X:0000 Y:0000 S:1cff D:0000 DB:03 nvMXdizC V: 36 H:1270
008f6c lda $825f,y   [$03825f] A:ff0d X:0000 Y:0000 S:1cff D:0000 DB:03 nvMXdizC V: 36 H:1294
008f6f iny                     A:ff00 X:0000 Y:0000 S:1cff D:0000 DB:03 nvMXdiZC V: 36 H:1326
008f70 sta $7fff00,x [$7fff00] A:ff00 X:0000 Y:0001 S:1cff D:0000 DB:03 nvMXdizC V: 36 H:1340
008f74 inx                     A:ff00 X:0000 Y:0001 S:1cff D:0000 DB:03 nvMXdizC V: 37 H:  16
008f75 dec $20       [$000020] A:ff00 X:0001 Y:0001 S:1cff D:0000 DB:03 nvMXdizC V: 37 H:  30
008f77 bne $8f6c     [$008f6c] A:ff00 X:0001 Y:0001 S:1cff D:0000 DB:03 nvMXdizC V: 37 H:  68
008f79 txa                     A:ff40 X:000d Y:000d S:1cff D:0000 DB:03 nvMXdiZC V: 38 H: 720
008f7a clc                     A:ff0d X:000d Y:000d S:1cff D:0000 DB:03 nvMXdizC V: 38 H: 734
008f7b adc #$03                A:ff0d X:000d Y:000d S:1cff D:0000 DB:03 nvMXdizc V: 38 H: 748
008f7d tax                     A:ff10 X:000d Y:000d S:1cff D:0000 DB:03 nvMXdizc V: 38 H: 764
008f7e dec $22       [$000022] A:ff10 X:0010 Y:000d S:1cff D:0000 DB:03 nvMXdizc V: 38 H: 778
008f80 bne $8f68     [$008f68] A:ff10 X:0010 Y:000d S:1cff D:0000 DB:03 nvMXdizc V: 38 H: 816
008f82 rep #$30                A:ffa0 X:00a0 Y:0082 S:1cff D:0000 DB:03 nvMXdiZc V: 53 H:1060
008f84 bra $8f3c     [$008f3c] A:ffa0 X:00a0 Y:0082 S:1cff D:0000 DB:03 nvmxdiZc V: 53 H:1082
008f48 dex                     A:2020 X:00fe Y:0082 S:1cff D:0000 DB:03 nvmxdiZC V: 53 H:1238
008f49 dex                     A:2020 X:00fd Y:0082 S:1cff D:0000 DB:03 nvmxdizC V: 53 H:1252
008f4a cpx #$001e              A:2020 X:00fc Y:0082 S:1cff D:0000 DB:03 nvmxdizC V: 53 H:1266
008f4d bne $8f3f     [$008f3f] A:2020 X:00fc Y:0082 S:1cff D:0000 DB:03 nvmxdizC V: 53 H:1290
008f4f bra $8f86     [$008f86] A:3120 X:001e Y:0082 S:1cff D:0000 DB:03 nvmxdiZC V: 69 H: 506
Reset:

Code: Select all

008f3f lda $7ffe00,x [$7ffefe] A:03ff X:00fe Y:0000 S:1cff D:0000 DB:03 nvmxdizC V: 26 H: 852
008f43 cmp $815f,x   [$03825d] A:2020 X:00fe Y:0000 S:1cff D:0000 DB:03 nvmxdizC V: 26 H: 900
008f46 bne $8f51     [$008f51] A:2020 X:00fe Y:0000 S:1cff D:0000 DB:03 nvmxdiZC V: 26 H: 946
008f48 dex                     A:2020 X:00fe Y:0000 S:1cff D:0000 DB:03 nvmxdiZC V: 26 H: 962
008f49 dex                     A:2020 X:00fd Y:0000 S:1cff D:0000 DB:03 nvmxdizC V: 26 H: 976
008f4a cpx #$001e              A:2020 X:00fc Y:0000 S:1cff D:0000 DB:03 nvmxdizC V: 26 H: 990
008f4d bne $8f3f     [$008f3f] A:2020 X:00fc Y:0000 S:1cff D:0000 DB:03 nvmxdizC V: 26 H:1014
008f4f bra $8f86     [$008f86] A:3120 X:001e Y:0000 S:1cff D:0000 DB:03 nvmxdiZC V: 42 H: 230
Branch test: $7ffe14 = 0 on power, 2 on reset. Only show "Licensed by Nintendo" when 2. Also transfers title screen graphics here.

Code: Select all

008fbf lda $7ffe14   [$7ffe14] A:eaaa X:00c0 Y:00f8 S:1cff D:0000 DB:03 nvMXdiZC V: 53 H: 308
008fc3 bne $900f     [$00900f] A:ea00 X:00c0 Y:00f8 S:1cff D:0000 DB:03 nvMXdiZC V: 53 H: 348
00900f lda #$02                A:ea02 X:00c0 Y:00f8 S:1cff D:0000 DB:03 nvMXdizC V: 53 H: 446
009011 sta $7ffe14   [$7ffe14] A:ea02 X:00c0 Y:00f8 S:1cff D:0000 DB:03 nvMXdizC V: 53 H: 462
This is the fork that matters the most, and where the bug lies:

$7ffe12 = 0 ? graphics show up : graphics are corrupted.

Code: Select all

00ae13 lda $7ffe12   [$7ffe12] A:0000 X:000a Y:0018 S:1dbf D:0000 DB:03 nvMXdizC V:239 H: 852
00ae17 bne $ae36     [$00ae36] A:0000 X:000a Y:0018 S:1dbf D:0000 DB:03 nvMXdiZC V:239 H: 892
The code splits up over dozens and dozens of pages (and that's with the trace mask!!) with no stack coherence between the two. I can't make any sense of what's going on from staring at it.

So unfortunately it looks like we're at an impasse here.

A long shot, but if anyone here knows x816 and would like to help, I'd really appreciate it:

http://www.megaupload.com/?d=HLY2UA5G

Those are the two logs. You can find the split by searching for 00ae17 in both files and going from there. They converge again near the very end of the file, which is stopped at the title screen waiting for input.

Something in tracePower.log is transferring lots and lots of graphics to VRAM; and either something in traceReset.log is skipping it, or is screwing it up somehow so that the graphics are never shown.

EDIT: updated archive. Has power+reset logs for v1.0 and v1.1 now.
Looks like that's the exact section of code changed by the new version. Code right up to that point is 100% identical.

I'm really suspecting that this bug probably does occur on real hardware -- maybe it's just limited to certain hardware revisions or something. Why else would they patch it so extensively and fix the bug in a revision? It makes no sense otherwise ...
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

Is there a way to check my SNES hardware revision? What revision does bsnes emulate? We need to try and find an SNES model that exhibits the problem.
byuu

Post by byuu »

Is there a way to check my SNES hardware revision? What revision does bsnes emulate? We need to try and find an SNES model that exhibits the problem.
Some copiers report the hardware info ... other than that, you'd need a test ROM that does it. I don't know of any off-hand. You can take the system apart and look at it -- first revision has a separate daughter board for the APU, second revision is all on the main board. Older ones shells tend to oxidize quicker, too. Or anyone here can try the game on their copier, see if they can reproduce the bug or not ...

Right now, it's set to emulate the mid-range, 2/1/3 setup. But the bug exists in 1/1/1 mode, too. So there's something going on that we aren't getting right.

Could be anything -- maybe your work RAM is being partially corrupted on reset (maybe that happens on all systems ... or just some -- even the same revisions often have different branded memory chips), causing the very large RAM block compare to fail and making the game think its powering on for the first time. How about playing Street Fighter 2, see if resetting clears your high score list, maybe?

I don't know ... this being fixed in v1.1 is just way too coincidental. I have trouble believing that was a random fluke in the revision, when it targets only the exact area of code that v1.0 has problems with in emulators.

EDIT: Interesting ...

The missing data in VRAM happens only when you clear VRAM data on reset. The game only transfers that data on power-on.

So it looks like resetting from the ZSNES GUI doesn't do that, but doing so via the debugger does. Manually placing the VRAM data back allows it to work from the example ZST.

Now, all the data appears to be on BG3. This includes "Licensed by Nintendo", which should show up even after reset. So for some reason, BG3 isn't rendering at all after reset. I've dumped VRAM, OAM, CGRAM and the entire PPU register context both after power-on and reset ... and they're identical! Very strange ...
byuu

Post by byuu »

Okay, I got it figured out. Great catch, FitzRoy.
I wrote:regardless of who gets it right or wrong, we should both work together to figure out why and get it working correctly in (all) emulators.
As promised:

The basic gist is that neither work RAM nor video RAM should be cleared upon a soft reset.

If you clear work RAM, it appears to work because the game thinks a hard power cycle occurred.

If you do not clear work RAM, but clear video RAM, the game knows a soft power cycle occurred, and doesn't bother to reload BG3's tiledata. This causes the graphics corruption seen in emulators.

bsnes:

I actually didn't clear VRAM on soft reset, but there was another problem:

There was a bug in my tiledata caching system. I cache the 2/4/8bpp to linear data conversion to speed up rendering ... whenever VRAM is written to, that tile is marked as invalid. Whenever the renderer tries to draw a tile, it checks the flag. When invalid, it will reload the contents from actual VRAM and mark the tile as valid again.

All well and good, but I got the clear value wrong (that, or I was still resetting VRAM to 0 on soft reset, so I was using it as a speedup.) 0 is considered valid, and 1 is considered invalid. In my reset routine, I was calling clear_tiledata_cache(), which set all the states to zero, and also flushed the caches themselves to 0x00.

So I was basically saying, "all of the caches match real VRAM, and all of real VRAM is 0x00." You don't see this bug in other games, because they re-write the VRAM data, and it gets marked as invalid again.

The solution is that I really don't need to clear the tiledata cache at all on a reset ... the data is still valid. So I moved that to only occur during a power cycle, and I also fixed the flag clear inside the routine as well. I'll also relabel the state block names to have _invalid at the end, so the value of 0 or 1 is more obvious.

Snes9X:

Snes9X is clearing only VRAM on soft reset:

cpu.cpp:S9xSoftReset():
Comment out or remove this line:

Code: Select all

memset (Memory.VRAM, 0x00, 0x10000);
Move to S9xHardReset() or whatever if it's not there already.

ZSNES:

https://zsnes.bountysource.com/svn/!sou ... rc/initc.c
GUIDoReset calls init65816. init65816 calls clearvidsound. clearvidsound:1495 contains:

Code: Select all

memset(vram, 0, 65536);
Erase that, and put it inside void powercycle() instead.

The reason the tiledata still shows up even after a reset from the GUI, is because ZSNES' tiledata cache is not being flushed, even though the VRAM is.

It's essentially the mirror opposite of the problem bsnes had.

If you want proof: run Super Buster Bros V1.0 to the title screen. Take a savestate. Open it in bview (available @ http://byuu.cinnamonpirate.com/programming/), View->Goto address->20c13->Go. View->Mode->4bpp. You'll see lots of font data there. Or use whatever sprite viewer you want -- 0x20c13 is the start of VRAM data.

Now reset the game in ZSNES, go to the title screen again, take another savestate. Load that savestate in bview, do the same as above. You'll see that all of the font data is missing from VRAM, yet it still shows up on the screen. Either reload the state you just took immediately (which will flush the tiledata cache), or load the same ZST in vSNES, and you'll see the data is not there.

I wasn't able to track down how to clear the tiledata cache, though. I'm not familiar enough with ZSNES, so I'll leave that to Nach or Jonas. Just add that flush call inside clearvidmem and everything should be fine.

Also, I'm sorry if I seem like a pest in pointing this out ... I'm not trying to make a big deal out of the bug, I'm only pointing it out so that it can be fixed. The screw-up in bsnes was much worse, so I have no room to brag anyway.

Super Sleuth and SNESGT:

I can't cite exact source lines to change, but the above should be enough info to fix it.
Locked