gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > Some questions about memory

#66860 - ProblemBaby - Fri Jan 13, 2006 10:56 pm

Hi ive some questions about the memory layout!

1.
Is arm9 code forced to be in main memory and arm7 code in the exclusive iwram?
if no: why is it like so by default, and is it any good reason?
if yes: is the memory copied from the ROM data or is there special memory in the cart?

2.
What kind of sections do really exist? in GBA it was so easy you just could write section iwram/ewram/rodata and the code/data was putted there, why isnt it like that for DS?

3.
I looked at the makefile for tutorial 6 when the program cat was runned, what is it doing?

4.
How is memory allocation functions written? is it a global pointer to the free memory or something? how is it usually done?
for example if I do like this:

u32 *a = alloc(1024);
u32 *b = alloc(2048);

free(a);

u32 *c = alloc(512);
u32 *d = alloc(1024);

free(b);

free(c);
free(d);

what should an ultimate allocation routine look like?


Hope you can answer any of my questions;)
any help is very welcomed cause iam really confused!
Thanks in advance

#66936 - wintermute - Sat Jan 14, 2006 3:28 pm

ProblemBaby wrote:
Hi ive some questions about the memory layout!

1.
Is arm9 code forced to be in main memory and arm7 code in the exclusive iwram?


yes

Quote:

if no: why is it like so by default, and is it any good reason?
if yes: is the memory copied from the ROM data or is there special memory in the cart?


The nds file contains both arm7 and arm9 binaries. The start addresses and lengths of each are also specified in the header. The loaders copy these binaries to the specified places.


Quote:

2.
What kind of sections do really exist? in GBA it was so easy you just could write section iwram/ewram/rodata and the code/data was putted there, why isnt it like that for DS?


What specifically is the problem?

The DS doesn't have read only memory, all code is run from RAM. The equivalent of iwram on the ARM9 side of the DS would be itcm & dtcm, the ARM7 exclusive RAM is the equivalent on ARM7 but the devkitARM crtls place all ARM7 code and data there by default.

For most purposes you shouldn't really ever have to put anything in specific sections, even with the GBA.

Quote:

3.
I looked at the makefile for tutorial 6 when the program cat was runned, what is it doing?


It's combining several files into one.

Quote:

4.
How is memory allocation functions written? is it a global pointer to the free memory or something? how is it usually done?
for example if I do like this:

u32 *a = alloc(1024);
u32 *b = alloc(2048);

free(a);

u32 *c = alloc(512);
u32 *d = alloc(1024);

free(b);

free(c);
free(d);

what should an ultimate allocation routine look like?


