#32698 - scknight - Sat Dec 25, 2004 4:19 am
Ok, so I'm looking over the ROM header from the metroid dump and looking at the code for darkfaders ndstool.cpp utility, and I have a couple questions hopefully someone can clear up. There's a rom9 rom offset and an arm7 rom offset in the header. So what does this mean? That when the game starts up it's executing both sections of code on each processor?
From what I understand as well since the header has the arm9 and arm7 rom offset, size and ram address, does this mean when the DS starts up it will copy these sectiions of code into RAM and execute from there? What is the purpose of this?
I guess it's not really clear what the DS is doing when it starts up. Can someone clue me in.
#32699 - LOst? - Sat Dec 25, 2004 4:37 am
And if it really runs the code in RAM, that must be expensive for Nintendo. A solution I have never seen Nintendo has ever done. They always choose cheaper ways to perform game functions such as running everything on the ROM itself, or use built in BIOS functions (ROM too)
RAM is something limited. If they decided to give the games more RAM, still that RAM will be used by the games, and not the code itself.
#32703 - mike260 - Sat Dec 25, 2004 4:57 am
| scknight wrote: |
From what I understand as well since the header has the arm9 and arm7 rom offset, size and ram address, does this mean when the DS starts up it will copy these sectiions of code into RAM and execute from there? What is the purpose of this?
I guess it's not really clear what the DS is doing when it starts up. Can someone clue me in. |
Yes, the DS copies both binaries to the specified RAM addresses, then jumps to the specified RAM entry points.
Presumably the carts are too slow to feed the CPUs at full speed - don't forget that compared to the GBA, the demand for instructions is tripled.
So is anyone else working on the Metroid ROM?
#32705 - scknight - Sat Dec 25, 2004 5:18 am
| mike260 wrote: |
| scknight wrote: | From what I understand as well since the header has the arm9 and arm7 rom offset, size and ram address, does this mean when the DS starts up it will copy these sectiions of code into RAM and execute from there? What is the purpose of this?
I guess it's not really clear what the DS is doing when it starts up. Can someone clue me in. |
Yes, the DS copies both binaries to the specified RAM addresses, then jumps to the specified RAM entry points.
Presumably the carts are too slow to feed the CPUs at full speed - don't forget that compared to the GBA, the demand for instructions is tripled.
So is anyone else working on the Metroid ROM? |
Ok so here's my next question. I've read speculation that the ARM9 processor is running the main game code and then possibly the ARM7 is used for audio and wireless and stuff like that.
So if it's the case that the code is copied to RAM and both processors started up running it, I would assume there's a way for the processors to communicate. Like if the ARM 7 is playing music and it has to be in sync with the ARM 9 somehow they're talking, probally just using RAM?
What is starting this whole process of copying the code to meory and running it. There's no branch instruction as the first thing like in the GBA Roms. So I would think there must be BIOS code to start the NDS ROM. But I thought everyone said the BIOS is identical. I think though that there must be some different routines for starting up NDS games.
Can anyone confirm this?
#32706 - tepples - Sat Dec 25, 2004 5:18 am
| LOst? wrote: |
| And if it really runs the code in RAM, that must be expensive for Nintendo. A solution I have never seen Nintendo has ever done. They always choose cheaper ways to perform game functions such as running everything on the ROM itself, or use built in BIOS functions (ROM too) |
The ROM portion of the N64's cart edge connector has 20 pins: a 16-bit multiplexed bus, and four control signals: latch high 16 address bits, latch low 16 address bits, read 16 bit word, and write 16-bit word. A scaled-down version of this bus, with 16 dedicated pins for the high address bits, was used in the Game Boy Advance cart edge connector. The MIPS processor in the N64 had no support for MIPS16, the MIPS analog to ARM's Thumb instruction encoding. I'm guessing that the N64 would run code much faster from the internal RAM than from ROM.
In addition, see also GameCube. Notice that GameCube games come on a disc, not a cartridge plus a disc.
| Quote: |
| RAM is something limited. If they decided to give the games more RAM, still that RAM will be used by the games, and not the code itself. |
By "that RAM will be used by the games, and not the code" do you mean "used by assets"? The PS1 seemed to get along fine with less than 4 MB of RAM plus a ROM BIOS.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#32712 - sgeos - Sat Dec 25, 2004 5:32 am
| scknight wrote: |
| So if it's the case that the code is copied to RAM and both processors started up running it, I would assume there's a way for the processors to communicate. Like if the ARM 7 is playing music and it has to be in sync with the ARM 9 somehow they're talking, probally just using RAM? |
The ARM 9 and ARM 7 have some shared RAM that they can use to communicate with eachother.
-Brendan
#32714 - scknight - Sat Dec 25, 2004 5:43 am
So what copies the code to RAM?
#32716 - sgeos - Sat Dec 25, 2004 5:48 am
| scknight wrote: |
| So what copies the code to RAM? |
I'd assume a BIOS boot strap routine initially moves code from the cart to a place where it can be run. Once the processors are running code, then they read from and write to the shared memory to communicate.
-Brendan
#32719 - scknight - Sat Dec 25, 2004 8:26 am
| sgeos wrote: |
| scknight wrote: | | So what copies the code to RAM? |
I'd assume a BIOS boot strap routine initially moves code from the cart to a place where it can be run. Once the processors are running code, then they read from and write to the shared memory to communicate.
-Brendan |
Like I said earlier, everything I've read here said the BIOS was identical to the GBA, but it seems like obviously it's not. Hopefully we'll be able to find a way to dump the DS BIOS.
#32732 - Zhila - Sat Dec 25, 2004 12:51 pm
From what I understand, the BIOS is the same as the GBA when the DS is in GBA mode. When in DS mode, it would thus use it's own BIOS.
_________________
Current high scores on Super Mario 64 DS:
Shell Smash - 50230
Wanted - 140
#32733 - mike260 - Sat Dec 25, 2004 12:55 pm
| Zhila wrote: |
| From what I understand, the BIOS is the same as the GBA when the DS is in GBA mode. When in DS mode, it would thus use it's own BIOS. |
Interesting factoid: The ARM spec defines an optional bit in a CP15 register, which controls where the CPU looks for exception vectors (ie. where the BIOS lives). The two selectable addresses are 0x00000000 and 0xFFFF0000, which happens to be where the DSes two BIOSes live (according to the leaked memory-map). So it may be that poking this bit switches which BIOS the DS uses.
#32744 - dafer - Sat Dec 25, 2004 6:32 pm
I'm don't know very much about hardware, so I wonder if the bios is placed inside the cpu. Because if it's not couldn't the cpu then be removed and replaced with some kind of device in betwen like the one darkfader uses to read the roms to get all the information of what instructions the cpu gets.