bsnes v0.033 released

King Of Chaos · Post by **King Of Chaos** » Thu Jul 31, 2008 4:45 pm

Here...

Picture of two Justifiers:

Picture of a Super Scope:

Basically, the Justifier is just a gun, and the Super Scope is pretty big and goes on your shoulder to look through.

Post by **grinvader** » Thu Jul 31, 2008 7:55 pm

tetsuo55 wrote:How do the super-scope and justifier differ other than their size?

The second Justifier, as seen here, is plugged in the first one. This is already documented.

FitzRoy · Post by **FitzRoy** » Thu Jul 31, 2008 10:39 pm

Whatever Nintendo employee came up with that unwieldy thing should be pistol whipped with a justifier. Konami could have used orange instead of pink, though. God.

byuu · Post by **byuu** » Fri Aug 01, 2008 1:11 pm

Posted a new WIP which can pass the test_hdmasync ROM I posted in the other thread.

Please note that it's currently throwing off Jumbo Osaki exactly 50% of the time. I'll look into it over the weekend. But the change I've made is correct, so if I can't fix these, the games stay broken :/

One of the most unfortunate parts of emulation: when a game works because two things are bad, but no longer when only one thing is bad.

King Of Chaos · Post by **King Of Chaos** » Fri Aug 01, 2008 9:32 pm

FitzRoy wrote:Konami could have used orange instead of pink, though. God.

His and her Justifiers perhaps?

byuu · Post by **byuu** » Fri Aug 01, 2008 10:39 pm

Looks like Lord Jumbo Osaki is returning from the depths of hell to torment me once more.

Good:

Code: Select all

0af3c3 sbc $02       [$001ddf] A:fe68 X:002d Y:0006 S:1fe9 D:1ddd DB:7e NvmxdIzC V:  2 H:1070
* HDMA @   2,1100
0af3c5 sta $00       [$001ddd] A:fe65 X:002d Y:0006 S:1fe9 D:1ddd DB:7e NvmxdIzC V:  2 H:1152
0af3c7 inx                     A:fe65 X:002d Y:0006 S:1fe9 D:1ddd DB:7e NvmxdIzC V:  2 H:1194

Code: Select all

00876d lda $09       [$001ddf] A:7e80 X:0096 Y:0044 S:1fdf D:1dd6 DB:00 NvmXdIzC V:224 H:1194
00876f sta $0200,x   [$000296] A:5400 X:0096 Y:0044 S:1fdf D:1dd6 DB:00 nvmXdIzC V:224 H:1232
008772 inx                     A:5400 X:0096 Y:0044 S:1fdf D:1dd6 DB:00 nvmXdIzC V:224 H:1278
008773 inx                     A:5400 X:0097 Y:0044 S:1fdf D:1dd6 DB:00 NvmXdIzC V:224 H:1292
008774 stx $0003     [$000003] A:5400 X:0098 Y:0044 S:1fdf D:1dd6 DB:00 NvmXdIzC V:224 H:1306
008777 jmp $87b2     [$0087b2] A:5400 X:0098 Y:0044 S:1fdf D:1dd6 DB:00 NvmXdIzC V:224 H:1338
0087b2 rep #$10                A:5400 X:0098 Y:0044 S:1fdf D:1dd6 DB:00 NvmXdIzC V:224 H:1362
0084f1 rep #$30                A:5400 X:0098 Y:0044 S:1fdb D:1dd6 DB:00 NvmxdIzC V:225 H:  82

Code: Select all

