Hardware Project Open source flashcart project info

[Apache Thunder]

The thing is, you cannot run all ROMs with a NAND chip because some ROMs (usually smaller ROMs) have lower delays.

Oh yeah as I recall N-Cards are likely getting around this by altering the romctrl port flags in the header stored at 0x027FFE00 (romctrl port flag values stored at 0x02FFFE60 specifically) region of ram which is what the game uses to setup it's rom reads. I imagine this is why DS Download Play didn't work initially and xmenu later added limited support for fixing that once xmenu was created. (because I think this header data is being used for child SRLs sent to other DS's and if it's altered it breaks the RSA?) I say limited in that it probably doesn't work for newer games. I'm not sure what they did to fix it. Likely rom patches? Of coarse flashme being present on the client DS's connecting to the N-Card's DS host would also be the way people would get around this.

Anyways I noticed that altered header data when dumping ram with a test program when I was setting up my NTRO DLDI driver that used direct rom reads to read fat image from rom's nitrofs and I had to know the romctrl portflag values at 0x60 in the header which Xmenu alters before booting the game. chipID is also cached in a nearby region of ram there so I was able to recontstruct the required romctrl settings to read game data without doing a new card init. (new card init would still be required for reading secure area again, but I didn't need that for the DLDI driver. Fat image wouldn't be there for obvious reasons)

You can easily do the same here. But you'd of coarse need some way of ensuring DS Download Play stuff can still work. I'm not very familiar with why these old flashcarts break DS Download Play stuff. The altered header data in ram would be my guess on that.

 

[NathaanTFM]

because I think this header data is being used for child SRLs sent to other DS's and if it's altered it breaks the RSA?

yes, ROMs have an option to send a copy of their ROM which includes their header

Post automatically merged: Feb 20, 2025

Do you know the range of these ROM timings? I want to make sure that anything I build using an eMMC chips is within a reasonable range in terms of latency, if it’s too slow than I might have to look for another NAND type.

http://problemkaputt.de/gbatek-ds-cartridge-i-o-ports.htm

This is not fully correct, but the important information is that the actual gap between command and data transfer is gap1+gap2,
which is in cycles. Consider that every ROM has its clock rate set to 6.7 MHz, the minimum gap you can have is 0x18 which is about 3 µs. You don't need the last 4 bytes of command, so it can be 4 µs. (If my maths are not wrong and they might be, but that's the idea)

 

[Re-Identifiable]

http://problemkaputt.de/gbatek-ds-cartridge-i-o-ports.htm

This is not fully correct, but the important information is that the actual gap between command and data transfer is gap1+gap2,
which is in cycles. Consider that every ROM has its clock rate set to 6.7 MHz, the minimum gap you can have is 0x18 which is about 3 µs. You don't need the last 4 bytes of command, so it can be 4 µs. (If my maths are not wrong and they might be, but that's the idea)

So, how long does it take to receive the command, like is there some sort of initial, unavoidable delay, before the command has to be processed then have something ready for the DS? Because if so, it's looking like I'm going to have to try to down clock the DS IO speed as much as possible without triggering any AP stuff and keeping it as fast as possible (not that this is not going to have to be altered anyway, eMMC NAND (if I choose to use it) already appears to have a delay of around 4µs from all the information I could find, although I am likely going to use something else because of this).

 

[Hpela]

Won't ESP 32 dramatically increase power consumption?

 

[Re-Identifiable]

Won't ESP 32 dramatically increase power consumption?

Probably. I don't know if I actually plan on using one though, as I could not make it fit flush with the DS, not without several boards and some very thin plastics that wouldn't last very long. I only said that before I thought about actually trying to make it work, lol. For a proof of concept though something like the ESP32 could be fine, even if it's just for testing my ideas on something cheap and expendable.

