Gathering DS flashcard knowledge - DIY "opencard" idea

[Sono]

I received my nds cartrigde slot which means I can also model a cart-reader board that I can hook up to a RPi / Arduino / FPGA / whatever. I'll do that too and see if I can make a KiCad Part for the slot too so.

Than I'd have two pcb's, one that represents a cart and one that represents a slot that I can both communicate through.

Watch out: try to use wires as short as possible, I'm already having signal integrity problems at ~6.3MHz with just a 10cm jumper wire.

 

[xbmbmx]

Watch out: try to use wires as short as possible, I'm already having signal integrity problems at ~6.3MHz with just a 10cm jumper wire.

I have this in the back of my head indeed. Signal integrity will most likely be a problem but sadly that's something I can't really tackle without designing a board with the FPGA on-pcb, but I don't have the knowledge or the design for such a setup yet...

So let's hope this testing setup right now functions just well enough to get me to that design phase.

 

[ghjfdtg]

Also a little tip. If you order the extender PCBs get them with ENIG finish. I personally only had issues when the finish is plain tin (HASL). With gold these will last longer and not ruin your contacts. It's more expensive, i know but it will save you from hassles later.

 

[NathaanTFM]

I have been working on a micro-controller powered cartridge and I can finally share some progress

The chip contains a STM32G431CBU6 controller (170 MHz, $1.8/unit on JLCPCB) and a W25Q128JVSIQ SPI rom (which is currently unused).

I've been optimizing my code on the last 3 days and I managed to fully implement the transfer protocol and encryption at 6.7 MHz CLK speed.

The issue is that I'm not using SPI yet and it should really slow things down (mostly because I wired it software instead of hardware), so I must put the ROM in the flash memory of the controller which only has 128 KB. I can put partial ROMs which allows the DS show the banner. I can fit the acekard loader, so here's a demo.

I'm gonna try to make it work with SPI in hope to remove the need for a "loader" ROM, and then eventually open-source it.

 

[NathaanTFM]

