DesMuMe mods !!!

[NHervé]

After some debugging, I remarked that MarioKart calls SWI #3 in ARM9, which means "delay loop". This is not supported by DeSmuME that only returns the cycle count. Shash told me that the MarioKart failure was related to timing, maybe this's because of this opcode that's not implemented correctly.

[refraction]

quite possibly. Give it a go, find out

[shashClp]

Originally Posted by NHervé

After some debugging, I remarked that MarioKart calls SWI #3 in ARM9, which means "delay loop". This is not supported by DeSmuME that only returns the cycle count. Shash told me that the MarioKart failure was related to timing, maybe this's because of this opcode that's not implemented correctly.

I'm not 100% sure if it's related to timing, but I know of the Zelda video Demo having the same bug (CP irq wait hangs the app), and it gets fixed with a bit of timing fixing.

[NHervé]

I think the problem is this SWI #3 : some games call it, but R0 being always 1, this SWI becomes a dummy opcode. Whereas, MarioKart calls this SWI with different values than 1, so the game is executing delays for a special purpose, and it fails probably because DeSmuME doesn't support it. I'll try to implement it and tell you the results (if it works : some beautiful screenshots, else... nothing particular).

[NHervé]

Here's what I could discover after more debugging :
The emu gets caught in a loop. R0 must be 1 for the emu to exit this loop. Each time, the game loads to R0 the content of [PC+0x24] (=0x215122A). R0 is 0x40000, and the game calls SWI #3, then loops to start point, where it first checks if R0 is 1.

[refraction]

isnt R0 suppose to be a constant?

[NHervé]

Are you sure ?

[refraction]

im not sure no, but usually on a system there is a constant register which the value is always 1 in for multiplication/division purposes.

[NHervé]

No, in the NDS, there is no constant register.

[refraction]

so there isnt.

btw if you dont have any proper ARM docs on the cpu's themselves (always better than a tech sheet like the no$gba ones etc) there seems to be some nice ones here

emu-docs: CPU ARM

[Normmatt]

SWI 03h (NDS7/NDS9) - WaitByLoop
Performs a "LOP: SUB R0,1 / BGT LOP" wait loop, the loop is executed in BIOS memory, which provides reliable timings (regardless of the memory waitstates & cache state of the calling procedure). Intended only for short delays (eg. flash memory programming cycles).

r0 Delay value (should be in range 1..7FFFFFFFh)

Execution Time: NDS7: R0*4 cycles, plus some overload on SWI handling.
Execution Time: NDS9: R0*2 (cache on), or R0*8 (cache off), plus overload.
Note: Both NDS7 and NDS9 timings are counted in 33.51MHz units.
Return: No return value.

The current desmume implementation of this software interrupt is incorrect, as in it only returns the arm7 cycles for both cpus.

so here is my fixed implementation (untested).

u32 delayLoop(armcpu_t * cpu)
{
	u32 cycles = 0;
	u32 delay = cpu->R[0] & 0x7FFFFFFF;
	
	if(cpu->proc_ID) 
	{
		cycles = delay * 4;
	}
	else
	{
	
		if((armcp15->ctrl>>12)&1)
		{
			cycles = delay * 2;
		}
		else
		{
			cycles = delay * 8;
		}
	}
	
    return cycles;
}

[NHervé]

Thanks. I'll test it and tell you the result.

EDIT : It doesn't make MarioKart work, but I'm currently debugging this game. I actually found that the ARM9 gets caught in a loop, and the game wants R0 to be 1 to jump out from this loop. I need more debugging to know why R0 is not 1. Maybe it's DMA fault, or timing problem (as Shash said), or even unsupported I/O port or unaligned 32-bit read.

[Low Lines]

I put the SDL in the root folder, load up SM64DS and...

Problem signature:
  Problem Event Name:	APPCRASH
  Application Name:	desmume.exe
  Application Version:	0.0.0.0
  Application Timestamp:	4825a806
  Fault Module Name:	desmume.exe
  Fault Module Version:	0.0.0.0
  Fault Module Timestamp:	4825a806
  Exception Code:	c0000005
  Exception Offset:	000471cb
  OS Version:	6.0.6000.2.0.0.768.3
  Locale ID:	3081
  Additional Information 1:	17ba
  Additional Information 2:	4443eb8d185bad98a0d9398208759c99
  Additional Information 3:	0998
  Additional Information 4:	17751bbd515f9fd87f0026eb0a3a9806

[Normmatt]

Originally Posted by NHervé

Thanks. I'll test it and tell you the result.

EDIT : It doesn't make MarioKart work, but I'm currently debugging this game. I actually found that the ARM9 gets caught in a loop, and the game wants R0 to be 1 to jump out from this loop. I need more debugging to know why R0 is not 1. Maybe it's DMA fault, or timing problem (as Shash said), or even unsupported I/O port or unaligned 32-bit read.

I talked it over with shash and the asm that makes up the original formula for the swi 3 would itself stop looping when r0 = 1; so really that function should set r0 to 1 before returning;

[refraction]

Usage

The SWI instruction is used as an operating system service call. The method used to select which operating system service is required is specified by the operating system and the SWI exception handler for the operating system determines and provides the requested service. Two typical methods are:

* The 24-bit Immediate in the instruction specifies which service is required and any parameters needed by the selected service are passed in the general-purpose registers.

* The 24-bit immediate in the instruction is ignored, general-purpose register R0 is used to select which service is wanted and any parameters needed by the selected service are passed in other general-purpose registers.

Thats from one of them manuals. so from what i see the SWI needs one of 2 options.

1. the instruction calls the service and R0 gives the result (1 for pass, 0 for error etc)
2. R0 is actually the service that it wants to interrupt and the result is like that of 1.

[NHervé]

Here is the routine in asm where MarioKart freezes :
Note : NeonDS seems to freeze on the same routine. The failure is because of a NDS feature not supported by both DeSmuME and NeonDS.

02151202 : ADD R0, R7
02151204 : ADD R1, R6
02151206 : ADD R2, R5
02151208 : ADD R3, R4
0215120A : long branch - set LR
0215120C : long branch - BL 02151288                 //A long routine that must presumably set R0 to 1
0215120E : CMP R0, 1
02151210 : BEQ 0215121A                                  //Exit routine
02151212 : LDR R0, [PC, 14]                               //Set R0 = 00040000
02151214 : long branch - set LR
02151216 : long branch - BL 02000664                  //Just SWI #3
02151218 : B 02151202                                      //Loop to start of routine

EDIT : this routine is executed in Thumb mode.
EDIT2 : it is on the ARM9, and before that routine, R7 is set to 2.

[ShadowPlayer]

Is it possible to speed up this emu?I set frameskips to 9,can I do something else to speed it up?

[NHervé]

ShadowPlayer : of which game are you talking ? If you're not happy of DeSmuME mods, download the sources of DeSmuME and release your mods, you'll see how it's hard.

[ShadowPlayer]

I'm happy with DeSmuMe mods and I know how hard is to make emulator.
Sorry if I said something wrong I just wanted to know is it possible to speed it up because I love playing handheld games on bigger speeds.

[RockmanForte]

Be patient and NHerve and Shash will have speed improvement in the future or go to other emulators or better yet, play them on a real DS. Be patient.