Hardware Project Open source flashcart project info

Re-Identifiable

Member
OP
Newcomer
Joined
Dec 22, 2024
Messages
18
Trophies
0
XP
94
Country
Australia
Hello,
I am trying to make a fully open source flashcart for all DS/DSi/3DS consoles, although currently I am just going to focus on getting it working on the DS lite.
However, I can't seem to find much information on a few areas making it difficult to get what I need to actually start making the thing on my FPGA dev kit thing (me failing to find this information could just be my fault, lol).

Firstly, I can't really find any good resources on how the SD protocol works, I tried looking through the SDIO simplified specifications but that just feels like it has a lot of information missing, I understand that the way it appears to work is you send commands over the CMD pin of the SD card and then you can get a response or no response depending on the command, but beyond that, I can't find much on it. The sort of things I am looking for are how the commands are set out, like, what format are the commands in, what does all the abbreviations for the commands actually mean in binary (for example, I am seeing a lot of things like CMD0 Pin1=high, CMD8, IO=0, etc. but what does this actually look like if I were to try to send this down the CMD pin in binary, how would it be sent down as well), also an explanation of how to initialise the SD card and pull data from it would be nice too, their flow charts from their SDIO simplified specifications feels like there is some information I am just missing to understand it (BTW, I would prefer to use SD mode rather than SPI mode for the faster transfer speeds).

Secondly, I could find some resources on how the DS protocol worked but I am not understanding how the AP of the DS works, found nothing on the DSi, and also have no idea how the data transfer works, some information on how that works would be greatly appreciated. I understand it uses XOR encryption for most of the game file (I think) and than has some special encryption for the first few bytes of the game data which is double encrypted? But how does the encryption work and where are the encryption keys from?

Thirdly, I want to have IR sensors and receivers built into this flashcart for games that use them. How do games that have integrated IR sensors and receivers built into their cartridges go about using them? Like, do they have some special custom command that they send to the cartridge some how from the DS to send IR signals and a custom command that the IR receiver sends over the cartridge to the DS, or does it work some other way?

Finally, is there anything else I should know that I haven't asked about, something that all or most flashcarts have as standard and would be required, something about the DSIO protocol I should know (maybe something about SDHC/SDXC cards or something like that), anything else that could be an issue due to the DS hardware begin what it is (like how I have heard that the DS can be finicky with timings, how true is that, how precise do the timings need to be, and so on), etc?
 
  • Like
Reactions: KIlly728

kijetesantakalu042

Language guy
Member
Joined
Aug 3, 2024
Messages
965
Trophies
3
Location
planet x65943
XP
2,550
Country
Antarctica
Hello,
I am trying to make a fully open source flashcart for all DS/DSi/3DS consoles, although currently I am just going to focus on getting it working on the DS lite.
However, I can't seem to find much information on a few areas making it difficult to get what I need to actually start making the thing on my FPGA dev kit thing (me failing to find this information could just be my fault, lol).

Firstly, I can't really find any good resources on how the SD protocol works, I tried looking through the SDIO simplified specifications but that just feels like it has a lot of information missing, I understand that the way it appears to work is you send commands over the CMD pin of the SD card and then you can get a response or no response depending on the command, but beyond that, I can't find much on it. The sort of things I am looking for are how the commands are set out, like, what format are the commands in, what does all the abbreviations for the commands actually mean in binary (for example, I am seeing a lot of things like CMD0 Pin1=high, CMD8, IO=0, etc. but what does this actually look like if I were to try to send this down the CMD pin in binary, how would it be sent down as well), also an explanation of how to initialise the SD card and pull data from it would be nice too, their flow charts from their SDIO simplified specifications feels like there is some information I am just missing to understand it (BTW, I would prefer to use SD mode rather than SPI mode for the faster transfer speeds).

Secondly, I could find some resources on how the DS protocol worked but I am not understanding how the AP of the DS works, found nothing on the DSi, and also have no idea how the data transfer works, some information on how that works would be greatly appreciated. I understand it uses XOR encryption for most of the game file (I think) and than has some special encryption for the first few bytes of the game data which is double encrypted? But how does the encryption work and where are the encryption keys from?

