#154514 - Lazy1 - Thu Apr 17, 2008 4:13 am
What features would you look for in a TCP/IP loader?
I have been working on one today and so far it is able to save to "download.nds" in the root of a flash card.
I'm thinking of expanding it though, maybe GBA binary support and auto booting of downloaded nds applications.
The nds binaries can be sent easily using netcat:
| Code: |
nc -n -q 1 192.168.x.x 2000 < file.nds
|
#154516 - Sektor - Thu Apr 17, 2008 5:04 am
If the binary is less than 4MB then optionally download into RAM instead of writing to flash. You would of course need to add auto booting from RAM.
_________________
GTAMP.com/DS
#154521 - dsl_andy - Thu Apr 17, 2008 8:10 am
the facility to configure your wireless settings (SSID, IP, DNS etc..) so you don't have to load up a game with wifi before you do a transfer ?
_________________
Andy..
____________________________________
M3DSReal GBAexp NDSLite
#154529 - silent_code - Thu Apr 17, 2008 2:01 pm
and support for single rom burn for older slot2 carts. well, if that's possible.
anyway, thanks! ;^D
#154540 - Lazy1 - Thu Apr 17, 2008 7:34 pm
| Sektor wrote: |
| If the binary is less than 4MB then optionally download into RAM instead of writing to flash. You would of course need to add auto booting from RAM. |
All the nds booting examples I looked at booted from FAT, is there one that I'm missing?
If that is possible maybe it's better to just boot from ram instead of saving the file, thoughts?
| dsl_andy wrote: |
the facility to configure your wireless settings (SSID, IP, DNS etc..) so you don't have to load up a game with wifi before you do a transfer ?
|
It's only meant to be a loader, this will not be added in unfortunately.
Isn't there already an application out there to modify wifi settings?
| silent_code wrote: |
and support for single rom burn for older slot2 carts. well, if that's possible.
anyway, thanks! ;^D
|
Maybe, if there is good documentation on how to do it but I do not have one of those carts.
GBA Should be able to be saved if you have ram in slot-2.
I'm thinking of adding zlib support as well to cut down on transfer time.
Oddly enough I'm testing newer versions of the loader by using it to download newer versions of itself :D
#154554 - Fling - Fri Apr 18, 2008 1:00 am
I wrote something similar a while back. Downloads a nds program via HTTP, writes it to your card and boots it. I haven't been developing it all since the 1.2 release, as it now does everything I want and makes for much less painful development test cycles for me.
Anyway, don't know if you'd seen it before, but maybe the source will be of some help to you.
Looking forward to seeing what you come up with anyway!
#154558 - silent_code - Fri Apr 18, 2008 3:32 am
doesn't libfat's default driver support writing to nand (?) carts? that's where i would check first.
basically, i'm developping on a neoflash slot 2 512Mb + mk4 passme. it's a pain, because i have to burn the cart with another pc, as neoflash team won't bother supporting amd-based PCs (i wrote them many times about this issue, no response, yet). one has to use an intel based system... that's why i was asking. it would be easing development with this kit a big deal. unfortunately, i don't have much money and none to spend on new (slot1) hw. enough whining.
no matter if you'll support slot2 or not, this is a great idea. also, i'll try to have a look at the other, older project. :^)
well, after all, i read slot 2 kits are very unpopular these days (there were no slot1s when i got the kit) and very few people develop using them. at least most people trying out my shadow volume demo complained about the incompatibility with slot1 kits due to gbfs.
would this be possible: load the rom to ram and then use libreset (or at least the functionality it offers) to "soft boot" from the rom in ram? next time you would need to boot another rom, you simply restart the system, booting from cart and then wifi the new rom (that would not require to leave a stup in memory for reentry to the wifi loader after a soft reset.)
at least for me, that would be more than enough, even without permanent cart storage of the rom! loading assets from the slot2 would be "impossible" (not worth implementing - i doublt it's easy without special knowledge), but that's a minor problem. that can be still done with "big" builds, wifiing just smal test builds bundeled with all needed data would be sufficient enough and already a better solution than now.
i hate wasting power by running another pc (which is highly unstable due to old and partially broken hardware, so it's not usable as a primary dev system in the first place!) for just copying stuff. ;^D
okays, then.
happy coding!
#154578 - Lynx - Fri Apr 18, 2008 2:38 pm
| Quote: |
| one has to use an intel based system.. |
Hmm.. All of my systems are AMD based and I never had a problem with NeoFlash's crap.. Then again, I haven't touched it since they initially released.
_________________
NDS Homebrew Roms & Reviews
#154587 - silent_code - Fri Apr 18, 2008 4:27 pm
<OT>
me, too - all software that shipped with the kit - neo max flash writer software, or what ever it is called. works like a charm on intels.
i have tested it on different amd (sempron 3200+, turion)/intel (celeron 400, 1000) laptops and desktop computers (athlon 3400+, different p3s and 4s). non of the amd based systems worked, whereas all intels worked well.
i can't write the gba cart with usb slim loader 3 on amds. ???
my primary system is the turion 64X2.
what software are you using?
</OT>
#154929 - Lazy1 - Wed Apr 23, 2008 12:16 am
I need some input on implementation:
Would it be better to write a PC application to send over the application data?
I've been using netcat for now but I realize that there is no way to verify the incoming data is good.
One thing that bothers me though is I haven't seen any examples for booting .nds applications from ram.
All the ones I saw loaded from disk but I would like that to be optional, except for .gba files which can only be booted from slot-2.
EDIT:
Also, is there a way to increase the transfer rate with dswifi?
I get anywhere from 40-70 KB/s which is good but faster would be nice :D
#154932 - silent_code - Wed Apr 23, 2008 12:42 am
feedback: yes, a pc side server program would be really nice. :^)
#154937 - 0xtob - Wed Apr 23, 2008 1:04 am
I would very much like to see a decent wifi loader because most of us are probably still doing the ol' switcheroo to test their code on hardware. In order to be useful for coding, the server side app should be useable from the command line, so we can add a "make wifi" target to the makefile.
_________________
http://blog.dev-scene.com/0xtob | http://nitrotracker.tobw.net | http://dsmi.tobw.net
#154938 - Lazy1 - Wed Apr 23, 2008 1:15 am
I guess to boot nds files I would need to have code running in vram download to main ram.
Does anyone know how the download play loader works?
I have code running in vram now thanks to a few modifications to chishm's exec stub linkscripts.
Maybe the main application should just copy the vram loader, execute it and do nothing else.
#154940 - tepples - Wed Apr 23, 2008 1:18 am
I think that's what DSFTP was supposed to be for. The intended use case was that an "exit" command in the program would start an FTP server, and then a program on the PC would copy the new .nds, load it, and run it. But I never really got even the DSFTP demo program to work on my hardware.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#154951 - theli - Wed Apr 23, 2008 6:23 am
| tepples wrote: |
| I think that's what DSFTP was supposed to be for. The intended use case was that an "exit" command in the program would start an FTP server, and then a program on the PC would copy the new .nds, load it, and run it. But I never really got even the DSFTP demo program to work on my hardware. |
hm ... i got and that's where i have 'make put' in my makefile :)
#154990 - Lazy1 - Wed Apr 23, 2008 6:56 pm
Any suggestions on how to go about this?
GBATek says download play sends the arm7 and arm9 binaries separately so maybe that's what my loader needs to do.
The question is how do I download if my application is already running in main ram?
What do I do with the arm7?
I have code running from vram except the irq functions won't link because libnds puts them in itcm and any printf code will only work in an emulator.
I really like the idea of a TCP/IP download play client but I'm beginning to fear that this goes way over my head.
#155019 - HyperHacker - Wed Apr 23, 2008 11:20 pm
Your code has to contain itself to a small download function in VRAM or (better) at the end of RAM, and let the rest of the binary get overwritten by the download. ARM7 runs out of its own dedicated memory, but many unofficial cartridges such as Action Replay have their ARM7 binary copied there, and the firmware loads them fine, so I'd guess ARM7 is also running from the end of RAM during this time. I'm not sure if WMB is allowed to do this. If you're not using the WMB protocol, then that's no problem, and if this is for developing apps, then you should be fine running from VRAM and just writing your apps to properly set up VRAM for themselves at startup.
_________________
I'm a PSP hacker now, but I still <3 DS.
#155028 - Lazy1 - Thu Apr 24, 2008 1:55 am
So basically:
1) Copy arm9 stub to vram
2) Copy arm7 stub to vram
3) Download arm9 binary to ewram
4) Download arm7 binary
5) ???
6) Profit
Unfortunately newlib does not like running from vram and libnds's interrupt functions will not link with the vram linkscripts.
I wonder how dswifi will like running from vram...
#155032 - silent_code - Thu Apr 24, 2008 2:20 am
what about the two 16kb shared work memory banks? (03000000h / mirrored at 37F8000h)
ps: are these even two "banks"? gbatek says that either 0, 16 or 32 kb can be allocated to each processor (obviously 32kb in total), although, i haven't used them yet, so idon't know how to configure them. ;^)
#155035 - HyperHacker - Thu Apr 24, 2008 5:41 am
I remember finding the official client would reject binaries that came too close to the end of RAM, so I would guess it has a stub there.
_________________
I'm a PSP hacker now, but I still <3 DS.
#155393 - dantheman - Tue Apr 29, 2008 2:27 am
There is Wifiloader which doesn't write to disk (I use the 1.5 Beta version often), but since it comes in versions for specific homebrew devices, I'm guessing it merely downloads the file to the slot-2 device's RAM and executes from there.
#155779 - Lazy1 - Sun May 04, 2008 3:35 am
I haven't given up on this yet, instead of messing around with code in vram I just modified the linkscripts to put everything in the last 512k of ewram and that seems to work so far.
Still, what do I do when it's time to send the arm7 binary?
I cannot just download it to the arm7's work ram since the arm9 cannot access it.
I just thought up a horrible idea though, what if:
1) Download arm7 binary to vram
2) Give vram bank to arm7
#155794 - silent_code - Sun May 04, 2008 11:25 am
again: shared ram?
you would still need a way to "activate" code execution on the arm7 though. i'm wondering how that could possibly be done... that would need something like a jump to shared ram... (????)
#155953 - Lazy1 - Tue May 06, 2008 1:39 am
| GBATek wrote: |
Shared-RAM
Even though Shared WRAM begins at 3000000h, programs are commonly using mirrors at 37F8000h (both ARM9 and ARM7). At the ARM7-side, this allows to use 32K Shared WRAM and 64K ARM7-WRAM as a continous 96K RAM block.
|
The only thing I can think of is increasing the download size limit and download both binaries to ewram then copy the arm7 binary from there or download to vram and give access to the arm7.
Can anyone more experienced with this stuff provide some ideas/information?
#156001 - HyperHacker - Tue May 06, 2008 5:53 am
What if you do the download on the ARM7, constraining ARM9 to a small loop at the end of RAM? Then you'd have full access to main RAM and ARM7 work RAM.
_________________
I'm a PSP hacker now, but I still <3 DS.
#156013 - Cydrak - Tue May 06, 2008 8:44 am
HH: Yeah, the ARM7 BIOS has this advantage. Since you're not running from BIOS, you can use VRAM, which is what Chism's loader does (just loading from FAT, not over the network).
If VRAM is too much trouble, one of the "wifiloader"s linked uses another method:
1) Download .NDS (to EWRAM or SLOT-2)
2) Place a tiny loader "stub" somewhere convenient
3) Patch it with any needed arguments
4) ARM7 swiSoftReset()s to the stub
5) ARM9 swiSoftReset()s to an uncached loop
6) Loader stub moves ARM7/ARM9 binaries to the correct place
7) ..then rewrites the loop to unstick ARM9
(4) and (5) need to be well enough synchronized, that the ARM9 doesn't get its code pulled out from under it before it gets to the loop. (Shh. Yes, I am silly, and had this happen.)
If you have both CPUs in EWRAM, I would be even more careful! I never looked in depth, but it might be possible to deadlock that way. I had a situation where sending the ARM9 into that loop made my reboot hang. I had to ensure the ARM7 (running in IWRAM, and then SLOT-2), was given EWRAM priority via EXMEMCNT beforehand.