Hacking How does a flash cart work?

[Dj DiLorenzo]

First off let me thank the GBATEMP community for having a great website and forum. I have been watching some post for awhile but finally registered today. I have owned a few flashcarts between gba ones and the r4i.
My question is how exactly is the rom emulated through the cartridge. I am aware there is a storage medium for the roms to be place in, but what processes occur between the console and the cartridge. any and all opinions answers greatly appreciated.

 

[CIH137]

Well from my understanding, to emulate other game consoles, that the 3ds wasn't made specifically to play, there needs to be sufficient hardware. The psp and 3ds have similar processing power, i think, but Since the 3ds was not made to play those kinds of games, chances are it will never be emulated on the 3ds. DS games are made to play on 3ds so there is no compatibility issue with DS roms, but in the case of the original ds, if you used a flash cart, it was better to have a supercard ndstwo to help process gba games. While the ds could play gba games, it was from a seperate slot so that processing power was probably lost or separate from the DS game slot.


This is my understanding, and I think is is pretty accurate. As for the insides, I think it just uses the extra processing power necessary to treat the 3ds part as the gba part and so fourth.

 

[FAST6191]

Emulation, as CIH137 was getting at, is the wrong term. It refers to the running of code intended for another system via some form of code manipulation. Flash carts tend to run code on the hardware it was intended to run on, occasionally then lend extra processing power but that is also not unheard of on the consoles themselves (the NES and SNES were notorious for this).

Current 3ds carts then.

From my understanding the carts use a collection of bugs starting with DS mode (hence the extra loader cart/software, said bug also present until quite recently) and ending with a kernel level bug (which was present until system menu 4.5) to take over the system. If you own the kernel then you own the system, in this case they use that ownership to redo a bunch of code pertaining to the reading of 3ds carts.
The second cart is something of a retooled DS flash cart which the newly hacked kernel can instead direct 3ds cart reads to, apparently in something resembling DS protocol rather than 3ds protocol (which is different). Most flash cart setups do not always have this luxury, though GBA slot DS flash carts are another example, and will actually try to mimic the proper read protocol. Failures to do this are often used as anti piracy methods -- trying to read below address 8000h on a DS cart would fail in a given way, earlier DS flash carts did respond properly here and thus what I am told is the most common DS anti piracy method was born.

Once the signals come into the 3ds cart the onboard chip translates these reads into reads for the microSD card and sends them back in the appropriate format (this is why flash carts would have a device like a CPLD or a FPGA onboard to do this -- they are programmable chips and very well suited to just this sort of task). It does a similar thing for any save requests, though how each flash cart does this did vary on the DS and I am not sure what they are doing on the 3ds.

Along the way they added the option to trick the 3ds into thinking the NAND image (where the kernel and a lot more is stored when it is not running) was in fact on the SD card. As they own the kernel they can also run homebrew of various forms hence things now having a menu. Multirom is then a basic abstraction if you have a filesystem in place, the early MT card stuff seemed to take the N64 third party memory pack route of have multiple pages swapped with a button (obvious and pointless in the long run but if it sells you a few flash carts to people that are willing or clueless then what the hey).