Quick update on the cartridge: I have ordered a new prototype that is correctly wired to the SPI chip, and it seems to work (at least with DSi and 3DS - don't have a regular DS)

I haven't implemented the SPI protocol yet (between the console and the cartridge), which prevents commercial games cannot find their EEPROMs and seems to prevent them from booting. So I tried with a kiosk demo ROM and it seems to work!

I haven't implemented any kind of NDS whitelist bypass, so I'm testing on homebrew consoles for now. Again, I'm planning on open-sourcing it when it's in a correct state. I still need to implement the EEPROM chip (for saving) and reduce power usage.

I have started working on this because I wanted a way to distribute a custom homebrew game without having to buy individual flashcarts or cracking every console (this is why I'm using a FLASH NOR memory instead of a MicroSD card).

For other technical details, the ROM headers are barely modified so it transfers at the same rate as a commercial game (6.7 MHz, same gaps). The only modified value is the 4 character code - because I was too lazy to change the command decryption values. The uC is clocked at 150MHz and the transfers are handled by DMA (with GPIO).

EDIT: Seems like the issue is not related to the EEPROM, but to ROMs with filesystems (for some reason, the console seems to fail reading the cartridge after booting?)

 

[PoroCYon]

That's pretty cool, it could probably be used to make the DSi boot ROM (attempt to) boot into gamecart boot mode. You probably won't get boot0/stage1 code execution with it (you need a modchip for that), but there might be other interesting things here. (Also, quick note: you have about 100 ms (yes, milli, not micro) between the 3.3V power rail coming up and the DSi's ARM cores powering up and starting to do things, so that should be enough I think?)

Though, I do wonder: is there a specific reason for the STM32G4? I'd expect the STM32U5 to give similar performance figures but with much lower energy usage. (Many flashcarts using the ProASIC3/A3P250 FPGA tend to decrease the console's battery life quite a bit, which can be problematic, and that's on top of the obsoleteness/expensiveness/hard-to-obtain-ness of these parts that make them an all-around bad choice these days compared to 15y ago.)

FWIW I've made a quick comparison of a number of chips (all prices are from Mouser, and slightly rounded because the prices of the same chip in different packages can vary a bit):

Chip name	Average power usage estimate (mA)	Estimation method	Unit price (US$, qty 1) (price of chip, not of devboard)	Unit price (US$, bulk)
DSi PCB (CPU-TWL+BPTWL+PMIC)	40	measured this myself; screens, backlight and audio speakers disabled	N/A	N/A
A3P250 (ProASIC3)	40	datasheet: 12 static + 5 pins @ 6.7 MHz + 23 dynamic @ 48 MHz	22	22
A3PN060 (ProASIC3 nano)	35 (10 static + 5 pins + 20 dynamic)	datasheet: 10 static + 5 pins @ 6.7 MHz + 20 dynamic @ 48 MHz	13	10
GW1N-LV1	???	not documented!	7..10	5..7
STM32G4	32	datasheet: core @ 150 MHz + all AHB on	6	4
STM32U5	22	datasheet: core @ 150 MHz + all AHB on	7	4
RP2040 (Raspberry Pico)	45	datasheet: "Popcorn demo", core+IO	1	0.7
ICE40UP5K (Lattice FPGA)	5	source	10	7.5
ICE5LP1K (Lattice FPGA)	(seems to be similar to the UP5K)	(see above)	5	4

In conclusion, personally I'd go with either the STM32U5 or iCE40. (The iCE5LP1K is slightly slower and has fewer resources than the UP5K, but it's actually the same die as the iCE5LP4K, but the official Lattice software doesn't let you use the full chip. However, using the FOSS Yosys+nextpnr tooling, you can use all the resources on the chip of the 5LP1K as if it's a 5LP4K, and you can save some money this way.)

 

[SylverReZ]

I have been working on a micro-controller powered cartridge and I can finally share some progress

View attachment 397053

The chip contains a STM32G431CBU6 controller (170 MHz, $1.8/unit on JLCPCB) and a W25Q128JVSIQ SPI rom (which is currently unused).

I've been optimizing my code on the last 3 days and I managed to fully implement the transfer protocol and encryption at 6.7 MHz CLK speed.

The issue is that I'm not using SPI yet and it should really slow things down (mostly because I wired it software instead of hardware), so I must put the ROM in the flash memory of the controller which only has 128 KB. I can put partial ROMs which allows the DS show the banner. I can fit the acekard loader, so here's a demo.

View attachment 397054

I'm gonna try to make it work with SPI in hope to remove the need for a "loader" ROM, and then eventually open-source it.

Amazing work, man. I can't wait to see the rest of your progress.

 

[Duo8]

If cost is a concern it seems you can get an fpga breakout board for as little as $5.
Most flashcards seem to use the A3PN060 variant of the proasic3, which features 512 "macrocells", by their terminology.

 

[PoroCYon]

If cost is a concern it seems you can get an fpga breakout board for as littlethen as $5.
Most flashcards seem to use the A3PN060 variant of the proasic3, which features 512 "macrocells", by their terminology.

Not all FPGAs are created equal. While they all have "programmable logic functionality", they differ in size/features, power usage, chip packaging, and so on.

The GW1N FPGA from the Sipeed Tang Nano has a datasheet that doesn't even specify its energy usage -- you can't even know how much it will affect battery life. Secondly, devboard prices don't always correspond closely to chip prices for manufacturing: sometimes, chip makers have devboards that are even cheaper than the chips themselves. On Mouser, the GW1N-LV1 costs $7 to $10 (or $5-$7 in bulk). (This happens because they want as much people to use those devboards as possible, because if people will use them in designs that are manufactured at a larger scale, they'll get a lot of money from this.) Thirdly, the GW1N chips actually have a pretty bad bug in their power supply circuitry, leading to instabilities and crashes.

Finally, according to the ProASIC3 Nano datasheet, the A3PN060 uses a similar power figure as the table entry I used for the A3P250 (10mA static dissipation + ~5 mA output pins + 10mA dynamic for internal FPGA fabric at 48 MHz). So in the end, the iCE5LP1K is probably still the best option here.

 

[Duo8]

Not all FPGAs are created equal. While they all have "programmable logic functionality", they differ in size/features, power usage, chip packaging, and so on.

The GW1N FPGA from the Sipeed Tang Nano has a datasheet that doesn't even specify its energy usage -- you can't even know how much it will affect battery life. Secondly, devboard prices don't always correspond closely to chip prices for manufacturing: sometimes, chip makers have devboards that are even cheaper than the chips themselves. On Mouser, the GW1N-LV1 costs $7 to $10 (or $5-$7 in bulk). (This happens because they want as much people to use those devboards as possible, because if people will use them in designs that are manufactured at a larger scale, they'll get a lot of money from this.) Thirdly, the GW1N chips actually have a pretty bad bug in their power supply circuitry, leading to instabilities and crashes. See juj/gowin_flipflop_drainer on Github (again, still can't post links yet, sorry).

Finally, according to the ProASIC3 Nano datasheet, the A3PN060 uses a similar power figure as the table entry I used for the A3P250 (10mA static dissipation + ~5 mA output pins + 10mA dynamic for internal FPGA fabric at 48 MHz). So in the end, the iCE5LP1K is probably still the best option here.

I mean surely a 55nm chip from a few years ago can't be as bad as a 150nm chip from almost 2 decades ago. The power bug might be a concern. if the application triggers it.
The Mouser price is unreasonably high, the actual price is ~$3 in singles but they're kinda hard to get outside of china it seems.

 

[PoroCYon]

The Mouser price is unreasonably high, the actual price is ~$3 in singles but they're kinda hard to get outside of china it seems.

Yeah. Plus all prices on Mouser are unreasonable (they add quite a bit of markup on every chip for the sweet $$$), but they have a lot of stuff, so if it's all equally unreasonable, it still works as a comparison because it's all in the same place.

 

[Duo8]

Yeah. Plus all prices on Mouser are unreasonable (they add quite a bit of markup on every chip for the sweet $$$), but they have a lot of stuff, so if it's all equally unreasonable, it still works as a comparison because it's all in the same place.

I really doubt you can get the lattice chips anywhere else though, at least not for less.
In the end it's a difference of a couple $, not a big deal for small runs.

 

[NathaanTFM]

Though, I do wonder: is there a specific reason for the STM32G4? I'd expect the STM32U5 to give similar performance figures but with much lower energy usage. (Many flashcarts using the ProASIC3/A3P250 FPGA tend to decrease the console's battery life quite a bit, which can be problematic, and that's on top of the obsoleteness/expensiveness/hard-to-obtain-ness of these parts that make them an all-around bad choice these days compared to 15y ago.)

That choice was only due to the fact that this was my cheapest option (and only one) on JLCPCB that had a chance to be fast enough. I looked at many other STM32 uCs, but none of them were available and I don't think I can request a part to only produce 5 pcbs.

For reference, for qty=5, the cost of the STM32G431CBU6 on JLCPCB was $1.8/unit

 

[SylverReZ]

That choice was only due to the fact that this was my cheapest option (and only one) on JLCPCB that had a chance to be fast enough. I looked at many other STM32 uCs, but none of them were available and I don't think I can request a part to only produce 5 pcbs.

For reference, for qty=5, the cost of the STM32G431CBU6 on JLCPCB was $1.8/unit

Despite the PCB being very thin around 0.4mm, I suspect that it'll cost way more than the defaults.

 

[PoroCYon]

Wait, that's a 0.4mm PCB, not a 0.8mm one? Regular cartridge PCBs are 0.8mm (as well as the DSi mainboard and the WiFi board).

In either case, the PCB looks small enough (and all components are on a single side) that you could probably attempt to do hand-assembly using a hot plate:

1. Put flux everywhere and tin the pads (using regular solder and a soldering iron)
2. Add more flux for good measure
3. Place the components on the tinned footprints
4. Put the whole on a hotplate and let the hotplate heat up to slightly above the melting temperature of your solder (typically 240 °C for leaded solder, 270 °C for lead-free solder, 130..180 °C for Bismuth solder)
5. Make sure that the assembly is at >200 °C for less than 20 seconds, or else the PCB itself will get damaged (FR4 starts breaking down)

EDIT:

For reference, for qty=5, the cost of the STM32G431CBU6 on JLCPCB was $1.8/unit

Wow, that's cheaper than the amount ST asks for these in bulk.

 

[xbmbmx]

Nothing short of completely amazing!


This is where I want(ed) to go when I made the original post here. I am very impressed and appreciate you sharing your work, this really got me excited to the max !!!

 

[Apache Thunder]

On the subject of thin PCBs I've been thinking that some flashcarts use thinner then normal ones not to cheap out but to allow for more space for the chips usually found on the label side of the PCB. Think of it this way, thinner PCB means you have more room for the chip on the otherside and thus have to remove less plastic from the label half of the shell you plan to use. I think a good portion of flashcarts used thin PCBs for this reason. Though some carts may still use thin PCBs as a cost cutting measure despite this. I think original R4s didn't have anything on the label side of the PCB yet they still used thin PCBs on them anyways.

Anyways if you manage to keep all the components on the side that has the contacts then there is no reason why you shouldn't use the standard retail PCB thickness especially if you plan to maintain compatiblity with retail shell layout. The retail cart shells aren't meant for the really thin PCBs so you may have issues with the cart not making contact with the pins in the slot. The original R4 for example has this issue with some consoles like the 3DS and I had to put in a slip of paper between the label half of the shell and the PCB.

I noticed my N-Cards have a thin PCB too but they have till raised ridges of plastic near the contacts on the label side shell half that keeps the PCB closer to the contact side and acts as a brace so in that case they would be less likely to have contact issues. But I'm pretty sure such design isn't incorperated into standard repro retail shells. So it's best to try and design around a PCB with standard thickness if you don't have any components on the label side of the PCB.

 

[PoroCYon]

On the subject of thin PCBs I've been thinking that some flashcarts use thinner then normal ones not to cheap out but to allow for more space for the chips usually found on the label side of the PCB.

The amount of FR4/bulk material of the PCB is hardly a factor in the cost though. How things are fabricated is a much stronger factor.

Most PCBs are 1.6mm thick, most manufacturing equipment is designed to handle this thickness. PCB fab houses that make prototypes for many people can thus combine many of these prototypes in a single huge board (which is later cut apart). Of course, all these designs must have the same thickness, or they can't be used on the same board. This makes ordering 1.6mm boards at these prototype services much cheaper than any other thickness, because it can be combined more easily.

Furthermore, thinner PCBs also pose other sorts of problems: they're more fragile, which means machinery must be able to handle this (instead of accidentally snapping the boards in two). During automated assembly, a 0.4mm/0.6mm thick PCB will actually start acting like a trampoline instead of a rigid board, so extra stabilizing things will have to be added, if you don't want the components to start jumping off.

All these things end up making thin PCBs much more expensive than standard-thickness ones.

 

[SylverReZ]

Any updates so far?

 

[NathaanTFM]

Can't currently give any update, but I'm definitely not giving this up and still planning to eventually open-source everything. Don't have enough free time for now, sorry!