#141753 - conejoroy - Sat Sep 29, 2007 9:44 am
Hello all ^.^
I've a simple question: how do I tell the compiler/linker that some binary data (like unsigned char data[] = { 0x01, 0x02, 0x82, etc... })
should be kept in ROM; that is, not loaded into RAM with the whole program?
Furthermore, can I access that pointer directly in my program?
I mean unsigned char a = data[1]; or maybe copy some part to RAM like this:
unsigned char* ram_p = new unsigned char[4];
memcpy (ram_p, data, 4)
I know it sounds soo newbie =S but i'll really appreciate any help...
PS: I saw the example makefile uses bin2o.. but it doesn't do what I want, am I right ._.?
Thanks =)!
#141755 - keldon - Sat Sep 29, 2007 10:46 am
| Code: |
| unsigned char data[] = { 0x01, 0x02, 0x82, etc... } |
You can access that array directly in your program.
#141758 - M3d10n - Sat Sep 29, 2007 1:25 pm
For SLOT-1 devices: you can't. At least not in the way you want. The whole ARM9 binary is loaded into RAM, so such array would be loaded too. You need to use libFAT and load your binary data from an external file stored on the card's filesystem.
(That's how commercial games do it, BTW).
With SLOT-2 you still have direct access to whatever data is appended to the ROM, so it's possible to do it that way, but you should avoid that if you want compatibility with SLOT-1.
#141765 - Peter - Sat Sep 29, 2007 3:59 pm
| conejoroy wrote: |
I've a simple question: how do I tell the compiler/linker that some binary data (like unsigned char data[] = { 0x01, 0x02, 0x82, etc... })
should be kept in ROM; that is, not loaded into RAM with the whole program? |
I guess it's not possible, because the NDS does not have ROM. The way to go is probably to store it into a file.
_________________
Kind Regards,
Peter
#141810 - conejoroy - Sun Sep 30, 2007 11:42 am
Thanks everyone for the replies ^^
| M3d10n wrote: |
For SLOT-1 devices: you can't. At least not in the way you want. The whole ARM9 binary is loaded into RAM, so such array would be loaded too. You need to use libFAT and load your binary data from an external file stored on the card's filesystem.
(That's how commercial games do it, BTW). |
So the official SDK also has a filesystem to retrieve files? by how much it differs from libFAT? I mean... libFAT is a standard way to do this (maybe an improvement using rw capacity on flash cards?) or just a workaround to a "propietary" filesystem? that filesystem also has "files" stored everywhere on the cartridge ROM? or an official game, by means of that filesystem, embeds everything on a single .nds?
(that reminds me of some old DOS games; they stored datafiles way beyond the end of the .exe itself; reading read-only data by opening the very same .exe... commercial games more or less do the same or I'm very wrong?)
| M3d10n wrote: |
| With SLOT-2 you still have direct access to whatever data is appended to the ROM, so it's possible to do it that way, but you should avoid that if you want compatibility with SLOT-1. |
Yes, I've R4DS, so SLOT-2 is out of the question.
Thanks again =)
#141825 - tepples - Sun Sep 30, 2007 4:10 pm
| conejoroy wrote: |
| So the official SDK also has a filesystem to retrieve files? |
Yes. It's been called several names: NitroROM, NitroFAT, NitroFS, etc. after "Nitro" which is the name for the official DS development kit.
Point of terminology: I don't really like the name "NitroFAT" anymore. What GBATEK calls its "FAT" is more like an inode table than it is like the linked chain of cluster numbers used by Microsoft's FAT file system.
| Quote: |
| by how much it differs from libFAT? |
NitroFS is read-only for most of the cart and read-write for a single file of fixed size (that is, the EEPROM).
| Quote: |
| I mean... libFAT is a standard way to do this (maybe an improvement using rw capacity on flash cards?) |
Chishm's libfat is the library that allows fopen() and friends to work on an ordinary FAT or FAT32 file system on a CF or SD card.
| Quote: |
| or an official game, by means of that filesystem, embeds everything on a single .nds? |
A .nds file is like a .iso file: it contains a boot sector (the ARM9 and ARM7 binaries) and a set of files for a program to read. Homebrew .nds files and DS Download Play demos just have the "boot sector" with no files.
| Quote: |
| (that reminds me of some old DOS games; they stored datafiles way beyond the end of the .exe itself; reading read-only data by opening the very same .exe... commercial games more or less do the same or I'm very wrong?) |
You'd be correct. I made a tool for appending an asset archive to a GBA program several years ago, and it still works on a DS with some SLOT-2 cards (such as SuperCard and M3).
One reason that more DS homebrew doesn't work this way is that nobody has figured out how the SLOT-1 and SLOT-2 cards' .nds loaders pass argv[0] to the program. This means that .nds files generally have to either hardcode the path in the .nds, search the entire card for the assets every time they run, or search once and overwrite part of the .nds. It's rumored that wintermute might be working on a more robust argv[0] for devkitARM R21.
| Quote: |
| Yes, I've R4DS, so SLOT-2 is out of the question. |
If you have a microSD adapter in SLOT-1, such as R4 or GnM, then libfat is the best option.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#142026 - conejoroy - Wed Oct 03, 2007 10:51 am
Thanks tepples, I'll use libfat =)
Just one more question... is it possible to develop and test a program that uses libfat on an emulator? or shoud I use gbfs instead while the program is in development or testing?
Thanks again =)
#142028 - tepples - Wed Oct 03, 2007 11:47 am
FCSR is libfat's answer to GBFS and should work on any emulator or SLOT-2 card that supports ds.gba (PassMe format) files.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#142031 - alekmaul - Wed Oct 03, 2007 2:59 pm
EFS-LIB can be a good try for such things too with SLOT-1 devices :)