[MasterPhW]

Originally Posted by shashClp

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:

1. 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.
   
   
   
2. 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.
   
   
   
3. 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.

It's always so interesting to read your posts!
Thanks for sharing that infos with us, was a great read and am still hoping you update your blog in near future!

Originally Posted by NHervé

shash : you got mini-games to work, congrats and thanks for header info !
I'll try to fix them and then I'll release mod 2.

Nice, looking forward to it! It's great to see some improvements over the public desmume source aswell! Hope you won't stop that fast!

__________________

The Future of Emulation: Emulate a High End Computer on a Low End System
Current PC specs:
Portable: Intel C2D T7250 (2x2.0Ghz, 800Mhz) | 2048 MB DDR2 PC800 | Geforce Go 7950 GTX PCI-E | Realtek HD Audio |
180Gbyte Internal SATA2 + 4x500GB external | Windows Vista Business X64 MSDNAA
Desktop: AMD Athlon 64 X2 4200+ (2x2.5Ghz, S939) | MSI KbT Neo2-F V2.0
| 2x1GB Corsair Value VS1GBKIT400 | MSI Geforce NX 7800GS-TD256/AGP8x
| Creative SB Audigy LS | 2,5TB (4 SATA2 HDDs in Raid0) | Windows Vista Business MSDNAA

Visit my Blog