008616 ldx $02       [$000002] A:0220 X:0001 Y:0044 S:1fd0 D:0000 DB:00 nvmXdIzC V:229 H: 178
008618 cpx $03       [$000003] A:0220 X:0090 Y:0044 S:1fd0 D:0000 DB:00 NvmXdIzC V:229 H: 202
00861a beq $8658     [$008658] A:0220 X:0090 Y:0044 S:1fd0 D:0000 DB:00 NvmXdIzc V:229 H: 226
00861c ldy $0200,x   [$000290] A:0220 X:0090 Y:0044 S:1fd0 D:0000 DB:00 NvmXdIzc V:229 H: 242
...
008650 ldy #$01                A:5400 X:0098 Y:0000 S:1fd0 D:0000 DB:00 NvmXdIzc V:229 H: 920
008652 sty $420b     [$00420b] A:5400 X:0098 Y:0001 S:1fd0 D:0000 DB:00 nvmXdIzc V:229 H: 936
008655 jmp $8618     [$008618] A:5400 X:0098 Y:0001 S:1fd0 D:0000 DB:00 nvmXdIzc V:229 H: 966
[DMA] channel:0 direction:a->b reverse:0 fixed:0 mode:0 b_addr:$2118 a_addr:$7e8000 length:$0400 ( 1024) [dd:0 vram:a800]
* VRAM wa800: 11 [7e8000=11]
008618 cpx $03       [$000003] A:5400 X:0098 Y:0001 S:1fd0 D:0000 DB:00 nvmXdIzc V:235 H:1262
00861a beq $8658     [$008658] A:5400 X:0098 Y:0001 S:1fd0 D:0000 DB:00 nvmXdIZC V:235 H:1286
008658 stx $02       [$000002] A:5400 X:0098 Y:0001 S:1fd0 D:0000 DB:00 nvmXdIZC V:235 H:1308
00865a rts                     A:5400 X:0098 Y:0001 S:1fd0 D:0000 DB:00 nvmXdIZC V:235 H:1332

Bad:

Code: Select all

0af3c3 sbc $02       [$001ddf] A:fe68 X:002d Y:0006 S:1fe9 D:1ddd DB:7e NvmxdIzC V:  2 H:1074
* HDMA @   2,1104
0af3c5 sta $00       [$001ddd] A:fe65 X:002d Y:0006 S:1fe9 D:1ddd DB:7e NvmxdIzC V:  2 H:1160
0af3c7 inx                     A:fe65 X:002d Y:0006 S:1fe9 D:1ddd DB:7e NvmxdIzC V:  2 H:1206

Code: Select all

00876d lda $09       [$001ddf] A:7e80 X:0096 Y:0044 S:1fdf D:1dd6 DB:00 NvmXdIzC V:224 H:1268
00876f sta $0200,x   [$000296] A:5400 X:0096 Y:0044 S:1fdf D:1dd6 DB:00 nvmXdIzC V:224 H:1306
008772 inx                     A:5400 X:0096 Y:0044 S:1fdf D:1dd6 DB:00 nvmXdIzC V:224 H:1352
008773 inx                     A:5400 X:0097 Y:0044 S:1fdf D:1dd6 DB:00 NvmXdIzC V:225 H:   2
0084f1 rep #$30                A:5400 X:0098 Y:0044 S:1fdb D:1dd6 DB:00 NvmXdIzC V:225 H:  80

Code: Select all

008616 ldx $02       [$000002] A:0220 X:0001 Y:0044 S:1fd0 D:0000 DB:00 nvmXdIzC V:229 H: 182
008618 cpx $03       [$000003] A:0220 X:0090 Y:0044 S:1fd0 D:0000 DB:00 NvmXdIzC V:229 H: 206
00861a beq $8658     [$008658] A:0220 X:0090 Y:0044 S:1fd0 D:0000 DB:00 nvmXdIZC V:229 H: 230
008658 stx $02       [$000002] A:0220 X:0090 Y:0044 S:1fd0 D:0000 DB:00 nvmXdIZC V:229 H: 252
00865a rts                     A:0220 X:0090 Y:0044 S:1fd0 D:0000 DB:00 nvmXdIZC V:229 H: 276

Because every other frame ends up triggering HDMA four cycles later, the alignment ends up consuming more time in three of four cases, and the same in the last one.

The slow build-up of 225 scanlines worth of HDMAs extra time ends up triggering NMI three or four opcodes earlier. It just so happens that one of those sets a variable to point to the end of the DMA transfer list for the BG2 tilemap transfer that holds all the Japanese character positions.