Thirdly, I want to have IR sensors and receivers built into this flashcart for games that use them. How do games that have integrated IR sensors and receivers built into their cartridges go about using them? Like, do they have some special custom command that they send to the cartridge some how from the DS to send IR signals and a custom command that the IR receiver sends over the cartridge to the DS, or does it work some other way?

Finally, is there anything else I should know that I haven't asked about, something that all or most flashcarts have as standard and would be required, something about the DSIO protocol I should know (maybe something about SDHC/SDXC cards or something like that), anything else that could be an issue due to the DS hardware begin what it is (like how I have heard that the DS can be finicky with timings, how true is that, how precise do the timings need to be, and so on), etc?
I found this for sd card reading with an fpga. https://github.com/ZipCPU/sdspi

It fully supports sdio

If you want to build your own, there is this 27 page long specification: https://www.ercankoclar.com/wp-content/uploads/2017/11/SD-InputOutput-SDIO-Card-Specification.pdf
It's from 2001 and might be outdated but should still work for lower write speeds.
 

amomo

Member
Newcomer
Joined
Dec 20, 2024
Messages
10
Trophies
0
XP
69
Country
France
Firstly, I can't really find any good resources on how the SD protocol works, I tried looking through the SDIO simplified specifications but that just feels like it has a lot of information missing, I understand that the way it appears to work is you send commands over the CMD pin of the SD card and then you can get a response or no response depending on the command, but beyond that, I can't find much on it. The sort of things I am looking for are how the commands are set out, like, what format are the commands in, what does all the abbreviations for the commands actually mean in binary (for example, I am seeing a lot of things like CMD0 Pin1=high, CMD8, IO=0, etc. but what does this actually look like if I were to try to send this down the CMD pin in binary, how would it be sent down as well), also an explanation of how to initialise the SD card and pull data from it would be nice too, their flow charts from their SDIO simplified specifications feels like there is some information I am just missing to understand it (BTW, I would prefer to use SD mode rather than SPI mode for the faster transfer speeds).
See the SD Card Association specifications for the protocol and wiring. The "Physical Layer Simplified Specification" is part of what you're looking for. There are also plenty of resources online.

Secondly, I could find some resources on how the DS protocol worked but I am not understanding how the AP of the DS works, found nothing on the DSi, and also have no idea how the data transfer works, some information on how that works would be greatly appreciated. I understand it uses XOR encryption for most of the game file (I think) and than has some special encryption for the first few bytes of the game data which is double encrypted? But how does the encryption work and where are the encryption keys from?
For this, you need to look at what the DS, DSi and 3DS firmware do. You can also find a lot more information about this on GBAtek.

Thirdly, I want to have IR sensors and receivers built into this flashcart for games that use them. How do games that have integrated IR sensors and receivers built into their cartridges go about using them? Like, do they have some special custom command that they send to the cartridge some how from the DS to send IR signals and a custom command that the IR receiver sends over the cartridge to the DS, or does it work some other way?
Those cartridges use custom SPI devices. I believe GBAtek also documents this.

Finally, is there anything else I should know that I haven't asked about, something that all or most flashcarts have as standard and would be required, something about the DSIO protocol I should know (maybe something about SDHC/SDXC cards or something like that), anything else that could be an issue due to the DS hardware begin what it is (like how I have heard that the DS can be finicky with timings, how true is that, how precise do the timings need to be, and so on), etc?
SD cards have variable/inconsistent timings (variable amount of clocks for a response), and DS cartridges require specific timings (amount of clocks for a response determined by the cartridge header and the protocol), which is part of the challenge and why most flashcarts patch games.




I would recommend that you try implementing SD card reading on something simpler, like a Raspberry Pi Pico, from scratch using PIO. It's a much easier platform to work with and it should give you a lot of insights as to how SDIO and SD cards work. FPGA development is another beast, and if you don't have those basics, you'll be completely lost. I would recommend even starting with SPI and following ChaN's "How to Use MMC/SDC". This base work will let you expand later into the SDIO bus, and then into hardware design.
I would also recommend that you poke at cartridges using official hardware to understand their behaviour and how they work; that ground work will be necessary to debug your designs.
 

Re-Identifiable