I haven't really has a coherent plan for the final design, but I would like to do something similar to the Acekard RPG where it had both NAND and Micro SD support, and has an FPGA that can be updated using only components built into the flashcart (so something like an integrated USB-C port).
I know nothing about what I am actually doing for the most this stuff, I have some 'okay' C/C++ programming skills, and understand a (I don't know what is considered not much and what is considered a lot, fill in the blank here) of logic design, enough to make a custom CPU on a software logic simulator, if that means anything.

 

[Hpela]

I haven't really has a coherent plan for the final design, but I would like to do something similar to the Acekard RPG where it had both NAND and Micro SD support, and has an FPGA that can be updated using only components built into the flashcart (so something like an integrated USB-C port).

I like your project. But i think that FPGA programmer will fit into limited DS card space with all other stuff.

Spoiler: My idea how flashcart can work. I know nothing what to do too

FPGA will be core of the cart. It will be connected to DS game card bus, SD card, IR transceiver, and QSPI chip.
Command FSM will imitate original DS cart commands for rom reading, but also have custom commands, custom commands will allow code on the console to 1) read and write SD card. 2)special commands will be used to say special FPGA module where on SD card ROM and SAVE are stored.
On the power on FPGA will show console header from the QSPI and launch small code from there. Code will read root of SD card and launch menu from it. Menu will read SD card and show ROMs list. when user will choose game menu code will send special commands to tell fpga point where on sd chosen ROM and save are located. then somehow(idk how flashcarts do it start game execution)
during this game code will send standard DS commands to read ROM or save, and FPGA will translate that commands to pointed places in SD card.
If game will send IR commands they will be decoded ad data send to IR diode connected to FPGA.

PS. Sorry for my paint skills
PS2. English is not my native and IDK how to use google translate

 

[Re-Identifiable]

PS. Sorry for my paint skills
PS2. English is not my native and IDK how to use google translate

Your English skills are great (I only speak English by the way), and your paint skills are more then adequate, especially to get across what you are trying to say. Also not using Google Translate is probably making it easier for me to understand what you are saying, Google Translate has it's way of loosing what you meant to say, or translating uncommon/technically incorrect words to stuff that makes no sense when translated.

I like your project. But i think that FPGA programmer will fit into limited DS card space with all other stuff.

You are probably right, I do know some FPGA's on startup will load all of their logic from a memory chip, so programming them is as simple as re-writing the data on the memory chip. I don't know what form-factor these FPGAs come in, and how much they cost though. Maybe I could just include some pins that are semi-exposed, or some kind of connector, which an external FPGA flasher can be connected too.

when user will choose game menu code will send special commands to tell fpga point where on sd chosen ROM and save are located. then somehow(idk how flashcarts do it start game execution)

From what I understand, there is no actual common way of doing flashcart communication, and none of them really did just use the DS cartridges commands directly for running the game.
The Acekard flashcarts just provide the flashcarts kernel with a 'SD card interface' where you are given a way to communicate with the SD card directly for initalising the SD card, reading data and writing data to the SD card and everything else inbetween.
The original R4 just gave you some nice and simple commands to get some information about the SD card and read data from it, unlike what the Acekard did.
IDK how I plan on doing it for mine, but having some method of having just the flashcart do most the work, like what you said, sounds like the best idea (easiest to work/program with). Also once you have the ROM patched with everything you need for it to work, you can often just jump the program counter to the start of where the ROM would normally load from to start executing the ROM.
TLDR: Often the kernel is the responsible for controlling all of the flashcart, and sometimes are even required too for anything to work, depending on how the FPGA/ASIC was designed.

On the power on FPGA will show console header from the QSPI and launch small code from there. Code will read root of SD card and launch menu from it.

I feel like I should have known how they did this, but for some reason this just didn't come to my head until you said it, I knew they had some sort of boot code on there, and I also knew they have some 3DS/DSi flashcart blocker bypass code stored in the SPI chip, I just for some reason didn't understand how that all worked out to load the kernel from the SD card.

 

[Hpela]

You are probably right, I do know some FPGA's on startup will load all of their logic from a memory chip, so programming them is as simple as re-writing the data on the memory chip