The bad news is this is exactly the same thing I see on hardware. So something during this frame must be consuming extra time somewhere.

I can't simply hook the function to log variables on the real SNES because the routine is shared by other functions that run well before this one. It would throw off the timing.

So, I'm basically forced to manually clone and then step through a full frame worth of opcodes to find where timing diverges from emulation and hardware and hope I come up with something.

FitzRoy · Post by **FitzRoy** » Fri Aug 01, 2008 10:46 pm

If it helps to have another case, I noticed that Energy Breaker flickers on the intro just briefly now, and it happens every time. Does not do this in .033, does do it in .033.04 and .033.05.

Street Racer also while racing.

byuu · Post by **byuu** » Sat Aug 02, 2008 12:02 am

Odd, Street Racer doesn't flicker at all for me. Not that it matters much, there's obviously something still not quite right. Need to get more HDMA tests going with mixtures of indirect transfers, line fetches and no, and byte fetches and no.

And people still think this level of precision is unnecessary, hah.

EDIT: forcing 8-cycle channel overhead regardless of line counter load seems to fix all commercial game issues, and keep Mecarobot working. Have to test it on hardware, obviously.

FitzRoy · Post by **FitzRoy** » Sat Aug 02, 2008 1:18 am

byuu wrote:Odd, Street Racer doesn't flicker at all for me.

Ok, I just tried practice mode a few times, and it didn't do it at all. Then I reset and tried head-to-head as I had before, and I got a few flickers per lap. It also flickered between menu transitions a few times. Strange, I guess I'll have to play a few modes next time we conclude it's being normal.

bobthebuilder · Post by **bobthebuilder** » Sat Aug 02, 2008 6:50 am

I can't access the WIP, so remember to check out that robocop game that had flickering problems in the past.

I.S.T. · Post by **I.S.T.** » Sat Aug 02, 2008 8:02 am

Which game is that, exactly?

FitzRoy · Post by **FitzRoy** » Sat Aug 02, 2008 8:39 am

bobthebuilder wrote:I can't access the WIP, so remember to check out that robocop game that had flickering problems in the past.

I did. We have a pretty huge list now of usual suspects for both sides of the see-saw. If it's tipping even a nanometer to one side, one of them breaks. Byuu has to make it perfectly straight.

AamirM · Post by **AamirM** » Sat Aug 02, 2008 1:52 pm

Hi,

I was trying Super Mario Kart in different emulators and just noticed a one line flickering at the end of top screen during the race. It is pretty noticeable and doesn't happen in ZSNES and SNES9X.

stay safe,

AamirM

King Of Chaos · Post by **King Of Chaos** » Sat Aug 02, 2008 5:16 pm

AamirM wrote:Hi,

I was trying Super Mario Kart in different emulators and just noticed a one line flickering at the end of top screen during the race. It is pretty noticeable and doesn't happen in ZSNES and SNES9X.

stay safe,

AamirM

It's fixed in the latest WIP, along with that God-aweful Mecarobot Golf game.

FitzRoy · Post by **FitzRoy** » Sat Aug 02, 2008 7:10 pm

AamirM wrote:Hi,

I was trying Super Mario Kart in different emulators and just noticed a one line flickering at the end of top screen during the race. It is pretty noticeable and doesn't happen in ZSNES and SNES9X.

stay safe,

AamirM

byuu wrote:New WIP posted.

It adds my new findings on HDMA, which I've posted here:
http://board.zsnes.com/phpBB2/viewtopic.php?t=11804

This effectively fixes Mecarobot Golf once and for all. Interestingly enough, it also eliminates the track line flickering in Super Mario Kart.

byuu · Post by **byuu** » Sat Aug 02, 2008 8:25 pm

And to reiterate why SMK is not a priority for me, even if it does flicker:

The game uses the DSP-1 chip, which requires a certain amount of time for each math operation to complete. Since we don't emulate this time delay, our emulation of the game will never be perfect (it will always run too fast). Thus, it'd be kinda silly / futile to try and match hardware timing for that game. The second a DSP-1 op is involved, the timing will differ.

