Hardware Project Open source flashcart project info

[Re-Identifiable]

Really, so the communication standard is just SPI then, interesting. That makes things a lot easier.

 

[NathaanTFM]

Really, so the communication standard is just SPI then, interesting. That makes things a lot easier.

Well, it's OCTO-SPI as it's just a CLK, CS and data pins. You have two encryption layers:

- "KEY1" (name from nocash), the 8-byte command is encrypted and you have about 2300 clocks cycles to decrypt it (it's blowfish). Pretty easy to implement with a MCU as 2300 clock cycles @ 6.7MHz is a LOT for a high clocked MCU, so fairly easy there. Might be annoying to implement on a FPGA??

- "KEY2" (name from nocash), every received and sent byte is encrypted. It's basically a stream, and every sent/received byte updates the current state. It uses two 39 bits registers. Annoying to use on a MCU, but I assume it shouldn't be too difficult on FPGA?? You can find an optimized version on my stm32cart github repo which calculates 4 bytes simultaneously in about as many instructions as a single byte (for a 32 bits MCU).

The Nintendo DS/DSi/3DS only communicates in multiples of 4 bytes, but nothing forces that in the protocol AFAIK. I can get in more details if ya want but that ruins the fun

 

[Re-Identifiable]

Alright, that's really helpful. Thank you so much.

 

[Luisao]

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.

Sorry for the late reply bud, I'm back to school now. Anyway, that storage size sounds great and allows for a lot of things to be implemented in the future like maybe a dual boot where the user configures via USB C if the cart is going to behave as a single ROM (for the compatibility thing) or boot into a regular kernel. Well the sky is the limit and I'm becoming a great enthusiast of this project of yours XD

 

[Re-Identifiable]

Thanks. Means a lot to me.

 

[Re-Identifiable]

Okay, so there is a slight problem with making an N-Card like flashcart, I can't actually appear to find any SPI NAND chips that would be big enough, and if I were to use some other type of NAND, that might actual negate the benefits of using the NAND chips. So, how I understand that the N-Card works is it has an octo SPI NAND chip (unlike the octo SPI ROM that Nintendo uses with their DS cartidges) and just maps the instructions it receives from the DS to the locations on the NAND (so, for example, if the DS wants to ask for the first instruction on the cartidge (Bit 1), it will map it to a different location where the start of the ROM you are trying to load is (so let's say the ROM is actuall stored at 10256th Bit due to this flashcart being able to store several games, then it will Map the Bit 1 Command to the Bit 10256)), now I beleive this only really works if you are using an SPI NAND, problem is, the largest SPI NAND I could find was only around 16 Gigabytes I think, might have been Gigabits, which is just too small for it to be practical too me. Using alternative NAND methods basically mean I might as well use an SD card, as the ESP32 has support for SD cards. I could try to make an adapter built into the cartidge to convert a larger NAND size to SPI, but that requires a lot more PCB design and Analogue electronics that I don't know how to do. However, I will still look into alternative NAND methods as SD cards, sure are cheap and standard, but I will still look into alternatives to SD cards as SD cards are a sort of dynamic storage which might cause issues, as well as them being fragile and having so many varying specifications.

 

[Apache Thunder]

N-Cards are using TSOP48 NAND packages. Not sure how the ASIC blob chip was setup to talk to them them. Could be SPI. Don't know much on how the the nand chips work in that regard.

As far as I know N-Cards never had anything larger then 16gigabit NAND chips. Though in theory one could use 4GB (or 32gigabit) chips. Nothing with how the ASIC is programmed on them suggests that wouldn't work beyond perhaps uDisk/Xmenu/DLDI not being setup to handle it. Anyways N-Cards don't use SPI to talk to the Nand. They implemented a set of custom card commands for handling it and SPI is only used for game saves. (unless you specifically were talking about how the FPGA/ASIC talks to the nand chip on the PCB)

N-Card's ASIC also has extra commands for setting up block tables and whatnot so that retail B7 card reads get mapped to specific 16KB sized blocks on the nand in a transparent manner that allows roms to run without patching.

Personally a 32gigabit nand chip would be more then enough for me but I can see how that would be limiting for those who want to run a much larger collection of games on it.


You could go the EZFlash Omega route and get a ram chip and use FPGA to copy rom to ram. MIght have some noticable load time still with some of the larger roms though I imagine.

Anyways if you do end up going the nand route you'll want to have bad block management and what not handled on the FPGA/ASIC side instead of console side like N-card does else you'll end up needing 32KB DLDI like the N-Card does and that would make homebrew compatiblity difficult. I'm not sure how practical that would be though. DS-Xtreme seems to get away with it but they severally bodged it on their FPGA programming because their DLDI is dog **t slow for some reason.

 

[Re-Identifiable]

