Gathering DS flashcard knowledge - DIY "opencard" idea

[Pk11]

YSmenu runs on a lot of different flashcarts, among them Acekard, DSTT and numerous clone carts, because it's been modified to work with almost anything, but originally/officially it only ever worked with the DSTT/AK2 and it was an unofficial modification by RetroGameFan that allowed it to work with other carts. I reiterate, the DSTT has no relation to the DSONE whatsoever.

Specifically DSONE SDHC I should say, @lifehackerhansol has said the DSTT is a cut down version of the DSONE SDHC several times in the past. I believe the DSTT DLDI also works on DSONE though I'm not certain on that. They're certainly not the same thing, but the architecture is similar or something like that due to being a cut down version.

I believe the only two carts YSMenu really supports are original R4 and clones and DSTT and clones (and thus back up to DSONE SDHC)

Edit: See this post

 

[metroid maniac]

A good read if DSi+ is to be supported: https://hackmii.com/2010/02/lawsuit-coming-in-3-2-1/

Is there any further information on how DSi protection is broken, especially in flashcards seen in the wild?
According to this article the ARDSi achieves code execution by returning a different overlay depending on whether the DSi menu is validating its authenticity or whether the game is loading it to execute it.

Is this the only method used? It may be possible to have a software exploit in the game software which doesn't require hardware spoofing.

I'm also very interested in the Stargate3DS flashcard's NDS mode because that has some really weird behaviour when used in consoles other than a 3DS.

 

[lifehackerhansol]

YSmenu runs on a lot of different flashcarts, among them Acekard, DSTT and numerous clone carts, because it's been modified to work with almost anything, but originally/officially it only ever worked with the DSTT/AK2 and later the original R4 and it was an unofficial modification by RetroGameFan that allowed it to work with other carts. I reiterate, the DSTT has no relation to the DSONE whatsoever.

There is no unofficial modification. You can even check the checksum of YSMenu.nds yourself between the DSONE version and the DSTT one.

YSMenu has worked with the DSONE SDHC since the beginning of time. You just had to load YSMenu.nds straight out of the menu, it was that simple. And people have since figured out how to directly boot into it, and RGF took an existing method to do so authored by bliss and shipped it with the rest of his YSMenu stack. NOTHING changed in YSMenu aside from basically using an autoboot.

In fact, the only unofficial modification that exists in RGF's YSMenu is the M3 DS Real. That one truly wasn't supported by the original YSMenu, and was a process of hex editing the original R4's YSMenu. (Which is fairly simple actually, since they're basically the same source code, just need to hex edit like 4 u8s and two opcodes)

It's been no secret that DSTT was created by remaining members of the SuperCard team.
And as far as compatibility between the two carts are concerned. Everything that works on the DSTT is retroactively compatible with the DSONE SDHC, but not vice versa, as the DSTT is missing PSRAM hardware. It really is just a cut down DSONE SDHC all the way down to the core SD card commands. Hell, I was writing some SD driver for the DSTT just last week, and I took the DSONE SDHC's source code as base for it, and made it work on both of them...

 

[xbmbmx]

I have started gathering information in a more organized manner using Obsidian.md and biblatex. If anyone wants access to the resource collection feel free to send me a PM. Currently it's on a private git repository because I use PDF copies of my resources, and I'm pretty sure I can't just throw PDF copies of articles and books into a public repo.

Just send me a pm and I'll give you read/PR rights and URL to the repo. I intend to work quite a bit on it in the upcoming month.

In the meantime, any suggestions, code resources, source code and tips are more than welcome.

Currently the DS <-> card protocol and Technical Spec are my primary focus. I'll be playing around with my RP Pico and I'll see if I can get my hands on a logic analyser.

 

[Flame]

i think software of loading roms and what not wouldn't be a problem if you can get the right open source blueprint for the hardware. when i saw this thread and read the post. first thing that came to my mind was the sd2vita and PSVSD project. yes the hardware and software is completely different things. so those project were made by homebrew veterans. but the type of road-map you would need can be based on that.

 

[Sono]

Yeah, the problem with this is the cost of the hardware.

The cost of the software is effectively "free", as you're already paying a lot to stay alive, and as a side-effect you can use that energy you have as a result of being not dead to make the software.
It's also infinitely replicable at effectively no cost, as deleting the replicas gives back the price of the storage (and let's pretend that filesystem fragmentation doesn't exist).