henke37 · Post by **henke37** » Sat Aug 02, 2008 11:13 pm

Perfect timing matching isn't needed, the games are broken if they can't take a normal sized delay for this.

Post by **Nach** » Sun Aug 03, 2008 2:39 am

henke37 wrote:Perfect timing matching isn't needed, the games are broken if they can't take a normal sized delay for this.

Emulation is broken if we don't cover emulate the proper amount of cycles for something.

Our DSP emulation is also fundamentally broken in that we don't emulate the hardware at all, we just try to replicate the firmware functionality wise.

henke37 · Post by **henke37** » Sun Aug 03, 2008 10:00 am

My point is that it might not be as accurate as reality if you just pick a fixed delay, it is still closer to the reality than not having a delay at all.

Post by **grinvader** » Sun Aug 03, 2008 10:13 am

Err, not really. Fixed delay for all operations is as dumb as no delay for all operations.

byuu · Post by **byuu** » Sun Aug 03, 2008 12:08 pm

New WIP.

After some more hardware testing, it seems my theory from before was correct. See the HDMA thread for more info if you care.

With those changes plus a few others, I'm now able to get everything in my "known troublesome" games list to work properly and with no flickering:
- Breath of Fire 2 (G)
- Earthworm Jim 2 (U+E)
- Energy Breaker
- Jumbo Osaki no Hole in One
- Mecarobot Golf
- Secret of Mana
- Street Racer
- Super Mario Kart

I still can't get Street Racer to flicker, maybe you guys can? Hopefully not, such a hard-to-trigger bug will be even harder to debug.

(ignore the framerate, from a pause/resume screen capture.)

And fucking hell that game is hard.

Note that to get BoF2 (G) to work, I had to modify S-SMP cycle timing from 32040hz*768 to 32041hz*768. It seems the game is very sensitive to S-CPU <> S-SMP timing, and the improved HDMA timing was just unlucky enough to just barely miss the handshake. This was further compounded by there being no input before the point in question to vary timing.

It's not really a problem with the game itself -- d4s really pushed the limits of these two chips to pull off that impressive intro. It was more that I was hitting an extremely tiny window of time that caused a deadlock.

This timing change only affects S-CPU <> S-SMP communications (eg handshakes and such), and not timing inside each individual processor. Recall that both processors in both regions (NTSC and PAL) have slightly different timings, and the exact timings vary even on real hardware, as the crystal clocks used are not perfect.

The NTSC S-SMP has been observed at ~32040hz on an oscilloscope by the guy at alpha-ii.com, which is faster than the stock speed of ~32000hz. But we still use stock speeds for the S-CPU because that's all we have. Changing the S-CPU speed a bit would've fixed this as well.

So yeah, the fix is a bit of a kludge, but it's the best I can do when the problem is in communication between the two chips.

Keep in mind that the S-SMP clock rates are cached in the config file. You'll either need to delete it, or reset the values to the default in the advanced panel. Otherwise the game will hang on first run.

Also, I tightened DMA transfer restrictions even more. A-bus accesses to $4200-421f and $4016-4017 are now blocked. And I also block these during HDMA line counter / indirect address fetches (as observed on hardware.) Further, I was previously allowing invalid B->A transfers to still write the the MMIO reg specified in A, but ignoring the B-bus read. This seemed wrong: not being able to access the reg should mean not being able to access it period, so I swapped that around.
Shouldn't affect any known games, but mentioning it just in case.

Perfect timing matching isn't needed, the games are broken if they can't take a normal sized delay for this.

Mortal Kombat II breaks if you're exactly 6 cycles off from expected timing (but works if you're more than six cycles off.) Jumbo Osaki was failing by 20 cycles. Wild Guns fails if off by two cycles. A couple other games were the same. There are roughly 21 million cycles in a second.

Death Brade and some European racing game break if uninitialized RAM doesn't return the values they like.

