Quote:
Originally Posted by NHervé
Shash : when I visit current CVS (with my Internet Explorer), I visit MMU.c and OGLRender.c, and I can't see any GXFIFO IRQ implementation, these files don't differ with mines.
|
That's normal, my GFX FIFO irq handling isn't public. Neither I know when it'll be.
----------------------------------------------------------
About the ITCM/DTCM issue, that's what I've found so far:
- I hacked the ITCM handling needed by New Super Mario Bros. Currently it's not doing full mirroring (as it should, as it's using an ITCM virtual size of 32MB) through 0..1FFFFFFh, because I only logged the writes to that range and hacked the handling. That makes the first 32kb of the ARM9 memory and the 32kb from 01FF8000 equal (thus mirrored). It's still missing all the other mirrors. I don't know if the mini-games fail due to this. I'll implement full mirroring later.
- The code that shown the issue with the ITCM is reading uninitialized data (in desmume, that's zeros, because memory is set up to zeros on startup). That was quite nice as it showed the ITCM issue, but also means it's not reading the data it expects. For example, all registers are set to zero due to the uninitialized memory. I'll be a bit more concise about this on the next point.
- The routine starting on memory offset 0 (first on ITCM), it's doing some division and sqrt with the hardware registers. Using ITCM for this is logical, as code will execute faster there, even if using those registers still means that it has to wait for the results. When exiting, it's using LR (r14) to return to the calling routine. When this is called before freezing (call on offset 0x01FFD82C), LR is 0. If we check the preceding code, it's loading a value on r12, then assigning it to LR, and calling the routine. The r12 register is loaded from memory, exactly from location [r13+24h], being the base offset (r13) 0x027FFE00. This resembles quite a lot to the DTCM 16kb area (it's default offset is 0x27C0000, but on this case it's changed to 0x27E0000 on game init), so it could be an issue with mirroring. The problem is that it's virtual size matches it's set exactly as it's physical size, so theoretically it shouldn't mirror. If I compare that memory location with NeonDS, it has initialized values on the later, so we're missing something.
And that's all I could discover in 2 hours, I'll try to work more on the issue later/tomorrow.
EDIT: 0x027FFE00 isn't related to the DCTM at all. It's the
cartridge header! Gonna implement it now, and tell the results :P
EDIT2: And that does the trick, the cookie is for me!!!!!!!!!!! (Attached screenshot
) Not bad for 4 hours of work
EDIT3 (hopefully, last): Uploaded fix to the CVS.
Last edited by shashClp; February 20th, 2008 at 00:04..