Member
OP
Newcomer
Joined
Dec 22, 2024
Messages
18
Trophies
0
XP
94
Country
Australia
See the SD Card Association specifications for the protocol and wiring. The "Physical Layer Simplified Specification" is part of what you're looking for. There are also plenty of resources online.
Alright, I will try checking that out seeing if I could find anything else useful their, I did already try checking their though and their specifications felt over simplified and didn't have a lot of definitions for what I feel like needed explaining, like what the layout of the CMD pin commands are, I will read their other documents other then their SDIO spec to see if they have written stuff elsewhere about how their CMD commands are set out.
Those cartridges use custom SPI devices. I believe GBAtek also documents this.
Alright, I will have a look there.
SD cards have variable/inconsistent timings (variable amount of clocks for a response), and DS cartridges require specific timings (amount of clocks for a response determined by the cartridge header and the protocol), which is part of the challenge and why most flashcarts patch games.
Okay, so maybe I should have some sort of ram storage on the flashcart for storing the games with consistent timings, or something similar where I can store backed up data from the SD card to send to the DS, that should solve this issue.
I would recommend that you try implementing SD card reading on something simpler, like a Raspberry Pi Pico, from scratch using PIO. It's a much easier platform to work with and it should give you a lot of insights as to how SDIO and SD cards work. FPGA development is another beast, and if you don't have those basics, you'll be completely lost. I would recommend even starting with SPI and following ChaN's "How to Use MMC/SDC". This base work will let you expand later into the SDIO bus, and then into hardware design.
I would also recommend that you poke at cartridges using official hardware to understand their behaviour and how they work; that ground work will be necessary to debug your designs.
Will do looking through 'ChaN's "How to Use MMC/SDC"', and I will probably experiment with my ESP32 then to nail down how the SD card protocol works before porting anything I do over to my FPGA. And I do have an oscilloscope available to me and a pulled apart DS lite (took it apart to fix the buttons, now I also have to replace the touchscreen now too after breaking that awful ribbon cable, lol) so I will invetigate the way the DS cartidge communicates with the DS and so on, I guess that also means I should look into getting a burner DS game to pull apart and test with.

Thanks for all this info, this is all hugley helpful.
 

amomo

Member
Newcomer
Joined
Dec 20, 2024
Messages
10
Trophies
0
XP
69
Country
France
Okay, so maybe I should have some sort of ram storage on the flashcart for storing the games with consistent timings, or something similar where I can store backed up data from the SD card to send to the DS, that should solve this issue.
This is something some flashcarts like the DSTwo do, I believe.