Uniracers is quite simply beyond broken.

I wish I could get away with just saying the games themselves were broken (and they are), but when it runs at least 99% of the time on hardware, you can't use that as an excuse. Everyone will still call it an emulation bug :(

Err, not really. Fixed delay for all operations is as dumb as no delay for all operations.

I typically like the idea of emulating as much as we can ("building blocks" and such), if that means guessing approximate delays, so much the better. But for the DSP-1, adding any delays is even worse in my opinion. Why?

First, the delay lengths will no doubt vary depending upon how complex the transfer is. Second, emulating the delays would force us to implement the DSP-1 as the dedicated processor that it is: thusly, its overhead would soar from barely noticeable to nearly as intense as SuperFX / SA-1 emulation. Third, it may be possible to read partially computed results before the operations finish. We can't even figure out the partial computations of mere unsigned multiplication and division in the S-CPU core, so how the hell would we ever plan to figure out attitude / altitude calculations?

The only feasible way we're going to get this right is to dump the program ROM and then emulate the instruction set. Even decapping the DSP-1 has been no help for that, and even if by some miracle we got the ROM, we'd have to figure out the instruction set and timing with no documentation. And all of this to improve emulation of a couple of lackluster action games. Good luck finding someone willing to do all that for free, and just to end up getting ~90% of people bitching that suddenly DSP-1 emulation is as demanding as SFX emulation, yet provides no visible improvement over existing emulation. And it even requires another DSP1program.rom file that they didn't need before!

Thus, it's really not worth the effort if our entire model of emulating the chip is busted in such a manner that we couldn't improve it more even if we wanted to anyway.

tetsuo55 · Post by **tetsuo55** » Sun Aug 03, 2008 3:12 pm

byuu wrote: emulating the delays would force us to implement the DSP-1 as the dedicated processor that it is

i didn't know this was not the case yet...

The way i presented the rom storage method assumes(and requires) the co-processors to be emulated as dedicated processors...

-------

Great work on the fixes, another win for snes emu accuracy!!

AamirM · Post by **AamirM** » Sun Aug 03, 2008 3:47 pm

FitzRoy wrote:
AamirM wrote:Hi,

I was trying Super Mario Kart in different emulators and just noticed a one line flickering at the end of top screen during the race. It is pretty noticeable and doesn't happen in ZSNES and SNES9X.

stay safe,

AamirM

byuu wrote:New WIP posted.

It adds my new findings on HDMA, which I've posted here:
http://board.zsnes.com/phpBB2/viewtopic.php?t=11804

This effectively fixes Mecarobot Golf once and for all. Interestingly enough, it also eliminates the track line flickering in Super Mario Kart.

Hi,

Sorry, I didn't read that.

byuu wrote:I still can't get Street Racer to flicker, maybe you guys can? Hopefully not, such a hard-to-trigger bug will be even harder to debug.

Street Racer is a bitch game to emulate on a Genesis too. It is one game that will later lock up on Kega Fusion. No such problems on Regen though although I did had a hard time making this game running perfectly too.

stay safe,

AamirM

DancemasterGlenn · Post by **DancemasterGlenn** » Sun Aug 03, 2008 4:24 pm

I feel like making a game on multiple platforms can lead to a game jumping through a few weird hoops to provide a similar experience on both systems. Not sure if that's true or not, but when you're dealing with two separate systems, both with different kinds of processors and specs, it can't be that simple to make them both play "the same".

Of course, some of the problem games here are nintendo exclusive, so no excuse there.

FitzRoy · Post by **FitzRoy** » Sun Aug 03, 2008 6:39 pm

Probably the best it's ever been, but Street Racer's track does still flicker on "Head to Head" mode. I have no idea why practice mode doesn't trigger it while another mode does. Both NTSC and PAL versions of the game behave the same. It's funny, when you're racing, sometimes a notice will pop up on the bottom right of the screen saying "Timing by West Bros." Nice job, West Bros, you suck!

That really is the only one breaking. I tested all regions of all regressions I know of, too, including SoM.