DesMuMe mods !!!

[shashClp]

Originally Posted by RockmanForte

(...) Some people work on the emulator then gave up and release source which is sad.

If you're talking about me, you should check this, if not, sorry for the assumption :P

[NHervé]

I don't want to give up. I want to make of this the perfect emu, which can run all games without any bug and fast. But when it'll be, Nintendo surely had release the next-generation handheld, maybe DS II. Making a perfect emu takes a long time.

[RockmanForte]

Originally Posted by shashClp

If you're talking about me, you should check this, if not, sorry for the assumption :P

Don't worry. I am not talking about you. I have every news on my note. To my point of view, you are doing just fine.

Originally Posted by NHervé

I don't want to give up. I want to make of this the perfect emu, which can run all games without any bug and fast. But when it'll be, Nintendo surely had release the next-generation handheld, maybe DS II. Making a perfect emu takes a long time.

Great! Then don't give it up.

Yes, there is no maybe. There is planning for next update of DS this summer.

[NHervé]

Well, all VRAM handling should be rewritten...
In NSMB, the mini-games have bad sprites due to faulty VRAM handling...
I found how do they work :
They map the bank D as BOBJ and I as <Disabled> and write the sprite data in BOBJ, then they map bank D as LCD and bank I as BOBJ, and write in BOBJ some data for the pause buttons, and finally map bank D as BOBJ and I as LCD. When I press A (pause), the bank D gets mapped as LCD and the bank I as BOBJ.

So I can say that the sprite data must be at 0x06860000 (LCD+0x60000, bank D) and button data must be at 0x068A0000 (LCD+0xA0000, bank I).

[NHervé]

I was reading the earlier posts...
When I talked about the RRR2 bug in the 3D core, Shash said it was not the 3D core. It was the 3D core, because the game sends the 3D commands in big-endian (ie : 0x1B000000 instead of 0x0000001B). The 3D core was designed for standard commands (0x0000001B), because of the NOPs being before the cmd, the 3D core was not shifting the command container and missing the command. After that it was interpreting the params as commands and was being completely messed up. Stupid bug, but not so simple to find.

[NHervé]

Mod 3 is out !!! Don't wait anymore !!! Come download it !!!

[shashClp]

Your fix for the depth clearing is faulty, it basically pushes the maximum depth to an unreasonable distance, with a maximum of 511, when the farthest distance on openGL after the modelview projection is 1, thus it will fail on any case of an .nds abusing it.

[dreampeppers99]

shashClp always seeing every thing...

NHervé good job

[refia]

Wonderful job! FF4DS could play now,but the speed is too slow......
Still can't play DQ4DS,BTW.

[NHervé]

Shash : I see you don't waste your time, the first thing you did when you saw the mod 3 is looking at the sources.
My depth fix is accurate, compared to Nocash specs, and it is correct.
You're wrong, I did the operation for the max possible depth (0x7FFF, not 0x7FFFF as it is in your source : 0x7FFF = 32767; 0x7FFFF=524287; that differ a lot), the result is giving 0xFFFFFF, which is divided by (1<<24)(=0x1000000), so the result CANNOT overflow 1.0 .
Check your code :
The good func (mine) is :

void NDS_glClearDepth(unsigned long v)
{
	u32 depth24b;

	v		&= 0x7FFF;
	depth24b = (v*0x200)+((v+1)/0x8000)*0x1FF;

	glClearDepth(depth24b / ((float)(1<<24)));
}

whereas your func is :

void NDS_glClearDepth(unsigned long v)
{
	u32 depth24b;

	if(beginCalled)
		glEnd();

	v		&= 0x7FFFF;
	depth24b = (v*0x200)+((v+1)/0x8000);

	// Using 23 instead of 24 fixes SM 64 DS
	glClearDepth(depth24b / ((float)(1<<23)));

	if(beginCalled)
		glBegin(vtxFormat);
}

As you can see, in your func, the depth is ANDed with 0x7FFFF instead of 0x7FFF, so your final depth overflows on informations about CLRIMAGE_OFFSET, that are garbage in this case. You got Mario64 to render correct with your hack that consists into dividing the final depth by (1<<23) instead of (1<<24), but some games could render incorrect on your code, whereas they will render correct on my code, because your final depth will contain garbage.
Check here :
Specifications

4000354h - CLEAR_DEPTH - Clear Depth Register (W)
0-14 Clear Depth (0..7FFFh) (usually 7FFFh = most distant)
15 Not used
16-31 See Port 4000356h, CLRIMAGE_OFFSET


