G6 driver debugging

Subforum for discussion and help with ScummVM's Nintendo DS port

Moderator: ScummVM Team

viruseb
Posts: 14
Joined: Tue Feb 06, 2007 7:44 am

G6 driver debugging

Post by viruseb »

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 !
User avatar
Grimgoil
Posts: 11
Joined: Sat Sep 23, 2006 11:24 am

Post by Grimgoil »

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
Posts: 14
Joined: Tue Feb 06, 2007 7:44 am

Post by viruseb »

yep it's the A
agentq
ScummVM Porter
Posts: 805
Joined: Wed Dec 21, 2005 4:29 pm
Location: London, UK

Post by agentq »

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
Posts: 14
Joined: Tue Feb 06, 2007 7:44 am

Post by viruseb »

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.
User avatar
Grimgoil
Posts: 11
Joined: Sat Sep 23, 2006 11:24 am

Post by Grimgoil »

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
Posts: 14
Joined: Tue Feb 06, 2007 7:44 am

Post by viruseb »

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
ScummVM Porter
Posts: 805
Joined: Wed Dec 21, 2005 4:29 pm
Location: London, UK

Post by agentq »

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
Posts: 14
Joined: Tue Feb 06, 2007 7:44 am

Post by viruseb »

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
ScummVM Porter
Posts: 805
Joined: Wed Dec 21, 2005 4:29 pm
Location: London, UK

Post by agentq »

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

Code: Select all

bool writeSectors (u32 sector, u32 numSectors, void* _buffer) {
	bool retval;
	u16 numsectowrite;
	int nbsecwrite;
	u16 *buffer = (u16 *)_buffer;     // This line will cause problems if _buffer is not at an even address!
viruseb
Posts: 14
Joined: Tue Feb 06, 2007 7:44 am

Post by viruseb »

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

Code: Select all

bool writeSectors (u32 sector, u32 numSectors, void* _buffer) {
	bool retval;
	u16 numsectowrite;
	int nbsecwrite;
	u16 *buffer = (u16 *)_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:000026E4                 MOV     R4, R2
.text:000026E8 loc_26E8         ; CODE XREF: writeSectors+E4j
.text:000026E8                 MOV     R0, R6
.text:000026EC                 MOV     R1, R5
.text:000026F0                 MOV     R2, R4
.text:000026F4                 BL      WriteBlockFunc  ; PIC mode
agentq
ScummVM Porter
Posts: 805
Joined: Wed Dec 21, 2005 4:29 pm
Location: London, UK

Post by agentq »

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(u16 buffer[],u32 nbword)
{
	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
Posts: 14
Joined: Tue Feb 06, 2007 7:44 am

Post by viruseb »

I will see into this.
User avatar
Grimgoil
Posts: 11
Joined: Sat Sep 23, 2006 11:24 am

Post by Grimgoil »

:?: any news?
viruseb
Posts: 14
Joined: Tue Feb 06, 2007 7:44 am

Post by viruseb »

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