I used an r4i revolution card for NTR Boot but then I semi-bricked it because I did not know it was incompatible. Every time I loaded a ds game it would not load but all homebrew apps worked fine. So what is the difference between homebrew ad regular ds games. (I know this is meant for 3ds questions but that area is kind of dead)
Most people do view new content so sections being less active does not matter so much.
Anyway for the purposes of flash carts homebrew tends to lack anti piracy, might have some subtly different formatting, might well use a different format (though I am not sure if current DS slot stuff will support all the legacy fun and games), might well use DLDI and as such probably has a different launch pathway in whatever flash cart firmware you are using compared to commercial games. I would then probably guess that the semi bricked cart lost/corrupted its commercial code but the homebrew stuff was either in a different location or small enough to dodge it.
Anyway for the purposes of flash carts homebrew tends to lack anti piracy, might have some subtly different formatting, might well use a different format (though I am not sure if current DS slot stuff will support all the legacy fun and games), might well use DLDI and as such probably has a different launch pathway in whatever flash cart firmware you are using compared to commercial games. I would then probably guess that the semi bricked cart lost/corrupted its commercial code but the homebrew stuff was either in a different location or small enough to dodge it.
ds games resort to SDK calls, and "NDS loaders" patch SDK calls to redirect to DLDI, thus, a "rom" on memory, or use native SD card calls to onboard FPGA commands (so it is faster), but literally the DLDI driver does that for you and as long a DLDI driver is properly written all NTR homebrew is guaranteed to work.
ds homebrew skip all of that, and just execute NDS binaries through a somewhat standardized / mimicked NDS layout (ARM7 and ARM9 binaries) defined in the NDS Header. The NDS loaders (such as closed source or open source nds loaders) just read the header from the file, extract and relocate each binary into their respective sections and then both ARM Cores at the same time reload their sections.
As for the reason why semi-bricking your card prevents you from running retail "rom", this is just conjeture but maybe the NTR Boot more or less messed up the FPGA <-> SD card init sequence, and the cart loader (not open source) rely on these as opposed to an open source nds "rom" loader such as nds-bootstrap (of which may work in your case)
ds homebrew skip all of that, and just execute NDS binaries through a somewhat standardized / mimicked NDS layout (ARM7 and ARM9 binaries) defined in the NDS Header. The NDS loaders (such as closed source or open source nds loaders) just read the header from the file, extract and relocate each binary into their respective sections and then both ARM Cores at the same time reload their sections.
As for the reason why semi-bricking your card prevents you from running retail "rom", this is just conjeture but maybe the NTR Boot more or less messed up the FPGA <-> SD card init sequence, and the cart loader (not open source) rely on these as opposed to an open source nds "rom" loader such as nds-bootstrap (of which may work in your case)
Last edited by Coto,
This is really useful but I'm still a nube in this area what exactly are SDK calls, nds loaders and FPGA commands and in a slightly more basic way how does homebrew bypass them.
SDK = The official toolchain DS games were developed with (that is 3D-gl like wrapper the NDS 2D/3D games, surround audio, hardware, and then higher level things like video decoders, audio decoders, WIFI, IPC comms (ARM7 and ARM9 cores work each independently), and the method ninty seems to love so far: the threading context (regardless if the system is single or dual/quad/whatever core). I think the threading context is the highest layer Nintendo uses to build games and to make them run as events. Such as certain character event will play a desired sound, and maybe render a few particle-like effects. That idea comes definitely from the N64 era, where the task/threading subsystem emerged. (that is the OSxxxx calls in the N64 SDK). Basically each thread happens either synchronously (such as running from the main() method) or asymchronously (such as running through an interrupt), but the state of a given thread is part of a global task and while the task must go from A->B->C->D->E->F to finish, it could maximize hardware performance.
nds loaders: chishm (the DLDI creator) wrote a bootstub nds loader, where you get the first sector pointed by a file handle (that the NDS binary start, from a filesystem point of view), and it will do what I wrote earlier
FPGA commands are just that, commands sent from the ARM7/ARM9 core AND understood through the SPI bus, by the FPGA, the onboard processor the flashcart has, mapped to CART ports. There is a bunch of commands you can dissect by reverse engineering flashcart loaders, such as writing or reading the onboard SPI flashcart bootcode (the one NTR Boot uses), and the same bootcode used since day-1 when flashcart makers found bugs or improvements, of which can be uploaded from the NDS and flashed.
FPGA commands also have the lower level SD card commands implemented:
http://academy.cba.mit.edu/classes/networking_communications/SD/SD.pdf
which basically enables the NDS to stream data from a SD device. And it is much faster to send SD read/seek/write commands directly than it is to use the DLDI layer (which does the same, but exposed through the DLDI API). Actually fatfs + DLDI is something I have seen a lot lately in NDS development and it does a fantastic job at supporting whatever kind-of-SD-you-may-have.
An example of FATFS + DLDI:
a gbarunner2 branch where I merged FATFS driver so it works on any card having DLDI R/W capabilities: (yes, any, even the old ninjapass x9sd but it is unbearably slow)
https://bitbucket.org/Coto88/gbarunner2/src/master/
ToolchainGenericDS:
https://bitbucket.org/Coto88/toolchaingenericds/src/master/
the open source "SDK" I am writing for NDS, very similar to devkitARM
nds loaders: chishm (the DLDI creator) wrote a bootstub nds loader, where you get the first sector pointed by a file handle (that the NDS binary start, from a filesystem point of view), and it will do what I wrote earlier
FPGA commands are just that, commands sent from the ARM7/ARM9 core AND understood through the SPI bus, by the FPGA, the onboard processor the flashcart has, mapped to CART ports. There is a bunch of commands you can dissect by reverse engineering flashcart loaders, such as writing or reading the onboard SPI flashcart bootcode (the one NTR Boot uses), and the same bootcode used since day-1 when flashcart makers found bugs or improvements, of which can be uploaded from the NDS and flashed.
FPGA commands also have the lower level SD card commands implemented:
http://academy.cba.mit.edu/classes/networking_communications/SD/SD.pdf
which basically enables the NDS to stream data from a SD device. And it is much faster to send SD read/seek/write commands directly than it is to use the DLDI layer (which does the same, but exposed through the DLDI API). Actually fatfs + DLDI is something I have seen a lot lately in NDS development and it does a fantastic job at supporting whatever kind-of-SD-you-may-have.
An example of FATFS + DLDI:
a gbarunner2 branch where I merged FATFS driver so it works on any card having DLDI R/W capabilities: (yes, any, even the old ninjapass x9sd but it is unbearably slow)
https://bitbucket.org/Coto88/gbarunner2/src/master/
ToolchainGenericDS:
https://bitbucket.org/Coto88/toolchaingenericds/src/master/
the open source "SDK" I am writing for NDS, very similar to devkitARM
so just to get it straight first of all how can a ds have a single processor that has two different types of cores? Second nds loaders are basically the homebrew version of Nintendo's SDK tool? And third are FPGA commands officially used by Nintendo or are they only a homebrew command. And what is the SPI Bus? Also does the DLDI Layer play a big role in loading ds homebrew? Also by any card having DLDI R/W capabilities you mean flash cards right? And is ninjapass9xd a homebrew loader? Sorry one last thins is the fat fs driver used for fat32 support?
Last edited by LinusRG,
Both processors are connected through an APB/AHB bus (ARM "model" to badge hardware together to their ARM cores):
http://www.differencebetween.net/technology/difference-between-ahb-and-apb/
Then each core runs their own bootcode and interrupts. The IPC FIFO hardware is a hardware unit which allows to send "mailing" words (4 bytes, unsigned 32bit) from an ARM Core to another, and there are events when the "mail box" is either full or empty (both trigger an interrupt on both ARM cores, depending what kind of "mailbox" event happened will generate an IRQ to the desired processor). This is unlike today's SMP design, but my take is that ninty tried to maximize their findings on what I wrote earlier about the "task context", and move it to a hardware design, while retaining minimal power consumption. This means, coding properly an application could work very well while retaining power saving features.
The SDK is a Software Development Kit. A NDS Loader is just bootcode supporting filesystem (through DLDI) so you can relaunch a NDS homebrew binary
while retaining some flags on the NDS Header section, also SDK binaries could have compressed code sections... while the homebrew one uses the minimal definitions to boot a homebrew binary.
FPGA could have been used by Nintendo at some point but they use ROM for retail carts. Also they use NitroROM / NARC (https://problemkaputt.de/gbatek.htm#dscartridgenitroromandnitroarcfilesystems) as a filesystem layer around their SDK. This means cart commands (through the SPI bus) aren't really FPGA, but NAND flash-like commands (http://www2.lauterbach.com/pdf/nandflash.pdf) but if they used FPGA in their development systems I wouldn't be surprised. FPGA allows more flexibility over tasks you can do while connecting more hardware, given BUS constraints.
Look around the web for "Serial Peripheral Interface". The DS uses it to connect to various hardware such as the RTC, the Touchscreen and the Flash NVRAM memory (Wifi + NDS bootloader)
Yes it does. For instance I have no idea if a newer R4i card 2020 will emerge tomorrow, but as long the DLDI init / read / write methods are working, the card is guaranteed to work with NTR homebrew. Thanks to Chishm's the DLDI section can be detected if a NTR homebrew uses DLDI, so you can dump the DLDI section into a file, and use it to patch other NTR homebrew that may have DLDI issues / not working. That way as long you have the DLDI binary, the homebrew nds loader can inject it into the upcoming next-to-load ntr homebrew, and use it to enable SD access, so the NTR homebrew can use SD. (that process is almost taken for granted for anyone loading a NTR homebrew binary)
Yes, the DLDI driver has a read command and a write command (required for performing any kind of write operation back to SD card filesystem, such as saving your game from within an emulator)
The Ninjapass X9SD I use it as a test case for almost all NTR homebrew coding, because it was one of the first SLOT-1 enabled "flashcards" back in 2008, it is buggy and the DLDI driver is unstable, and slow. I can safely say anything working on a X9SD (short for Ninjapass X9SD) will work everywhere.
Well, also Nintendo code is great in some NTR games, because even if that card is slow, their code was usually LZSS compressed thus as result, assets, programs streaming from SD card ended up being faster even on that card. Being 2019 and FPGA in NTR flashcards are very fast, so this isn't an issue anymore...
Indeed. In fact FAT12/FAT16 was common back in 2008, and fat fs driver still missed some FAT12/FAT16 stuff (of which @Gericom fixed) in gbarunner2, and yeah it allows also for mounting FAT32/EXFAT partitions in NTR homebrew.
I have no idea which slot-1 flashcard came before, but the DLDI binary is a driver, and as long you have that chunk worth of data you can use the embedded SD card in your flashcard through the DLDI driver API.
In fact, thanks to that "standardization" you can use the SD card in literally any NDS flashcard, and fat fs is an higher level API for generating file handles, where you just implement the raw sectors read/write commands (of which the DLDI layer exposes). In other platforms where there is no such DLDI driver, you must write your own read / write sectors commands (or these come from the vendor FPGA/SD driver manual, and you write these in either C or assembly where usually these write to specific mapped ports (in the NDS case it is the CARD address ports, of which a FPGA is listening at the same time).
edit: more info at:
https://www.chishm.com/DLDI/
In fact, thanks to that "standardization" you can use the SD card in literally any NDS flashcard, and fat fs is an higher level API for generating file handles, where you just implement the raw sectors read/write commands (of which the DLDI layer exposes). In other platforms where there is no such DLDI driver, you must write your own read / write sectors commands (or these come from the vendor FPGA/SD driver manual, and you write these in either C or assembly where usually these write to specific mapped ports (in the NDS case it is the CARD address ports, of which a FPGA is listening at the same time).
edit: more info at:
https://www.chishm.com/DLDI/
Last edited by Coto,
DLDI was a response to the dozens of new carts coming onto the market each with their own access code for the SD cards. That made old homebrew not work with newer stuff (which was happening at a rapid pace, also meant older carts started to be more desirable by some -- for quite a while actually we did not have a DLDI ROM dumper) and while some libraries/cart access protocols played nicely together there started to be conflicts as well.
To that end DLDI is more of an agreed standard that devs provide a space in the binary that devs can patch in their code to so as to have things read and write from their SD card/cf card/nand chip/..., and any cart looking to make any traction would do well to have it. DS carts all also seemed to go in for automatic patching but GBA side stuff didn't (or at least I don't know of any that did), though we did have DS side tools to handle it in the end. There were also a series of DLDI patches made to use the ARM7 instead of the ARM9 for a video playback program but we can skip that one.
So just to confirm basically it is an agreement all ds devs have including flashcard devs so all home brew works on all flashcards? Also do you mean the flashcard's binary or the homebrew app's binary?
Sorry that probably should have read
"To that end DLDI is more of an agreed standard that homebrew devs provide a space in the binary that flash cart devs can patch in their code to so as to have things read and write".
It is not really a formal agreement or anything like openGL, directX and such like but more that any flash cart dev that hoped to compete would have to provide it and there were nice libraries made available for homebrew devs so they did not have to have the headaches of having to test with multiple flash carts.
The piece of homebrew will also be the thing being patched, either hardpatched or softpatched at runtime.
Not all homebrew will use DLDI either, both in the technical sense (I doubt a flash cart maker would patch their own loader) and in a more practical sense -- if you did not care about loading and saving files from the SD card it was perfectly possible to make something more akin to a commercial DS ROM where all the files the homebrew needs are contained within the .nds file.
https://web.archive.org/web/20071012121745/http://chishm.drunkencoders.com/DLDI has some more if you are curious but we are now quite far from anything you likely will find practical and is more just technical discussion for the sake of technical discussion.
"To that end DLDI is more of an agreed standard that homebrew devs provide a space in the binary that flash cart devs can patch in their code to so as to have things read and write".
It is not really a formal agreement or anything like openGL, directX and such like but more that any flash cart dev that hoped to compete would have to provide it and there were nice libraries made available for homebrew devs so they did not have to have the headaches of having to test with multiple flash carts.
The piece of homebrew will also be the thing being patched, either hardpatched or softpatched at runtime.
Not all homebrew will use DLDI either, both in the technical sense (I doubt a flash cart maker would patch their own loader) and in a more practical sense -- if you did not care about loading and saving files from the SD card it was perfectly possible to make something more akin to a commercial DS ROM where all the files the homebrew needs are contained within the .nds file.
https://web.archive.org/web/20071012121745/http://chishm.drunkencoders.com/DLDI has some more if you are curious but we are now quite far from anything you likely will find practical and is more just technical discussion for the sake of technical discussion.
So for example if a small manufacturer creates an r4 card if they do not provide the right code home brew will not work on that card? Also doesn't that mean the part of the card that runs ds games also needs to be DLDI patched, because (correct me if I'm wrong) the flash card tricks the ds rom into loading and writing to the processor in the r4 card, then the r4 card interprets that and loads the next part of the game, or writes to the sd card. Also is all homebrew run from the r4 card's processor or does it use he ds processor as well?
They don't have to provide code to anybody. They can even keep it closed source and buried within their kernel if they want. It is mainly a list of how to form the commands people need for dealing with a file system. I don't know what the full list is but probably file open, file close, read, write, verify and maybe a file lookup command. This in addition to telling it what sizes of request to make (some things might only have worked with say 4K chunks, while others could do 8 or something), and possibly what timings or what to look for when it is ready to send. I never properly looked into all this so I don't know much more here, but source should be available if you want to look.
But yes if they put out their take on a DS flash cart but did not make sure to have DLDI working it would have been considered a serious negative to most flash cart purchasers and reviewers.
"r4 card's processor"
...
This is a whole other area.
For the most part DS homebrew code is run entirely within the DS itself, give or take whatever accessories people want to hang off it (DSserial if you want another tangent there) or server things that were done and sent over network.
Flash carts do technically have their own processors. The first of any real note as far as discussion about what it could do was probably the DSX with its FPGA but that amounted to very little in the end.
Things like the later EZ5 revisions/family did actually do some onboard DLDI processing to help speed write speeds up (when writing flash memory it makes sense to check the data is what it is supposed to be, you do this by hashing it and said hashes are not the cheapest computing operation) but this is academic at best. Said processors (or chips that could do something more than basic operations independently of the DS' CPU) probably also helped out with some kind of cheats, in game menus and whatever else for some flash carts but we can skip that one as I don't know what goes here and we have very little source code to look at for it.
For the most part though if anybody talks about running things on a flash cart's processor they mostly mean things like the iplayer, ismart MM and DSTwo, and as the first two* did not amount to too much/did not release code to allow homebrewers to do their thing then most likely just the DSTwo. These did
have an onboard processor of some note (one shared by a lot of "open" handhelds which was a popular concept at the time, hence the ports of dingux to it) that could go beyond what the baseline DS could do, though it was not easy coding in some ways, and why you have nice GBA, SNES, video playback, even a touch of PS1 emulation on those where your basic R4 type thing has far more limited options there.
*the iplayer was supercard attempting to make a more legit flash cart that could possibly be sold in shops (similar to some Datel cards) by not focusing on commercial games, it notably featured video playback options beyond what moonshell and the like could achieve. The isMM was a licensed clone of the iplayer but with the DSTwo loader ported to it.
As far as "tricking" the DS... that is not really how most electrical engineering types would view it. They would probably say the flash cart's job is to take the commands the DS sends in its format, translate them into something (most likely a read to the SD for a piece of ROM) and send it back in a timely fashion, and do what needs doing for saves as well which is just a different version of that (some different pins involved with that one). The flash cart's loader might also be able to tweak the ROM in real time to work differently (cheats, reset, savestates, in game text guide...).
@LinusRG
Just because I hate talking a lot on baseless conjecture:
https://bitbucket.org/Coto88/toolchaingenericds-multiboot
own NDS Loader, loads ToolchainGenericDS NDS binaries (thus, just homebrew). But that will give you a good insight about the process of booting NDS binaries. This is a NDS homebrew loader.
Just because I hate talking a lot on baseless conjecture:
https://bitbucket.org/Coto88/toolchaingenericds-multiboot
own NDS Loader, loads ToolchainGenericDS NDS binaries (thus, just homebrew). But that will give you a good insight about the process of booting NDS binaries. This is a NDS homebrew loader.
-
Sicklyboy
-
Xdqwerty
what are you looking at? -
The Real Jdbye
*is birb*
-
@
The Real Jdbye:
if i was female i would be a lesbian cause the lesbian flag has all my favorite colors in it
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
