#153121 - skrooby - Tue Mar 25, 2008 8:11 am
Hi Gang,
I have a few questions geared toward transitioning from Homebrew to Nintendo's SDK and was wondering if anyone knows enough about Nintendo's SDK to answer these questions. I wasn't able to readily find answers to these in the newbie forum so please humor me:
1) I understand that main memory is 4mb. Can I use an arbitrary portion of that memory for executable code? If I'm limited to a certain size, can I swap in code at runtime?
2) What's the maximum amount of memory I can use and safely assume would fit on a shipping DS cartridge?
3) About the homebrew APIs themselves: how closely do the match Nintendo's APIs? Could I just take my homebrew code and drop it over Nintendo's SDK and expect to recompile with no problems, or are the APIs totally different?
4) Does the compiler in DevKitARM come anywhere close to Nintendo's compiler in terms of optimization capabilities?
That's about it, thanks for reading. I've download DevKitARM and played around with the examples. Everything looks straightforward so far and I'm looking forward to doing some real coding.
-S
#153131 - silent_code - Tue Mar 25, 2008 1:37 pm
disclaimer: not meant to personally offend you!
hint: people who (*legally*) got in touch with the official nds sdk had to sign a NDA prior to that. don't expect anyone to answer your questions. at least not in great detail.
if you start working with the sdk, you'll have a lot of docs and demos to start with. so, come on, what do you need that info for? it's not all *that* related to the nitro sdk and also applies to libnds, because it's really about the hw.
most likely nitro sdk and libnds are totally incompatible.
hot swappable code can be done (ds organize and others support .dll-style plugins) with some effort on your side.
4mb are 4mb are 4mb are... ;^p desing your code to fit data in 2mb as needed and you'll have enough memory for the code and memory buffers etc.
devkitarm is cool! especially for a free product! :^) i don't know if it's better than nintendo's though.
about official cartridge sizes: they are floating somewhere on the net. i remember sizes of 1024 megaBIT (= 128 megabyte) and up.
last but not least: WELCOME TO THE SCENE! :?D
#153155 - Miked0801 - Tue Mar 25, 2008 8:12 pm
1. I've not had an issue with the memory footprint of the SDK. You link what you use. Yes, you can page code in at run-time via overlays or whatever, but it's a bit of a pain to debug. I doubt you will have need to do this.
2. Nintendo carts go from 32MBytes to 128MBytes right now with various save game sizes and options, but that's subject to change at any time.
3. I haven't done homebrew, so I can't comment on difficulties. That said, most of your code should be machine independent which makes porting a bit easier. Personally, I don't think it would be too hard to part across. Just getting the initial hardware layer in place will take a bit of time.
4. Lol. The homebrew compiler is far superior believe it or not.
I'm pretty sure I've violated no NDAs with the above info. That said, I am treading somewhat carefully here so don't expect too much more in depth info that the above.
#153161 - silent_code - Tue Mar 25, 2008 9:40 pm
4. <- <lol> ;^D
#153183 - furrykef - Wed Mar 26, 2008 2:17 am
DevkitARM uses GCC as its compiler. GCC is a very old compiler... now, "old" often means "bad", but that's definitely not the case here. Since GCC is still very much used and maintained -- in fact, it's probably the most popular compiler in the world next to Visual C++ -- that just means it's really stable and really good at what it does.
I recall hearing a couple of years ago that some official developers also use GCC as their Nintendo DS compiler. I'm sure they don't use libnds, though.
- Kef
#153193 - skrooby - Wed Mar 26, 2008 7:13 am
No offense taken, and all your answers helped greatly. I just needed a broad picture. =)
#153780 - sgeos - Sun Apr 06, 2008 6:50 am
1) Read the homebrew docs. Everything you need to know ought to be in there.
2) Read the homebrew docs or find game specs or worry about this when it becomes a problem.
3) Abstract your code. If you build on top of whatever API your are using you should be able minimize the code rewriting.
4) Miked0801 knows what he is talking about.
Just make a game. I guess my advice is:
A) Use tools and flexible PC files that can easily be converted into some platform specific format.
CSV and TXT are good places to start if you need something simple and standard.
B) Work from a spec. If you have clearly defined what you are doing, even 100% module rewrites should not be a huge deal.
-Brendan