#115156 - DragonMinded - Sat Jan 13, 2007 11:21 am
Hi. Shameless plug here, but since there were several parties interested in adding on to DSOrganize, and there is now a relatively easy way to do so, I figured people might want to hear about it.
As you are aware, I am coding again. As you might not be aware, there are two new file formats recognized in DSOrganize: .dsp and .dse. The stand for DSOrganize plugin and DSOrganize executable, respectively. I encourage any of you out there interested in developing an application that deals with specific file extensions (such as an emulator) to consider the DSOrganize plugin framework as an option.
Why should I use your stupid plugin framework anyway?
Good question. There are several reasons. First being that there is already a rich API provided in DSOrganize plugins that you would have to implement on your own if you started from scratch. For example, libFB is already implemented for you. Wifi is already set up, and even includes commands to fetch an html page given a url. The FAT library is available to you as well, and since DSOrganize has already started, FAT is guaranteed to at least read, with no init time! The sound API for DSOrganize is robust and allows you to play back any supported extension or stream with a single line of code in your plugin. For those writing emulators who don't want to set up sound streaming to arm7, there is anther API call you can use that sets up streaming for you! Also, why code a file browser from scratch when you can use the robustness of DSOrganize to find your files? Lastly, as homebrew launching from other homebrew is crappy at best, creating a plugin would cause less headache for the community as people can launch your plugin from any card, and return seamlessly to DSOrganize when they finish.
Wow. You make it sound perfect. What's the catch?
Of course it's not perfect. Nothing is. First off, you have no access to the arm7. While this isn't a huge deal, you can't take some of the load off to the arm7. Also, if someone doesn't want to use DSOrganize, you wouldn't be able to provide an alternative to them. Also, the PSG is not currently available, neither is the microphone, but if enough demand for these arises, I will add them. Lastly, since DSOrganize stays loaded in the background, you don't have the full 4MB of ram to play with.
Ok, so why standalone EXE files too?
Simple, because not all DSOrganize addons call for a specific file type to manipulate. The DSOrganize executable format includes all of the API from the plugin framework, while being launched simply by loading the file from the browser, in any directory. Again, a major advantage goes to mini-apps. Also, in the future, page three of the home screen will have customizable shortcuts that can call a DSOrganize EXE, creating a seamless addition to DSOrganize that the userbase can enjoy.
Well, hopefully this causes a few people to consider coding for the DSOrganize plugin formats, as this feature (IMO) is too cool to waste. To get started, download the Plugin Framework or the Executable Framework.
Please drop me a line or leave feedback here if you have any questions or comments!
_________________
Enter the mind of the dragon.
http://dragonminded.blogspot.com
Seriously guys, how hard is it to simply TRY something yourself?
#115170 - strager - Sat Jan 13, 2007 2:45 pm
Using the plugin template, I was unable to compile successfully...
I get the following after entering make:
| Code: |
crt0.s
link start
/usr/share/devkitpro/devkitARM/bin/../lib/gcc/arm-eabi/4.1.1/../../../../arm-eabi/bin/ld: error: no memory region specified for loadable section `.ARM.extab'
collect2: ld returned 1 exit status
make[1]: *** [/home/strager/projects/nds/dsoshadow/arm9.so] Error 1 |
Perhaps something is missing from the linker script?
Also, I would like to ask, is it possible to "overlap" plugins? As in, associate a plugin with a type, but have another plugin preprocess the file first? Or perhaps pass on a file to another plugin? Some IRC clients allow plugins, and they can "catch" a command (like /me) and preprocess it first. Preprocessing does not necessarily have to change the input in any way; it might log something to a file or something.
I believe this plugin idea is great. Hopefully some real neat plugins could be made to make DSO even stronger...
#115179 - user6336 - Sat Jan 13, 2007 3:15 pm
This is such a good idea! Now coders can work on coding stuff without having to worry about card compatibility! Since this program is really starting to branch out, you should think about renaming it to something more general, like 'DS Shell' or something that has to do with your name.
#115198 - dantheman - Sat Jan 13, 2007 5:41 pm
Well, to be fair, card compatibility problems are pretty much eliminated due to the DLDI system, but I do agree that this plugin system could be very useful.
Last edited by dantheman on Sat Jan 13, 2007 6:18 pm; edited 1 time in total
#115202 - tepples - Sat Jan 13, 2007 6:13 pm
DragonMinded: Do you have a Wii? What do you think of its "channel" interface?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#115212 - DragonMinded - Sat Jan 13, 2007 7:05 pm
| strager wrote: |
Using the plugin template, I was unable to compile successfully...
I get the following after entering make:
| Code: | crt0.s
link start
/usr/share/devkitpro/devkitARM/bin/../lib/gcc/arm-eabi/4.1.1/../../../../arm-eabi/bin/ld: error: no memory region specified for loadable section `.ARM.extab'
collect2: ld returned 1 exit status
make[1]: *** [/home/strager/projects/nds/dsoshadow/arm9.so] Error 1 |
Perhaps something is missing from the linker script?
Also, I would like to ask, is it possible to "overlap" plugins? As in, associate a plugin with a type, but have another plugin preprocess the file first? Or perhaps pass on a file to another plugin? Some IRC clients allow plugins, and they can "catch" a command (like /me) and preprocess it first. Preprocessing does not necessarily have to change the input in any way; it might log something to a file or something.
I believe this plugin idea is great. Hopefully some real neat plugins could be made to make DSO even stronger... |
For now, plugins must be compiled with DKP r.17 as newer versions had issues with DSO. If you or someone else could look at the new linkscripts and add that section, let me know if it runs successfully in DSOrganize and I'll update the code.
| dantheman wrote: |
| Well, to be fair, card compatibility problems are pretty much eliminated due to the DLDI system, but I do agree that this plugin system could be very useful. |
Not so much card compatibility as code launching, which never works anyway.
| tepples wrote: |
| DragonMinded: Do you have a Wii? What do you think of its "channel" interface? |
I has a wii. :3 The channel interface is cool, but I don't do virtual games, so I can't really take full advantage of it. But it's kinda like .dse with it's soon to come shortcuts, if noone takes advantage of it, it would be a pity. ;P
_________________
Enter the mind of the dragon.
http://dragonminded.blogspot.com
Seriously guys, how hard is it to simply TRY something yourself?
#115221 - HyperHacker - Sat Jan 13, 2007 9:28 pm
I can think of a few uses for it, especially if I had access to the PSG.
_________________
I'm a PSP hacker now, but I still <3 DS.
#115238 - strager - Sun Jan 14, 2007 2:32 am
| DragonMinded wrote: |
| For now, plugins must be compiled with DKP r.17 as newer versions had issues with DSO. If you or someone else could look at the new linkscripts and add that section, let me know if it runs successfully in DSOrganize and I'll update the code. |
Ah, I must have forgotten about that.
Luckily, I managed to get everything compiled and running with the latest devkitPro release.
Here's the patch to the original /specs/ds_arm9_dsplugin.ld:
| Code: |
51a52,70
> .ARM.extab : { *(.ARM.extab* .gnu.linkonce.armextab.*) } >dlram
> __exidx_start = .;
> .ARM.exidx : { *(.ARM.exidx* .gnu.linkonce.armexidx.*) } >dlram
> __exidx_end = .;
> /* Ensure the __preinit_array_start label is properly aligned. We
> could instead move the label definition inside the section, but
> the linker would then create the section even if it turns out to
> be empty, which isn't pretty. */
> . = ALIGN(32 / 8);
> PROVIDE (__preinit_array_start = .);
> .preinit_array : { KEEP (*(.preinit_array)) } >dlram = 0xff
> PROVIDE (__preinit_array_end = .);
> PROVIDE (__init_array_start = .);
> .init_array : { KEEP (*(.init_array)) } >dlram = 0xff
> PROVIDE (__init_array_end = .);
> PROVIDE (__fini_array_start = .);
> .fini_array : { KEEP (*(.fini_array)) } >dlram = 0xff
> PROVIDE (__fini_array_end = .);
>
90c109
< .got : { *(.got.plt) *(.got) } >dlram = 0
---
> .got : { *(.got.plt) *(.got) *(.rel.got) } >dlram = 0
|
Running the test plugin seems to work perfectly (expect I can't press the buttons; a bug, perhaps?).
#115242 - alfatreze - Sun Jan 14, 2007 2:52 am
Great to have u back to your pet Dragonminded & sharing it with us.
DSO is looking great, iconsets are a bless, the old ones really threw me off a bit :). I started with one set, but will do many many more.
Not sure if this will be the right place to post bugs, but out it goes anyway.
Text is much better than in 2.41, but with large files it crashes completely, while it has no problem loading a 500kb file, with one three times the size it crashes.
I don't know how much you would be willing to try to fix it, but it would be great, I, and many others I believe, would much prefer using DSO for ebook pleasure, even though it takes s bit longer to load the books than moonshell.
Also as a request, text size options would be awesome!
#115251 - Darkflame - Sun Jan 14, 2007 4:50 am
This looks absolutely amazing stuff O_o
A "space-elivator" to lift us on too another level of development ;)
I was also thinking of the Wii-channel interface when you discribed the above. And with the ability to re-arrange things for awhile anyway, the interfaces are suppriseingly close.
Anyway, I'm snowed under with freelance at the mo, but I'll start to look into writting some DSOrganiser stuff when I have time :)
| Quote: |
| This is such a good idea! Now coders can work on coding stuff without having to worry about card compatibility! Since this program is really starting to branch out, you should think about renaming it to something more general, like 'DS Shell' or something that has to do with your name. |
Or Dragonshell? :p
I dont really think its a good idea going for anything like Moonshell.
It would create the feeling of competition between them when really they do quite different things. (even if they both boot stuff).
But, that said, DSO really has gone way past a mere organiser now :)
Dragonminded ~ Have you considered posting a copy of this thread onto the Pocketheaven forums?
Might be a few emulator writters interesting in doing a plugin version for DSO :)
_________________
Darkflames Reviews --
Make your own at;
Rateoholic:Reviews for anything, by anyone.
#115267 - wintermute - Sun Jan 14, 2007 9:46 am
| strager wrote: |
| DragonMinded wrote: | | For now, plugins must be compiled with DKP r.17 as newer versions had issues with DSO. If you or someone else could look at the new linkscripts and add that section, let me know if it runs successfully in DSOrganize and I'll update the code. |
Ah, I must have forgotten about that.
Luckily, I managed to get everything compiled and running with the latest devkitPro release.
|
devkitARM release 20 will include the linkscript for the dldi system, I strongly suggest using a variation of that script for your plugin system. You probably only need to change the size of the memory region or find out if there's a way to specify the region size at link time ( I think there might be but I haven't found it yet)
the dldi template project can be found at
http://devkitpro.cvs.sourceforge.net/devkitpro/examples/nds/templates/dldi/
the dldi linkscript at
http://devkitpro.cvs.sourceforge.net/devkitpro/buildscripts/dkarm-eabi/crtls/dldi.ld?view=log
devkitPro does not have version numbers, it is a brand name encompassing several toolchains and associated libraries.
I've expended considerable effort in making the devkitPro toolchains work pretty much out of the box on several platforms which has thus far resulted in most projects constructed around the templates being buildable on most people's setups without modification. Encouraging people to use old broken toolchains is a bit unhelpful.
It's great to see you back working on DSO again, it would just be nice to get you up to date and have your work build with the most recent toolchains. If you need any help getting DSO working with r20 I'm generally found in #dsdev on irc.blitzed.org or you can contact me via the feedback form on devkitpro.org or any of the methods at the bottom of this post.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#115270 - DragonMinded - Sun Jan 14, 2007 10:38 am
I have updated the default code for both the executables and the plugins to include the patch by strager. It still compiles on DKA r17 but LiraNuna has also confirmed r19 working, so we may be in business. I also had LiraNuna help fix the makescripts to spit out a proper dsp/dse instead of a .bin that had to be renamed. Buttons seem to work here too, and Liran confirmed they work there. Maybe you aren't smacking it hard enough?
@wintermute: I had a gander at the DLDI linkscript and framework and it is very very similar to mine. All the same crucial sections are in the linkscript aside from the glue which I have no idea what it's for. The header is similar to the header format for the plugins and exe files too. I will try upgrading to r20 when it comes out, but I've had fiascos with DSO source and r18 and 19, including errors with random freezes after mallocs which did not happen in r17, and other miscelaneous issues that I didn't want to deal with. Hopefully this is all peachy when I make the jump ;P
I will NOT, however, be joining any scene IRC channels due to some of the people that hang there. I am always reachable here, or virtually any other well known forum as I lurk at maxconsole, m3-forums, sosuke, gbatemp, scdev, and wherever else I see soeone linking on my HTTP logs. Feel free also to email me or request an instant messenger address.
_________________
Enter the mind of the dragon.
http://dragonminded.blogspot.com
Seriously guys, how hard is it to simply TRY something yourself?
#115276 - wintermute - Sun Jan 14, 2007 2:30 pm
The glue sections are inserted by the linker for interworking, they contain stubs for switching between arm & thumb code.
The malloc problems *should* all have been resolved by r19b, if you still have some issues with that release I'd be grateful if you could break it down to a small testcase I can examine.
If you feel like adding one of the IM accounts at the bottom of my posts, feel free :)
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#115308 - Lynx - Sun Jan 14, 2007 11:00 pm
Not that it matters, but I feel DSO is still a very relavent title, as with Palm, they are known to be organizers, but capable of much more.. I thought that was obvious from the day DSO came out that it would be much more than just an organizer.
_________________
NDS Homebrew Roms & Reviews
#115336 - Darkflame - Mon Jan 15, 2007 3:51 am
True, but its name hides its importance a bit.
A bit like calling a swissarm knife a tooth-pick ;)
_________________
Darkflames Reviews --
Make your own at;
Rateoholic:Reviews for anything, by anyone.
#115515 - tyraen - Tue Jan 16, 2007 9:57 pm
So, the readme talks about using custom dswifi calls, but how do you go about using the simplified gba_nds_fat?
After writing that little bit up I decided to check plugin.h, sure enough I found the fat functions. I decided to post this anyways in case someone else was wondering. :)
EDIT: One more issue I had was that I originally had been including string.h amongst others in some of my source, before moving it to the plugin stuff. Well, since all those functions are define'd in plugin_def.h it was giving a bunch of errors. At first I had no idea what was going on, then I caught on. I'm no C guru; how are you supposed to use the original methods rather than the define'd ones? Is that even a good idea? I could do 'undefine' right? Seems like a hassle for every function I want to use. I ended up having to include: "dso_const.h", "plugin.h", and "plugin_def.h" to get it to compile correctly. :)
#115537 - DragonMinded - Wed Jan 17, 2007 12:05 am
There is a reason most of those are defined for you. They ARE the original functions, just linked in the DSO binary instead. They save space, and with the mallocs, allow it to actually work in the first place. Only include defines of stuff that aren't there or your binary will be larger than it has to be!
And yes, you have to include the headers to get compiled. ;P
_________________
Enter the mind of the dragon.
http://dragonminded.blogspot.com
Seriously guys, how hard is it to simply TRY something yourself?
#115539 - tyraen - Wed Jan 17, 2007 12:17 am
Made more sense as I thought about it more. I wasn't considering the whole thing about this being loaded in instead of being standalone, heh. Thanks for the explanation.
I guess I was just thinking it was weird to have to include them all rather than just a single one, but it doesn't matter (obviously...). :)
#115545 - tyraen - Wed Jan 17, 2007 1:17 am
Guess this might be a stupid question...
If I have a class, Test, what's wrong with saying:
Test* testy = new Test();
Within LaunchFile()? Does it have to do with this being a plugin architecture?
Doing: Test testy = Test();
Works fine. Is the problem that when I declare a pointer, it doesn't figure out how much memory it will require during compilation, whereas when the object is declared in the second manner it does?
Sorry these beginner type questions are clogging up your thread, heh. :)
#115551 - chishm - Wed Jan 17, 2007 2:37 am
I'm not entirely sure this plugin architecture will fully support C++. The 'new' operator will call malloc, so either you (or DragonMinded) need to modify the 'new' code inserted by the compiler to call on DSO's 'malloc' instead, or DragonMinded needs to create a 'new' stub within the plugin architecture that calls on DSO's 'new' operator. This is easier said than done, because you'll still need to get 'delete' working too. Then there's the problem of global objects constructed at start time, which won't be constructed without the appropriate framework.
In short: Use C or ASM only, not C++.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#115567 - DragonMinded - Wed Jan 17, 2007 7:23 am
Chishm has hit the nail right on the head. Unfortunately, new will not work.
_________________
Enter the mind of the dragon.
http://dragonminded.blogspot.com
Seriously guys, how hard is it to simply TRY something yourself?
#115607 - tepples - Wed Jan 17, 2007 8:48 pm
That, or override your class's operator new to use DSO's malloc(), and override operator delete to use DSO's free().
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#115641 - tyraen - Thu Jan 18, 2007 2:23 am
What I did and seems to be working is override the global new after reading up on it a bit. Seemed to make sense if the normal new/delete doesn't work properly.
#116516 - tyraen - Fri Jan 26, 2007 2:52 pm
Will there be any additional GUI elements added to the API, or are we pretty much on our own? It might be handy to be able to add buttons, or touch sensitive text; more than what's offered with the drawButtonTextsEx call. Another thing would be the keyboard input that is available throughout DSO.
Just some ideas, probably not even an issue for anyone else. ;)
EDI: One more thing that would be useful for (me personally) debugging plugins is something that will return some memory usage info. I'm afraid I might be missing some delete's and it seems like the only real way to check is to run my plugin until things crash. :)
#117124 - tyraen - Thu Feb 01, 2007 2:30 pm
Since DSO already seems to go into sleep mode when you close the lid, is it all that hard to add the ability to a plugin/exe? Do I need to make the libnds calls (that's what it is right?) myself, or is there a function supplied by the plugin framework (I didn't see anything in readme or plugin.h)?
Thanks!