search

DaveTCode / GBADotnet

A C#/net core GBA emulator
MIT License
20 stars 1 forks source link

Mario kart track doesn't quite line up how it should #78

Closed DaveTCode closed 2 years ago

DaveTCode commented 2 years ago

As per #65 the vcount irq issue is resolved but the game now jumps the track around so that the sprites aren't quite lined up properly.

Almost certainly I'm just missing something about when the affine registers are latched/set so I need to look at how that code works again

No gif yet

DaveTCode commented 2 years ago

Worth noting that f-zero and f-zero 2 do render properly

DaveTCode commented 2 years ago

image

So it kinda looks like it's zoomed wrong perhaps? Still no idea what exactly is going wrong but it's quite amusing

DaveTCode commented 2 years ago

The relevant background here is BG2 (BG3 is not included because we're in mode 1) and it's a 1024*1024 map (obviously affine).

DaveTCode commented 2 years ago 
BG2PA=612 on 73:1011
BG2PA+1=612 on 73:1011
BG2PB=0 on 73:1011
BG2PB+1=0 on 73:1011
BG2PC=0 on 73:1013
BG2PC+1=0 on 73:1013
BG2PD=1896 on 73:1013
BG2PD+1=2152 on 73:1013
BG2X+0=167200 on 73:1015
BG2X+1=159008 on 73:1015
BG2X+2=159008 on 73:1015
BG2X+3=159008 on 73:1015
BG2Y+0=73568 on 73:1017
BG2Y+1=120928 on 73:1017
BG2Y+2=55392 on 73:1017
BG2Y+3=55392 on 73:1017
BG2PA=543 on 160:3
BG2PA+1=543 on 160:3
BG2PB=0 on 160:3
BG2PB+1=0 on 160:3
BG2PC=0 on 160:5
BG2PC+1=0 on 160:5
BG2PD=2167 on 160:5
BG2PD+1=1911 on 160:5
BG2X+0=159096 on 160:7
BG2X+1=167288 on 160:7
BG2X+2=167288 on 160:7
BG2X+3=167288 on 160:7
BG2Y+0=55515 on 160:9
BG2Y+1=8155 on 160:9
BG2Y+2=73691 on 160:9
BG2Y+3=73691 on 160:9

That's all writes to PA-PD and the X,Y ref points for BG2 during the live screen once it's rotated so that the track is as in the image above.

There's writes at line 73 (vcount interrupt) and then writes at line 160. Lines 73-160 are the ones after the mode switch to include affine backgrounds so are the ones which should be relevant.

Since the affine X,Y base registers are set on line 73, line 74 should use them (they're latched on write so any updates to them before are irrelevant) and the matrix should be fixed for the remaining lines. Given that there's very little weird that could be going on here.

That's backed up by printing out the affine values on line 74 PA=612, PB=0, PC=0, PD=2152, X=159008, Y=55392

I started with the hypothesis that there was an issue with updating the affine regs but that doesn't look right any more. The other things it could be are:

  1. Something wrong with the matrix calculation but somehow not affecting all the other example roms
  2. Something wrong with memory addressing based on these affine values (but again not affecting all the other examples)
  3. The wrong values are being written in to the regs somehow

None of which sound massively plausible and all should really be covered by other test roms but I need to start investigating somewhere and those three are my obvious candidates.

DaveTCode commented 2 years ago

I checked mgba and can see that PA-D are all identically set on line 73 as part of vcount irq along with X,Y (both low and high registers) - they then don't seem to be set to anything else after that before line 160 (as with my implementation)

The mode is also set from 0->1 during that vcount irq as I already know, BG2 control register is also changed during that process but that shouldn't affect anything since none of those values are latched or anything like that.

I think that rules out number 3 from the above comment. It could still be either 1 or 2.

I'm not sure how to test the matrix calculations though!

DaveTCode commented 2 years ago

The matrix is

2.39 0.00
0.00 8.41

with X,Y as 2.426, 0.845

At each line, since PC is 0, ref y will remain the same.

DaveTCode commented 2 years ago

image

is what it should look like

DaveTCode commented 2 years ago

It's kinda interesting to look at the comparison between the two screenshots. The real version has been rotated more around the x axis I think. The first line at 74 looks identical as far as I can tell but beyond that mine seems to stay flat where the real one gets stretched for want of a better phrase. I don't know enough about programming these affine maps to know what part of the matrix affects that though :(

DaveTCode commented 2 years ago

Powerlated noted on discord that you can't get perspectives like this generated from fixed affine transforms so something must be adjusting the affine regs during hblank each row (either irq, hdma or cycle timed code). HBlank dmas are disabled at this point in IE so that leaves HDMA.

Checking HDMA transfers I can see:

Starting HDMA on line 73 with DMA DMA0 03005060->04000020 (4)
Starting HDMA on line 74 with DMA DMA0 03005060->04000020 (4)
Starting HDMA on line 75 with DMA DMA0 03005060->04000020 (4)
Starting HDMA on line 76 with DMA DMA0 03005060->04000020 (4)

So we're transferring 03005060 from RAM to the IO reg at 04000020. This should be 4 word writes starting at BG2PA and going through to all the BG2 affine registers.

However I didn't notice these writes actually happening when logging out all writes so what's going wrong? Something to do with DMA or word writes to BG registers?

DaveTCode commented 2 years ago

Interestingly only the HDMA on lines 72 and 159 generates any writes to ppu registers. It appears that the rest of the time the cpu is halted and so I'm not firing any DMAs off. Presumably that's not quite the right behaviour and HDMA should still fire during halted cpu which might need some refactoring

DaveTCode commented 2 years ago

Fix was indeed that HDMA should continue whilst the CPU is halted, actual fix was quite trivial, just moving an if statement to another location