The 15bit Depth is expanded to 24bit as "X=(X*200h)+((X+1)/8000h)*1FFh".

[shashClp]

Ouch, I stand corrected, I don't know why I ignored the nocash documentation when I implemented, good find

Btw, of course I look first at the sources, I'm a coder, I'm way more interested on code than final result XD

[NHervé]

You didn't ignore totally the Nocash doc when you implemented it.
Your operation to convert the depth to 24-bit is almost the same as on Nocash doc.
Anyway it's great you recognized it. Don't forget to credit me when you'll commit your correct fix to your CVS.

[ShadowPlayer]

great work NHerve,just keep it up

Pokemon Diamond is still not playable but I get this error message(see screenshot)

[NHervé]

Shash : just another thing : your code to support flipped-repeat textures work great, but there's a simpler way to do this. Look at the SetupTexture func found in opengl_collector_3Demu.c (I use this func in my core), it simply uses GL_MIRRORED_REPEAT.

ShadowPlayer : strange problem indeed. I think the problem is the emu returning a wrong value (unsupported I/O port or unaligned read, they are badly supported even if marked OK by ArmWrestler) and this value being loaded to PC. The value being wrong, PC gets wrong too, and the emu executes the content of a memory region that's not meant to contain code, but data.

[Hard core Rikki]

Not to sound like an a**, but some of this technical exchange might be more appropriate in private messagery or IRC. Just a note.

[shashClp]

Originally Posted by NHervé

Shash : just another thing : your code to support flipped-repeat textures work great, but there's a simpler way to do this. Look at the SetupTexture func found in opengl_collector_3Demu.c (I use this func in my core), it simply uses GL_MIRRORED_REPEAT.

I'll check it. I searched for an extension that did that, but didn't found it (or only some Matrox hardware supported it, I can't remember). I guess I'm forgetting the fixed pipeline after moving to shaders :P

Originally Posted by Hard core Rikki

Not to sound like an a**, but some of this technical exchange might be more appropriate in private messagery or IRC. Just a note.

Why, having some technical and intelligent discussion is forbidden in a release thread? Not to sound like an a** too, but I prefer this over messages with "LOL" all over or "Mmm ***". This being a NHervé's thread without any violation of the rules, I can't see any proble

[NHervé]

Shash : GL_MIRRORED_REPEAT is defined in glext.h . Apparently, you don't need anything other.
I'm currently working on unaligned LDRs, I got ArmWrestler to mark them OK, but I think they are still not correct, some games displaying "undefined ARM instruction x" msg, probably due to unaligned LDRs returning wrong data. Maybe this is why RaymanDS isn't still working. (this game performs some unaligned LDRs at start, maybe these data are used later, after the 3rd intro screen).

Hard core Rikki : this is my thread, and this isn't against the forum rules. I know that normal people don't understand half of what we're discussing here.

Shash : how did you fix the LDRs in your emu ? In your arm_instructions.c file, they are still using the bad ROR macro.
I think unaligned reads could be the problem of RaymanDS, but I'm not sure at all. I don't know why it doesn't go over the 3rd intro.

[dreampeppers99]

Well I agree with shashClp... this discussion don't "hurt" any rule ... anyway this is a emulation forum :S

("I know that normal people don't understand half of what we're discussing here") but those that understand... ;D even the minor

[NHervé]

Shash : I implemented low-power mode for ARM9, but RaymanDS still doesn't work. It's driving me nuts. I tried to log the opcodes, but, when logging is enabled, the emu logs for about 20 seconds and then crashes, giving a log that's not interesting. I wonder what's the problem.

And, what do you mean by "timing problem" ? I guess that the IRQs don't happen when they should do.

[refraction]

Originally Posted by NHervé

Shash : I implemented low-power mode for ARM9, but RaymanDS still doesn't work. It's driving me nuts. I tried to log the opcodes, but, when logging is enabled, the emu logs for about 20 seconds and then crashes, giving a log that's not interesting. I wonder what's the problem.

And, what do you mean by "timing problem" ? I guess that the IRQs don't happen when they should do.

it could be related to what i think i said earlier in terms of timing. Its common fact, when someone happens on the hardware, its never instant, so you need a delay on the interrupt to simulate the processing time. How long this is i dont know, but it might be worth having an internal timer system which waits xcycles * size for the dmas or what have you, to simulate the bus transfer time.