#165724 - hacker013 - Mon Jan 05, 2009 3:31 pm
The code from rebootlib needs the var _io_dldi . But this var doesn't exists anymore with the new libfat so does anybody now how to fix this?
_________________
Website / Blog
Let the nds be with you.
#165726 - Dwedit - Mon Jan 05, 2009 4:31 pm
The symbol changed its name, and moved back 0x60 bytes.
The equate is now named "_io_dldi_stub". To get "_io_dldi" from that, add 0x60 bytes to the address.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#165732 - hacker013 - Mon Jan 05, 2009 6:01 pm
Dwedit wrote: |
The symbol changed its name, and moved back 0x60 bytes.
The equate is now named "_io_dldi_stub". To get "_io_dldi" from that, add 0x60 bytes to the address. |
i get also an error that _io_dldi_stub not exists. maybe you can give some code.
EDIT:
this is my code:
Code: |
extern const u32* _io_dldi_stub;
const u32* _io_dldi = _io_dldi_stub + 0x60; |
Krijg nu deze error: initializer element is not constant.
_________________
Website / Blog
Let the nds be with you.
#165733 - Maxxie - Mon Jan 05, 2009 6:20 pm
hacker013 wrote: |
this is my code:
Code: | extern const u32* _io_dldi_stub;
const u32* _io_dldi = _io_dldi_stub + 0x60; |
Krijg nu deze error: initializer element is not constant. |
uhm not on the actual problem, but your offset is way off.
The 0x60 add, gets 0x60*sizeof(u32) bytes forward (pointer arithmetic with a known type).
_________________
Trying to bring more detail into understanding the wireless hardware
#165735 - hacker013 - Mon Jan 05, 2009 6:24 pm
thx for notice me on that bug but has anyone a fix for that error?
_________________
Website / Blog
Let the nds be with you.
#165739 - samel - Mon Jan 05, 2009 6:49 pm
May be
const u32* _io_dldi = (u32*)(((char*)_io_dldi_stub) + 0x60);
#165740 - hacker013 - Mon Jan 05, 2009 6:50 pm
then I get still the same error
_________________
Website / Blog
Let the nds be with you.
#165741 - samel - Mon Jan 05, 2009 6:54 pm
remove const
#165742 - hacker013 - Mon Jan 05, 2009 7:01 pm
ok, so then i have this code
Code: |
extern u32* _io_dldi_stub;
u32* _io_dldi = _io_dldi_stub + 0x60*sizeof(u32);
|
and still the same error.
_________________
Website / Blog
Let the nds be with you.
#165744 - samel - Mon Jan 05, 2009 7:20 pm
As i understand what Maxxie & Dwedit write && as i say before
const u32* _io_dldi = (u32*)(((char*)_io_dldi_stub) + 0x60);
not
u32* _io_dldi = _io_dldi_stub + 0x60*sizeof(u32);
but may be i'm wrong [ 8p ].
For the other error ... dunno, may be you can post the full error?
#165745 - hacker013 - Mon Jan 05, 2009 7:27 pm
samel wrote: |
remove const |
so i removed const and the error what I post a few posts back was the full error. And the error isn't changed.
_________________
Website / Blog
Let the nds be with you.
#165748 - elhobbs - Mon Jan 05, 2009 7:39 pm
samel - is your code in c++? I think _io_dldi_stub is in a c module. so you may need to use the whole extern "C" business if you are using c++.
#165749 - hacker013 - Mon Jan 05, 2009 7:45 pm
i fixed the error to move the define of the var to an function.
_________________
Website / Blog
Let the nds be with you.
#165765 - chishm - Tue Jan 06, 2009 4:23 am
DLDI is now fully exposed in libnds. Check <nds/arm9/dldi.h> for details, but you want to use dldiGetInternal() then grab a pointer to the ioInterface member.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#165766 - elhobbs - Tue Jan 06, 2009 8:50 am
chishm - is it possible to convert a cluster from fstat into a sector usable directly with dldi? PARTITION does not appear to be exposed anywhere - or am I missing something obvious?
#165802 - chishm - Wed Jan 07, 2009 8:16 am
There's no exposed functionality for doing that, although I really can't see why you want to anyway. For argument's sake, you can pull the PARTITION* for a path using getDeviceOpTab() in <sys/iosupport.h>. The structure isn't publicly defined so you'll need to grab it from the libfat source. This is a bad idea, however, since it is subject to change (when the library is updated) without notice.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#165816 - elhobbs - Wed Jan 07, 2009 3:48 pm
chishm wrote: |
There's no exposed functionality for doing that, although I really can't see why you want to anyway. For argument's sake, you can pull the PARTITION* for a path using getDeviceOpTab() in <sys/iosupport.h>. The structure isn't publicly defined so you'll need to grab it from the libfat source. This is a bad idea, however, since it is subject to change (when the library is updated) without notice. |
I agree it is not the best solution. I was using it to stream data from quake pak files in cquake. and as you can imagine it has caused all sorts of issues as it requires the pak file to be completely defragmented. the issue that I am trying to work around is that the quake pak files are similiar to a tar file, so finding a particular file in the archive requires seeking to an offset in a very large file which is very slow and there is not enough memory to cache all of the data.
I already pulled the code from the libfat source and it does work. I was just trying to avoid that mess if something else was publicly exposed now like dldi. In any case thanks for the response.
#165831 - chishm - Thu Jan 08, 2009 8:02 am
You could try opening two handles to the file. One for reading the table of contents (or whatever a TAR file calls it) and one for seeking to the next file in the table. As long as you only seek forward, libfat won't rescan the entire cluster chain up to that point.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#165834 - elhobbs - Thu Jan 08, 2009 6:45 pm
unfortunately, it is not sequential access. it is random. textures and models need to be swapped in and out of memory as they are needed during game play.