#93027 - Mighty Max - Sun Jul 16, 2006 4:29 pm
Hi all,
i am building up a generic exec() stub for starting other .NDS files from devices. You probably know that the method used in GBAMP is bound to the gbamp and chishm's modified firmware. Well this exec() command does not rely on this anymore.
I have set up the first working examples, tested to boot wifi-code & official WMB-Demos. (Zelda Preview Video)
There is still alot of work to clean the code & the boot process. But this is the first version that allows every homebrewer to boot other NDSes with just including one function to your arm7 and one to your arm9 code, as the example shows.
http://mightymax.org/exec_test.zip contains all needed sources. Put the ds_arm9_vram.ld & specs into the corresponding devkitARM folders & make. Needed to run the code are the two output files exec_test.nds & exec_stub.bin. The example runs any nds named "zelda.nds" (as i tested it with the zelda preview) but you can change it accordingly
How it works:
the exec() command copies exec_stub.bin into the VRAM, and starts executing this binary, which itself loads the .NDS that exec() points it too.
What it can be used to:
- create a launcher menu
- use a seperate NDS for different tasks in your homebrew (i.e. a seperated viewer for the movies of your game)
- (when datel CF) is supported: run >1MB files from Max Media Player
Issues:
- i created the example using devkitpro r18. (it might need some changes for r19+)
- it uses the "old" gba_nds_fat driver. The new fatlib as well as gbfs support shouldnt be a problem tho
- long filenames are a problem. 8bit writeaccess to VRAM :/
Please report issues & whishes.
have fun
Mighty Max
_________________
GBAMP Multiboot
#93047 - tepples - Sun Jul 16, 2006 7:11 pm
Does this exec() support displaying something on both screens while the program loads, or does it take up the whole VRAM and require blanking the screen to avoid garbage? Can it be configured to display an animation while loading the .nds so that the user doesn't think that the DS has frozen?
Anyway, using the "old" gba_nds_fat driver should suffice until the "new" driver manages to implement <dirent.h>.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#93050 - Mighty Max - Sun Jul 16, 2006 7:28 pm
The DS is still able to use both screens. At the current state it just takes 2 of the 4 main banks, but the bin is so small it can be reduced to 1 of those 4.
The rest is still available for gfx.
For now however the video mode is set by the exec_stub again for bugtracking purpose.
_________________
GBAMP Multiboot
#93055 - dovoto - Sun Jul 16, 2006 8:02 pm
Thanks...I was about to write just such a thing for a wifi loader I was working on. Saved me a good bit of work :)
_________________
www.drunkencoders.com
#93056 - Mighty Max - Sun Jul 16, 2006 8:03 pm
:)
I allready found some bugs. i think there will be a new version allready tonight.... if i found out why it happens.
_________________
GBAMP Multiboot
#93061 - Payk - Sun Jul 16, 2006 8:32 pm
Yeah good work mighty!
Perhaps useable for making somekind of multitask...not sure if thats possible but i think so...THANX
#93065 - Mighty Max - Sun Jul 16, 2006 9:08 pm
Two bugs solved.
- the main makefile was not starting the exec_stub make too
- if the arm7 code of the target was to be load in exclusive ram, the arm7 was pointed to a wrong address (missing an & *grrr*)
:edit: Update
- added mem clearance for work ram up to 0x27FC000 and vram bank a. This solves a lot of oddities in homebrew. Devvers don't seem to initialize their classes/structs correct with values.
_________________
GBAMP Multiboot
#93304 - Mighty Max - Tue Jul 18, 2006 1:38 pm
a little fix for the problem loading >3MB files. (ToD i.e.)
insert
| Code: |
FAT_fclose(nds) ;
nds = FAT_fopen(file,"r") ;
|
just after the line
| Code: |
header.arm9_base |= 0x00400000 ;
|
in the exec_stub/main
I don't exactly understand why the filereset fixes the fread aborting while returning the full size, however this (dirty) hack fixes it.
Next step: support RAM &ROM images of .NDS files.
_________________
GBAMP Multiboot
#93341 - Mighty Max - Tue Jul 18, 2006 6:55 pm
Yes i like monologes ;)
I've updated the sources again. The exec_stub works now for the big files and for nds files that are allready loaded somewhere in the ram. The exec_stub code should be much more readable now ;)
the "command" parameter can contain now either the (fatlib) path to the nds file or "mem:/" + the decimal representation for the buffer address.
Who will be the first one to implement a Download&Play from this? *g*
:edit: SausageB hinted me to a bug, fixed
_________________
GBAMP Multiboot
#93490 - MechaBouncer - Wed Jul 19, 2006 3:35 pm
I'm still not quite sure I follow what this does. It sounds really cool, but I'm missing something. Is this for creating code that automatically executes on boot with other hardware (flashcarts, Supercard, M3)? Like how the GBAMP automatically runs anything named _BOOT_MP.nds at boot? (Then again, isn't that something that FlashMe does and chishm's firmware just allows it?) Is it something to make boot loaders easier to make? Or is this some kind of method of launching homebrew code on un-FlashMe/PassMe/NoPass DSes? Sorry for all the questions. Whatever it is, it sounds nifty.
_________________
Cobalt/Black NDSL
CycloDS Evolution (firmware 1.55 BETA 3) and EZFlash 3-in-1
Kingston SD-C02G JAPAN 2GB MicroSD
MoonShell 1.71, DSOrganize 3.1129, QuakeDS Pre3, ScummVM DS 0.11.1, Pocket Physics 0.6, OpenTyrian DS 0.3
#93501 - Mighty Max - Wed Jul 19, 2006 4:05 pm
It is a method homebrew developers can use to start other .NDS files. It might be a nds that got downloaded from the inet via wifi or stored on a compatible card.
You can easily create a new bootloader for cards that do not allow the start of homebrew. I.e. you could just flash a selfbuild menu on the GBAMP-SD replacing the gba menu, once the sd version is supported in the fatlib.
For the end-user, the stub alone is of no use.
_________________
GBAMP Multiboot
#93521 - MechaBouncer - Wed Jul 19, 2006 5:48 pm
Okay, I think I get it. So it's basically for any app to switch to another, but in a universal way and without everyone having to reverse engineer other multiboot programs?
Could this method then be used to "return" to a multiboot app (your own GBAMP Multiboot, Moonshell, DSOrganize, etc.) by re-executing it? Of course, that would probably require that there be some kind of standardized file to execute (like _BOOT_MP.nds) or that the homebrew programs that make use of that include a specific multiboot launcher. That would at least let the user re-run whatever loader of choice they use.
_________________
Cobalt/Black NDSL
CycloDS Evolution (firmware 1.55 BETA 3) and EZFlash 3-in-1
Kingston SD-C02G JAPAN 2GB MicroSD
MoonShell 1.71, DSOrganize 3.1129, QuakeDS Pre3, ScummVM DS 0.11.1, Pocket Physics 0.6, OpenTyrian DS 0.3
#93538 - DynamicStability - Wed Jul 19, 2006 7:55 pm
Mecha, yes it would allow that if you have a standard name, like _BOOT_MP.nds.
I use the gbamp method on all my programs, which lets me use select to boot _boot_mp.nds, and start to boot wifc2.nds (which re-downloads my latest code on the current project and executes again)
#93555 - dovoto - Wed Jul 19, 2006 9:52 pm
Do you think you could switch to the stdio functions (fopen vs FAT_open etc...) I am writting a wifi device for use with the devkitpro stub (similar to the way chishms new fat lib works) that will allow loading of files over wifi. (fopen("wifi:/blah.nds") for instance).
There should be enough vram to load a wifi enable exec stub i would hope? Otherwise i can just load it into available ram and exicute it that way. I may just modify the stub myself but best to keep that sort of thing in one place :)
_________________
www.drunkencoders.com
#93567 - Mighty Max - Wed Jul 19, 2006 10:33 pm
To use the stdio fopen() und co should be no problem at all.
The implementation of the wifilib in a code running from VRAM could be some work, but not impossible.
_________________
GBAMP Multiboot
#93625 - dovoto - Thu Jul 20, 2006 6:27 am
It is probably not really worth it if it is too complex to get wifi enabled stub to run from vram. I can just load it into whatever ram I have free and launch it that way
_________________
www.drunkencoders.com
#93628 - tepples - Thu Jul 20, 2006 6:40 am
Would it be acceptable to limit the Wi-Fi stub to a 3.5 MB .nds file?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#93629 - dovoto - Thu Jul 20, 2006 6:45 am
| tepples wrote: |
| Would it be acceptable to limit the Wi-Fi stub to a 3.5 MB .nds file? |
yah..that is pretty much along the lines i was thinking
_________________
www.drunkencoders.com
#93633 - melw - Thu Jul 20, 2006 8:09 am
Not even WMB (at least on Windows) allows >3Mb .nds files to be transferred. Limiting the .nds size is just natural - I guess that's how the DS download play works too - it reserves some 3Mb of the DS' 4Mb RAM for the download.
#94001 - Mighty Max - Sat Jul 22, 2006 12:39 pm
The current restrictions are not really big. Actual, using the fatlib or ROM as source for the executeable, allows to (theoretical) run a nds file wich binaries fits into the 4MB - 768 Bytes.
However you are much more likely to run into other problems before you reach that limit (location of the IPC-Struct, etc)
The RAM as source is limited by the size of heap left at the time you create the image.
Btw. a bug that prevented loading an mem-Image correct was found by Dovoto, and is fixed since yesterday.
:edit: Updated it once more. Be carefull, the ARM7 code has changed and the new exec_stub is not compatible with the old ARM7 code. So Update both or none.
The new arm7 ode can (but doesn't need to) be called from within an IRQ Handler now. And is now part of the IRQ_VBLANK.
_________________
GBAMP Multiboot
#94033 - dovoto - Sat Jul 22, 2006 4:41 pm
I have wifi loading of nds files working. I was able to load the few nds examples from the example pack I tried. The official demos I did not have as much luck with. I got the zelda trailer to load but it froze after a few seconds of playback, the other two i tried I had no luck with (tetris and meteos i think).
Looks like i get about 15KB/s with no attempt at making it fast (I am not sure where to begin optimizing network code to tell the truth).
My code is not too clean and normaly I would hide it till I had some time to clean it up and, speed it up, and make it a bit more stable but I am going out of town for a couple of days so here it is anyway. (I also have made no attempt to reduce the size of the binary)
[url]
www.drunkencoders.com/temp/exec_test.zip[/url]
It also has a stuf for wifi file io that will plug into devkitpro (fopen("wifi:/blah...") ). This works insofar as the functions get called but I have not actualy filled them out to connect to any sort of file server. They might serve as a good starting point.
This also does not require a fat capable device like the original version might posted. The fileserver simply waites for a connection on port 12345 and when it gets a connection it sends the file size followed by the actual file.
_________________
www.drunkencoders.com
#94472 - Mighty Max - Mon Jul 24, 2006 10:26 pm
I can't get it to work dovoto.
The client does never complete the connection to the AP. (Alltho the wifilib can and does in my own applications)
And i can't run the server. I guess that i need framework?
_________________
GBAMP Multiboot
#94475 - dovoto - Mon Jul 24, 2006 11:03 pm
interesting...I did not spend much time trying to make it robust. Odd that the server does not run as it is just a console app...but maybe i have some setting messed up on compiler and it is outputing .net code or some such.
_________________
www.drunkencoders.com
#94497 - josath - Tue Jul 25, 2006 2:12 am
| dovoto wrote: |
| interesting...I did not spend much time trying to make it robust. Odd that the server does not run as it is just a console app...but maybe i have some setting messed up on compiler and it is outputing .net code or some such. |
for me it wants msvc80d.dll or something (forget the exact one). if it's a simple server, you could just give us the C code and let us compile it. or we could just wait for an improved version
#94599 - dovoto - Tue Jul 25, 2006 1:35 pm
| josath wrote: |
for me it wants msvc80d.dll or something (forget the exact one). if it's a simple server, you could just give us the C code and let us compile it. or we could just wait for an improved version |
I will get the source out when i have a minute. Should be easy to make your own though...just wait for a connection on port 12345 and when you have one send the file size (4 bytes) to the nds followed by the nds file.
_________________
www.drunkencoders.com
#94719 - tepples - Tue Jul 25, 2006 10:19 pm
Would it be hard to make your client use standard HTTP/1.1 so that I can just drop my .nds file in my Apache public folder?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#94728 - dovoto - Tue Jul 25, 2006 10:53 pm
| tepples wrote: |
| Would it be hard to make your client use standard HTTP/1.1 so that I can just drop my .nds file in my Apache public folder? |
Yes, but right now it is set up to be interupted by the server so I can reset and reload the nds file without touching the NDS. It would be a simple modification to have the retrieval allways grab a certain file from an http.
_________________
www.drunkencoders.com
#94920 - Mighty Max - Wed Jul 26, 2006 9:50 pm
There have been again several changes to the exec()
+ the host can now decide if mem gets cleared, arm7 loaded, etc (see LF_ flags)
* the parameter "mem:/dddd" is no longer supported. Instead of a string, pass the pointer to the mem image directly (suggested by dovoto to reduce mem load by not relying to string functions) add LF_MEMDIRECT as loaderflag
+ long filename & directory support
- changed the synching, to reduce the danger of overwriting the arm7 loader from an allready running arm9 bin (its stack was overwriting this in the demos)
I still have problems loading the newer official demos. The old ones work just fine. In dualis even the new demos load just fine. If anyone has any suggestion what might caus it, please let me hear.
:edit: forgotten: LF_LOADGBFS will load an appended gbfs image into the main ram just below __eheap_end (0x200 aligned) and tries to change __eheap_end so it doesnt get overwritten after an malloc. Works only for homebrew & files loaded from fat, not mem
_________________
GBAMP Multiboot
#95547 - Sektor - Sun Jul 30, 2006 4:23 am
I ran the binary on M3CF but it displayed this error:
FAT:
1: 0 400000
2: 0 0
3: 0 20132C4
4: 20313EDC 2013ECC
ARM9
LD9FAT
file open failed
-> 0
ARM7
LD7FAT
file open failed
-> 0
CLR
I had exec_test.nds, exec_stub.bin, bootme.nds and zelda.nds on my CF card. Same error when started with WMB or M3 menu. I don't think it looks for zelda.nds anymore, I just had it there because of the first post in this thread. I haven't tried compiling it yet, I have a newer devkitarm installed.
_________________
GTAMP.com/DS
#95561 - Mighty Max - Sun Jul 30, 2006 7:36 am
A yes sorry to test the long filenames the nds to start has changed to "A_long_filename.nds"
The exec_test without exec_stub should be able to compile in the newer devkits too, so you can change the filename to whatever you need.
_________________
GBAMP Multiboot
#95565 - Sektor - Sun Jul 30, 2006 8:23 am
It worked with that filename. I'll try and add this to all my DS projects.
_________________
GTAMP.com/DS
#96189 - DragonMinded - Tue Aug 01, 2006 8:20 pm
Hey MightyMax, thanks for finally getting out the one piece of code everyone wanted!
I'll let you know how it works.
EDIT: I cannot get the stub to compile. Complained that it couldn't find the specs file, so I edited the INI to include the specs path, and now it can't find the .ld file, in the same directory.
_________________
Enter the mind of the dragon.
http://dragonminded.blogspot.com
Seriously guys, how hard is it to simply TRY something yourself?
#96206 - Mighty Max - Tue Aug 01, 2006 9:04 pm
The makefiles & linkscripts are still based uppon devkitArm r18. I should relly move on to r19 :p
For r18 however the path to copy those two file to, is "devkitPro\devkitARM\arm-elf\lib"
_________________
GBAMP Multiboot
#96208 - DragonMinded - Tue Aug 01, 2006 9:12 pm
Ok, compiled here with latest rein and it seems to be executing just fine. One minor thing, both my happycat.nds and drugwars.nds files have the arm7 mod player playing incorrectly after boot. If you want to have a look, they are here: www.dragonminded.com/dsorganize/files/DrugWars.nds and http://www.dragonminded.com/dsorganize/files/HappyCat.nds
(Both use older dekutree mod player if that helps)
_________________
Enter the mind of the dragon.
http://dragonminded.blogspot.com
Seriously guys, how hard is it to simply TRY something yourself?
#96210 - Mighty Max - Tue Aug 01, 2006 9:23 pm
I gonna check it
btw, here are the r19 (eabi) specs & linkscripts to put into "devkitPro\devkitARM\arm-eabi\lib"
_________________
GBAMP Multiboot
#96211 - DragonMinded - Tue Aug 01, 2006 9:25 pm
I dont use eabi as it causes many many MANY errors with my projects.
EDIT: Ok, it seems to work ok on some files, but other files it will crash partway through loading.
Example: http://www.stud.uni-karlsruhe.de/~uxasl/beup.nds gets stuck after CI
Any demo I try goes after loading the arm7 to CLR and then just goes to blank screens.
http://www.dragonminded.com/dsorganize/files/dissonance.nds freezes after CW
Long demo filenames fail on opening.
http://www.dragonminded.com/dsorganize/files/SylphIRC.nds freezes after trying to init arm7
_________________
Enter the mind of the dragon.
http://dragonminded.blogspot.com
Seriously guys, how hard is it to simply TRY something yourself?
#96219 - Mighty Max - Tue Aug 01, 2006 10:10 pm
I've checked these nds, and they work fine for me.
I'll update the archive as soon i got a successfull responce from others on IRC
_________________
GBAMP Multiboot
#96220 - DragonMinded - Tue Aug 01, 2006 10:23 pm
Well, what should I be doing differently so that they do boot? Keep in mind I'm using a newer fatlib.
EDIT: Just tried with your original stub with the same results. Also, sometimes it fails on files that it normally works on, with a failed to init fat or can't load.
EDIT AGAIN: Seems dissonance works fine now. Also, if I use my own compiled src, it seems to reliably boot the ones it works with, as apposed to erratic failures.
_________________
Enter the mind of the dragon.
http://dragonminded.blogspot.com
Seriously guys, how hard is it to simply TRY something yourself?
Last edited by DragonMinded on Tue Aug 01, 2006 10:34 pm; edited 1 time in total
#96225 - Mighty Max - Tue Aug 01, 2006 10:33 pm
I have updated the archive.
The precompiled exec_test.nds & bin work for me to boot all the wifi examples you put above as "boot.nds"
_________________
GBAMP Multiboot
#96227 - DragonMinded - Tue Aug 01, 2006 11:01 pm
I recompiled the newest that you've posted and it is working on the ones it didn't before, save for the demos and sylphIRC. I've always had a problem with SIRC, and there's one built in to my program, so that doesn't matter a bit, really. The demos still were failing on fat init, so I just wrote a function to convert to short file names and pass your function the short instead of long, and they boot now. BEUP works fine now!
You rawks :>
EDIT: Still getting random fat_fopen errors on both your .bin and my compiled bin
EDIT 2: Doesn't work with .ds.gba or .sc.nds either. Should be easy enough to bypass the loader.
EDIT 3: Brain age usa demo loads like, once in a blue moon here, but usually just shows a white and black screen.
EDIT 4: Seems setting the filename to lowercase and then displaying it in the actual bin makes the files that woudln't load before work... strange. I can also patch it myself to load .sd.nds and .ds.gba
EDIT 5: Seems I like edits as much as you like monologues ;P Random fat_fopen errors seem to be few and far between, and don't happen consistently on all caps files anymore. .ds.gba and .sc.nds booting works fine now that I added a few lines of code. Brain age usa demo still doesn't load, gets through the whole process but stays on white screen. Keep up the good work :>
PS: WTF is an impressum?
_________________
Enter the mind of the dragon.
http://dragonminded.blogspot.com
Seriously guys, how hard is it to simply TRY something yourself?
#96256 - josath - Wed Aug 02, 2006 3:13 am
As far as booting .ds.gba files, you can do it sometimes, but it is not reliable. Most people recommend to just use the original .nds files, instead of trying to hack a .ds.gba back into a .nds.
However, if you really want to, it turns out that about 80% of .ds.gba files are simply loader + .nds file. The other 20% have other data / configuration, and you will not be able to convert them back into a working .nds
You can see the source of the app I wrote here, http://davr.drunkencoders.com/pme2nds.zip
basically, I just search for the 16 byte string '************AXXE' or '************####' (where * can be anything) and assume they will be aligned to 16 byte boundries. When I find a match, I just discard everything up to (but not including) that 16 bytes.
#96287 - Mighty Max - Wed Aug 02, 2006 9:51 am
| DragonMinded wrote: |
EDIT 2: Doesn't work with .ds.gba or .sc.nds either. Should be easy enough to bypass the loader.
|
I concentrated on real .nds only.
| Quote: |
EDIT 3: Brain age usa demo loads like, once in a blue moon here, but usually just shows a white and black screen.
|
The new demo's don't run at all here. That they do for you very seldom, hints that i really should get into that synching better then before. I got an idea for this ...
| Quote: |
PS: WTF is an impressum? |
It's a register of personal data of a webside owner. It is required in germany for any page that is not purely for personal use. There are some lawyers sueing anyone without the impressum even for personal use, i'm just beeing on the secure side here ;)
:edit: Update Yes it is the synch. prepare for a version running the new demos today. I can now run the mkds demo, which does not load native on gbamp *g*
:edit^2: Its updated.
_________________
GBAMP Multiboot
#96351 - DragonMinded - Wed Aug 02, 2006 7:51 pm
| Mighty Max wrote: |
| DragonMinded wrote: |
EDIT 3: Brain age usa demo loads like, once in a blue moon here, but usually just shows a white and black screen.
|
The new demo's don't run at all here. That they do for you very seldom, hints that i really should get into that synching better then before. I got an idea for this ... |
Ok that makes kinda sense, the old E3 demos work great ;P
PS, making it work with the majority of .ds.gba and .sc.nds is VERY easy. I simply added another flag and turned it on if it was a proper .ds.gba or .sc.nds file, and in your boot code itself, that flag tells code to add 512 bytes to all file read operations, thus finding the correct header, and so far, booting everything I've tried.
EDIT: Tried newest that you've put up, still doesn't boot brain age demo, but seems to be an all around solid release, so I don't really mind. I own brain age anyhow ;P
_________________
Enter the mind of the dragon.
http://dragonminded.blogspot.com
Seriously guys, how hard is it to simply TRY something yourself?
#96360 - MechaBouncer - Wed Aug 02, 2006 9:23 pm
So is this something we might see added to the next DSOrganize, then? ;)
_________________
Cobalt/Black NDSL
CycloDS Evolution (firmware 1.55 BETA 3) and EZFlash 3-in-1
Kingston SD-C02G JAPAN 2GB MicroSD
MoonShell 1.71, DSOrganize 3.1129, QuakeDS Pre3, ScummVM DS 0.11.1, Pocket Physics 0.6, OpenTyrian DS 0.3
#96368 - MaHe - Wed Aug 02, 2006 10:13 pm
DragonMinded: When implementing this in DSOrganize: could you make it load the .sc.nds files under 4MB using this method and everything bigger load using the current (slower) method? Thanks for answers :)
_________________
[ Crimson and Black Nintendo DS Lite | CycloDS Evolution | EZ-Flash 3-in-1 | 1 GB Transcend microSD ]
#96371 - Mighty Max - Wed Aug 02, 2006 10:26 pm
| DragonMinded wrote: |
EDIT: Tried newest that you've put up, still doesn't boot brain age demo, but seems to be an all around solid release, so I don't really mind. I own brain age anyhow ;P |
The version uploaded works just fine with brainage demo here. Just solved a sudoku puzzle. Probably a deffect dl or such?
_________________
GBAMP Multiboot
#96373 - DragonMinded - Wed Aug 02, 2006 11:11 pm
| MechaBouncer wrote: |
| So is this something we might see added to the next DSOrganize, then? ;) |
What is this might crap?
_________________
Enter the mind of the dragon.
http://dragonminded.blogspot.com
Seriously guys, how hard is it to simply TRY something yourself?
#96808 - MaHe - Sat Aug 05, 2006 5:10 pm
A problem with my SuperCard miniSD - the top screen will turn white, while the lower one will shut off ... Any ideas?
_________________
[ Crimson and Black Nintendo DS Lite | CycloDS Evolution | EZ-Flash 3-in-1 | 1 GB Transcend microSD ]
#96824 - Mighty Max - Sat Aug 05, 2006 7:34 pm
Might be a problem reading from the SD, or it fails to run the arm7 code.
What is the output of the loader itself, while it tries to load the nds?
_________________
GBAMP Multiboot
#96832 - Sektor - Sat Aug 05, 2006 8:35 pm
How can I reset the DS with code?
Do you know how to launch the M3 menu? It's part of the firmware and not an .nds file on the CF/SD card.
_________________
GTAMP.com/DS
#96833 - Mighty Max - Sat Aug 05, 2006 8:40 pm
To reset to booting the nds, "swi 0" on both CPUs
_________________
GBAMP Multiboot
#98072 - dovoto - Sun Aug 13, 2006 2:01 am
| dovoto wrote: |
I have wifi loading of nds files working. I was able to load the few nds examples from the example pack I tried. The official demos I did not have as much luck with. I got the zelda trailer to load but it froze after a few seconds of playback, the other two i tried I had no luck with (tetris and meteos i think).
Looks like i get about 15KB/s with no attempt at making it fast (I am not sure where to begin optimizing network code to tell the truth).
My code is not too clean and normaly I would hide it till I had some time to clean it up and, speed it up, and make it a bit more stable but I am going out of town for a couple of days so here it is anyway. (I also have made no attempt to reduce the size of the binary)
[url]
www.drunkencoders.com/temp/exec_test.zip[/url]
It also has a stuf for wifi file io that will plug into devkitpro (fopen("wifi:/blah...") ). This works insofar as the functions get called but I have not actualy filled them out to connect to any sort of file server. They might serve as a good starting point.
This also does not require a fat capable device like the original version might posted. The fileserver simply waites for a connection on port 12345 and when it gets a connection it sends the file size followed by the actual file. |
here is the source to the file server. It should now build under linux/windows with no change. It includes the win exe.
http://www.drunkencoders.com/temp/wifimb.zip
I was unable to get it to work with the newer stub. After some tinkering I was able to get the newer stub to read the ndsfile but I can not seem to get it past the "CI" stage. As soon as i get the newer stub to work I will release a more useful version.
_________________
www.drunkencoders.com
#98109 - Mighty Max - Sun Aug 13, 2006 8:48 am
That CI thing is weird. Monsti also observes this while running the stub on the M3SD. What is the card you were testing it with?
The CI stall basically tells that the arm7 counterpart does not act. Basically it is checking if the given value has been cleared by the arm7 (which is the first thing it does after disabling IRQs):
The wait:
| Code: |
// wait until arm7 notifies that the job started
while (*(vu32 *)0x027FFFFC!=0) {
} ;
|
The arm7:
| Code: |
*(vu32 *)0x27FFFFC = 0 ;
|
Since you got it running with wifi, your arm7 code obviously doesnt crash before trying to exec.
What is your WAIT_CR set to?
Does it change if you put in a swiWaitForVBlank in the while-loop?
_________________
GBAMP Multiboot
#98178 - DragonMinded - Sun Aug 13, 2006 9:27 pm
I am now getting a stall on CW on all of my boot attempts on anything. I've tried putting a swiWaitForVBlank there but it still doesn't help.... What else should I check for?
_________________
Enter the mind of the dragon.
http://dragonminded.blogspot.com
Seriously guys, how hard is it to simply TRY something yourself?
#98183 - Mighty Max - Sun Aug 13, 2006 10:05 pm
If CW is the last message, the arm7 could not complete copying it's code.
This might have the following reason:
- the header info's are invalid for the arm7 base or size
- the arm7 code to do this was not copied over to 0x027FFD00, or got otherwise damaged
- the arm7 exec_stub address (at 0x27FFFFC) was set with false information, having the arm7 jump into nirvana
When did it stoppped working? Which was the last working version for you? For me it still acts as it did, so its a bit problematic to find the error.
The whole procedure is as follows, with the states marked (for nds files using arm7 exclusive ram = homebrew)
- ARM9 loads ARM9 binary
*** ARM9
- ARM9 loads ARM7 binary
*** ARM7
- ARM9 sets parameters & exec_stub for ARM7
- ARM9 tells the ARM7 to continue execution (at *0x27FFFFC)
*** CI
- ARM7 clears clears the flag & continues execution where it's told to
- ARM9 waits for the flag to be cleared
*** CW
- ARM7 clears exclusive memory
- ARM7 copies it's binary
- ARM7 clears its first parameter
- ARM9 waits for the first parameter to be cleared
*** CD
- ARM9 clears memory
*** CLR
- ARM9 loads gbfs data to end of heap & corrects heap end
*** PAD
- ARM9 sets the first parameter again
- ARM7 waits for the parameter to become not zero
- ARM7 jumps to new NDS Code
- ARM9 jumps to new NDS Code
_________________
GBAMP Multiboot
#98223 - DragonMinded - Mon Aug 14, 2006 6:09 am
| Mighty Max wrote: |
If CW is the last message, the arm7 could not complete copying it's code.
This might have the following reason:
- the header info's are invalid for the arm7 base or size
- the arm7 code to do this was not copied over to 0x027FFD00, or got otherwise damaged
- the arm7 exec_stub address (at 0x27FFFFC) was set with false information, having the arm7 jump into nirvana
When did it stoppped working? Which was the last working version for you? For me it still acts as it did, so its a bit problematic to find the error.
The whole procedure is as follows, with the states marked (for nds files using arm7 exclusive ram = homebrew)
- ARM9 loads ARM9 binary
*** ARM9
- ARM9 loads ARM7 binary
*** ARM7
- ARM9 sets parameters & exec_stub for ARM7
- ARM9 tells the ARM7 to continue execution (at *0x27FFFFC)
*** CI
- ARM7 clears clears the flag & continues execution where it's told to
- ARM9 waits for the flag to be cleared
*** CW
- ARM7 clears exclusive memory
- ARM7 copies it's binary
- ARM7 clears its first parameter
- ARM9 waits for the first parameter to be cleared
*** CD
- ARM9 clears memory
*** CLR
- ARM9 loads gbfs data to end of heap & corrects heap end
*** PAD
- ARM9 sets the first parameter again
- ARM7 waits for the parameter to become not zero
- ARM7 jumps to new NDS Code
- ARM9 jumps to new NDS Code |
It was working fine, but then suddenly it stopped last week sometime. I hadn't even compiled anything new. It has always seemed rather erratic in DSO.
EDIT: FYI for Mighty Max and anyone else. Compiling your arm7 with O3 WILL BREAK THE LOADER! Don't do what I did!
EDIT again: Why is it that the exec_stub fails to init any card on the NDS side? My MK2, MK3, and NinjaSD all do not boot from them, checking the interface says that it failed and went to GBAMP. Why is this?
_________________
Enter the mind of the dragon.
http://dragonminded.blogspot.com
Seriously guys, how hard is it to simply TRY something yourself?
#98244 - Mighty Max - Mon Aug 14, 2006 9:42 am
| DragonMinded wrote: |
EDIT: FYI for Mighty Max and anyone else. Compiling your arm7 with O3 WILL BREAK THE LOADER! Don't do what I did!
|
Seems like i got to search for a forgotten option for datastructures/volatiles.
| Quote: |
EDIT again: Why is it that the exec_stub fails to init any card on the NDS side? My MK2, MK3, and NinjaSD all do not boot from them, checking the interface says that it failed and went to GBAMP. Why is this? |
It still uses the old gba_nds_fat MK3/NinjaDS were not included. There might be some additional trouble, as the nds does not reset in exec, therefor the encryptions doesnt reset. And i think im clearing the memory where the bootloader stores the card's header.
_________________
GBAMP Multiboot
#98252 - DragonMinded - Mon Aug 14, 2006 10:35 am
| Mighty Max wrote: |
| DragonMinded wrote: |
EDIT: FYI for Mighty Max and anyone else. Compiling your arm7 with O3 WILL BREAK THE LOADER! Don't do what I did!
|
Seems like i got to search for a forgotten option for datastructures/volatiles.
| Quote: |
EDIT again: Why is it that the exec_stub fails to init any card on the NDS side? My MK2, MK3, and NinjaSD all do not boot from them, checking the interface says that it failed and went to GBAMP. Why is this? |
It still uses the old gba_nds_fat MK3/NinjaDS were not included. There might be some additional trouble, as the nds does not reset in exec, therefor the encryptions doesnt reset. And i think im clearing the memory where the bootloader stores the card's header. |
Chishm said he had a bug with init -> free -> init, but I seem to have fixed it for ninjaSD. The loader is working fine again on my GBAMP and my ninjaSD. My MK2 and MK3 don't load though, as they don't reinit, encountering that bug.
EDIT: I just installed the newest wifi lib last night, and after that, the exec_stub hangs on CW again for ninjaSD. It was hanging on CI, but I changed that bit of code to be FIFO. The arm7 sends back that it recieved the CI instruction now, so it moves to CW, but it never leaves from there.
EDIT 2: I changed the arm7 asm code that it sends to send fifo back saying its done, and now on ninjaSD it hangs on CLR. It seems that it can't read any of the values on the arm7 to test properly... Note that in both cases GBAMP and ninjaSD, I'm using the GBAMP to boot, so it's not a loader issue. The only thing different is the card interface, which loads the executable fine in both cases.
EDIT 3: Tested with flashme which was working last night. Seems it still boots this one fine, because it doesn't go through the CI/CW loop, so it wasn't the wifi that was doing it. Something else isn't allowing the arm7 to execute. To clarify, it looks like official demos and flashme boot, because they don't do the CI/CW loop. All other homebrew hangs there though.
_________________
Enter the mind of the dragon.
http://dragonminded.blogspot.com
Seriously guys, how hard is it to simply TRY something yourself?
#104156 - bjoerngiesler - Tue Sep 26, 2006 8:07 pm
Hi,
I'm a bit late to the party. I'm in the process of replacing DSFTP's exec code with yours, MightyMax. Result: For some NDSs, it consistently works, for others it consistently doesn't -- for example, DSOrganize.
For the ones that don't work, the output is consistently:
...
ARM9
LD9FAT
-> 0
ARM7
LD7FAT
and then it hangs.
From looking at the code, I guess this means it can't read anything (0 bytes for the ARM9 code, hang for the ARM7 code). I just don't have any idea why, since it works with my old code (which was stolen from MoonShell). To address the obvious points: Short filenames, and in the same directory with other files that can be booted.
Am I interpreting the messages right? Any idea what might cause this?
EDIT: Just tried DSOrganize 2.3, blue version, I'm on SC CF. Same results with the same files.
_________________
DSFTP homepage
#105212 - ThaKilla - Fri Oct 06, 2006 7:21 pm
Wondering if anyone can help me.
I'm trying to add the exec() code to DSBlue (for Wifi downloads of nds files)
I can get it to almost work in DeSumME. Gets to...
| Code: |
MEM
1: 1F1F00 1F5F001F
2: 1F001F1F 1F1F00
3: 1010101F 18181818
4: 18181818 18181818
ARM9
ARM7
|
And on hardware it only gets to...
| Code: |
MEM
1: 1F1F00 1F5F001F
2: 1F001F1F 1F1F00
3: 1010101F 18181818
4: 18181818 18181818
ARM9
|
I was noticing that its getting stuck in a loop. If i use the desembler in the Emu than I can step past the ARM7 to see "CI" "CS" and "CLR" than the screen goes blank.
I'm sure its in the ARM7 somewhere (maybe missing a makefile parm, though I checked) because the ARM9 in the Emu is just waiting for a response.
I'm going to try and get the exec_stab.bin re-compled and see if that helps.
Also could it be that I'm including the exec_stab.bin as a ".h" file?
Edit: I updated to the latest Flashme. (small chance that was it, but it wasn't)
#105279 - jmk - Sat Oct 07, 2006 8:22 am
I'm trying to get this to work now, too, and I'm also getting hangs at the "CI" stage. If I understand things correctly, this is the point where the ARM9 is waiting for the ARM7.
The odd thing is, this works just fine on my SuperCard miniSD when I use DSFTP-2.2. I can't seem to figure out what the difference between my code and Bjorn's code might be -- they seem to be doing the exact same thing.
#105549 - ThaKilla - Mon Oct 09, 2006 2:38 pm
OK I got my problem fixed.
I was trying to pass the Mem Address for a GBFS file over.
If you are using the DL-ed code than I would change a few things in "exec()"
First would be the function Header, it should look like
| Code: |
| void exec(vu32 command, bool gbaBoot) |
(be sure to change the ".h" file
from there you can Rem from...
| Quote: |
| char *exec_filename = (char *)0x0605FC00 ; |
to
| Quote: |
| *(vu32 *)0x0605FFFC = 0x0605FC00 ; |
note: the last line is where it saves the Mem Addr for the stub to run.
Now just set your MemLocation (passed to exec) to...
| Quote: |
| *(vu32 *)0x0605FFFC = command ; |
Hope that helps, probly the best I can explain it
#105813 - jmk - Thu Oct 12, 2006 6:19 am
I also fixed my own problem -- I idiotically forgot to add the arm7 vblank exec check to my test program. (That would explain why it, uh, never responded to the arm9.)
Now it works, but I'm seeing some minor memory corruption and side effects in some programs; are you still working on this (or reading this thread) at all, Mighty Max?
#107511 - Marcel24 - Mon Oct 30, 2006 11:57 am
Hi, i have a strange problem :(
i can boot NDS code now with your source code *great work* but the problem is that
my programm that loads a NDS inits the WIFI connection .
there is no problem with that but if then this application loads another NDS an it need WIFI support too , than it hangs there on AutoConnect source code :(
any tipps ?
tnx
#107526 - tepples - Mon Oct 30, 2006 3:16 pm
Is there a command in 802.11b to disconnect the data link layer cleanly?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#107531 - Mighty Max - Mon Oct 30, 2006 4:26 pm
| jmk wrote: |
| Now it works, but I'm seeing some minor memory corruption and side effects in some programs; are you still working on this (or reading this thread) at all, Mighty Max? |
Yes, but not very intense atm.
Things are not developing fast over here, so that i am still busy with my studies. Im actually a bit too much behind there for my taste.
At least that will result in better code when im done ;) Currently i am attending an parallel processing course beneath normal studying, so that ipc in that code might get some tuning.
I had tested WiFi init in starting and started nds files with no problems, but the tests were limited, due to my setup here. The IPC Fifo and the wifi hardware are not reset on the exec(). Both might be the reason for this problem.
At what exactly point do the Wifi* calls fail? Does it initialize correct?
_________________
GBAMP Multiboot
#114968 - Baffles - Thu Jan 11, 2007 11:26 pm
I talked to Mighty Max on IRC about porting this to work on a Supercard DS (slot one), and he said we just need a new FAT driver.
Has anybody worked on this at all for Supercard DS? I didn't want to do the work of a new FAT driver if someone had already done it.
There are drivers avaliable for the SC DS One, so it shouldn't be too hard, should it?[/url]
#114998 - Baffles - Fri Jan 12, 2007 2:22 am
Alright, I have it working (at a new gba_fat_nds with way more drivers). However, I can't get it to actually copy and execute any roms. If anybody knows much about the workings of this, or how it's supposed to be done, please talk!
The problem seems to be it crashing or hanging somehow in the arm 7 loading:
| Code: |
#ifdef VERBOSE
iprintf("CI\n") ;
#endif
// wait until arm7 notifies that the job started
while (*(vu32 *)0x027FFFFC!=0) {
// printf was here that got printed sparadoically.
} ;
#ifdef VERBOSE
iprintf("CW\n") ;
#endif |
If I put an iprintf in the loop, it only prints about 8 times, but the code never reaches CW to print (it does print CI first however).
#122546 - Fling - Tue Mar 20, 2007 4:30 am
Has anyone managed to get this to work correctly with the newest libfat by any chance?
I've modified the exec_test.nds program to download a .nds binary over HTTP and then have it exec() the downloaded .nds. I tried using the exec_stub included in the download provided by Mighty Max, but it doesn't work with my DSX (I didn't think it would, but I figured I'd give it a go anyway).
So, then I decided to try and convert it over to use the newest libfat so I could patch it with the DSX DLDI. I managed to do this... it all compiled, but when execution hits the exec_stub code, it doesn't get past GetNDSInfo(). Specifically, it locks up at some point after "FAT", and I notice some garbled junk on the screen. However, it does appear that libfat initializes correctly (or it wouldn't have got that far).
Also, I figure I'll point out (though I'm not sure if it makes a difference) that I had to downgrade to libnds-20060621 as the exec_stub has some CP15 calls in it that seemed to have been removed in the newer version of libnds.
Any help or suggestions would be much appreciated. I feel that I'm very close, and it's bugging me. Kinda wish I had thought to actually test the exec() code to see if it worked for me before putting together the HTTP downloader heh.
#122557 - HyperHacker - Tue Mar 20, 2007 7:06 am
I just noticed today that, contrary to my earlier belief, DSOrganize's launcher (which uses this) doesn't hang on Initializing FAT. It takes about a minute to pass that, then hangs on CI. (The other launcher works fine, though.)
[edit] Working fine in V2.61. Might just be my dodgy GBAMP. Takes ages to init though.
_________________
I'm a PSP hacker now, but I still <3 DS.
#122587 - Fling - Tue Mar 20, 2007 3:37 pm
Hmm... hadn't tried out DSOrganize before today, but thought I'd give it a go since you mentioned it uses this exec code.
Anyway, patched it for my DSX, and while the DSOrganize app itself works great, the launcher code doesn't. Fails saying "For some reason, the file was not loadable."
There doesn't seem to be any source provided for his modified exec_stub either, so I'm kind of at a loss here.
EDIT: Just spent a bit searching around the official DSX forums and the DSOrganize forums, and it looks as if this is a known problem with no solution currently.
#122812 - tyraen - Thu Mar 22, 2007 12:56 pm
I've tried this in various forms: the standalone example, the DSO implementation, and none have worked for me. They always hang on CI. Has anyone with a SC lite gotten it to work?
#122813 - Diddl - Thu Mar 22, 2007 1:26 pm
** deleted **
#124232 - knight0fdragon - Wed Apr 04, 2007 7:47 am
ok I am trying to update the exec_stub to r20 with dldi support, but alas, it will not work for me. I dont know if it is because my stub is too large, or perhaps the stuff that is inside the dldi fat drivers are corrupting areas needed by the stub?
anyway here is my work if anyone wants to take a look at it and lend me a hand in getting this to work
http://knight0fdragon.team-gx.org/DS/Examples/exec_test.rar
_________________
http://www.myspace.com/knight0fdragonds
MK DS FC: Dragon 330772 075464
AC WW FC: Anthony SamsClub 1933-3433-9458
MPFH: Dragon 0215 4231 1206
#124236 - GrizzlyAdams - Wed Apr 04, 2007 8:33 am
Ok, I've been using an updated version of the exec_stub in dschannels, and I've released a unstable source tarball of everything in dschannels.
The exec_stub relevant pieces are in arm9/source/util.c arm9/source/dldi.c and the exec_stub folder.
Tarball Download
Any pieces by me that don't have a license header are basically 3-clause BSD licensed. This archive doesn't include the contents of the data directories.
#124241 - knight0fdragon - Wed Apr 04, 2007 9:21 am
unfortunately the .ld you have provided caused my stub to grow 70MB when I include the function fatInit or fatInitDefault
_________________
http://www.myspace.com/knight0fdragonds
MK DS FC: Dragon 330772 075464
AC WW FC: Anthony SamsClub 1933-3433-9458
MPFH: Dragon 0215 4231 1206