Trouble with Dualis and latest libnds..

[tekknow]

Hi,

 

I think I found an issue when using the latest libnds with newer Dualis versions.. I don't know what the exact issue is, but I have a way to duplicate easily if it'll help.

 

Basically it looks as though either it's not outputting what it's supposed to be, or it's locking up (printf statements).

 

All that's needed for this is one of the examples from the libnds package and chishm's fat library. The library won't actually be used for anything, it's more just to be compiled in and to make the file larger (which seems to cause the actual problem?)

 

Two things.. (1) This is gonna be a copy/paste from my previous post over at gbadev, because I'm feeling lazy. =) (2) I'm wondering if this might be the same issue that alekmaul is seeing (see post "Chism FAT drvier and Dualis r19.1 & 20"), as I first noticed this problem with my app which is using the fat driver, and I noticed that I was having trouble with the FAT_fseek operation also. Basically there was a final divison in the function that was coming out to 0, you'll see parts of that function in my example below.

 

Take the original "examples\nds\graphics\2d\hello_world\" project from the latest libnds and make a copy of it naming it something else.. (You could probably create a new file from scratch, this way is just easier.) In the main.cpp, 'replace' the following..

 

iprintf(" Hello DS dev'rs\n"); 
iprintf(" www.devkitpro.org\n"); 
iprintf(" www.drunkencoders.com\n\n"); 

int clusCount; 
u32 position; 
u32 curPos; 
int curSect; 
int curByte; 
int filesysBytePerSec; 
int filesysBytePerClus; 

position = 0x4a095; 
curPos = 0x0; 
curSect = 0x0; 

filesysBytePerSec = 0x200; 
curByte = 0x0; 
filesysBytePerClus = 0x2000; 

clusCount = (position - curPos + (curSect * filesysBytePerSec) + curByte) / filesysBytePerClus; // Fixed thanks to AgentQ 

iprintf("test: 0: %lx\n", (position - curPos + (curSect * filesysBytePerSec) + curByte)); 
iprintf("test: 1: %lx\n", filesysBytePerClus); 
iprintf("test: 2: %lx\n", (position - curPos + (curSect * filesysBytePerSec) + curByte) / filesysBytePerClus); 
iprintf("test: 3: %lx\n", 0x4a095/0x2000); 

iprintf("test: 0: %d\n", (position - curPos + (curSect * filesysBytePerSec) + curByte)); 
iprintf("test: 1: %d\n", filesysBytePerClus); 
iprintf("test: 2: %d\n", (position - curPos + (curSect * filesysBytePerSec) + curByte) / filesysBytePerClus); 
iprintf("test: 3: %d\n", 0x4a095/0x2000); 

while(1) {} 

return 0;

 

The printf's at the top and "return 0;" at the bottom are from the original file to give you an idea of where this is pasted into the file (pretty much replacing the while loop from the original.)

 

Nothing will be done with fat library files yet, so don't compile them into the project yet.

 

You can them save/make/run the prog.. On my machine (Dualis) I got this as my output:

 

test: 0: 4a095 
test: 1: 2000 
test: 2: 25 
test: 3: 25 
test: 0: 303253 
test: 1: 8192 
test: 2: 37 
test: 3: 37

 

Which is what I expected.

 

Now you can do a make clean and then add the files from chishm fat library to the project.. (all the *.h files in the \include folder and all the *.c files into the \source folder). The main.cpp shouldn't reference the other files in anyway, which is fine. When make is run on the project, it should compile ok, basically just increasing the filesize of the final nds. Now when I run this program in Dualis I get this...

 

test: 0: 4a095 
test: 1: 2000 
test: 2: 25 
test: 3: 25

 

The outputs are right, there's just stuff missing.. In my original program (which is a big mess, but that's another problem) I have other issues where it will even output the wrong values in some cases..

 

 

If I compile this program (or my original) against the r17 libnds, everything is fine.

 

Hope this isn't too confusing, it's kinda early.

[Robert]

which Dualis version exactly... mic fixed some issues in 20.1

[tekknow]

which Dualis version exactly... mic fixed some issues in 20.1

<{POST_SNAPBACK}>

 

Sorry, I thought I had that in the original post. I was using 20.1 for the above test, but I have also walked back to version 18.2 and it does the same thing there.

[mic]

MightyMax also has reported problems when using FAT_fseek. I have yet to find out the cause of this.

[mic]

Well, I fixed this bug (I think). It was not a problem directly with fseek or iprintf but with unsigned divisions using the division swi.

[tekknow]

Well, I fixed this bug (I think). It was not a problem directly with fseek or iprintf but with unsigned divisions using the division swi.

<{POST_SNAPBACK}>

 

Unfortunately, at least for me, it still doesn't seem to be working. I'm still not getting the output from the %d iprintf statements.

[mic]

I fixed it after 20.2 was released, so the fixed version is not yet available.

Edited May 1, 2006 by mic

[tekknow]

I fixed it after 20.2 was released, so the fixed version is not yet available.

<{POST_SNAPBACK}>

 

Oh.. well.. that explains why it's not working for me.