Okay. I did not know that, just assumed that they were SPI NAND chips as that would be how I would do it, simpler that way (I think). Also, what are block tables? They sound important and I sort of went into this project without knowing anything, is there anything else I should be concerned with in regards to special commands and what not as well? I don't want to make a clone of the N-Card, but if there are commands that are essential for the flashcart to work, than I would like to know.

 

[Apache Thunder]

https://datasheet4u.com/datasheet-pdf/SamsungElectronics/K9LAG08U0M/pdf.php?id=604472

This is the 16gbit chip I've seen on all my N-Cards FYI. N-Cards setup a 16KB block table in specific sections of nand for setting up one ore more special rom sections. There was 2 sections usually. First section is "stage2" as I call it. The N-Card also has special data near 0x0 of nand that contain the main rom the console sees. (this includes the banner). This rom boots first, then reads a 16KB block table at 0x8000. This block table organizes a series of 16KB blocks of nand. It's simply a table of 4kbyte offsets that point to specific blocks on nand. The table can assign a max of 256Megabytes of data which seems to be why 512MB games aren't supported by xmenu. This block table is probably read off nand and into internal ram on the ASIC chip so that one is probably a hardware limitation of the ASIC package. (so no reason why you can't go with a larger table if you implement a similar style if you are using a FPGA that is better then what they used).

Anyways once first rom boots stage2, stage2 checks for a key combo held on boot for if user wants to boot into recovery mode that uses USB slot2 card to reflash uDisk section. If not it looks at second block table at 0x40000 that maps out the region of nand the uDisk rom is at. uDisk is what handles formatting the filesystem and allowing turning N-Card into USB flashdisk via the slot2 USB cart if it was present on boot. Otherwise uDisk then boots xmenu.dat which is the the kernel software they use to handle rom loading/saves/etc. xmenu is stored in the filesystem. Only stage2/udisk have special "sections" on nand outside of that.

