Basic layout of a computer:
You have a processor (and possibly some stuff on the side)
You have some memory (usually a form of ram)
You have an output (think screen)
You have an input (think keypad)
You have some storage (in this case the DS cart)
You have something (or some things) to tie it all together
Some consider the processor the heart of the device whereas in reality it is just a number cruncher. It does however need code to run and this code is loaded when you load the DS game*. There is some memory inside the processor (the registers and the cache) but this amounts to a few kilo bytes in the case of the DS and even on top flight PCs it is less than 20 megabytes. The DS then has 4 extra megabytes of general purpose ram and a few sections of more specialist stuff.
*the DS has some onboard loadup code that loads the firmware which allows you to go on, earlier stuff like the GBA and all the old 8 and 16 bit consoles (leave off master system II fans) lack this which is why they do not work without a cart in them.
You need some way of accessing everything and the easiest way is to map it all to the "bus" as it were. The GBA did this and the DS still does this by giving over "bus" locations 08XXXXXX and 09XXXXXX to the GBA slot as well as a few mirrors at higher waitstates for the GBA (time to read increased so as to enable some things to be faster than others) but that gives a 32 megabyte limit without switching what appears on the memory (see bankswitching).
32 megabytes is small and it is hard to make it any bigger by simply mapping it to the bus (you can however then abstract it or you can use sector based addressing). The DS however does not mess around with mapping any longer and enables a very large limit by allowing small specialist commands (the abstraction part from the sentence above) to read the game cart (your flash cart acts as an interpreter for these reads and pulls the corresponding code from the memory available to it be it SD, CF, ms, NAND, ram......).
When a commercial game first loads up the header (think contents pages) of the game cart has all the data on the DS rom to come as well as stuff like the icon and text and the DS then pulls the ARM9 binary (program), the ARM7 binary and a file system storing it in the 4 megs of ram. More on this here: http://nocash.emubase.de/gbatek.htm#dscartridgeheader
As it needs the files it looks up the location in the file system and generates a command to do the deed. What the header is and does is stored within the DS firmware.
Just to add to the confusion although all known roms do use the nitro rom file system there is nothing stopping it from using something else from a technological sense (the specifics of the file system parsing is done by the binaries change from game to game, nobody would bother to make a new system though as there would be nothing much to gain and only time to waste).
In homebrew we can just pull the data from or stick it on the SD,CF...... thanks to stuff like libfat (DLDI which the user applies is used as every cart works differently and trying to get them to play nice is near impossible so the necessary code is added by the user).
FCSR just fakes the existence of an SD and when the game thinks it is reading SD it is really reading part of the homebrew .nds file.
Back when though we did not have the luxury and so homebrew used the 08XXXXXX and 09XXXXXX to up this limit a bit although the same thing essentially still happened (binaries went to the DS ram).
You have a processor (and possibly some stuff on the side)
You have some memory (usually a form of ram)
You have an output (think screen)
You have an input (think keypad)
You have some storage (in this case the DS cart)
You have something (or some things) to tie it all together
Some consider the processor the heart of the device whereas in reality it is just a number cruncher. It does however need code to run and this code is loaded when you load the DS game*. There is some memory inside the processor (the registers and the cache) but this amounts to a few kilo bytes in the case of the DS and even on top flight PCs it is less than 20 megabytes. The DS then has 4 extra megabytes of general purpose ram and a few sections of more specialist stuff.
*the DS has some onboard loadup code that loads the firmware which allows you to go on, earlier stuff like the GBA and all the old 8 and 16 bit consoles (leave off master system II fans) lack this which is why they do not work without a cart in them.
You need some way of accessing everything and the easiest way is to map it all to the "bus" as it were. The GBA did this and the DS still does this by giving over "bus" locations 08XXXXXX and 09XXXXXX to the GBA slot as well as a few mirrors at higher waitstates for the GBA (time to read increased so as to enable some things to be faster than others) but that gives a 32 megabyte limit without switching what appears on the memory (see bankswitching).
32 megabytes is small and it is hard to make it any bigger by simply mapping it to the bus (you can however then abstract it or you can use sector based addressing). The DS however does not mess around with mapping any longer and enables a very large limit by allowing small specialist commands (the abstraction part from the sentence above) to read the game cart (your flash cart acts as an interpreter for these reads and pulls the corresponding code from the memory available to it be it SD, CF, ms, NAND, ram......).
When a commercial game first loads up the header (think contents pages) of the game cart has all the data on the DS rom to come as well as stuff like the icon and text and the DS then pulls the ARM9 binary (program), the ARM7 binary and a file system storing it in the 4 megs of ram. More on this here: http://nocash.emubase.de/gbatek.htm#dscartridgeheader
As it needs the files it looks up the location in the file system and generates a command to do the deed. What the header is and does is stored within the DS firmware.
Just to add to the confusion although all known roms do use the nitro rom file system there is nothing stopping it from using something else from a technological sense (the specifics of the file system parsing is done by the binaries change from game to game, nobody would bother to make a new system though as there would be nothing much to gain and only time to waste).
In homebrew we can just pull the data from or stick it on the SD,CF...... thanks to stuff like libfat (DLDI which the user applies is used as every cart works differently and trying to get them to play nice is near impossible so the necessary code is added by the user).
FCSR just fakes the existence of an SD and when the game thinks it is reading SD it is really reading part of the homebrew .nds file.
Back when though we did not have the luxury and so homebrew used the 08XXXXXX and 09XXXXXX to up this limit a bit although the same thing essentially still happened (binaries went to the DS ram).
