G6 driver debugging

viruseb · Post by **viruseb** » Thu Feb 15, 2007 7:30 pm

Hi,
I'm currently tring to see wh the G6 drivers doens't work so well with scummvm.
So I patched scummvm beta 3 with the G6 dldi v0.16, saved a dott game and observed that it didn't work.
To debug I added manually the G6 driver into scummvm code and voila! it work.
To be sure that it's dldi related I need people to test this version of scummvm.
http://www.gigeshare.com/preview/1f88a2 ... 27ng71a5a/
As there is already the G6 driver inside the .nds there is no need to patch, just copy-paste the .nds into the NDS directory of your G6.
And don't forget to make a backup of all your savegames before !

Grimgoil · Post by **Grimgoil** » Thu Feb 15, 2007 8:32 pm

I'll give it a run through with sam and max and see if it does the same problem in the last area, is this NDS file scummvm A?

viruseb · Post by **viruseb** » Thu Feb 15, 2007 9:00 pm

yep it's the A

agentq · Post by **agentq** » Thu Feb 15, 2007 9:15 pm

As far as I know, the DLDI code should act exactly the same way as any driver compiled into the code. So what could be different about it?

Is it perhaps a bug in the patcher?

There must be a reason why all the other DLDIs work, right?

viruseb · Post by **viruseb** » Fri Feb 16, 2007 7:17 am

agentq wrote:As far as I know, the DLDI code should act exactly the same way as any driver compiled into the code. So what could be different about it?

Is it perhaps a bug in the patcher?

There must be a reason why all the other DLDIs work, right?

I agree with you. The only reason I can think of is I made a bad copy paste while doing the DLDI driver

I'll see this tonight after work.

Grimgoil · Post by **Grimgoil** » Sat Feb 17, 2007 12:27 pm

Well as to the specific Problem i had with Sam and Max, your tweak did the job - while going into the map cut scene it dosent get stuck and ruin the saves. So many thanks, and i hope this info helps.

viruseb · Post by **viruseb** » Sat Feb 17, 2007 12:52 pm

I rewrote the G6 dldi yesterday just to be sure and again same behavior. The dldi version doesn't work whearas the one integrated directly in libfat work.
I'm a bit puzzled at the moment. Keep posted !

agentq · Post by **agentq** » Sun Feb 18, 2007 1:38 am

The G6 source code on chishm's FAT page still has unaligned data issues. Is this an old version? If not, it would explain things.

viruseb · Post by **viruseb** » Sun Feb 18, 2007 10:13 am

agentq wrote:The G6 source code on chishm's FAT page still has unaligned data issues. Is this an old version? If not, it would explain things.

No It's a new version I wrote with unaligned support

agentq · Post by **agentq** » Sun Feb 18, 2007 10:22 pm

The source code on Chishm's page is clearly not going to work for byte-aligned data:

Code: Select all

bool writeSectors &#40;u32 sector, u32 numSectors, void* _buffer&#41; &#123;
	bool retval;
	u16 numsectowrite;
	int nbsecwrite;
	u16 *buffer = &#40;u16 *&#41;_buffer;     // This line will cause problems if _buffer is not at an even address!

viruseb · Post by **viruseb** » Mon Feb 19, 2007 8:23 am

agentq wrote:The source code on Chishm's page is clearly not going to work for byte-aligned data:
Code: Select all
bool writeSectors &#40;u32 sector, u32 numSectors, void* _buffer&#41; &#123;
	bool retval;
	u16 numsectowrite;
	int nbsecwrite;
	u16 *buffer = &#40;u16 *&#41;_buffer;     // This line will cause problems if _buffer is not at an even address!

Interesting, could be the problem. Will look at this.
After checking in asm this is not a problem since the compiler doesn't modify the register that hold void* _buffer (R2 here).

Code: Select all

.text&#58;000026E4                 MOV     R4, R2
.text&#58;000026E8 loc_26E8         ; CODE XREF&#58; writeSectors+E4j
.text&#58;000026E8                 MOV     R0, R6
.text&#58;000026EC                 MOV     R1, R5
.text&#58;000026F0                 MOV     R2, R4
.text&#58;000026F4                 BL      WriteBlockFunc  ; PIC mode

agentq · Post by **agentq** » Mon Feb 19, 2007 10:03 pm

It might not modify the register, but that's only half the problem. What about when you deference the pointer? The ARM cpu cannot deference a misaligned u16*. If you have one, you will end up in trouble.

Take another look at the code and you will see that this does happen:

Code: Select all

void static DMAWriteWordData&#40;u16 buffer&#91;&#93;,u32 nbword&#41;
&#123;
	u16 word,wordanc;
	u32 i;

	for &#40;i=0;i<nbword;i++&#41; 
		WriteWordData&#40;buffer&#91;i&#93;&#41;;   // buffer&#91;i&#93; won't evaluate correctly if buffer&#91;&#93; is misaligned

viruseb · Post by **viruseb** » Tue Feb 20, 2007 8:14 am

I will see into this.

Grimgoil · Post by **Grimgoil** » Sun Mar 04, 2007 3:39 pm

any news?

viruseb · Post by **viruseb** » Sun Mar 04, 2007 4:07 pm

Just found the last bug 5 min ago. Have to finish some test and I'll post the g6fl.dldi V0.17