SNES Emulation - Where to look for inaccuracies?

[Myself086]

Here's a hack that'll display the lower 8-bit of the horizontal counter above coins. It should be the same timing as the original but needs to be double checked. The horizontal counter is latched near the end of the NMI routine.

[Alyosha_TAS]

Wow thanks! I have some dev. boards on their way. Will post back when I have some results.

EDIT: The values aren't displaying in water levels, which is where the desync happens. Can a version be made that works in water levels too?

[Myself086]

EDIT: The values aren't displaying in water levels, which is where the desync happens. Can a version be made that works in water levels too?

Absolutely! I'll get back to you once I'm done.

I'm wondering if the numbers desync before the water level. It's possible that something desync early and only takes effect at the water level.

[Myself086]

This one fixes tile priority and will be visible for water levels and level preview.
I also fixed a timing mistake (2 master cycles).
I enable fast ROM for this one since the timing was too tight and the original game doesn't use any of the fast ROM address space from what I can see.

[Alyosha_TAS]

Thanks this version works!

I'll report back results once my board is assembled, probably next week.

[Alyosha_TAS]

Following up here I did get some boards assembled but they don't work and I can't figure out why. I'm using original CIC chips that I verified work and double checked that the ROM programmed correctly, really not sure what's wrong. I tried with an original unmodified ROM too. I was going to try a simpler no SRAM game like Battletoads, but now I need an EPROM eraser.

So, I'll keep troubleshooting and post back if i get anything useful.

[Alyosha_TAS]

Ok, so I got a working board and started doing basic testing. Right now I can confirm that at least on the title screen I do get pretty consistent results. I only see 2 patterns. Either FD on the fade in and then a pattern with only 7 as the last after that, or a value of DD on the fade in with a repeated pattern of 0,7,2,7 in the last digit after that. (EDIT: Sometimes I get alternating FD and DD on the fade in, but I never see any other values than that on fade in.) This has been consistent across power and reset cycles, so that's really encouraging. So far though I haven't been able to recreate these patterns in emulator. I'm trying to vary the audio clock rate which seems to have some effect but so far no matches.

Unfortunately my replay device broke, and I broke it even more trying to fix it, so now I need to wait for a new one to run the TAS. It's like the universe doesn't want me to figure this out!

So I'll try to match what I have with emulator, so by the time I get a working replay device I'll be pretty confident I have a good starting point.

[Myself086]

What patterns do you get on emulator?
Have you tried different versions of bsnes?

Now that we know the desync happens before the title screen, the next ROMs that I'll make won't require the replay device.

EDIT: Do you have a battery for the next few tests?

[Alyosha_TAS]

Focusing on the title screen fade in, on emulator I get the pattern mostly of alternating CD, DD instead of the alternating FD,DD on console. This is the same on BSNES 115 and 87. Also changing audio clock doesn't seem to effect these fade in values at all.

Yes I have a working battery in the dev board for any additional testing. Thanks for your help I'm really hoping to making progress on this!

EDIT: Oh and the console capture is at 30 fps, but on emulator I do see values are the same for two consecutive frames, ie it's CD,CD,DD,DD, though sometimes I do see something like CD,CD,DD,4E. I can't get a good capture at 60 fps but 30 fps does seem to be good enough in this case.

[Myself086]

Here's one where you only have to hold start the entire time.

Give me 8 consecutive numbers either at fade-in or fade-out on console and emulator.

I need to build another test either on the coin screen or as a separate ROM.

the console capture is at 30 fps

This explains the 2 patterns that you get on console.

[Alyosha_TAS]

So on emulator I get (on title screen fade in): CD-CD-DD-DD-CD-CD-DD-DD
On console I get: 2E-2E-DD-DD-2E-2E-DD-DD

SRAM state doesn't seem to matter, these values are pretty consistent. I varied audio clock a bit in emulator but that didn't change anything either.

I'm no expert but this looks to me like one extra RAM refresh sometimes being hit on emulator. Is there a separate test ROM around that tests refresh timing on console?

[Myself086]

For test 4, I moved the HV latch closer to the interrupt and I fixed the order of each digit, I was writing them backward.
I added an X sometimes showing after the number, this is to indicate which instruction was interrupted.

The timing should be very tight now that noise from if statements is removed.

I want 16 numbers of the same time frame. Including the X if present.

Is there a separate test ROM around that tests refresh timing on console?

I'm building each test as we go. I rarely search for them. Feel free to search for test ROMs while I make my own.

[Alyosha_TAS]

Title screen fade in:

Console: 91-91-82-82-84-84-82-82-84-84-82-82-84-84-82-82-84-84-84-84-91X-91X

emulator(clock 32040): 83-84-84-84X-83-84-84-84X-83-84-84-84X-84X-84-93X-92X-91X-93X-93X-83X-83-84
emulator(clock 32080): 83-84-84-83-83-84-84-83-83-84-84-83-84X-84-84-83X-86-93X-93X-83X-83X-84

Emulator has a little variability with audio clock frequency, but I never see any 82's like on console. Console is quite stable with that pattern shown.

[Myself086]

Test 5 doesn't require recording capture and shows a list of the H,V values for when the game started waiting for the next frame.

The "frame" number doesn't take lag frames into account.

Controls:
Up and Down to scroll by 1
L and R to scroll by 10

I want to know the first inaccurate frame according to the list and information around it.

[Alyosha_TAS]

I get very inconsistent results with this test both on console and in emulator when varying audio clock.The first page of results doesn't seem to give any useful info since it's so random.

I previously tested the clock on my SNES to be ~32045, and when I run that I get a perfect match with console in the range 200 until 3w1 where things deviate:

compare.png

3w3 is the last line captured (holding start from power on.) note that the 33 and 45 on the V column that don't match are just graphical glitches that also happen on console.

Here's page 1 of this same run for completeness, but note that the H values on console vary widely, especially on frames 0-2:

compare2.png

EDIT: I did a couple more runs on console, and sometimes 3w1 and 3w2 match emulator as well, but 3w3 never does. On runs where 3w2 matches, the V value of 3s3 is 2QL