However there is no getting around the cost of hardware. Even if you find the right thickness and cheapest copper board, you'll still need to modify a plastic case, as it's needed for the ejection mechanism and card insert detection. Also the contacts on the cartridge pins will eventually wear out (especially if it's some cheap and uncoated material), and you also need a pull-up resistor on the /IRQ line.

Ironically I would've already done this if it wasn't for the breakout PCB I need, as my makeshift cart adaptor made out of a YSMenu'd R4i clone (as in, completely bricked) flashcart has destroyed my cartridge slot and its pins, so there is definitely a barrier to entry. You either pay up for a PCB plus cartridge outside plastic, or risk damaging your cartridge slot. Let's not even talk about the price of the solder, the soldering iron, and the bricked flashcart in the first place.
Also mass-production is a whole other can of worms. How do you get people to pay for it? I don't know the demand for versatile flashcarts and/or breakout board for the DS and/or 3DS, but it has definitely died down these days, so it might not be viable anymore to mass-produce a cartridge adapter which you could re-use for both DS and 3DS, and only reprogram the chip when it's needed.

 

[xbmbmx]

Yeah, the problem with this is the cost of the hardware.

The cost of the software is effectively "free", as you're already paying a lot to stay alive, and as a side-effect you can use that energy you have as a result of being not dead to make the software.
It's also infinitely replicable at effectively no cost, as deleting the replicas gives back the price of the storage (and let's pretend that filesystem fragmentation doesn't exist).

However there is no getting around the cost of hardware. Even if you find the right thickness and cheapest copper board, you'll still need to modify a plastic case, as it's needed for the ejection mechanism and card insert detection. Also the contacts on the cartridge pins will eventually wear out (especially if it's some cheap and uncoated material), and you also need a pull-up resistor on the /IRQ line.

Ironically I would've already done this if it wasn't for the breakout PCB I need, as my makeshift cart adaptor made out of a YSMenu'd R4i clone (as in, completely bricked) flashcart has destroyed my cartridge slot and its pins, so there is definitely a barrier to entry. You either pay up for a PCB plus cartridge outside plastic, or risk damaging your cartridge slot. Let's not even talk about the price of the solder, the soldering iron, and the bricked flashcart in the first place.
Also mass-production is a whole other can of worms. How do you get people to pay for it? I don't know the demand for versatile flashcarts and/or breakout board for the DS and/or 3DS, but it has definitely died down these days, so it might not be viable anymore to mass-produce a cartridge adapter which you could re-use for both DS and 3DS, and only reprogram the chip when it's needed.

True. I'm prepared to spend "quite a bit" on this. We'll see where it goes and if my progress is viable enough to justify spending money on this project.

Currently I'm planning on buying and FPGA dev board (but only after thoroughly researching and understanding what I really need), getting breakout boards and cartridge cases printed (can be done at maker space in my town for reasonable prices).

Other things to get started right now that I do have on hand are bread boards (loads of 'em ), jumper wires, RP Pico, a few other dev boards but those are presumably too slow for the project anyways (arduino, a few banana pi boards, ...)

Just need to avoid breaking the DS in the learning process. I am quite sure I can get a few of them in questionable states at around €15~€30 but I'd rather not spend too much on consoles.

Post automatically merged: Jan 19, 2023

i think software of loading roms and what not wouldn't be a problem if you can get the right open source blueprint for the hardware. when i saw this thread and read the post. first thing that came to my mind was the sd2vita and PSVSD project. yes the hardware and software is completely different things. so those project were made by homebrew veterans. but the type of road-map you would need can be based on that.

I'll take a look at that project setup. I even have one of those in my Vita right now . I never really looked at the research behind it though.

 

[Kevin23]

Lurker here,

If it is unclear to know where to start regarding hardware, in 2023, after public discussion, how did multiple people privately make flash carts back then?

 

[xbmbmx]

Lurker here,

If it is unclear to know where to start regarding hardware, in 2023, after public discussion, how did multiple people privately make flash carts back then?

Indeed, would be good to know. Major problem is that I doubt many teams were happy discussing hardware at all, let alone in an understandable and publicly available fashon.

Most of the knowledge was, I believe, kept within closed teams and forgotten once they disbanded or got into legal trouble and whatnot.

I wonder if some more in-depth information or discussion about this may be available on Chinese forums, or maybe even Japanese forums. Unfortunately I speak/read neither of these languages nor do I know of Chinese or Japanese forums with a theme like GBATemp.

I also believe that for people with good knowledge about embedded systems and the information available about the DS now, it wouldn't actually be  that hard to make a flashcard. It's just not really worth it unless you are personally interested in making one. There are already flashcards that can do pretty much everything a flashcard should be able to do for anywhere from €5 to €120.

I see this as a passion/learning project and I am personally fascinated by the DS and all the quirks and tricks of flashcards

 

[xbmbmx]

Very small update:

I have a breakout board for the DS now. I am working on getting a 3D printed cartridge casing for it, or repurposing a broken flashcard casing for it. I'm going through some github repository code (specifically two python projects to dump NDS roms and SAV, and a sav downloader in C) to get the hang of the command / read exchange a bit.

I'm ordering a proasic 3 devkit board from China (≈€20) and have found a few good looking cheap ebooks to get started with SystemVerilog. I have also found someone on my uni who once made a project with an RGB array and an FPGA and an SD card to display a single image from the SD card in the RGB array, he's open to guiding me through the SD card file specifics.

I guess it'll be silent here for a while now. I understand that my process and progress through this project will be a matter of many months, probably year +.

I'll keep posting significant updates in the future, maybe here or maybe in a new thread if this one becomes stale / not relevant to the progress topic.

 

[ghjfdtg]

Make sure System Verilog is supported by the tools and/or IDE Actel provides.

Probably too late but i would recommend the FPGAs from Lattice since they are more power efficient and have great open source community support.

 

[xbmbmx]

Make sure System Verilog is supported by the tools and/or IDE Actel provides.

Probably too late but i would recommend the FPGAs from Lattice since they are more power efficient and have great open source community support.

Not too late yet, I haven't ordered anything just yet. I figured I'd at least discuss it with someone IRL who has actually worked with them.

Any tips are still valid and I'll for sure resarch the Lattice option now that it has been brought up. Thanks!

 

[xbmbmx]

During the current state of my research I'm mainly trying to get the hang of DS <-> flashcard interaction. I've come across a few good starter reads: the "eeprom" example of DevkitPro's DevkitARM (especially the card.h made me understand it all a bit better). Also a few dumper programs in C and Python.

I've also tried to take a look at the old RPG source code for the AKLoader but I'm simply not advanced enough on the topic yet to really understand any of that.

I came across a question that's really bothering me now though, and it may sound simple but I'm having a tough time wrapping my head around it so please be nice , I'd like some semi-technical explanation about it.

As I understand it right now, after the DS does the KEY1 & KEY2 exchange and starts reading the ROM of the card, an executable binary is transferred from the card to the DS's memory, and later in the process of DS <-> card communication the execution of said transferred binary is started.

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?

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".

Would it be possible to have the kernel be a "KERNEL.nds" file basically that gets loaded into the DS's RAM once the KEY1 & KEY2 and other required stages of the card protocol are passed succesfully?

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?

I'm obviousy making assumptions about the protocol here in my message, I am starting from almost scratch with my knowledge on any of this so feel free to correct any wrong assumptions I made but keep it civil .

 

[ghjfdtg]

How it usually works:

1. The DS firmware initializes the ROM and encrypted communication. The flashcard pretends to be a game and delivers legit looking data.
2. The firmware reads headers, executables and overlays. The flashcard will at some point deliver modified data/code in form of executables or overlays instead of the game data it pretends to be. Sometimes vulnerabilities are used in the overlay handling of the firmware.
3. The firmware executes the loaded executables and this is where the loader for the "kernel" kicks in. It initializes the microSD card and loads + deobfuscates whatever .dat file the kernel uses from the root of the microSD filesystem.
4. The "kernel" takes over and you will see the menu to select games.
5. If you select a game the "kernel" loads and deobfuscates the ROM loader, passes it some config options and executes it.
6. The ROM loader loads the games executables, overlays and then applies patches so it can read from the microSD via a cluster lookup table. The same is done for savegame read/write. This cluster lookup table is sometimes implemented on the FPGA so the ROM loader just needs to fill it.
7. The game runs.

It really is just a big chain of stages of executables. Often just .nds files with or without obfuscation.

 

[xbmbmx]

How it usually works:

1. The DS firmware initializes the ROM and encrypted communication. The flashcard pretends to be a game and delivers legit looking data.
2. The firmware reads headers, executables and overlays. The flashcard will at some point deliver modified data/code in form of executables or overlays instead of the game data it pretends to be. Sometimes vulnerabilities are used in the overlay handling of the firmware.
3. The firmware executes the loaded executables and this is where the loader for the "kernel" kicks in. It initializes the microSD card and loads + deobfuscates whatever .dat file the kernel uses from the root of the microSD filesystem.
4. The "kernel" takes over and you will see the menu to select games.
5. If you select a game the "kernel" loads and deobfuscates the ROM loader, passes it some config options and executes it.
6. The ROM loader loads the games executables, overlays and then applies patches so it can read from the microSD via a cluster lookup table. The same is done for savegame read/write. This cluster lookup table is sometimes implemented on the FPGA so the ROM loader just needs to fill it.
7. The game runs.

It really is just a big chain of stages of executables. Often just .nds files with or without obfuscation.

Hmm, more steps than I had in my mental image up to now...

So before the kernel of the SD card is loaded, there is first some other, "bootloader" sent to the DS? (Step 3).

Is there any example of such bootloader source code? I assume there isn't but it's worth asking.

 

[ghjfdtg]

I'm not aware of source code for such a loader. It's stored in the SPI flash you can see on the PCB of most flashcards and they obfuscate it too. This is used to install ntrboot on these cards which is basically just replacing the ROM and blowfish keys.

 

[xbmbmx]

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?

Can someone provide me with an example codebase to achieve such a thing? I found a few posts on hackaday of some things that read SD cards and display something or do some HID input on a computer from an SD card but they al seem to use either microcontrollers or just a raspberry pi which isn't IC at all at that point. I have ready on multiple topics about hardware for the DS now that microcontrollers are simply too slow to be used for card emulation or even hardware interaction in general so I assume the microcontroller examples won't really be of any use for me.

Does someone know of a codebase that displays said interaction between code and SD through an FPGA? It doesn't have to be DS related, I'd just like to see what ports and rules the FPGA needs to allow such communication at all... I'm having a hard time picturing the protocol and structure of such functions.

I have found the fpga4fun website and that touches very lightly on the SD part of things but it doesn't go into code interaction. It just shows what pins are required for SPI mode and how you can achieve these pin connections in Verilog. The whole "how code can now use this connection" part is not present.

Also, somewhat off-topic: Am I better off making new topics for questions like this, or is this thread the best place to put this?

 

[Jayro]

I'm curious if the RP2020 Pi Pico chip is strong enough to manage running a DS Flashcart, as opposed to the typical power-hungry FGPA chips used. I know there's some GBC carts being developed with the RP2020 in progress at the moment, but the GBC is a far simpler system.

 

[xbmbmx]

I'm curious if the RP2020 Pi Pico chip is strong enough to manage running a DS Flashcart, as opposed to the typical power-hungry FGPA chips used. I know there's some GBC carts being developed with the RP2020 in progress at the moment, but the GBC is a far simpler system.

@Sono sent me a detailed explanation of his setup. I have followed his advice however of not diving into its codebase because it has the potential to confuse me completely...

It seems possible, however since I haven't analysed the codebase nor tested the setup physically I can't really comment on how efficient / reliable it is, and I also can't comment on wether it is suitable for flashcart emulation or only for commercial ROM emulation...

-- Edit:

Just noticed that Sono's implementation uses An RP2040 setup, not RP2020, my bad.

 

[Jayro]

@Sono sent me a detailed explanation of his setup. I have followed his advice however of not diving into its codebase because it has the potential to confuse me completely...

It seems possible, however since I haven't analysed the codebase nor tested the setup physically I can't really comment on how efficient / reliable it is, and I also can't comment on wether it is suitable for flashcart emulation or only for commercial ROM emulation...

Well the good news is the RP2020 chips are dirt cheap and plentiful, and come in a few package styles, so ordering a few to play with shouldn't set you back much. They're also well-documented online I believe.