DesMuMe mods !!!

[shashClp]

Originally Posted by dreampeppers99

Some move on DesMuMe project....

Better check again :P

NHervé: I just saw, debugged and tried to hack what you reported, but I've quite a lot to read to see why it's failing and how it should work, as I basically don't know a single bit about the TCM. As of now, I can't get it to work, I'll try harder whenever I've some free time (maybe later, maybe tomorrow, I don't know).

[NHervé]

I've fixed the reversed screens with homebrews, the screens were initialized with wrong offsets (192 for top, 0 for bottom)(old 2d core).

My ITCM implementation starts to work, it does not work with NSMB but it works with my PAlib TextColors demo, with the version 0.7.2 the ITCM is zero-filled, in my desmume it is filled with the good values compared with NeonDS.

[shashClp]

Originally Posted by NHervé

I've fixed the reversed screens with homebrews, the screens were initialized with wrong offsets (192 for top, 0 for bottom)(old 2d core).

Well, I already fixed that on the official CVS almost two weeks ago, and told you so, so you could fix it or update your working copy :P

Originally Posted by NHervé

My ITCM implementation starts to work, it does not work with NSMB but it works with my PAlib TextColors demo, with the version 0.7.2 the ITCM is zero-filled, in my desmume it is filled with the good values compared with NeonDS.

Kudos, I'll work on it later, basically focused on New Super Mario Bros, as it fill the ITCM on startup.

[dreampeppers99]

Originally Posted by shashClp

Better check again :P

Sorry Shash's:
Follow the correction...

Log of /desmume/src/mem.h
(4 hours, 26 minutes ago) by shashclp

- Fixed remaining armwrestler failing opcodes (LDM* mostly), now it's 100% correct, or atleast it does report to be correct (doesn't affect any games that I know of)

Log of /desmume/src/arm_instructions.c
(4 hours, 26 minutes ago) by shashclp

- Fixed remaining armwrestler failing opcodes (LDM* mostly), now it's 100% correct, or atleast it does report to be correct (doesn't affect any games that I know of)

From official CVS ...
Thanks shashClp and NHervé...

[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.

[shashClp]

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:

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.

[dreampeppers99]

Originally Posted by shashClp

Isn't public. Neither I know when it'll be.

Originally Posted by shashClp

And that's all I could discover in 2 hours, I'll try to work more on the issue later/tomorrow.

Originally Posted by shashClp

And that does the trick, the cookie is for me!!!!!!!!!!! (Attached screenshot ) Not bad for 4 hours of work

You rock !!!


See this conversation is very nice...

EDIT3 (hopefully, last): Uploaded fix to the CVS.

Nice!!!

Follow the commited "history" here.

The fix:
- Fix for the freeze on "New Super Mario Bros" minigames, reported by NHerv�. After investigating, I found that the whole ROM header wasn't copied to Main RAM as it's meant to be. This fixes "New Super Mario Bros" minigames, and probably others.

11 hours ago:
The last changes...

Don't lose any minute of that history... (wainting for the next chapters)

Jokes on side, it's good see progress, one more time congratulations Shash's by discovery in 4 hours.

[shashClp]

Originally Posted by dreampeppers99

(...)
Jokes on side, it's good see progress, one more time congratulations Shash's by discovery in 4 hours.

Thanks

[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.

[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!

[shashClp]

Originally Posted by NHervé

shash : you got mini-games to work, congrats and thanks for header info !

No problem, it was fun to debug.

Originally Posted by NHervé

I'll try to fix them and then I'll release mod 2.

Just copy the code you'll find in the CVS. I committed this changes to the official CVS so you didn't have to recode it. Just copy-paste on NDSSystem.c, and done :P

[dreampeppers99]

Originally Posted by MasterPhW

It's always so interesting to read your posts!

I agree totaly...

Originally Posted by MasterPhW

Thanks for sharing that infos with us, was a great read and am still hoping you update your blog in near future!

The future's post... about some comparison... I'll wait it too!!!
Shash's saids before that is very busy when he should has some spare time he can write... anyway it's nice see that content... (high quality)

[NHervé]

I implemented it and got mini-games to work, but they have many graphical bugs, even NeonDS renders better !!! I'll try to fix these bugs and release mod 2.

[dreampeppers99]

Originally Posted by NHervé

I'll try to fix these bugs and release mod 2.

Nice news

[NHervé]

I noticed that Worms2 and Rayman Raving Rabbids 2 don't work at all, it seems they have a problem with this instruction :

STMDA SP!, {R0-R3, R12, LR}

This instruction uses SP register, and when the ARM7 calls it, it is in IRQ mode (mode 12), and the SP reg can change when the proc is in irq mode. I think this is the problem : the SP reg (r13) must be r13_irq and not r13.

EDIT : I don't think this is the problem.

[shashClp]

Originally Posted by NHervé

I noticed that Worms2 and Rayman Raving Rabbids 2 don't work at all, it seems they have a problem with this instruction :

STMDA SP!, {R0-R3, R12, LR}

This instruction uses SP register, and when the ARM7 calls it, it is in IRQ mode (mode 12), and the SP reg can change when the proc is in irq mode. I think this is the problem : the SP reg (r13) must be r13_irq and not r13.

I don't know what you're talking about, and I won't be working on desmume for a while, so you're on your own for this bug :P

[NHervé]

Recently I worked on the GUI, I added a status bar and a tool bar to make it more user-friendly. I've attached a screenshot. Yes, this new GUI is very similar to the GUI of iDeaS, except the screens can't be separated.

[RockmanForte]

I like this GUI looking!