Gathering DS flashcard knowledge - DIY "opencard" idea

[xbmbmx]

I would like to learn some more about the technical workings of a DS flashcard. There are a few resources I am currently chewing through trying to get a general idea of the workings of the nds(i) systems. I'll go over the resources I already have and questions I have, and what my intentions are.

The software side of nds and flashcards is covered pretty well, my current reading list (in no particular order):

• problemkaputt GBATEK documentation
• GitHub ds-homebrew repositories source code
• GitHub DevkitPro source code & devkit
• Chism LibFat and DLDI

The hardware side of flashcards is a big questionmark for me, but I would really like to be able to learn more about the hardware setup.
Resources I have currently on my reading list for flashcard hardware (also in no particular order):

• DSBrut Schematics
• LibDSBrut (software but 100% related to the hardware side)
• GBATemp Thread "FlashCards: Which Chip Does Each Flashcard Use?" by c2ironfist
• natrium42's DSerial Edge documentation and libraries (most "complete" from-scratch-to-flashcard documentation I have found so far)

Projects like DSBrut and DSerial Edge (and the many software libraries) make me feel like making an open-sourced flashcard is a feasible task (and very very cool).
I'd like to take a very deep dive into this rabbit hole of possibility.

So, my questions for the community here are as follows:

• Are there more resources related to either software or hardware that are a must-read when attempting to understand any of this massive mountain of information?
• What are good resources to get going on the integrated-circuit and integrated programming side of things? I have good programming knowledge in some high-level languages (Java, JS, TS, C#, ...) and am currently learning/fidgetting with C++ using the learncpp site and have played with arduino for quite a while.
• Any resources on PCB design, physical side of things? (PCB and general hardware "design" are completely new to me when it's anything more complex then a breadboard with jumper wires).
• How do you program, test and reiterate with FPGAs and microcontrollers? Say I buy the required parts online and want to try to play with them (FPGA programmer etc) these tiny components obviously don't fit on a regular breadboard (and that wouldn't fit into a ds anyway) - how to do you go about testing it, making it, debugging it, reworking it...

I am amazed that there is not actually a "open sourced" flashcard project already with kernel code and chipset firmware and schematics and 3d print designs somewhere. Something you could send in to a pcb printing factory and get a basically working flashcard after some soldering and 3d printing...

I would like to clarify a few things too, as I have seen some threads on gbatemp with people interested in the same thing.

First, I know such opensource flashcard would get low traction, and not make any money. I know that, and it doesn't bother me. I am fascinated by this technology and if I ever could produce something at home that does the job, that is open source and that I can work with, I'd be immensly happy.

Second, playing commercial / licensed roms is not my intention. It's a major issue in the EU (where I am) - flashcards are generaly banned because they allow running pirated software. If I ever get to frankenstein a card together I would be more than fine with never supporting any commercial rom and only run homebrew. I am aware of the legal grey zone of creating a flashcard.

If anyone here has knowledge on any of my questions, has tips, has resources or reference documents about it... Please share them here! I'd really like to take a very long and deep dive into this and give it a shot.

--
For context: I'm a software engineering student (in my final year currently) looking to switch to a university bachelor of science in engineering technology. My knowledge regarding technology is growing every day and I am really trying to give this a shot.

English is not my native language

Thanks to anyone that shows any interest in this at all, I think it's really cool stuff

 

[SylverReZ]

I think @FAST6191 should know.

 

[master801]

FPGAs generally use an external flash for programming (although not every FPGA is the same), microcontrollers iirc can also have an external flash but generally use the internal flash instead.

Buy an FPGA kit and experiment with it. You don't really need anything overkill like a Xilinx Spartan-7 since a lot of the older flashcarts used ProASIC3 chips. You'll need to make a custom breakout board like with anything.

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

The DS is picky with timing, so don't use anything like a Raspberry Pi 3 because they're too slow.

You'll also need a logic analyzer and preferably an oscilloscope for sniffing out timing and data.

 

[FAST6191]

You have most things there.

Microcontrollers seem to have come rather up in the world compared to years past where it was FPGA and CPLD on the outside. Likewise FPGAs have more on the ease of use than years before where you were almost mandated to have 10 other things to make them work.
There will be dev kits and prototyping kits available, though if you want to jump if not in the deep end then over your head then you might find some old device that uses one and speak to it via its debug ports (JTAG through custom). FPGAs have moved on a bit from a few years back where it was a nice vhdl and verilog as your main options for things here, though FPGAs are still fundamentally getting a bunch of transistors/gates and making them do what you want which is a bit different to more abstract software programming and that which most microcontroller based things (never mind further simplified things like the arduino) go in for.

Not sure what I am pointing people at for learning electronics these days, and there is still a bit of a divide between pro (see altium and EAGLE) and open source world (variety of choices, though KiCAD is probably where you are heading here as most other things with traction are more low level).
There are generally three levels to a PCB design, many of which might be dedicated teams.
Breadboard a like is the base level that things start out at, sometimes it varies depending upon what level it is aimed at.
You then make a classic circuit diagram
After this you go to layout, and despite the promises of autorouters you are going to have manual things. This is also where you largely address the fun with physics -- all the same problems you might get with networks in the real world ( https://www.gamedeveloper.com/desig...r-what-i-learned-coding-x-wing-vs-tie-fighter ) applies with stray induction and such with your high speed lines, and you start pondering concepts like matched impedance to dodge things as well.

For DS stuff you then either make a PCB to extent the pins out into the world (see breakout board), though I might adapt something like the blaze 3 in 1 selector. You have options for the protocol already but if you were learning that then you get to contemplate dropping clock speeds (which can also be done if your FPGA is not speedy enough).

 

[xbmbmx]

@master801 : Thank you for the link and the suggestions!
@FAST6191 : Same thing, thanks a lot!

It's nice to get some tips from people who are more into the subject matter than I am currently. My main points for this "project" will indeed be:

• FPGA & microcontrollers : how to use, how to choose
• Nintendo DS hardware interaction with cartridges (GBATek looks like a good source)
• C/C++/ASM - I have never before developed or programmed with focus on hardware.

Currently I have been looking into the following products (I can't post links yet I believe) :

Microchip dot com - Part Number: A3PE-STARTER-KIT-2
Microsemi dot com - Part Number: M1A3PL-DEV-KIT

Both are FPGA ( ProASIC3E and ProASIC3L respectively ) development boards with flash/programmers and GPIO headers (and lots of other development ports / extensions).

Major bummer currenlty is that they're only on backorder - and the soonest marked batch date is 17 january 2024 .
My primary focus currently will thus be learning some of the theoretical parts of FPGA programming, maybe look for some simple emulator for PC to get the hang of the general flow (general, not necessarily for that specific FPGA).

I also have my arduino uno and raspberry pi 4B+, both may be too slow for nds flashcard "emulation" but they'll help me get the hang of more in-depth hardware development / design.

I guess I'll use this thread as some sort of update board if I make any usefull developments or need any help regarding anything I get stuck on.

Anyways, thanks for the tips - if anything pops up related to this topic ever, feel free to send me a message or just throw it in the thread

 

[master801]

@master801 : Thank you for the link and the suggestions!
@FAST6191 : Same thing, thanks a lot!

It's nice to get some tips from people who are more into the subject matter than I am currently. My main points for this "project" will indeed be:

• FPGA & microcontrollers : how to use, how to choose
• Nintendo DS hardware interaction with cartridges (GBATek looks like a good source)
• C/C++/ASM - I have never before developed or programmed with focus on hardware.

Currently I have been looking into the following products (I can't post links yet I believe) :

Microchip dot com - Part Number: A3PE-STARTER-KIT-2
Microsemi dot com - Part Number: M1A3PL-DEV-KIT

Both are FPGA ( ProASIC3E and ProASIC3L respectively ) development boards with flash/programmers and GPIO headers (and lots of other development ports / extensions).

Major bummer currenlty is that they're only on backorder - and the soonest marked batch date is 17 january 2024 .
My primary focus currently will thus be learning some of the theoretical parts of FPGA programming, maybe look for some simple emulator for PC to get the hang of the general flow (general, not necessarily for that specific FPGA).

I also have my arduino uno and raspberry pi 4B+, both may be too slow for nds flashcard "emulation" but they'll help me get the hang of more in-depth hardware development / design.

I guess I'll use this thread as some sort of update board if I make any usefull developments or need any help regarding anything I get stuck on.

Anyways, thanks for the tips - if anything pops up related to this topic ever, feel free to send me a message or just throw it in the thread

Those FPGA kits look way too expensive ($800+). Go for something a little cheaper and in-stock. You don't need anything crazy. It looks like both of those chips are discontinued, anyway.

You want a balance of something in-stock, not too expensive, has what you're looking for (processing power, logic elements, I/O, etc) and well supported in the dev community.

But in my opinion, the ProASIC3 series seems way too old to consider using. Not to mention FPGA chips being either out-of-stock or exorbitantly high.

EDIT: Reminder that the WiiKey Fusion didn't use anything fancy. They used a cheap ($20) FPGA ProASIC3 A3P250-VQG100. And the WiiKey Fusion "emulates" the disc drive while loading from SD.

EDIT EDIT: Looks like even the R4i Gold (r4ids.com) used the same ProASIC3 FPGA the WiiKey Fusion uses. https://github.com/ntrteam/flashcart_core/issues/40

 

[FAST6191]

Might well do well to start by making a save dumper in that case as a more gentle intro, maybe then a cheat setup, following that some kind of game genie a like and at that point you are on your way to full flash cart.

C/C++/ASM with a view to hardware...

C and C++ (granted C++ is harder here as the overheard is enough to annoy things) is one thing and in hardware it is more you might have fewer libraries than a full fat Windows or Linux setup, and be tighter on memory wastage (in addition to the general memory management the highest of high level kind of dodges for you).
Assembly is its own thing again, though the "C is portable assembler" thing kind of comes into play.

Also yeah no need to be dropping that kind of cash on a dev kit to get to grips with things for. There is bound to be something more low end to start with to get to grips with it all, before maybe finding some old cable box or whatever "junk" device used one a few years back and exposes something you can repurpose (should be several talks in and around it on stuff like https://www.youtube.com/@mediacccde/search?query=fpga ).

 

[ghjfdtg]

You can't program a FPGA using traditional programming languages. You need to learn a hardware description language like Verilog, VHDL, System Verilog ect.

These projects you linked seem to abuse the SPI interface which is meant for accessing EEPROM/SPI flash for savegames. The actual protocol the DS uses to access the ROM is much more complex and you need blowfish keys for the encryption. You obviously can't redistribute these keys without risking a takedown from the Nintenjas.

 

[xbmbmx]

Those FPGA kits look way too expensive ($800+). Go for something a little cheaper and in-stock. You don't need anything crazy. It looks like both of those chips are discontinued, anyway.

You want a balance of something in-stock, not too expensive, has what you're looking for (processing power, logic elements, I/O, etc) and well supported in the dev community.

But in my opinion, the ProASIC3 series seems way too old to consider using. Not to mention FPGA chips being either out-of-stock or exorbitantly high.

EDIT: Reminder that the WiiKey Fusion didn't use anything fancy. They used a cheap ($20) FPGA ProASIC3 A3P250-VQG100. And the WiiKey Fusion "emulates" the disc drive while loading from SD.

EDIT EDIT: Looks like even the R4i Gold (r4ids.com) used the same ProASIC3 FPGA the WiiKey Fusion uses. https://github.com/ntrteam/flashcart_core/issues/40

Okay, clearly I don't know anywhere near enough yet of FPGA "tiers" and options. I will be focussing on learning the software side things for now while I look around for some good books and/or tutorials on general FPGAs. I have found an article by HardwareBee that goes over a high-level FPGA selection process (clock speed, IO requirements, size requirements ...). I have some general idea now of how to "think" about the power of an FPGA but still I know near to nothing on the subject.

I haven't used any more advanced harware than an Arduino Uno/RPi. The most advanced I have ever "been close to" is when someone I know made a DIY computer with a 6502 microprocessor and they had shown me their assembly code and hardware setup.

Might well do well to start by making a save dumper in that case as a more gentle intro, maybe then a cheat setup, following that some kind of game genie a like and at that point you are on your way to full flash cart.

C/C++/ASM with a view to hardware...

C and C++ (granted C++ is harder here as the overheard is enough to annoy things) is one thing and in hardware it is more you might have fewer libraries than a full fat Windows or Linux setup, and be tighter on memory wastage (in addition to the general memory management the highest of high level kind of dodges for you).
Assembly is its own thing again, though the "C is portable assembler" thing kind of comes into play.

Also yeah no need to be dropping that kind of cash on a dev kit to get to grips with things for. There is bound to be something more low end to start with to get to grips with it all, before maybe finding some old cable box or whatever "junk" device used one a few years back and exposes something you can repurpose (should be several talks in and around it on stuff like https://www.youtube.com/@mediacccde/search?query=fpga ).

The project options do indeed look like a must-do before I even think about making something card-firmware alike. I have already been gazing over the code for DevkitPro's HBMenu and RocketRobz' GodMode9i. It'll take a while before I go from reading to understanding but that's the whole point of learning.

Chewing through the relevant parts of the GBATek document is also a must I believe before I get serieus about programming anything onto any hardware.

You can't program a FPGA using traditional programming languages. You need to learn a hardware description language like Verilog, VHDL, System Verilog ect.

These projects you linked seem to abuse the SPI interface which is meant for accessing EEPROM/SPI flash for savegames. The actual protocol the DS uses to access the ROM is much more complex and you need blowfish keys for the encryption. You obviously can't redistribute these keys without risking a takedown from the Nintenjas.

GBATek goes into quite a bit of detail on the interaction between flashcard and Nintendo DS(i). The two projects I linked (DSBrut and DSerial Edge) use their libraries etc indeed for the GPIO/UART end of things - the documentation for the actual flashcard-in-ds side is not that well documented. It's part of the learning curve I guess.

I must be honest, I was not aware that ASM/C/C++ were not a direct option for FPGAs. Now that I think about it a bit more logically that was to be expected and quite dumb of me to expect to just be able to write C for it. Anyways, that's also part of the learning curve. I'll look around for good documentation on those Hardware Description Languages and try to get some fidgetting going with that.

For the encryption: does a modded DSi system also require this encryption on the flashcard side to be valid? If the flashcard runs on a modded console without needing the encryption keys that'd be a good start... I have not dug deep enough into GBAtek and Unlaunch to know what actually gets enabled/disabled when you mod the console and how the encryption for cards functions as a whole. I am sure once I progress through the GBATek doc I will know more about that.


Thank you all again for the insights, my exams end soon and I am looking forward to get going on this.

[EDIT]: fixed some typos that made sentences hard to understand

Post automatically merged: Jan 16, 2023

I found a ProASIC A3P125 Development board with on-board flash, a few leds, a mini usb port, gpio headers and a few buttons for around €40 online. I think I'll give that a shot for my fidgetting / learning.

I also found this book for quite cheap at an online book store (around €16): FPGA Programming For Beginners - Frank Bruno (2021). It seems to focus on the AMD/Xilinx side of things. I don't know if that is an issue / will conflict with the fact I aim to use an Actel ProAsic...

Does anyone know if the Actel v Xilinx thing will be an issue? Is it a bad idea to buy the €40 Dev board with the Actel ProAsic?

Post automatically merged: Jan 16, 2023

- Just read through the short description of the book and it looks to me the book is pretty tied to the Nexys A7 development board as it relies on the presence of a vga slot on the dev board...

I'll most likely have to look for another book if I want to stick with the ProAsic3 dev board. I haven't bought anything yet though so if any of you have suggestions please shoot

 

[master801]

Okay, clearly I don't know anywhere near enough yet of FPGA "tiers" and options. I will be focussing on learning the software side things for now while I look around for some good books and/or tutorials on general FPGAs. I have found an article by HardwareBee that goes over a high-level FPGA selection process (clock speed, IO requirements, size requirements ...). I have some general idea now of how to "think" about the power of an FPGA but still I know near to nothing on the subject.

I haven't used any more advanced harware than an Arduino Uno/RPi. The most advanced I have ever "been close to" is when someone I know made a DIY computer with a 6502 microprocessor and they had shown me their assembly code and hardware setup.


The project options do indeed look like a must-do before I even think about making something card-firmware alike. I have already been gazing over the code for DevkitPro's HBMenu and RocketRobz' GodMode9i. It'll take a while before I go from reading to understanding but that's the whole point of learning.

Chewing through the relevant parts of the GBATek document is also a must I believe before I get serieus about programming anything onto any hardware.


GBATek goes into quite a bit of detail on the interaction between flashcard and Nintendo DS(i). The two projects I linked (DSBrut and DSerial Edge) use their libraries etc indeed for the GPIO/UART end of things - the documentation for the actual flashcard-in-ds side is not that well documented. It's part of the learning curve I guess.

I must be honest, I was not aware that ASM/C/C++ were not a direct option for FPGAs. Now that I think about it a bit more logically that was to be expected and quite dumb of me to expect to just be able to write C for it. Anyways, that's also part of the learning curve. I'll look around for good documentation on those Hardware Description Languages and try to get some fidgetting going with that.

For the encryption: does a modded DSi system also require this encryption on the flashcard side to be valid? If the flashcard runs on a modded console without needing the encryption keys that'd be a good start... I have not dug deep enough into GBAtek and Unlaunch to know what actually gets enabled/disabled when you mod the console and how the encryption for cards functions as a whole. I am sure once I progress through the GBATek doc I will know more about that.


Thank you all again for the insights, my exams end soon and I am looking forward to get going on this.

[EDIT]: fixed some typos that made sentences hard to understand

Post automatically merged: Jan 16, 2023

I found a ProASIC A3P125 Development board with on-board flash, a few leds, a mini usb port, gpio headers and a few buttons for around €40 online. I think I'll give that a shot for my fidgetting / learning.

I also found this book for quite cheap at an online book store (around €16): FPGA Programming For Beginners - Frank Bruno (2021). It seems to focus on the AMD/Xilinx side of things. I don't know if that is an issue / will conflict with the fact I aim to use an Actel ProAsic...

Does anyone know if the Actel v Xilinx thing will be an issue? Is it a bad idea to buy the €40 Dev board with the Actel ProAsic?

Post automatically merged: Jan 16, 2023

- Just read through the short description of the book and it looks to me the book is pretty tied to the Nexys A7 development board as it relies on the presence of a vga slot on the dev board...

I'll most likely have to look for another book if I want to stick with the ProAsic3 dev board. I haven't bought anything yet though so if any of you have suggestions please shoot

Don't bother looking at those projects. They don't interface with an FPGA at all.

Instead, take a look at WoodR4. It directly interfaces with the FPGA and you'll be instantly confused by what it's doing because it's reverse engineered. https://github.com/lifehackerhansol/woodrpg

NTRBoot is also an alternative, but it doesn't really go much in-depth because it's meant solely to write firmware.

You'll still need to know ARM Assembly and C, because you'll need to write a kernel to interface between the FPGA card and your menu software. Otherwise you have an expensive fancy brick.

Slot-1 encryption for the DS was cracked long ago. This is how flashcarts like the R4 (original, not the clones) and AceKard, DSONE, etc get around the restrictions. Otherwise we'd still be using stone aged hardware like slot-1 passme cards and slot-2 flashcarts to load DS games. This is also how those physical cartridges of translated games and reproduction carts are made, as well.

The cracked encryption for the DS will not work for the DSi. It has extra signature checks and such. You'd run into the generic "error has occurred" like when an original R4 is put into an unhacked DSi. Look at the Hackmii link I posted a few posts ago. It covers how Action Replay (and newer flashcarts in general) bypass the DSi encryption.

 

[Sono]

I know you have written down a few things already, but I'll reiterate a few things so my reply is a bit more conscise.



On the software side, the bare minimums are:
- a UI where you can choose ROMs (needs DS programming knowledge, although you can probably nicely ask someone for this one)
- interfacing with an SD controller "compiled" into the CPLD/FPGA (which... good luck with knockoff cards, those don't support SPI mode, and SPI mode is slow as bollocks anyway, so you'll have to steal SDIO spec documents (pretty sure paywalled for members for 6k$, but leaked somewhere))
- FATFS (yeah, *you* have to make the filesystem code as well, like fopen/fread/etc.)
- DLDI (for homebrew which needs SD access, good luck with legacy hell and emulating flashcart DLDI behavior (as in, being broken instead of working to spec))
For DSi mode there are a few additional layers, but I didn't got it yet, so I don't know all:
- trick the system into even launching your flashcart in the first place without getting blacklisted
- somehow gain code execution

Optional:
- game patching (so games wait for the user's cheap and slow knockoff SD to finish reading (NTRCARD lacks waiting for the card to finish, not replying in time is illegal, unlike in CTRCARD), you need to patch some CARD_ and CARDi_ methods; you can probably find signatures for these functions on the internet)
- cheats (basically game patching, but from user-generated cheat codes instead)


For hardware side, you need:
- SD slot with enough pins to work in SDIO or SPI mode (you can omit card detect to save pins, I have not encountered a flashcart yet with hotswappable microSD)
- the CPLD/FPGA/microcontroller
- power regulation if using an FPGA with no internal regulator
- a single pull-up resistor on the /IRQ pin, so the DS doesn't go nuts

For chip side, you need:
- SDIO and/or SPI controller for SD
- 8-line (that is, 8 DATA lines, still need /CS and CLK, which are extra two pins) bidirectional SPI for NTRCARD interface side
- (1+3)-line SPI for save chip side (afaik mapped to D4..D7)
- iterative Blowfish (either clocked by the cartridge clock or by internal oscillator) for KEY1 mode (make sure your chip of choice has enough cells for at least 33344bits of register memory! Blowfish needs ((4*256)+18) 32bit numbers worth of direct storage)
- Linear-Feedback Shift Register for KEY2/enPng mode (it's just a 39bit LFSR, although optimizations are possible if you can't go over 32bits in size)
- some minimal state machine stuff and command interpreting, so you can actually boot the firmware of the flashcart without an SD inserted (it's too slow to power up the SD and read a firmware off of it, because as mentioned previously, not replying in time in NTRCARD is illegal, it will not work, and possibly cause bus contention if you try)



You'll sadly need a lot of already existing practical experience to be able to pull this off (it took me a lot of years to just start *comprehending*, and a few more years until I was able to recreate things), but Kudos if you can actually pull this off.

You could take a crack at the RP2040 (or if you want a ready-made board then Raspberry Pi Pico (not to be confused with the BCM chipset -based Raspberry Pi line!)) if you feel up to the challange but can't source a CPLD/FPGA in your budget. Although you need a lot of embedded systems knowledge for this one.


Comparison:

• CPLD
  • cheaper than FPGA
  • too few gates
  • not as clockable(?)
  • small size
• FPGA
  • super expensive
  • high barrier to entry (usually monetary and sourcing)
  • pretty well clockable, especially more expensive ones
  • probably too big to fit into a cartridge PCB
  • usually needs external power regulation
• microcontroller
  • extremely small
  • extremely cheap
  • very available
  • way too slow, but nothing some dark magic and overclocking can't fix
  • extremely slow internal/external flash
  • way too little amount of RAM to hold an entire ROM, and loading from microSD is just too slow for NTRCARD
    • you could fit a 2nd microcontroller with SRAM onto the PCB, and just load the ROM into SRAM. much more expensive and complicated, but you can get away with game patching CARD_ and CARDi_ functions if you do this

I haven't done much on DS-side, but feel free to ask for anything going outside of the DS (like cartridge hardware, protocoll, etc.).

 

[xbmbmx]

Don't bother looking at those projects. They don't interface with an FPGA at all.

Instead, take a look at WoodR4. It directly interfaces with the FPGA and you'll be instantly confused by what it's doing because it's reverse engineered. https://github.com/lifehackerhansol/woodrpg

NTRBoot is also an alternative, but it doesn't really go much in-depth because it's meant solely to write firmware.

You'll still need to know ARM Assembly and C, because you'll need to write a kernel to interface between the FPGA card and your menu software. Otherwise you have an expensive fancy brick.

Slot-1 encryption for the DS was cracked long ago. This is how flashcarts like the R4 (original, not the clones) and AceKard, DSONE, etc get around the restrictions. Otherwise we'd still be using stone aged hardware like slot-1 passme cards and slot-2 flashcarts to load DS games. This is also how those physical cartridges of translated games and reproduction carts are made, as well.

The cracked encryption for the DS will not work for the DSi. It has extra signature checks and such. You'd run into the generic "error has occurred" like when an original R4 is put into an unhacked DSi. Look at the Hackmii link I posted a few posts ago. It covers how Action Replay (and newer flashcarts in general) bypass the DSi encryption.

Thank you for the info. With the "knowledge" I have currently I understand what you are saying but I don't have enough experience or know-how to fully dive into it all. It'll be a slow process.

I do pick up from all the info I have already consumed that the FPGA side is indeed a very very core part of this.

I know you have written down a few things already, but I'll reiterate a few things so my reply is a bit more conscise.



On the software side, the bare minimums are:
- a UI where you can choose ROMs (needs DS programming knowledge, although you can probably nicely ask someone for this one)
- interfacing with an SD controller "compiled" into the CPLD/FPGA (which... good luck with knockoff cards, those don't support SPI mode, and SPI mode is slow as bollocks anyway, so you'll have to steal SDIO spec documents (pretty sure paywalled for members for 6k$, but leaked somewhere))
- FATFS (yeah, *you* have to make the filesystem code as well, like fopen/fread/etc.)
- DLDI (for homebrew which needs SD access, good luck with legacy hell and emulating flashcart DLDI behavior (as in, being broken instead of working to spec))
For DSi mode there are a few additional layers, but I didn't got it yet, so I don't know all:
- trick the system into even launching your flashcart in the first place without getting blacklisted
- somehow gain code execution

Optional:
- game patching (so games wait for the user's cheap and slow knockoff SD to finish reading (NTRCARD lacks waiting for the card to finish, not replying in time is illegal, unlike in CTRCARD), you need to patch some CARD_ and CARDi_ methods; you can probably find signatures for these functions on the internet)
- cheats (basically game patching, but from user-generated cheat codes instead)


For hardware side, you need:
- SD slot with enough pins to work in SDIO or SPI mode (you can omit card detect to save pins, I have not encountered a flashcart yet with hotswappable microSD)
- the CPLD/FPGA/microcontroller
- power regulation if using an FPGA with no internal regulator
- a single pull-up resistor on the /IRQ pin, so the DS doesn't go nuts

For chip side, you need:
- SDIO and/or SPI controller for SD
- 8-line (that is, 8 DATA lines, still need /CS and CLK, which are extra two pins) bidirectional SPI for NTRCARD interface side
- (1+3)-line SPI for save chip side (afaik mapped to D4..D7)
- iterative Blowfish (either clocked by the cartridge clock or by internal oscillator) for KEY1 mode (make sure your chip of choice has enough cells for at least 33344bits of register memory! Blowfish needs ((4*256)+18) 32bit numbers worth of direct storage)
- Linear-Feedback Shift Register for KEY2/enPng mode (it's just a 39bit LFSR, although optimizations are possible if you can't go over 32bits in size)
- some minimal state machine stuff and command interpreting, so you can actually boot the firmware of the flashcart without an SD inserted (it's too slow to power up the SD and read a firmware off of it, because as mentioned previously, not replying in time in NTRCARD is illegal, it will not work, and possibly cause bus contention if you try)



You'll sadly need a lot of already existing practical experience to be able to pull this off (it took me a lot of years to just start *comprehending*, and a few more years until I was able to recreate things), but Kudos if you can actually pull this off.

You could take a crack at the RP2040 (or if you want a ready-made board then Raspberry Pi Pico (not to be confused with the BCM chipset -based Raspberry Pi line!)) if you feel up to the challange but can't source a CPLD/FPGA in your budget. Although you need a lot of embedded systems knowledge for this one.


Comparison:

• CPLD
  • cheaper than FPGA
  • too few gates
  • not as clockable(?)
  • small size
• FPGA
  • super expensive
  • high barrier to entry (usually monetary and sourcing)
  • pretty well clockable, especially more expensive ones
  • probably too big to fit into a cartridge PCB
  • usually needs external power regulation
• microcontroller
  • extremely small
  • extremely cheap
  • very available
  • way too slow, but nothing some dark magic and overclocking can't fix
  • extremely slow internal/external flash
  • way too little amount of RAM to hold an entire ROM, and loading from microSD is just too slow for NTRCARD
    • you could fit a 2nd microcontroller with SRAM onto the PCB, and just load the ROM into SRAM. much more expensive and complicated, but you can get away with game patching CARD_ and CARDi_ functions if you do this

I haven't done much on DS-side, but feel free to ask for anything going outside of the DS (like cartridge hardware, protocoll, etc.).

Yes, the more I'm reading the replies and researching the more it seems I'll either take 20 years or I will need some peeps who have (big) part of the knowhow already and are interested in tracking along with me.

I'll take a look if I find some ARM/FPGA masterminds that may be, at all, interested in the makerspace in my town. Maybe I can find some ASM overlords in my uni as well. I had a team I joined a few hackathons with and some of them are into this sort of thing I think.

And the community here of course!

It's just all very cool technology and for some weird reason the nintendo DS(i) really interests me deeply.
I'm still amazed that apart from wood and some old acekard rpg kernel, there is basically 0 open (or leaked) source of kernels / firmwares / anything inbetween for the physical cards. If only teams threw their code on some issue tracker or file host the day they disbanded.

My main struggle currently is figuring out where to even start...

The integrated / FPGA part of the whole ordeal is clearly the most important part for getting anything going on the DS (Lite) at all. Even if it's just a blank icon or the ds recognizing anything.

So, to conclude this message - rough outlines of my plan:

1. Read GBATek, even if I don't understand it all, to know what topics I need to research
2. Based on reading GBATek make an obsidian knowledge base to organize things a bit, my notebook is exploding already and all I have done is research parts an post on this thread.
3. Find someone with more in-depth knowledge of FPGA programming and interfacing with hardware.
4. Find a good FPGA book and devkit, finish it and focus on learning an FPGA programming language.
5. Hardware (???) I'll at least need something that fits into the DS from the FPGA dev board with jumper wires. I imagine that must be "doable" to pcb print and 3d print a case and all...

After this I'm unsure, the plan will develop. Somewhere after step 5 I'll need to go really hard on the DS homebrew side and get a very good knowledge of ARM7/9 programming.

I predict tons of coffee, lots of crying and pain, possible failure and a lot to learn.

I do very much appreciate the community replies! I really really do. I was half expecting to instantly be told to not even start at it but I'm pleasantly surprised. Thank you all!

 

[Sono]

-snip-

If you have a chat system (IRC, Discard, Telegram, or whatever really) then I can hook you up with everything you need to know. I have done it before, so I already know all the pains and pitfalls.

 

[master801]

-snip-
It's just all very cool technology and for some weird reason the nintendo DS(i) really interests me deeply.
I'm still amazed that apart from wood and some old acekard rpg kernel, there is basically 0 open (or leaked) source of kernels / firmwares / anything inbetween for the physical cards. If only teams threw their code on some issue tracker or file host the day they disbanded.
-snip-

I don't think most of the people making the clone R4 flashcarts know what they're doing tbh.

All of the R4 clone carts use some sort of frankenstein FPGA code built on top of the R4 to support SDHC. Not to mention how few original carts there were on the market in ye' olden days.

DSTT is a clone of DSONE, R4 (original) is a clone of a different cart if I remember correctly (M3 DS Simply?) and well, you already know... all the R4i carts are just clones of the clone DSTT or clones of the R4...

The only original flashcarts I can think of which weren't clones, are: EZFlash, CycloDS, Acekard, and of course, SuperCard.

Also, I found a link to what I was talking about with the encryption. It's just general info on it, no explanations or details whatsoever. https://pineight.com/ds/pass/#nopass

As a side bit, proper flashcarts (like the DSTWO or similar) will allow games to connect successfully to the Wii. Flashcarts like the DSTT and R4i clones will not. Some flashcarts are known to break Download Play as well. Don't remember what exactly causes this to happen.

If you don't know where to start, start by sniffing out data and protocol made by regular game carts. You'll need a logic analyzer and maybe an oscilloscope. FPGAs can be made into logic analyzers, but in my opinion a dedicated unit is better.

 

[The Real Jdbye]

I wonder if it might be possible with RP2040 or if it's simply not powerful enough. We've seen some amazing things done with it already.

 

[Sono]

I wonder if it might be possible with RP2040 or if it's simply not powerful enough. We've seen some amazing things done with it already.

I have done it, it is possible. Although I think I will need two RP2040 instead of just one, as I need more CPU cores for processing, as NTRCARD alone takes up 100% of both CPUs. I had to involve *every* trick for the RP2040 to squeeze out all bus bandwidth with least waitstates possible.

To add SD streaming functionality, I *will* need a 2nd NTRCARD, and hook them up via some parallel bus. There are simply no CPU cycles left to handle SDIO and/or filesystem.

Currently I can get away with a single RP2040, as I have the ROM hardcoded into the binary, and stream it asynchronously during idle time into RAM.

 

[xbmbmx]

If you have a chat system (IRC, Discard, Telegram, or whatever really) then I can hook you up with everything you need to know. I have done it before, so I already know all the pains and pitfalls.

Sure, I'll send you a private message with my Discord information. I'd be very happy to see what you have, as a starting plate and to analyse the general communication before I dive into creating something myself.

I don't think most of the people making the clone R4 flashcarts know what they're doing tbh.

All of the R4 clone carts use some sort of frankenstein FPGA code built on top of the R4 to support SDHC. Not to mention how few original carts there were on the market in ye' olden days.

DSTT is a clone of DSONE, R4 (original) is a clone of a different cart if I remember correctly (M3 DS Simply?) and well, you already know... all the R4i carts are just clones of the clone DSTT or clones of the R4...

The only original flashcarts I can think of which weren't clones, are: EZFlash, CycloDS, Acekard, and of course, SuperCard.

Also, I found a link to what I was talking about with the encryption. It's just general info on it, no explanations or details whatsoever. https://pineight.com/ds/pass/#nopass

As a side bit, proper flashcarts (like the DSTWO or similar) will allow games to connect successfully to the Wii. Flashcarts like the DSTT and R4i clones will not. Some flashcarts are known to break Download Play as well. Don't remember what exactly causes this to happen.

If you don't know where to start, start by sniffing out data and protocol made by regular game carts. You'll need a logic analyzer and maybe an oscilloscope. FPGAs can be made into logic analyzers, but in my opinion a dedicated unit is better.

I understand. And posting your code online when you disband probably also boost competition which may be a bad thing if you plan to ever join another team / recreate your team in the future... Still the Flashcard scene (even projects that initially did share their source code) all seem pretty selfish.

I wonder if it might be possible with RP2040 or if it's simply not powerful enough. We've seen some amazing things done with it already.

Very interested in this myself too!

I have done it, it is possible. Although I think I will need two RP2040 instead of just one, as I need more CPU cores for processing, as NTRCARD alone takes up 100% of both CPUs. I had to involve *every* trick for the RP2040 to squeeze out all bus bandwidth with least waitstates possible.

To add SD streaming functionality, I *will* need a 2nd NTRCARD, and hook them up via some parallel bus. There are simply no CPU cycles left to handle SDIO and/or filesystem.

Currently I can get away with a single RP2040, as I have the ROM hardcoded into the binary, and stream it asynchronously during idle time into RAM.

Now this got me excited . I just knew that there had to be people here with the know-how that took a crack at this... I'll send you a message soon - bare with me I haven't used the PM system on here in a long while.

 

[The Real Jdbye]

I don't think most of the people making the clone R4 flashcarts know what they're doing tbh.

All of the R4 clone carts use some sort of frankenstein FPGA code built on top of the R4 to support SDHC. Not to mention how few original carts there were on the market in ye' olden days.

DSTT is a clone of DSONE, R4 (original) is a clone of a different cart if I remember correctly (M3 DS Simply?) and well, you already know... all the R4i carts are just clones of the clone DSTT or clones of the R4...

The only original flashcarts I can think of which weren't clones, are: EZFlash, CycloDS, Acekard, and of course, SuperCard.

Also, I found a link to what I was talking about with the encryption. It's just general info on it, no explanations or details whatsoever. https://pineight.com/ds/pass/#nopass

As a side bit, proper flashcarts (like the DSTWO or similar) will allow games to connect successfully to the Wii. Flashcarts like the DSTT and R4i clones will not. Some flashcarts are known to break Download Play as well. Don't remember what exactly causes this to happen.

If you don't know where to start, start by sniffing out data and protocol made by regular game carts. You'll need a logic analyzer and maybe an oscilloscope. FPGAs can be made into logic analyzers, but in my opinion a dedicated unit is better.

You got most of that wrong.
DSTT is not a DSONE clone, the DSONE's kernel was based on Moonshell whereas the DSTT's was based on the R4.
I don't know whether the R4 or M3 DS Simply was technically "first" or which team designed the hardware and software, but they both came out at the same time so there was obviously some cooperation happening there, neither of the cards can be considered a clone of the other. They were also not clones of anything else, at the time there were only a few other slot-1 flashcarts: NinjaDS, DS-X, SuperCard DSONE. All of them were original products, as were the R4 and M3 DS Simply. I think the Datel Max Media Player/Max Media Dock was also out before the R4/M3, which was also fully original, but couldn't (officially) run commercial ROMs.
Some of the R4i cards are Acekard clones, but most of them are indeed DSTT clones.

 

[Pk11]

You got most of that wrong.
DSTT is not a DSONE clone, the DSONE's kernel was based on Moonshell whereas the DSTT's was based on the R4.
I don't know whether the R4 or M3 DS Simply was technically "first" or which team designed the hardware and software, but they both came out at the same time so there was obviously some cooperation happening there, neither of the cards can be considered a clone of the other. They were also not clones of anything else, at the time there were only a few other slot-1 flashcarts: NinjaDS, DS-X, SuperCard DSONE. All of them were original products, as were the R4 and M3 DS Simply. I think the Datel Max Media Player/Max Media Dock was also out before the R4/M3, which was also fully original, but couldn't (officially) run commercial ROMs.
Some of the R4i cards are Acekard clones, but most of them are indeed DSTT clones.

DSTT actually is a cut down version of the DSONE, hence why the DSONE can run YSMenu. iirc it was actually designed by SuperCard or someone from SuperCard, though I'm not sure the details.

 

[The Real Jdbye]

DSTT actually is a cut down version of the DSONE, hence why the DSONE can run YSMenu. iirc it was actually designed by SuperCard or someone from SuperCard, though I'm not sure the details.

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.