And I do have an oscilloscope available to me and a pulled apart DS lite (took it apart to fix the buttons, now I also have to replace the touchscreen now too after breaking that awful ribbon cable, lol) so I will invetigate the way the DS cartidge communicates with the DS and so on, I guess that also means I should look into getting a burner DS game to pull apart and test with.
Alternatively, you can also solder wires to the cartridge slot. This might be less destructive and better for your needs (this way, you'd be able to analyze cartridge communications with an official cartridge as well.)
 

Re-Identifiable

Member
OP
Newcomer
Joined
Dec 22, 2024
Messages
18
Trophies
0
XP
94
Country
Australia
I did not know that's how the DSTWO worked, I thought it just used it's RAM to go with it's built in CPU for extra performance.
Maybe going for a less destructive method might be better, I just know that opening up a DS cartridge is a 1 way process due to them being held together by glue, and i don't trust my soldering capabilities to not dash against the plastic once or twice, although I think it is the better approach. An alternative could be to just hook up the oscilloscope directly to the DS's internal cartridge pins, less destructive that way and I don't have to be great with my soldering iron if I even need to use one at all.
Post automatically merged:

I did not know that's how the DSTWO worked, I thought it just used it's RAM to go with it's built in CPU for extra performance.
Maybe going for a less destructive method might be better, I just know that opening up a DS cartridge is a 1 way process due to them being held together by glue, and i don't trust my soldering capabilities to not dash against the plastic once or twice, although I think it is the better approach. An alternative could be to just hook up the oscilloscope directly to the DS's internal cartridge pins, less destructive that way and I don't have to be great with my soldering iron if I even need to use one at all.
Wait up, you did say solder pins to the cartridge slot, my bad.
 
Last edited by Re-Identifiable,

Luisao

Member
Newcomer
Joined
Sep 7, 2023
Messages
8
Trophies
0
Age
21
Location
São Paulo - Brazil
XP
52
Country
Brazil
I stumbled upon the N-Card flashcard recently, and its model of circumvention uses a NAND instead of reading from an SD card, which basically turns the cart into a retail equivalent, but the con is that the NAND is small so the user needs to reflash it to change the ROM. But with that setup, you potentially have 100% compatibility with the original features and it would be easier to set even IR/BT compatibility, given that you know their implementation.

Maybe we could use a large NAND (as the biggest ROMs are 512MB), expose the essentials to the DS as in the N-Card implementation, and whenever the user wants to swap the game, he would press a pushbutton and a microcontroller would make a bank switching kind of magic so that the ds would read the other game instead.

This thread contains a lot of information about the N-Card: https://gbatemp.net/threads/bootleg-overwrite-potential.644313/
 

Re-Identifiable

Member
OP
Newcomer
Joined
Dec 22, 2024
Messages
18
Trophies
0
XP
94
Country
Australia
I do like this idea a lot, but I'm thinking, just so we are not limited in storage, what if we used some sort of combo storage, where we have an SD card, and we just load the games off the SD card and into the NAND storage? This way, people could use any size SD card they want and have 100% game native game compatibility? Also, I am currently using an ESP32 for the designs just due to them being cheap and also having an SDIO controller built into the device. ESP32 S3 DevKit C1if you care.
Post automatically merged:

If we use NAND storage, there is also a chance that 3DS games might be able to work too, load the 3DS roms into the NAND storage and perfectly pretend to be a 3DS cartridge loading the 3DS game off the NAND instead off the ROM that 3DS game usually use. Use DS mode for the GUI though and IDK how to get homebrew to work, but for 'other' 3DS ROMS, 3DS ROM compatibility could be a feature.
Post automatically merged:

Maybe DS mode could be used for selecting the 3DS rom, then the user would restart the 3DS to play whatever ROM they slected. This feature could probably just be more generalised to all ROMS as a sort of retain previously loaded rom feature. Apparently some GBA games have the ability to transfer their data over to DS games so this could also add compatibility for that feature as well.
 
Last edited by Re-Identifiable,

Luisao

Member
Newcomer
Joined
Sep 7, 2023
Messages
8
Trophies
0
Age
21
Location
São Paulo - Brazil
XP
52
Country
Brazil
Well, I can surely see that working, but the I/O might be a nightmare since the NAND can take several pins from the microcontroller, leaving no room for the SD card.

I have one ESP32 S3. It can run at 220MHz and supports Bluetooth, so it could make a good interface for homebrew applications using Bluetooth or even games such as Pokemon Typing Adventure. However, in addition to the complexity, the space constraint can be a dealbreaker for that feature.

I am not sure about the 3DS side because 3DS games are, on average, much larger, and the protocol for access may differ, but Ace3ds+ already does that, so there's a way.
 

Re-Identifiable

Member
OP
Newcomer
Joined
Dec 22, 2024
Messages
18
Trophies
0
XP
94
Country
Australia
I gave the SD card idea a bit more thought, and realised that if there is just a big enough NAND, like 128GB (gigabytes) then their would be no need for an external SD card, just include a USB C port for flashing the NAND and firmware of the ESP32.
Also, size would be an issue but I think I could get it too fit flush using 2 PCB's (1 custom and 1 being the ESP32 S3 WROOM module) and a large cut out (in the custom PCB) to fit the ESP32 module. I don't think I am going to worry about getting it to fit first though, just get it booting DS ROMS on a DS lite, other basic features like fitting flush in the DS port can happen once the hardware and software both work.
 

NathaanTFM

Active Member
Newcomer
Joined
Jan 20, 2018
Messages
42
Trophies
0
Website
www.nathaan.com
XP
208
Country
France
NDS is just a OCTO-SPI slave. You only need to make sure you can get those timings right (immediately send data when pin goes low) and get the data encrypted in time. Then it's just a matter of connecting things together. Hope you have fun in that project!
 

Site & Scene News

Popular threads in this forum

General chit-chat
Help Users
    BigOnYa @ BigOnYa: Damn, sorry, I didn't know that was you