All flashcarts boot a certain file off the SD card. Almost always, it's just a homebrew `.nds` file, which may or may not be encrypted (original R4, or any timebombed carts out there). The exception to this `.nds` file is the M3 line of carts, which uses a different type of header for whatever reason.Does this mean that a flashcards kernel (kernel, not firmware) is in essence a ".nds" program like any other, that is specialized in starting / transferring other ROMs from the flashcards (SD or other) memory to the DS memory?
Yes, nds-hb-menu can be a "kernel". The word itself doesn't mean much. There's going to be a specific file on the SD card (with some random extension like .dat or whatever), but that file is normally just an NDS file. It may be encrypted in some form (original R4 or timebombed cart).e.g. could nds-hb-menu be seen as a "kernel" and could a flashcard simply transfer nds-hb-menu to the DS's memory as a "kernel"?
I got a bit confused on this topic because all flashcards basically have some cluttered mess of .dat files or __rpg folders that represent the "kernel".
That said, the real meaning of a "kernel" is that it is able to utilize the cartridge hardware to, you guessed it, load ROMs off the SD card. Some carts have special hardware, and the kernel patches the game in memory to make use of this and enable compatibility of running it off an SD card as opposed to a traditional flash chip.
But generally speaking, anything can be made a kernel if you can build any homebrew NDS file, DLDI patch it, and rename it to the file name that the cartridge expects. That way, instead of having to update the cartridge every single time, you can just update this .nds file and get easier compatibility updates.
All flashcarts do it this way, with minor obfuscations that are mostly defeated. The "dat" file you speak of is just a homebrew NDS file. You can see my personal project where I aim to replace the kernel with a standardized loader here: https://github.com/lifehackerhansol/flashcard-bootstrap. You'll probably find "devnotes.txt" useful. I've found that several just needed memory address adjustments but are otherwise standard stuff.Why are no flashcards doing it this way (e.g. using .dat files or having a cluttered combination of many files represent the kernel). Is this only for obfuscation or is there some major step in kernel to DS communication that I haven't picked up on yet?
Of course, there are some carts that are different, for example the M3 line of carts have a totally different structure in their boot file and I have to end up manually patching some things so it loads my NDS file.
You can see https://github.com/DS-Homebrew/DLDI. (well nowadays instead of being DS-Homebrew it's my personal playground lol).I have been browsing through DLDI repositories now.
I understand the principle of DLDI - it acts as a uniform bridge between binary and memory, allowing device manufacturers to implement a device specific codeset while homebrew developers can use a unified interface without having to worry about the hardware.
I do however have a hard time understanding how that code in the DLDI template file achieves said communication with the memory (most likely SD Card) hardware. I assume this also passes throught the FPGA but how?
In most cases, actual SD card read/write is generally handled in the flashcart internally (via the FPGA or whatever the case). Each flashcart exposes a few set of CARD_COMMANDs (defined in card.h as REG_CARD_COMMAND). We then utilize these commands in the DLDI to send cartridge commands to the flashcart. Think of REG_CARD_COMMAND as an API of sorts, and all flashcarts do it a bit differently. Then, whatever controller in the flashcart hardware reads these commands, and then transfers data via REG_CARD_DATA_RD register.
In most cases I've seen, for example reading from the SD, the cartridge would send a command to the SD card containing the address of the SD card it wishes to read. We then wait for the cartridge to ACK this, and then we send a command that starts the raw read, and we get data via REG_CARD_DATA_RD. Then we loop it for as many sectors as necessary. Some add a checksum to the data, which is slightly overkill but I digress.
That being said, I purely work on the DLDI side of things, and I don't really know what goes on internally. So I can't give a straight answer on that side of things.