#157986 - AO - Mon Jun 02, 2008 9:22 pm
Hey guys, as I'm new to homebrew for the DS I'm interested in knowing the kind of techniques and workflow you use for developing, testing and debugging DS apps.
I've set up a VS 2k5 project with a Makefile for compiling for the DS platform. I quickly found there's no way i'm gonna do a compile -> copy to flash -> insert flash into DS -> repeat process for every thing i want to test or debug.
It seems to be really easy to waste time if you're not being careful.
Currently I'm developing a DS wrapper in tandem with the DS game. The wrapper only includes the parts i need (like check the required init functiosn are called, GL functions, etc) and i flesh out the implementation of the wrapper as I need the functions.
Are you guys creating a similar wrapper or do you have another way of testing the app without having to copy the binary over to the DS for each test.
It's really nice to be able to have edit & continue for debugging the game on windows.
#157990 - tepples - Mon Jun 02, 2008 9:31 pm
You could develop a PC port of the game in parallel, from the same source tree. That's what I do for Lockjaw Tetromino Game.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#157991 - silent_code - Mon Jun 02, 2008 9:41 pm
i use no$gba (currently the free 2.6 version) for minor debugging and testing (hit F3 to check if no$ detects any errors, that works in any version). obviously that doesn't work for features that no$ doesn't emulate, but most of it is just eyecandy (at least the things i can thinking of right now) anyway.
in the end, all major testing is done on hw. nothing beats that! :^)
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
#157994 - AO - Mon Jun 02, 2008 10:43 pm
Tried No$gba 2.6a
| Quote: |
Errors per second -- 532,476
Total Errors -- 1,597,428
Low Power Mode -- Unsupported (drains battery power)
Multiboot Support -- Unsupported (bad entrypoint)
Quality Rating -- Disqualified |
I don't find that terribly helpful, i'm not sure why it's finding that many errors/what kind of errors it's finding.
the nds binary is created with: ndstool -c game.nds -9 game9.bin -7 arm7.bin
Last edited by AO on Mon Jun 02, 2008 10:44 pm; edited 1 time in total
#157995 - DensitY - Mon Jun 02, 2008 10:44 pm
the no$gba emulator is your best bet. I setup a while ago (don't really remember how, it was ages ago) an extra option in my VS menu which'll launch no$gba + my .no.gba file. allowes me to compile then quickly test. Sadly this doesn't allow things like Edit and Continue to work, which is a pain because features like that make PC based deving a complete joy.
In the end you will need todo some sort of hardware testing, sometimes things work on no$gba that won't on hardware (generally if you have a odd bug). just pray you don't have todo any heavy wifi usage development with your project, as currently testing of wifi based apps are hardware only as far as I know.
#157996 - silent_code - Mon Jun 02, 2008 11:56 pm
@ AO:
i find that *quite* helpful!
you can always insert infinite loops before lines and see which lines cause the errors. although this procedure is sub optimal, you can still get most errors traked down quite easyly.
the only cases that won't be helping are unsupported features and "buggy" libraries. ;^)
give it a try, let's see if you can get it down to one error or less. i usually have *always* one error, which occurs *before* the first line in main(). maybe it's counting running windows an error? ... :^p
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
#157997 - DensitY - Tue Jun 03, 2008 12:04 am
some DS debugging requires old school screen prints + inserting loop code to pause the app manually.. generally required if you get hardware specific bugs.. and yes its a major pain but all in good fun.
#158003 - Cydrak - Tue Jun 03, 2008 2:51 am
If you can get it working, IMHO, wifi is the way to go.
There are several downloaders; generally these save to slot-2 RAM or to the memory card, then run the *.NDS. Some even have code you can use to restart the loader at runtime.
These are the ones I'm aware of, there might be others:
- DSlurper (download via HTTP): http://www.scumways.com/dslurper/
- HTTPexec (another HTTP launcher): http://forum.gbadev.org/viewtopic.php?t=13143&highlight=httpexec
- DSFTP (an FTP server for the mem-card): http://giesler.biz/bjoern/en/sw_dsftp.html
- Wifiloader ("netcat" to SLOT-2 RAM; dead link): http://forum.gbadev.org/viewtopic.php?t=11665&start=15
Personally, I use a (heavily modified) build of Wifiloader; I haven't released it since it's still WIP and I'd like to add a few things. I never tried any of the others... so I can't say much about them.
One thing to beware of is old wifi and FAT libraries. Sometimes a new wifi chipset breaks homebrew, so you may need to recompile with current libs. And gba_nds_fat (long since replaced) has been known to trash memory cards. I started back in Jan/Feb 2007 and hit both problems, but modern apps should fare better.
With a wifi tool and a "restart" hotkey in my project, I've gotten compile cycles down to ~15-20 seconds for small binaries... so long as nothing crashes too badly!
#158025 - silent_code - Tue Jun 03, 2008 7:16 pm
wow, that sounds nice!
my only problem with wifi-ing is, that you need a special adapter with special "hacked" drivers to simulate an access point.
now, how will i get it to work with my *laptop's* build in atheos card (or the msi usb dongle i have)? thiswillworkNOT! ;^p
to make things wores, i even have to use another (intel) pc, than my dev machine (the laptop) to burn my slot2 gba cart, because i can't get the software/driver to work with any amd system (although someone here wrote he's no problem at all with the very same brand i'm using and his amd system/s)...
so, has the current state of wifi powered dev improved over what i have just written, or didn't it change at all? i would appreciate using wifi, because i then didn't have to waste so much energy any more. :^)
peace out! :?)
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
#158034 - EyeballKid - Tue Jun 03, 2008 7:57 pm
| silent_code wrote: |
wow, that sounds nice!
my only problem with wifi-ing is, that you need a special adapter with special "hacked" drivers to simulate an access point.
|
No, not if you're using one of the apps Cydrak mentioned.
I use (and wrote) DSlurper, and it just connects to a web server, which is pretty trivial to set up on your development machine.
(I'm just preparing a new release of dslurper, should appear in the next day or two...)
#158037 - silent_code - Tue Jun 03, 2008 9:12 pm
THAT SOUNDS AWESOME!
do i need flashme installed in order to make it work? what about older gba slot2-only carts, with no ram and build-in flash memory (so, not a FAT device)?
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
Last edited by silent_code on Tue Jun 03, 2008 9:37 pm; edited 1 time in total
#158039 - AO - Tue Jun 03, 2008 9:34 pm
The wifi http downloader sounds like a great idea and fixes the biggest issue i have now, having to physically move the flash card between PC and DS for each test.
I think I'll continue with my DS wrapper, run the binary with no$gba to check for errors now and then and create a simple http server to handle requests from... I was gonna choose HTTPexec since it seems relatively new, but is DSlurper gonna be compiled against the latest libfat/devkitarm/wifilibs and all that so i don't have to think about the problems Cydrak mentioned with older versions?
I'm not sure how stable the DS is after trying to restart itself and run the latest binary but i'll think about that when i get to it, there's a bunch of links here.
#158045 - TwentySeven - Tue Jun 03, 2008 10:29 pm
At worst you'll have toggle the power and try again. Homebrew seems to have a random failure rate on my ds-x of about 2%.
#158047 - Cydrak - Tue Jun 03, 2008 10:40 pm
| silent_code wrote: |
| my only problem with wifi-ing is, that you need a special adapter with special "hacked" drivers to simulate an access point. |
Nah, these apps use a standard AP. The wifi does have trouble with some of them; I needed to assign a static IP, rather than use DHCP, for example.
| silent_code wrote: |
| do i need flashme installed in order to make it work? |
You just need to be able to start the loader, and have a working wifi profile set up in the firmware. A WFC game like Mario Kart or Animal Crossing works for this; I think DSOrganize can also configure them now.
| silent_code wrote: |
| what about older gba slot2-only carts, with no ram and build-in flash memory (so, not a FAT device)? |
Ahh... this is a different story. Trouble is, the downloaded file has to go somewhere. I guess the easiest way is to save in EWRAM, then have a tiny ARM7 stub handle the relocation. Wifiloader pulls this trick from slot-2... I'm not aware of a pure EWRAM loader, though.
| AO wrote: |
| I'm not sure how stable the DS is after trying to restart itself and run the latest binary but i'll think about that when i get to it, there's a bunch of links here. |
It's not a "hard boot" in any sense; remember, the DS has already gone through the BIOS, firmware, and a launcher on the way to your app. This is just another path. ;)
Now, different flashcards (and loaders) do have their quirks. And your last binary will have left some state behind. So either way, you should already be initializing everything you need. Obviously you will also want to clean up (HDMA, timers, etc) during the "reset" process. For the most part, the DS seems quite tolerant of this.
There is one thing you can't just kill at any time though, and that is your 3D task. That is: you must be sure you've finished your scene and glFlush()ed for the current frame. If you don't--and yes, I found out the hard way--the geometry engine will choke and die on the next glFlush(), when it sees the half-baked display list. Then you're doomed to a power cycle, since further 3D attempts will fill the command buffer and lock hard. @_@
#158050 - silent_code - Tue Jun 03, 2008 11:02 pm
thanks, but now i am a sad panda. :^C
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
#158055 - AO - Wed Jun 04, 2008 12:18 am
| Cydrak wrote: |
for this; I think DSOrganize can also configure them now.
| silent_code wrote: | | what about older gba slot2-only carts, with no ram and build-in flash memory (so, not a FAT device)? |
Ahh... this is a different story. Trouble is, the downloaded file has to go somewhere. I guess the easiest way is to save in EWRAM, then have a tiny ARM7 stub handle the relocation. Wifiloader pulls this trick from slot-2... I'm not aware of a pure EWRAM loader, though. |
silent_code: Why not buy a cyclo DS evolution like i have or any slot 1 cart, they're not very expensive.
#158056 - silent_code - Wed Jun 04, 2008 1:00 am
i'm saving for one, but i'm not quite there, yet. ;^)
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
#158141 - Abcd1234 - Thu Jun 05, 2008 5:52 pm
| DensitY wrote: |
| some DS debugging requires old school screen prints + inserting loop code to pause the app manually.. generally required if you get hardware specific bugs.. and yes its a major pain but all in good fun. |
I've actually found Masscat's gdb stub to be incredibly helpful here (I've used it extensively while developing nethackds). Actually being able to debug running code on the DS has allowed me to find bugs that, otherwise, would've been impossible to find.
#158143 - Sarvesh50 - Thu Jun 05, 2008 6:41 pm
| tepples wrote: |
| You could develop a PC port of the game in parallel, from the same source tree. That's what I do for Lockjaw Tetromino Game. |
Or you could help the port of transport tycoon ds http://www.tt-forums.net/viewtopic.php?t=35306
#158144 - kusma - Thu Jun 05, 2008 6:44 pm
Dude, stop. He wasn't looking for what to develop, he was looking for a way of improving his methods of development. I hope you're not going to dig through all the threads here to find other places to promote your pet idea.
#158148 - silent_code - Thu Jun 05, 2008 8:47 pm
Or you could download my most recent release "Zombie NDS" off my page and try to break the highscore... <sarcasm/> ;^)
EDIT: just search the forum for mallinfo, there are several posts about it, some with example code.
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
Last edited by silent_code on Thu Jun 05, 2008 11:47 pm; edited 1 time in total
#158153 - AO - Thu Jun 05, 2008 10:16 pm
Also with only 4MB of memory, is there a way of verifying how much memory is being used?
Currently I'm just coding away but it's important to know the limitations i have. For example how big can the arm7/9 images be? Does their size affect how much heap i can allocate? Is there some way to find the available heap/stack space at runtime at the very least so i can print some warnings when i get close to the limits?
#158154 - Maxxie - Thu Jun 05, 2008 10:31 pm
bigger binaries size increase the address of the heap begin. Thus yes, larger binaries mean lower heapsizes.
You can use mallinfo to get information about the current malloc-situation.