#120334 - Lick - Fri Mar 02, 2007 11:58 pm
Link: http://lickr.org/libreset
The above link will take you to the official libreset page. There you will find all the modified DLDIs, including the source code. You will also find reset.h, which is the file that you will need to add to your project to make use of the modified DLDIs.
Please refer to the example project to see how to code with libreset.h! Code explains better than anything!
Also, remember to patch with the modified DLDIs. Or else it will not reset.
- Lick
_________________
http://licklick.wordpress.com
Last edited by Lick on Sat Mar 03, 2007 12:20 pm; edited 1 time in total
#120350 - dantheman - Sat Mar 03, 2007 3:04 am
So does this mean that the end-user will need to have two different sets of DLDI files available? Or do you plan to eventually have these replace the official ones on Chishm's site?
#120367 - felix123 - Sat Mar 03, 2007 6:09 am
Nice work!
Would copying what the NoPass software does help you write a universal reset library?
_________________
Nintendo DS homebrew on Wikipedia
#120378 - Lick - Sat Mar 03, 2007 11:57 am
Well I thought about it some more and do you guys think it's too much of a hassle?
Would it be better to simply continue on with libcartreset and leave the DLDI for what it was designed for (FAT)?
It sucks to have done wrong, but if it's wrong, I need to cut it off as soon as possible.
Update I am officially taking this library down. I will continue libcartreset instead.
- Lick
_________________
http://licklick.wordpress.com
#120379 - MelGibson - Sat Mar 03, 2007 1:01 pm
The problem is that Cardreset and FAT-Access are not really related to each. Still they are both device specific functions. What imho will happen now with libcartreset, is that a homebrew programm will be statically able to reset but will have FAT-access dynamically through the dldi interface.
I personally think it is a better solution to have reset and fat access in one dldi file. So both reset and fat access is managed through a patch and can be changed to a specific device withouth having to recompile the whole programm....
Of course it would be possible to have a dldi style solution for cardreset as well. So one patcher for reset and another one for fat access...
Or some patcher that combines fat.dldi + reset.dldi to both.dldi.
Thus one person can concentrate on the resetting stuff and anothe on the fat-access stuff
#120381 - chishm - Sat Mar 03, 2007 2:08 pm
The way it was being done with the DLDIs is fine. That's what the shutdown function is intended for (to take the device back to its initial state).
However, you don't need to patch the ROMs. You could simply have little binary files that are loaded, using libfat, into memory. You then jump to that loaded code, execute it and jump back. The only reason DLDI is needed is because it is not possible to load code from a disc without the driver for that disc.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#120382 - tepples - Sat Mar 03, 2007 2:13 pm
| chishm wrote: |
| However, you don't need to patch the ROMs. You could simply have little binary files that are loaded, using libfat, into memory. |
Loaded from where in the file system?
| Quote: |
| The only reason DLDI is needed is because it is not possible to load code from a disc without the driver for that disc. |
And because there is no argv[0] on the DS.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#120386 - Lick - Sat Mar 03, 2007 2:42 pm
I think it's easier to simply use the DKA r20 method to detect the devicetype and have a function like
Anyway, never mind this whole libreset thing. It's just more work for everybody.
_________________
http://licklick.wordpress.com
#120400 - Doom5 - Sat Mar 03, 2007 5:50 pm
Damn, I should have downloaded it while it was still up. Did anyone manage to download the source before it was pulled?
#120401 - Lick - Sat Mar 03, 2007 5:53 pm
Doom5: http://lickr.org/libreset-old
I'm not going to work on it anymore, though. libcartreset will be back.
_________________
http://licklick.wordpress.com
#120411 - dantheman - Sat Mar 03, 2007 7:15 pm
I didn't mean to discourage you Lick. Sorry if it came out that way.
I just have a question: which of the two options would be more likely to be implemented in more applications? Considering that you have to implement the library in some form to begin with, it's probably the same, right? If the DLDI system made it so that users could just patch their current homebrew with your modified DLDI files and automatically gain reset support, then I would greatly encourage the DLDI system. However, you said that the developer has to implement reset.h before the modified DLDI files will take effect, there's probably little difference, correct?
I like the reset functionality, but unfortunately too few homebrew applications make use of it. Even LMP-ng doesn't use it (as far as I can tell) which is a shame. I guess the best solution would be to talk to the developers of the applications and request that they implement your library.
#120430 - Tantrum - Sat Mar 03, 2007 8:37 pm
| dantheman wrote: |
| I just have a question: which of the two options would be more likely to be implemented in more applications? |
The one that causes the author and users the least long term support issues :) Which is exactly why DLDI came into being. So that new drivers didn't have to be implemented by the author. As soon as the author implements support, it's supported for all drivers for all time.
What we have at the moment is a situation where DLDI == FAT support. Whereas DLDI should, IMHO, really be a HAL with a variety of hardware drivers of various sources fulfilling the interfaces to support specific actions (FAT, Reset, etc). Each card would then have a 'pack' of HAL drivers to patch in. These could support FAT, Reset, etc.
What etc, you may ask? How about,
- a common interface to unlock and give info on the use of RAM expansion offered by various slot-2 carts? (offsets, banking, 8/16/32 bit write and read limitations)
- a common interface to rumble so that it needn't be hardware compatible with the original rumble.
- a common interface to accelerometers that reports the axis available (2-axis, 3-axis, resolution, range).
- a common interface to SRAM. Could either go to real SRAM or get written to your FAT device.
With all hardware drivers going thru a single interface layer it would making adding support for it in DS emulators easier, too. Instead of the author needing to emulate the function of a specific device, they just emulate the HAL interface (usually a lot easier).
It may also encourage hardware makers to be more inventive by not having to worry so much about keeping hardware compatible with existing similar devices or previous iterations of the same hardware.
#120434 - HyperHacker - Sat Mar 03, 2007 9:02 pm
Tantrum seems to have the right idea. A HAL would be a huge help for those who want to use card-specific functions such as reset and rumble, and we already have DLDI handling FAT. Building onto libFAT to add these things seems like the ideal method. However, this relies entirely on whether chishm wants to do this, as it would be a bit beyond the scope of libFAT and would increase the binary size.
If nothing else, will we see the "load reset code from a file" method implemented? As I'm working on what I hope will one day be a replacement firmware, I'm trying to keep the code as small as possible, and having the binary support only one card at a time is a huge help.
_________________
I'm a PSP hacker now, but I still <3 DS.
#120460 - Tantrum - Sat Mar 03, 2007 10:56 pm
| HyperHacker wrote: |
| If nothing else, will we see the "load reset code from a file" method implemented? As I'm working on what I hope will one day be a replacement firmware, I'm trying to keep the code as small as possible, and having the binary support only one card at a time is a huge help. |
hehe, I missed Chishms suggestion earler in the thread about putting them in a file and just finding it via FAT. That would do it, and a lot less painfully too. You'd then just have driver libraries suitable for your hardware that would be loaded dynamically by the app. Cool. O_o Must read more carefully in future o_O
So what we actually need is a framework for the creation and loading of dynamic libraries - does one exist already for the DS? I've no idea how to go about generating relocatable library code and loading it dynamically, but I suspect someone around here will have the expertise and that the toolchain can already do most of what is necessary.
Last edited by Tantrum on Sun Mar 04, 2007 2:49 pm; edited 1 time in total
#120476 - tepples - Sun Mar 04, 2007 2:00 am
| Tantrum wrote: |
| hehe, I missed Chisms suggestion earler in the thread about putting them in a file and just finding it via FAT. That would do it, and a lot less painfully too. You'd then just have driver libraries suitable for your hardware that would be loaded dynamically by the app. Cool. |
But from what path on the CF or SD card? Currently, the lack of argv[0] means you can't just put the driver in the same folder as the .nds file.
| Quote: |
| So what we actually need is a framework for the creation and loading of dynamic libraries - does one exist already for the DS? I've no idea how to go about generating relocatable library code and loading it dynamically, but I suspect someone around here will have the expertise and that the toolchain can already do most of what is necessary. |
There is such a framework as part of DSOrganize.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#120479 - chishm - Sun Mar 04, 2007 2:19 am
| tepples wrote: |
| Tantrum wrote: | | hehe, I missed Chisms suggestion earler in the thread about putting them in a file and just finding it via FAT. That would do it, and a lot less painfully too. You'd then just have driver libraries suitable for your hardware that would be loaded dynamically by the app. Cool. |
But from what path on the CF or SD card? Currently, the lack of argv[0] means you can't just put the driver in the same folder as the .nds file. |
That doesn't matter. The same reset binary would be usable by a number of programs, so you'd use a common path, like /libs/. They'd basically be DLLs.
Of course, we'd need to design the system to prevent conflicts (DLL hell). This could be done by putting the version number in the file name, like "/libs/reset-100.dsl" (.dsl stands for "DS library").
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#120532 - Tantrum - Sun Mar 04, 2007 1:45 pm
| chishm wrote: |
| Of course, we'd need to design the system to prevent conflicts (DLL hell). This could be done by putting the version number in the file name, like "/libs/reset-100.dsl" (.dsl stands for "DS library"). |
Yeah, we could obviate some of that Hell in two ways,
Firstly, the apps themselves don't load the libs directly, they call some support code that would load the latest api compatible version of the library. When loading a library you'd specify the base name of the lib and the major version number. The support code would then load the latest revision of that major version. Therefore, if there's an API change in a lib then the major version number must be bumped. That way you can have multiple major versions and the latest revision of each stored in /libs/. It also mean you can up/downgrade without having to rename the files.
Secondly, having an app that identifies your hardware (either automagically or by picking from a list) and downloads the latest drivers from a central repo. Of course, that means _having_ a central repo :)
This may also be a way of supporting multiple FAT devices, too. Your primary FAT driver is patched in the usual DLDI way, but additional FAT drivers could be loaded via the dynamic library route. Pure speculation on my part, there may be a easier/cleaner way of dong it :)