Bootleg games using N-Cards forgo a stage2/udisk combo and instead have first block table point directly to the retail rom flashed to 0x40000 on nand. In that instance there is no file system (as it's not needed for a single game) and the banner section in the main rom region is replaced to be the banner of the game that was flashed at 0x40000. These cards were flashed using an ancient USB dongle the very first N-Cards used and this was not done via homebrew on the DS. So right now I have no way of correctly flashing the banner section on nand to customize the banner the console sees when the card is inserted. But it is technically possible to customize that. Just no code around to allow it yet.

Anyways this is specifically how N-Card does things and may not apply to how you'd want to do things. I don't know all the details on how nand management works myself so you'll have to research that with the specific nand package I linked to above if you want to use it. I do know there is some important things you will want to code for like bad block management, and block refreshing, etc. The block tables N-Card use are just N-Card specific things. I'm not sure if it was something the nand package required. Likely just specifically how N-Card did things. Such block tables did not exist on DS-Xtreme's nand. It appears FPGA handles all that internally so I don't know how DSX is doing things there. Maybe that's why their DLDI was slow. They had the FPGA handle all the block management and what not so could be the perticular FPGA they used was too slow to really do that. In that case they should have done what N-Card did. That would require a 32KB DLDI though. But maybe if you got a really decent chip then maybe that won't be an issue now. As I recall DSX used a ProASIC 3 as the FPGA/ASIC chip.

You could try and talk to Asie (asiekierka) about this. I think Asie knows abit on how the nand based flashcarts work or at the very least how the perticular nand chips they use work. I myself don't know much on that. Just the N-Card specific things that may not apply to how you'd want to set it up.

 

[Re-Identifiable]

Okay, that's a lot of info, but it all makes sense and explains a lot.

For the file system, I think I will just use a standard file system such as exFAT, or maybe some more open source alternative that is fairly universally compatible.

I do believe there are chips out there that can do a lot of NAND management such as bad block detection/management and so on so I might look into those to see if i want I think exists really does exist.
The only reason why I am trying to aim for 32+ gigabyte NAND is because I don't want people to ever encounter storage limits as problem, so going overkill will help ensure that this limit is never reached, plus, if I choose to do anything new with the flashcart which might require a fair bit more storage, I have that option available to me (for example, trying to get DSi or 3DS games to work), I also, unrelated, hate running out of storage but it's something I seem to do frequently on all of my devices.

Here is how I have figured I am going to get the boot process to happen on my flashcart project.
Part 1: By-pass cartidge detection.
I am going to just have an encrypted NDS rom file stored on some seperate NAND (much smaller, a bit like the smaller NAND chips that all flashcarts already have, although I might just integrate this into the larger NAND, however, it would mean accessing it for required information while it's running the game might be hard) which just stores things like the code to boot the flashcart and the loading screens animations. This is for all intents and purposes an entirley standard ROM that could be run as if it were on a normal DS cartidge, it just send custom commands to the flashcart to use it's NAND hardware and the ESP32 (likely going to be S3 wroom 1).
Part 2: Load the menu.
Once it has the nessicary files loaded from Stage 1, it will just boot into the menu and let the user use the menu however they choose, loading games, homebrew, downloading files over to it over the internet using the ESP32 wifi capabilities, or using any other functions I plan to implement or the community (if one ever does develop) chooses to implement.

I will avoid using RAM to store the DS games as that makes unessicary restrictions on the maximum size homebrew can be. I might also try to have some sort of dynamically sizeable DLDI depending on the game size so it can support homebrew larger than any pre-determined limit, I do not know how DLDI works that well though so that might not be possible.

I think I will try to integrate all of the function of the flashcart on the one PCB, including flashing new games to it via a USB port. This way it can in future be forward compatible with the DSi and 3DS.

EDIT:
It looks like a lot of modern NAND chips have integrated ICs that handle stuff like bad block managment and even sometimes block refreshing form what I can tell, so if I get the right NAND chips, then that should all be sorted out for me.

Post automatically merged: Feb 17, 2025

You could try and talk to Asie (asiekierka) about this. I think Asie knows abit on how the nand based flashcarts work or at the very least how the perticular nand chips they use work. I myself don't know much on that. Just the N-Card specific things that may not apply to how you'd want to set it up.

Alright.

 

[kijetesantakalu042]

For the file system, I think I will just use a standard file system such as exFAT, or maybe some more open source alternative that is fairly universally compatible.

ext4 is free and open source, plus it's the default on linux. It's also much easier to program. The one issue with it is that windows can't read it without a third party program.

 

[Re-Identifiable]

Hmm, I will look into it. I am on Windows though so I will have to look into getting some third party software to read it.

 

[Apache Thunder]

For file system I'd recommend sticking to fat/fat32. DS homebrew is not setup for exfat or ext4.

 

[Re-Identifiable]

Hmm, alright. Isn't that the purpose of the DLDI though, to give nds homebrew SD card compatibility or is DLDI just for the flashcart specifically? If not then I will stick to Fat32.

 

[Apache Thunder]

DLDI is a driver standard for DS homebrew. It's used to interface with the flashcart's storage. It generally isn't specific to the filesystem you decide to use. It merely provides access the the storage at a low level. Homebrew uses libfat generally though. This is used on top of the DLDI to know how to access files and such which is why you'd want to stick to using fat/fat32.

You'd program your cart's FPGA to setup custom card commands of some sort to know when to read/write sectors of the flaschart's storage, and the DLDI runs on the console which tells the homebrew in question how to know what commands to send to your flashcart to facilitate that.

I imagine you can keep things simple by having FPGA handle block management and what not and and set up a custom card command for write commands. You could reuse existing retail B7 command for reading nand. But generally you'd still want to setup a custom command for filesystem stuff if you decide to emulate proper B7 read redirection for retail roms.

This section of code is an example of how N-Card's older DLDI used to work:

https://github.com/DS-Homebrew/DLDI/blob/master/staging/mk5n/source/iointerface.c

(MK5 is a N-Card clone)

They setup a custom D2 card command for nand read page. That driver is old and outdated though and does not contain the code for writing to nand so I don't know how N-Card currently does that. (the DLDI used with uDisk 1.45 is closed source sadly)

That old driver also omits the block table setup nand management related stuff. The older version relied on xmenu keeping that in a specific area of ram which predicatbly means a lot of homebrew could overwrite that and break the driver. The "current" version of the driver handles it all in the driver now which is why it requires 32KB DLDI space instead of 16KB like almost all DLDI out there. If you have the FPGA/ASIC handle that side of things you won't have to worry about that I imagine.

 

[Re-Identifiable]

DLDI is a driver standard for DS homebrew. It's used to interface with the flashcart's storage. It generally isn't specific to the filesystem you decide to use. It merely provides access the the storage at a low level. Homebrew uses libfat generally though. This is used on top of the DLDI to know how to access files and such which is why you'd want to stick to using fat/fat32.

Alright, so using any other file system doesn't really appear to be possible unless libfat implemented support for exFat, but seeing as nothing supports exFat (and also that no new flashcarts are really being manufactured), libfat likely is never going to add support for exFat.

I imagine you can keep things simple by having FPGA handle block management and what not and and set up a custom card command for write commands. You could reuse existing retail B7 command for reading nand. But generally you'd still want to setup a custom command for filesystem stuff if you decide to emulate proper B7 read redirection for retail roms.

From what I have found, if I use eMMC NAND, then I could avoid having to do any NAND maintenance implementation, they include all the NAND management stuff (such as block detection) in the same package and run over the MMC interface, which makes things easy. It's also meant to have a low power mode if the data transfer is slow which is nice for battery life.

Also, what's B7 and D2?

 

[Apache Thunder]

Alright, so using any other file system doesn't really appear to be possible unless libfat implemented support for exFat, but seeing as nothing supports exFat (and also that no new flashcarts are really being manufactured), libfat likely is never going to add support for exFat.


From what I have found, if I use eMMC NAND, then I could avoid having to do any NAND maintenance implementation, they include all the NAND management stuff (such as block detection) in the same package and run over the MMC interface, which makes things easy. It's also meant to have a low power mode if the data transfer is slow which is nice for battery life.

Also, what's B7 and D2?

Oh that's part of the romctrl commands sent to the cartridge slot. It's documented on gbatek if you want to read on what that is. D2 is a custom command N-Card uses. B7 is one of the normal commands retail games use.

Isn't EMMC nand similar to SD/MicroSD? They both use MMC I think. The issue there is if you use that, you may have latency issues as you have to send extra commands and such to interface with the MMC device and this will break timings if you intend to run retail roms without patches. This is probably why N-Card and DS-Xtreme uses the specific type of nand it uses.

 

[Re-Identifiable]

Isn't EMMC nand similar to SD/MicroSD? They both use MMC I think. The issue there is if you use that, you may have latency issues as you have to send extra commands and such to interface with the MMC device and this will break timings if you intend to run retail roms without patches. This is probably why N-Card and DS-Xtreme uses the specific type of nand it uses.

It's similar-ish. From what I understand, SDIO (SD/Micro SD cards) supports more than just storage capabilities than just storage like MMC, such as bluetooth, wifi and so on built into the cards. Also, the latency for eMMC is far lower than the latency for SD cards, SD cards have a latency of around 500 nano seconds to 200 micro seconds (200 micro seconds is the latency of the raspberry pi), wheras, the eMMC storage I am looking at has around 5 nano seconds of latency.

Also, how tight does the timings of the DS need to be, I hear about it being finneky but how much time does it actually give you between sending the command and receiving data?

Post automatically merged: Feb 18, 2025

Oh that's part of the romctrl commands sent to the cartridge slot. It's documented on gbatek if you want to read on what that is. D2 is a custom command N-Card uses. B7 is one of the normal commands retail games use.

Ahh, alright, thanks. So what section on GBATek should I be looking? is it somewhere under DS cartidge or elsewhere?

Also, this is something I haven't been able to find much information on, but what is the encryption for Key2, like, I understand it uses XOR gates and shift registers at an odd bus size (I read what thet was somewhere but don't remember what it was) for the encryption to obfuscate the data, but what is the actual order in which the data is 'encrypted'.

Post automatically merged: Feb 18, 2025

Link to eMMC I plan to use:
https://www.digikey.com.au/en/products/detail/lexar-enterprise/FEMDRW064G-88A19/23567824

EDIT:
I might try to look for a cheaper eMMC, but for all intents and purposes, they all use the MMC interface so they should all be cross compatible.

Post automatically merged: Feb 19, 2025

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Bit of an update to this project, I originally planned to use NAND storage for the flashcart, however, despite me liking the idea a lot and thinking it has several benefits, way more than what Micro SD cards have to make them good, I have recently learnt that YSmenu is not actually open source. Why does this matter? Because that means that unless you understand how both the TTmenu and how YSmenu works and are willing to spend the time working with editing close source code or adding extra files that the closed source code can somehow read, YSmenu is basically going to be stuck in it's current state.

Feel free to correct me if I'm wrong in any way.

That annoys me a bit, because that means any chance of getting a newer, up to date flashcart OS that is easily maintained, update-able and editable, is to either use Bl2CK, which has it's own issues, or work on the open source ancient flashcart kernels (outdated wood r.p.g, outdated wood r4 and outdated Akmenu).

I plan moving forward with this project to make this flashcart use Micro SD cards, I will also make a NAND version as well so people do have the option of perfect game compatibility right away, but I do also want people to have access to a regularly maintained, easily portable, flashcart OS for people that are not willing to get PCB manufacturing service to make the PCB and have to make the shells themselves, or simply have already bought a flashcart and want to use what they have already bought with their own money.

 

[NathaanTFM]

I don't know much about flashcards OS, but the only thing I can tell you is that the ROM timings are in the ROM header - it contains the delay between the command and the data. Also apparently Chip ID contains a bit that changes some behaviors with data transfers (repeated commands?) but I haven't experimented with that yet. The thing is, you cannot run all ROMs with a NAND chip because some ROMs (usually smaller ROMs) have lower delays.

I'm pretty sure those flashcards firmwares contains patches to the games that replaces ROM transfers functions with their custom protocol which removes the need for these sometimes strict delays (and also to remove anti piracy). The DSpico team is working on a (afaik) open-source flashcard+firmware that's not ready to be released yet.

 

[Re-Identifiable]

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.