Gathering DS flashcard knowledge - DIY "opencard" idea

[SylverReZ]

You can look into the type of flash chips N-Cards use. They are nand based and it would be awesome to see a modern retake on N-Cards. They are pretty neat. As far as I can tell xmenu (the loader for that card) didn't match games much at all. I think the asic chip handled the nand mapping itself and just mapped the rom reads and such to the correct locations on nand itself. That's a simplified explanation anyways.

The number of N-Card clones I've opened up, either had Hynix or Samsung NAND chips. The same kind you find in those cheap S1 MP3 players.

The ASIC mostly handles cart commands and to circumvent the DS's security.

 

[NathaanTFM]

You can look into the type of flash chips N-Cards use. They are nand based and it would be awesome to see a modern retake on N-Cards. They are pretty neat. As far as I can tell xmenu (the loader for that card) didn't match games much at all. I think the asic chip handled the nand mapping itself and just mapped the rom reads and such to the correct locations on nand itself. That's a simplified explanation anyways.

My N-cards appear to be fast enough to run Sonic Rush Adventure's intro at full speed so I think it should be fast enough for your purposes.

It still probably has to circumvent the DS security to reduce the read rate - I don't know a NAND chip able to load a 200h bytes region (at least, the first byte) in 5 us. But if you manage to increase the gap count before the game loads, then a NAND chip would definitely be fast enough without patching the game. Saving would still be an issue though

 

[Apache Thunder]

Yeah I'm not sure how that side of it works under the hood. I do know that it doesn't present it's main rom 1:1 to what is present on nand (the arm7 binary is no where to be found. Maybe in the odd compressed/encrypted blob of data it stores after the arm9 binary) and the asic chip can do the block mapping sorta but doesn't set that up on it's own so a rom has to load before hand to set up the nand's block tables and map the next rom to be booted. So there are some limitations the original N-Card had.

As for saves N-Card uses a battery backed SRAM chip for that and would copy the save back to nand after a reboot.

I suppose you could do something similar to that but then you'd need to either setup a loader that boots before the game or account for it in any games you plan to use for it.

EDIT: But if it's gonna be a single game cart you don't really need to worry about copying the save out of the chip. The very early N-Cards didn't have a menu and you'd flash a single game to it for it's main rom to boot. In that case the sram chip contents didn't need to be saved to nand because it always ran the same game.

 

[ghjfdtg]

I assume the latency from your microcontroller is the cause of the tight timings. Any decent NAND flash chip with a minimum of a 8 bits wide bus should be fast enough assuming the block mapping table is cached and the read request goes immediately to the NAND.

 

[NathaanTFM]

I assume the latency from your microcontroller is the cause of the tight timings. Any decent NAND flash chip with a minimum of a 8 bits wide bus should be fast enough assuming the block mapping table is cached and the read request goes immediately to the NAND.

I'm working on a budget with chips I can afford, and there's also limited space on a physical cartridge, so the best I can use are SPI NAND FLASH chips, which have slower read speeds. I have looked at some more SPI NAND flash chips, and it turns out the "slower" transfer rate (240µs before writing the first byte) is more than enough.

I'm planning on getting a RP2040 dev board soon - I was lucky with how cheap I got those STM32 MCUs.

 

[nullmalachite]

Hey, I found this while doing research into whether it would be possible to make NDS repro carts at home (note my wording, "possible" not "practical", i just wanna do it to see if I could lol) and after almost losing hope that it is even a possibility I find this thread! I'll have to do research of my own but this helps a LOT in getting me off the ground. Thank you so much!

Post automatically merged: Apr 13, 2024

Something im not understanding is exactly what instructions are necessarry on the microcontroller to get the DS to see the game and boot it. Sorry if theres something obvious im missing but I just wanna know how hard it would be to replicate this.

 

[NathaanTFM]

Hey, I found this while doing research into whether it would be possible to make NDS repro carts at home (note my wording, "possible" not "practical", i just wanna do it to see if I could lol) and after almost losing hope that it is even a possibility I find this thread! I'll have to do research of my own but this helps a LOT in getting me off the ground. Thank you so much!

Post automatically merged: Apr 13, 2024

Something im not understanding is exactly what instructions are necessarry on the microcontroller to get the DS to see the game and boot it. Sorry if theres something obvious im missing but I just wanna know how hard it would be to replicate this.

If you want to write your own program for your microcontroller, I think the best I can do is to explain how mine currently works? I'm not an expert in this field so there are most likely some parts that are wrong.