I am afraid it may cause problems. As that kind of FPGA spend some time when power on loading their bitstream they don't work first moments. But Nintendo DS checks game on startup, and if check will start before FPGA is ready to work cart won't be detected by console.

Post automatically merged: Jun 24, 2025

I let my intrusive thoughts caused by this thread win. But I cannot route power supply for FPGA.

 

[Re-Identifiable]

I am afraid it may cause problems. As that kind of FPGA spend some time when power on loading their bitstream they don't work first moments. But Nintendo DS checks game on startup, and if check will start before FPGA is ready to work cart won't be detected by console.

From what I understood, it does start trying to decrypt the data on boot, but it gives you a set amount of time to get the data there and have it decrypted into what the DS is looking for. So, we don't actually need to have data begin to be sent right away, but instead can hold off on sending the data until we have the rest of the systems initalised that are absolutely required for the DS to be happy. And on later consoles such as the DSi and 3DS, this (probably) doesn't even matter as I believe the 'hot swap' ability of the cartridges gives you a lot more time to actually make the cartridge exist at all to the DSi or 3DS while you have everything initalised.

View attachment 512931
I let my intrusive thoughts caused by this thread win. But I cannot route power supply for FPGA.

EDIT: I just realised none of the below fixes the routing the FPGA issue, lol. I will leave it here just in case you find any of the information useful though.
If this help for wiring, one of the connections you have is not necessary, the pin to the left of the power pin is actually just ground, where all you need I think it a resistor between the power and ground pins to prevent a dead short. Also if you move the 4 programming pins to beside the IR module, and move the SPI chip further downwards, closer to the cartridge connector pins, and exchange the current FPGA programming pins to smaller footprint ones, you could fit the FPGA programming pins slots next to the IR sender/receiver, that way likely giving you enough room to rout all the power wiring.

 

[Hpela]

pin to the left of the power pin is actually just ground

IRQ is not used in DS?

 

[Re-Identifiable]

IRQ is not used in DS?

As far as I can tell, it is never used. It is just grounded in most, if not all, official DS cartridges, and most flashcarts do the same, or use it as a programming pin of some sorts, likely to flash the SPI chips from the factory, or something similar. I think it might require it to be grounded for the cartridge to be detected, I don't know for sure though.

Post automatically merged: Jun 25, 2025

Okay, so for DSi/3DS it is used for cartridge removal detection, hence why most flashcart probably have it grounded just like official cartridges do.

 

[Hpela]

As far as I can tell, it is never used. It is just grounded in most, if not all, official DS cartridges, and most flashcarts do the same, or use it as a programming pin of some sorts, likely to flash the SPI chips from the factory, or something similar. I think it might require it to be grounded for the cartridge to be detected, I don't know for sure though.

Post automatically merged: Jun 25, 2025

Okay, so for DSi/3DS it is used for cartridge removal detection, hence why most flashcart probably have it grounded just like official cartridges do.

Understood. I think I should swap to 48 pin FPGA. Abadon NAND for a while.

Post automatically merged: Jun 25, 2025

Need to move sd slot a bit lower and make some adjustments. But smaller fpga really does the trick. Maybe change flash for WSON one to free some space.

I think I will buy Tang nano or something similar when will have money and order NDS cart breakout board for first tests.

 

[Re-Identifiable]

Okay, I have managed to get a design almost done, it's just missing the Infrared features and the NAND chip. Apart from that, and that I haven't done the ground plane yet, it's basically done. It uses both a RP2040 and an IceBreaker Ice40UP5K, the RP2040 handels all the USB/Mass storage stuff to ensure no software has to be used to update the FPGA, and no external adapter has to be used to upload files to the Micro SD card, and the IceBreaker Ice40UP5K handles everything else, such as making this an actual flashcart.

