That's odd. I was under the impression that the carts do not have a copy of a complete ROM. They only have snippets of a commercial ROM on them. The DS carts had very small snippets, while the DSi carts had about 1MB worth for the header and graphics which is why you see whatever icon you do in the DS menu. Since most carts just parrot a sequence during the boot process I don't think its necessary to have the entire ROM in there. I could be incorrect but if so I'd love to see a technical analysis of it. I think a lot of the 'full ROM' stuff came about because of the incorrectly named 'whitelisting' that was supposedly done which isn't the case.
Also they need to use an older game that uses the older SHA1 checksums in their 'whitelist' rather than the RSA sig that is used for later games. So that requirement somewhat limits what you can use as the icon.
I dunno, this is just what I read in one of the threads yesterday or the day before perhaps. And I thought there
was a whitelist of all existing DS games when the DSi was launched. In fact, I was pretty certain there was mention of that on HackMii or somewhere like that.
QUOTE said:
The integrity checking is there to ensure that the cartridge booted is a genuine licensed game cartridge. There is a whitelist stored in the DSi’s NAND, that has an entry for every DS game released, consisting of multiple SHA1 (How these hashes are constructed exactly hasn’t been confirmed) checksums for the cart header, ARM9 binary and ARM7 binary.
from
http://hackmii.com/2010/02/lawsuit-coming-in-3-2-1/
EDIT: From that same article, an explanation of how AR DSi works:
QUOTE
DSi console sends cart initialisation sequence
ARDSi cart determines it’s being ran on a DSi console and starts responding a fixed pattern on every read block request
Game’s header, ARM9 and ARM7 binary are loaded by the DSi menu and checked for integrity
Integrity checks pass since all data is 1:1 compared to the original ROM
Game starts running, parsing filename and file allocation tables of filesystem on cartridge
Game loads overlay 0×01 to 0x020BBF00
Game does more stuff and eventually branches to code inside loaded overlay @ 0x020BBFE8
The initial 0xE8 bytes of the datel payload are inifite-loop opcodes, entrypoint right behind it, payload gets executed
Payload sends secret F005000000000000 (Not so secret anymore now, huh?) cart command to put cartridge in secondary mode
Payload uses normal 0xB7 read commands to read the header, ARM9 binary and ARM7 binary respectively
Some IPC magic is done to capture execution of the ARM7 cpu
Finally a softreset SVC/SWI is issued to execute the newly loaded ARM9 code