devkitARM uses newlib as the C library. Newlib provides calloc & malloc (pretty standard functions as far as I'm aware)

http://sourceware.org/newlib/libc.html#SEC1


Can't say I've ever encountered alloc() - where did you get this from?

#66952 - ProblemBaby - Sat Jan 14, 2006 5:54 pm

Thanks for the reply!

Quote:

What specifically is the problem?

The DS doesn't have read only memory, all code is run from RAM. The equivalent of iwram on the ARM9 side of the DS would be itcm & dtcm, the ARM7 exclusive RAM is the equivalent on ARM7 but the devkitARM crtls place all ARM7 code and data there by default.

For most purposes you shouldn't really ever have to put anything in specific sections, even with the GBA.


I dont understand why its so hard to put things in ROM, and why .section .rodata puts in main memory?

Quote:

devkitARM uses newlib as the C library. Newlib provides calloc & malloc (pretty standard functions as far as I'm aware)

http://sourceware.org/newlib/libc.html#SEC1


Can't say I've ever encountered alloc() - where did you get this from?


I thought i had to write my own routines, so I just wanted an idea of how to do it. thats why I wrote alloc.

#66953 - wintermute - Sat Jan 14, 2006 6:13 pm

ProblemBaby wrote:
Thanks for the reply!

Quote:

What specifically is the problem?

The DS doesn't have read only memory, all code is run from RAM. The equivalent of iwram on the ARM9 side of the DS would be itcm & dtcm, the ARM7 exclusive RAM is the equivalent on ARM7 but the devkitARM crtls place all ARM7 code and data there by default.

For most purposes you shouldn't really ever have to put anything in specific sections, even with the GBA.


I dont understand why its so hard to put things in ROM, and why .section .rodata puts in main memory?



There isn't any ROM, the DS doesn't run code directly from it's game cards.


Quote:

I thought i had to write my own routines, so I just wanted an idea of how to do it. thats why I wrote alloc.


No, you don't have to write your own routines newlib provides the standard C library functions.

#66955 - tepples - Sat Jan 14, 2006 6:28 pm

ProblemBaby wrote:
wintermute wrote:
The DS doesn't have read only memory, all code is run from RAM [...] For most purposes you shouldn't really ever have to put anything in specific sections, even with the GBA.

I dont understand why its so hard to put things in ROM

Because not everybody has a GBA flash card. On the DS, ROM is considered a block device, in the form of a DS Game Card (if you're a licensed developer) or a CF or SD card (in a GBAMP, SuperCard, or M3). These block devices resemble a traditional disk drive much more than they resemble GBA ROM.

Quote:
and why .section .rodata puts in main memory?

Because if your storage is a block device, your program structure is going to be much more like a GBAMP CF multiboot program (such as Dwedit's PocketNES) than like a GBA ROM for the purposes of accessing assets.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#66957 - pepsiman - Sat Jan 14, 2006 6:31 pm

wintermute wrote:

There isn't any ROM, the DS doesn't run code directly from it's game cards.

The DS isn't able to run code directly from DS cards, but it is able to run code directly from GBA carts.
DSLinux does this, but it may be the only program that does.

#66959 - tepples - Sat Jan 14, 2006 6:40 pm

pepsiman wrote:
wintermute wrote:
There isn't any ROM, the DS doesn't run code directly from it's game cards.

The DS isn't able to run code directly from DS cards, but it is able to run code directly from GBA carts.

If you want to get a job with a licensed developer, then you are going to have to learn how to make your programs run the way official DS games run. Distributing a program as both a DS card and a GBA ROM will make the program twice as expensive to replicate, and Nintendo is not likely to approve it either.

If you do not want to get a job with a licensed developer, then what is the point of DS homebrew over GP2X homebrew or Palm OS homebrew?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#66966 - wintermute - Sat Jan 14, 2006 7:52 pm

pepsiman wrote:
wintermute wrote:

There isn't any ROM, the DS doesn't run code directly from it's game cards.

The DS isn't able to run code directly from DS cards, but it is able to run code directly from GBA carts.
DSLinux does this, but it may be the only program that does.


Well sure but writing code to run from GBA cart is a pain - both cores can't access GBA cart space simultaneously and you can't run code built this way from gbamp or via wmb.

#66976 - pepsiman - Sat Jan 14, 2006 9:19 pm

tepples wrote:
If you want to get a job with a licensed developer, then you are going to have to learn how to make your programs run the way official DS games run. Distributing a program as both a DS card and a GBA ROM will make the program twice as expensive to replicate, and Nintendo is not likely to approve it either.

I'm not trying to get a job with a licensed developer.
DSLinux can also be built as a .nds file that runs from RAM, but there is then less RAM available for userspace.

#66998 - olimar - Sat Jan 14, 2006 11:10 pm



Last edited by olimar on Wed Aug 20, 2008 10:06 pm; edited 1 time in total

#67012 - HyperHacker - Sat Jan 14, 2006 11:55 pm

I think I can answer that for most people: I actually have a DS. ;)

#67016 - tepples - Sat Jan 14, 2006 11:59 pm

olimar wrote:
tepples wrote:
If you do not want to get a job with a licensed developer, then what is the point of DS homebrew over GP2X homebrew or Palm OS homebrew?

WTF kind of comment is that?
The DS platform has many attractive qualities. I'm gonna go out on a limb here, and guess that most homebrewers are doing this for the enjoyment of it.

I became disillusioned with the Nintendo DS as a generic homebrew platform soon after I realized the following:
  • Emulators are not competent and will not become competent within the lifetime of the DS, forcing the time-consuming pak-swapping and reboot cycle, and
  • If none of the DS exclusive titles appeal to you, then DS homebrew is expensive (275 USD, itemized as $130 DS, $25 PassMe2, $30 for one of the few PassMe2 compatible games, $50 SuperCard, $20 CF or SD card, $20 CF or SD writer) compared to GP2X or Palm.

_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#67038 - ficedula - Sun Jan 15, 2006 2:25 am

tepples wrote:

I became disillusioned with the Nintendo DS as a generic homebrew platform soon after I realized the following:
  • Emulators are not competent and will not become competent within the lifetime of the DS, forcing the time-consuming pak-swapping and reboot cycle, and
  • If none of the DS exclusive titles appeal to you, then DS homebrew is expensive (275 USD, itemized as $130 DS, $25 PassMe2, $30 for one of the few PassMe2 compatible games, $50 SuperCard, $20 CF or SD card, $20 CF or SD writer) compared to GP2X or Palm.


You do realise most of that stuff isn't actually necessary for homebrew development? I mean, sure, if you want to spend that much...if you really want to inflate costs, after buying a GP2X you'd need to buy a lifetime supply of AA batteries! And hey, a computer would be good, and now I'll need a house to live in while I'm coding...

Seriously, what you actually NEED to develop on the DS would look rather like this:


  • Nintendo DS (you may already own one of these)
  • Ralink wifi card (if you weren't fortunate enough to own one already)


Note at this point you've spent less than the cost of a GP2X even if you bought a new wifi card. You need a Passme2 and a game if you have the new firmware and don't know a friend who can flash it for you and can't or won't attend a flashme meetup. You can sell both the Passme2 and the game afterwards if you're really short on cash. I always thought the point of DS development over GP2X development was that millions of us, literally, own a DS already (unlike the GP*) so the cost of homebrewing is the cost of a wifi card, in my case, and nothing else. If you want a console only for homebrew, why buy a console at all? Just develop GBA games on an emulator for free.

...on the other topic: the reason so few people run code from ROM is because as tepples said, not everybody has a GBA flash card. If your game requires a flash card to run, you've greatly reduced the number of people who will run it.

For maximum portability, write it to stream assets in at runtime via a variety of methods, and when running on a flashcart, your generic code (it IS all written generically, right?) will just be reading it from cart ROM rather than CF or whatever.

#67045 - The 9th Sage - Sun Jan 15, 2006 3:01 am

ficedula wrote:



  • Nintendo DS (you may already own one of these)
  • Ralink wifi card (if you weren't fortunate enough to own one already)


You would need to have your DS flashed already before you could run unsigned code (aka Homebrew) by sending it directly from a Ralink card. You'd need to either pay someone to do this, buy stuff to do it yourself, or if you're lucky have a friend do it.
_________________
Now with 20% More Old Man from Zelda 1 than ever before!

#67057 - ProblemBaby - Sun Jan 15, 2006 4:46 am

one more questions about 'cat', how do I know that it puts the data in ROM? and how do I know at which offset?

#67100 - dXtr - Sun Jan 15, 2006 3:05 pm

tepples wrote:

If you do not want to get a job with a licensed developer, then what is the point of DS homebrew over GP2X homebrew or Palm OS homebrew?


I hope that's not the reason why you're into NES development, I don't think "the big N" is so intressted in more licensed NES games ;P
_________________
go back to coding and stop screaming wolf :)

#67148 - tepples - Sun Jan 15, 2006 9:53 pm

ficedula wrote:
Seriously, what you actually NEED to develop on the DS would look rather like this:


  • Nintendo DS (you may already own one of these)
  • Ralink wifi card (if you weren't fortunate enough to own one already)

And shut down the PC every time I want to switch between accessing the Internet and developing with the DS. Would most of the people who read this forum consider that an acceptable sacrifice?

Quote:
You need a Passme2 and a game if you have the new firmware and don't know a friend who can flash it for you and can't or won't attend a flashme meetup.

Even if you do manage to find a used DS with firmware v1-v3 at a pawn shop, WMB still gives a corrupted logo and WiFiMe still needs GBA flash equipment. If the DS is your first handheld, how do you flash a DS without GBA flash equipment and without someone else on the Flash Equipment Meetups page who lives in your town?

And as for nesdev, the NES is out of patent so anybody can make and sell a famiclone without breaking the law as long as only homebrew ROMs are included if any.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#67155 - olimar - Sun Jan 15, 2006 10:13 pm



Last edited by olimar on Wed Aug 20, 2008 10:02 pm; edited 1 time in total

#67156 - tepples - Sun Jan 15, 2006 10:17 pm

olimar wrote:
tepples wrote:
Even if you do manage to find a used DS with firmware v1-v3 at a pawn shop, WMB still gives a corrupted logo and WiFiMe still needs GBA flash equipment.

FYI, the corrupted logo is from using the multi-loader built into ndstool. You're free to drop in any logo you like, including the original Nintendo one.

But that still doesn't solve the digital signature problem for people who don't have GBA flash equipment, such as people who played only authentic Game Paks on the GBA or who developed only multiboot games using the MBV2 or XBOO cable.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.