Currently done features (no programming/FPGA logic done, just what I have designed support for on the PCB):
- Update-able FPGA (if I can't get this to start within the boot time, then this will only stick for the prototype will try and get it to work using the cold boot mode, then switching to the warm boot mode after the DS Security has successfully been bypassed).
- Re-flash-able SPI chip over USB without any software.
- Can add files to the Micro SD card using the integrated USB port (removed requirement for external Micro SD card adapters).
- 'Power saving design' (I made sure the RP2040 wasn't turned ever powered during DS operation, technically this does mean I caused it to save power).

Below: Pictures of the current iteration of the PCB.

Spoiler: Pictures of the Flashcart PCB currently

I think I failed to do the formatting properly...
EDIT: I got the formatting eventually.

 

[TheStonedModder]

Okay, I have managed to get a design almost done, it's just missing the Infrared features and the NAND chip. Apart from that, and that I haven't done the ground plane yet, it's basically done. It uses both a RP2040 and an IceBreaker Ice40UP5K, the RP2040 handels all the USB/Mass storage stuff to ensure no software has to be used to update the FPGA, and no external adapter has to be used to upload files to the Micro SD card, and the IceBreaker Ice40UP5K handles everything else, such as making this an actual flashcart.

Currently done features (no programming/FPGA logic done, just what I have designed support for on the PCB):
- Update-able FPGA (if I can't get this to start within the boot time, then this will only stick for the prototype will try and get it to work using the cold boot mode, then switching to the warm boot mode after the DS Security has successfully been bypassed).
- Re-flash-able SPI chip over USB without any software.
- Can add files to the Micro SD card using the integrated USB port (removed requirement for external Micro SD card adapters).
- 'Power saving design' (I made sure the RP2040 wasn't turned ever powered during DS operation, technically this does mean I caused it to save power).

Below: Pictures of the current iteration of the PCB.

Spoiler: Pictures of the Flashcart PCB currently

View attachment 520154
View attachment 520156
View attachment 520157

I think I failed to do the formatting properly...
EDIT: I got the formatting eventually.

If you need any help designing a case for this or anything lmk

Unless you plan on just gutting another flashcart lol

 

[Coderkei]

Okay, I have managed to get a design almost done, it's just missing the Infrared features and the NAND chip. Apart from that, and that I haven't done the ground plane yet, it's basically done. It uses both a RP2040 and an IceBreaker Ice40UP5K, the RP2040 handels all the USB/Mass storage stuff to ensure no software has to be used to update the FPGA, and no external adapter has to be used to upload files to the Micro SD card, and the IceBreaker Ice40UP5K handles everything else, such as making this an actual flashcart.

Currently done features (no programming/FPGA logic done, just what I have designed support for on the PCB):
- Update-able FPGA (if I can't get this to start within the boot time, then this will only stick for the prototype will try and get it to work using the cold boot mode, then switching to the warm boot mode after the DS Security has successfully been bypassed).
- Re-flash-able SPI chip over USB without any software.
- Can add files to the Micro SD card using the integrated USB port (removed requirement for external Micro SD card adapters).
- 'Power saving design' (I made sure the RP2040 wasn't turned ever powered during DS operation, technically this does mean I caused it to save power).

Below: Pictures of the current iteration of the PCB.

Spoiler: Pictures of the Flashcart PCB currently

View attachment 520154
View attachment 520156
View attachment 520157

I think I failed to do the formatting properly...
EDIT: I got the formatting eventually.

Maybe a silly question but whats the FPGA needed for in this design if it also uses an RP2040?

As far as I know the DSPico project (another RP Pico based flashcart) uses the RP2040 chip for everything including flashcart functions.

It would certainly make the design cheaper and possibly reduce the amount of components needed on the PCB, but I am guessing using am FPGA might use less power, and possibly easier to manage & program?

 

[Re-Identifiable]

If you need any help designing a case for this or anything lmk

Unless you plan on just gutting another flashcart lol

I would appreciate some help.
I checked and apparently the PCB is not too large to fit inside any kind of shell unlike what I thought (something about it just makes it look too big to fit in anything for some reason).

As funny as I think the official way to make this cart would be to buy some more functional flashcart (for some time), them cut a hole in the shell for the Infrared LED's, I don't think that is very practical.

 

[TheStonedModder]

I would appreciate some help.
I checked and apparently the PCB is not too large to fit inside any kind of shell unlike what I thought (something about it just makes it look too big to fit in anything for some reason).

As funny as I think the official way to make this cart would be to buy some more functional flashcart (for some time), them cut a hole in the shell for the Infrared LED's, I don't think that is very practical.

Do you have discord or anything ? Dm me

Once I have the step file made you could get it made out of proper ABS or something

I did similar for the MiG switch and got one made in clear resin from pcbway

 

[Re-Identifiable]

Maybe a silly question but whats the FPGA needed for in this design if it also uses an RP2040?

As far as I know the DSPico project (another RP Pico based flashcart) uses the RP2040 chip for everything including flashcart functions.

It would certainly make the design cheaper and possibly reduce the amount of components needed on the PCB, but I am guessing using am FPGA might use less power, and possibly easier to manage & program?

Power consumption is a major factor, from what I could fine, the RP Pico consumes around 2mA dormant, with apparently something around 25 to 100mA during active use. From what I could find about the Ice40UP series, they consume around 1 to 10mA during active use.

The RP Pico's only purpose is to re-flash the SPI NAND chip, and remove the requirement for an external adapter to add/remove files from/to the Micro SD card.

One of the requirements I had for this project was to require no additional software once setup, and if possible, no extra adapters either. Some kind of the micro-controller happens to be the easiest way to do this without ever encountering a possible brick that the flashcart cannot be recovered from using the built-in USB port.

The micro-controller doesn't have to be a RP Pico, it can be any micro-controller that can fit in the available space with fast enough GPIO. Power consumption doesn't matter for the micro-controller, as it's only ever powered when connected to USB.

FPGA is also easier for me to understand how they work, but not easier to program really (well, not usually, this one happens to be easier then most). Micro-controllers are really easy to manage, program and so on in comparison as far as I know, that is another reason why the micro-controller exists.

Post automatically merged: Aug 2, 2025

Do you have discord or anything ? Dm me

Once I have the step file made you could get it made out of proper ABS or something

I did similar for the MiG switch and got one made in clear resin from pcbway

I do have a discord, yes, although I don't have a fully completed step file I could send right now, if you want the current iteration I could send that though.

 

[Coderkei]

Power consumption is a major factor, from what I could fine, the RP Pico consumes around 2mA dormant, with apparently something around 25 to 100mA during active use. From what I could find about the Ice40UP series, they consume around 1 to 10mA during active use.

The RP Pico's only purpose is to re-flash the SPI NAND chip, and remove the requirement for an external adapter to add/remove files from/to the Micro SD card.

One of the requirements I had for this project was to require no additional software once setup, and if possible, no extra adapters either. Some kind of the micro-controller happens to be the easiest way to do this without ever encountering a possible brick that the flashcart cannot be recovered from using the built-in USB port.

The micro-controller doesn't have to be a RP Pico, it can be any micro-controller that can fit in the available space with fast enough GPIO. Power consumption doesn't matter for the micro-controller, as it's only ever powered when connected to USB.

FPGA is also easier for me to understand how they work, but not easier to program really (well, not usually, this one happens to be easier then most). Micro-controllers are really easy to manage, program and so on in comparison as far as I know, that is another reason why the micro-controller exists.

Post automatically merged: Aug 2, 2025

I do have a discord, yes, although I don't have a fully completed step file I could send right now, if you want the current iteration I could send that though.

I suspected it would be the power draw that was a big factor, wouldn't be ideal for a flashcart to have the same kind of power draw as a Supercard DSTWO.

 

[Re-Identifiable]

I suspected it would be the power draw that was a big factor, wouldn't be ideal for a flashcart to have the same kind of power draw as a Supercard DSTWO.

Yeah.
I didn't think the DSTWO and the LNH DS PICO would be likely to have a similar power draw, that doesn't seem so good...