The DS cartridge protocol is documented on GBATEK. It works like SPI but with 8 bits of data: you have a Chip Select (CS1) pin, a Clock (CLK, driven by the DS), and input/output. CLK and CS1 are initially high ; when the DS wants to receive or send data to the cartridge (which is a proprietary ROM in official cartridges, and in mine it's a STM32 microcontroller), it firsts drives CS1 low. Then, when CLK becomes low, the console/cartridge drives the pins I/O7 to I/O0 depending on the byte it wants to send. I/O7 is bit 7 (MSB), I/O0 is bit 0 (LSB). High means 1, low means 0. Quick and dirty drawing for the timings. The DS doesn't care when you toggle the pins as long as it gets the value when CLK goes low.

So when a transfer begins, CS1 goes low, and the console transmits 8 bytes (CLK goes low 8 times) ; that's the command. The commands are documented on the page I linked above. After those 8 bytes, there might or might not be a gap, then the transfer reverses ; it's now the cartridge that drives the IO pins. The console still drives the clock, and every time the clock goes down, the console reads a new byte. Retail cartridges drives the I/O pins when the clock goes low, but due to timing issues with my microcontroller, I drive them when the clock goes high. The transfer ends when the console drives CS1 high.

The transfer's clock is initially at 4.2MHz, then goes up to 6.7MHz for (all?) retail games. This depends on the cartridge header. There's also encryption (KEY1/KEY2, also documented on GBATEK) and don't forget that there's a whitelist on non-homebrew DSi/3DS units.

Don't underestimate the clock rate. I'm using a STM32G431CBU6 which is clocked at 150 MHz, has many DMA channels I'm abusing, and DMA request generators for external interrupts/events. With the transfer rate, I can run *at most* 150/6.7 = 23 cpu instructions between two CLK falling-edges (not counting multi-cycles instructions and the time it takes to read the instruction from the internal flash). I am also using a NOR flash chip which are fast enough for retail games but somewhat expensive.

Sorry if that's hard to understand, this is my first time dealing with these and my vocabulary isn't really good (and english isn't my native language). I don't have much free time rn, so I'll try putting my current code for the STM32 cartridge on GitHub soon without bothering to clean it up.

EDIT: https://github.com/NathaanTFM/stm32cart. Haven't tested the few edits I've made.

 

[XLuma]

I am part of a team by the name of Lost Nintendo History. For the past 3 years now, we've been working on an open-source flashcart targeting every system in the *DS line of products.

The flashcart is based on the rp2040, and we expect to release the project to the public soon(tm, very relative to how much progress we make over time).

The cartridge can boot titles, as well as homebrew. It will not be sold anywhere, instead users will be able to order a shell and a pcb from popular manufacturers like JLPCB or PCBWAY as we do not intend (or want) to make any money from this project.

Now, this project is not meant to be used as a "reproduction" cartridge, rather being a modern replacement for all the flashcarts on the market currently. the STM32 projet could be good leverage towards programmable cartridges, maybe.

We thought we would let people know here so no effort is wasted on another rp2040 cartridge (especially since everything will be made open source, and open to contributions)

Picture of the cartridge on our twitter account:

 

[WolfyBuilder]

I am part of a team by the name of Lost Nintendo History. For the past 3 years now, we've been working on an open-source flashcart targeting every system in the *DS line of products.

The flashcart is based on the rp2040, and we expect to release the project to the public soon(tm, very relative to how much progress we make over time).

The cartridge can boot titles, as well as homebrew. It will not be sold anywhere, instead users will be able to order a shell and a pcb from popular manufacturers like JLPCB or PCBWAY as we do not intend (or want) to make any money from this project.

Now, this project is not meant to be used as a "reproduction" cartridge, rather being a modern replacement for all the flashcarts on the market currently. the STM32 projet could be good leverage towards programmable cartridges, maybe.

We thought we would let people know here so no effort is wasted on another rp2040 cartridge (especially since everything will be made open source, and open to contributions)

Picture of the cartridge on our twitter account:

That's awesome, I had no idea your team was working on a new flashcart!

I'd love for it to have NOR flash memory, similar to EZ-FLASH's OMEGA. I think that would solve the lack of DSi-enhanced support, while also finally allowing Pokemon Dream Radar and Poke Transporter to work

 

[PotatoStatic]

I am part of a team by the name of Lost Nintendo History. For the past 3 years now, we've been working on an open-source flashcart targeting every system in the *DS line of products.

The flashcart is based on the rp2040, and we expect to release the project to the public soon(tm, very relative to how much progress we make over time).

The cartridge can boot titles, as well as homebrew. It will not be sold anywhere, instead users will be able to order a shell and a pcb from popular manufacturers like JLPCB or PCBWAY as we do not intend (or want) to make any money from this project.

Now, this project is not meant to be used as a "reproduction" cartridge, rather being a modern replacement for all the flashcarts on the market currently. the STM32 projet could be good leverage towards programmable cartridges, maybe.

We thought we would let people know here so no effort is wasted on another rp2040 cartridge (especially since everything will be made open source, and open to contributions)

Picture of the cartridge on our twitter account:

Ooooooo, neat. I'll probably order one from PCBWay just to have one. I kinda wonder if any Chinese cloners will start making these carts too. I suppose it depends on how well it ends up working. The RP2040 is such a cheap and versatile little chip.

 

[XLuma]

That's awesome, I had no idea your team was working on a new flashcart!

I'd love for it to have NOR flash memory, similar to EZ-FLASH's OMEGA. I think that would solve the lack of DSi-enhanced support, while also finally allowing Pokemon Dream Radar and Poke Transporter to work

Our project will support dsi-enhanced features as well as dsi exclusive titles.

Making a programmable cartridge is outside the scope of the project, though nothing will prevent you or anybody from making your own flashcart with the features you want

Ooooooo, neat. I'll probably order one from PCBWay just to have one. I kinda wonder if any Chinese cloners will start making these carts too. I suppose it depends on how well it ends up working. The RP2040 is such a cheap and versatile little chip.

The design files for the hardware and all the code for the firmware and other components will be made open source. Obviously there will be clones reusing everything, however you can avoid buying from these resellers anyway

 

[PotatoStatic]

Our project will support dsi-enhanced features as well as dsi exclusive titles.

Making a programmable cartridge is outside the scope of the project, though nothing will prevent you or anybody from making your own flashcart with the features you want


The design files for the hardware and all the code for the firmware and other components will be made open source. Obviously there will be clones reusing everything, however you can avoid buying from these resellers anyway

Ah, sweet. Nobody's made a DSi mode capable cart in such a long time.
As for the second part, assuming they don't make any changes to the cart and just sell it as is, I don't really have an issue with clones. It makes it more accessible to the less technically inclined.

 

[SylverReZ]

I am part of a team by the name of Lost Nintendo History. For the past 3 years now, we've been working on an open-source flashcart targeting every system in the *DS line of products.

The flashcart is based on the rp2040, and we expect to release the project to the public soon(tm, very relative to how much progress we make over time).

The cartridge can boot titles, as well as homebrew. It will not be sold anywhere, instead users will be able to order a shell and a pcb from popular manufacturers like JLPCB or PCBWAY as we do not intend (or want) to make any money from this project.

Now, this project is not meant to be used as a "reproduction" cartridge, rather being a modern replacement for all the flashcarts on the market currently. the STM32 projet could be good leverage towards programmable cartridges, maybe.

We thought we would let people know here so no effort is wasted on another rp2040 cartridge (especially since everything will be made open source, and open to contributions)

Picture of the cartridge on our twitter account:

Do you know when or where it will be uploaded once its been finished?

 

[XLuma]

Ah, sweet. Nobody's made a DSi mode capable cart in such a long time.
As for the second part, assuming they don't make any changes to the cart and just sell it as is, I don't really have an issue with clones. It makes it more accessible to the less technically inclined.

We intend to make it as accessible to the people who arent that technical so its not a burden for them, as well as tutorials obviously. The only "DIY" part will be receiving the cartridge, setupping it, and clipping the case together (which tbf, most of that you have to do yourself with any flashcart)

Do you know when or where it will be uploaded once its been finished?

Github. An announcement will be made on our twitter, and most likely the DSi hacking server

 

[PotatoStatic]

We intend to make it as accessible to the people who arent that technical so its not a burden for them, as well as tutorials obviously. The only "DIY" part will be receiving the cartridge, setupping it, and clipping the case together (which tbf, most of that you have to do yourself with any flashcart)

Lol. I'm just saying, love the project, but I've seen so many people struggle to drag the firmware for their card onto an SD. Having to order the card off of PCBWay (and the shell then snapping them together) will filter so many people right out of the gate. Not saying you shouldn't do it this way. It's a good idea. But you need to understand that even this is going to be too hard for a lot of people.

 

[DSoryu]

Lol. I'm just saying, love the project, but I've seen so many people struggle to drag the firmware for their card onto an SD. Having to order the card off of PCBWay (and the shell then snapping them together) will filter so many people right out of the gate. Not saying you shouldn't do it this way. It's a good idea. But you need to understand that even this is going to be too hard for a lot of people.

Hi, I'm also part of the team.

It will be as easy as ordering any R4 card clone from Aliexpress, we even expect third party sellers to offer ready-to-use DSpico cards in online stores (not ideal but we know it's going to happen, the best option will always be to build your own cards). The important part is that users can customize their card build as much as they want, ranging from PCB colors, to different brand components or peripherals.

TL;DR: Ordering a unit is as simple as buying anything on any online store.

 

[PotatoStatic]

Hi, I'm also part of the team.

It will be as easy as ordering any R4 card clone from Aliexpress, we even expect third party sellers to offer ready-to-use DSpico cards in online stores (not ideal but we know it's going to happen, the best option will always be to build your own cards). The important part is that users can customize their card build as much as they want, ranging from PCB colors, to different brand components or peripherals.

TL;DR: Ordering a unit is as simple as buying anything on any online store.

Let's just agree to disagree. Because I'm not going to argue about this. And the thing you were saying about third party sellers offering ready-to-use cards was entirely my point in the first place. So congrats we agree. PCBWay (etc) and ordering multiple separate parts is still going to be way above some people's head.

 

[Flame]

Every time I open this thread. It gets better. can't wait to open it again.