Gathering DS flashcard knowledge - DIY "opencard" idea

[DobaMuffin]

Definitely true but as most flashcards use the ProAsic3 it is definitely up for the task. That's why I bought it all that time back. Microcontrollers are still in my notes and as they're generally way cheaper I could buy one or more later to test around with.

Anyways, microcontrollers (Especially the RP2040, which powers the Pi Zero) have already been discussed here and are definitely an option. A downside of the RP2040 as a standalone (on e.g. the PCB of a future flashcard) is that it's startup time is apparently too long. Sono (member who has replied to this thread and who I have chatted with too) explained some of this here and to me privately.

Another person I'm chatting with is currently trying to use an STM32H750VBT to create a self-made cart for a homebrew. An attempt was already made with a lower-clock microprocessor but it was too slow. This one should (in theory) be overkill and leave enough space to make this possible. They do not intend (currently) to use an SD card in their design. I do intend to do this, so my eventual implementation will differ, but their work is viable and valuable nonetheless.

I have ordered a replacement SLOT1, I have a few pico's and a RPi 4 and an Arduino Uno too so I can, once I receive the SLOT1, get going with the self-written card dumper etc. I am also close to KiCad-ing the breakout board with female headers.

Yeah I remember reading the comment they made about the pi pico. Didn't realize it took that long to boot. Do you know how long from poweron the system expects communication from the cartridge slot?

https://github.com/SonoSooS/pico-ntrbootleg

That is an interesting project. ntrboot being hardcoded is a little unfortunate, and it requiring the pico to be turned on first makes it a little impractical, but it's interesting to see it does work in the first place. Wonder what the timings look like from poweron to reading the cartridge.

 

[Sono]

Yeah I remember reading the comment they made about the pi pico. Didn't realize it took that long to boot. Do you know how long from poweron the system expects communication from the cartridge slot?



That is an interesting project. ntrboot being hardcoded is a little unfortunate, and it requiring the pico to be turned on first makes it a little impractical, but it's interesting to see it does work in the first place. Wonder what the timings look like from poweron to reading the cartridge.

There is not a lot of time.

However, I did manage to make it boot fast enough by overriding the SDK and using a custom linker script and DMA to perform the initialization.

 

[DobaMuffin]

There is not a lot of time.

However, I did manage to make it boot fast enough by overriding the SDK and using a custom linker script and DMA to perform the initialization.

I'll have to do a timing analysis on my test ds. I think a logic analyzer aught to do the job.

 

[Sono]

I'll have to do a timing analysis on my test ds. I think a logic analyzer aught to do the job.

Measure Vcc and /RESET, the rest aren't important for timing analysis*.
Vcc and /RESET should rise at the same time, then after 5ms or 27ms (I forgot) /RESET should go low for 1024 (or 4096 ?) cartridge cycles, then rise, then after maximum ~1.3ms (I didn't time it correctly) it will start spamming commands.

But yeah, I'd appreciate if you could do more precise timing analysis, that would be useful.

Here's the expected rundown:
- Vcc and /RESET rise at the same time, cartridge is in undefined state
- /RESET, /CS1, and /CS2 are pulled low, and it's clocked for 1024 (or 4096 ?) clock cycles
- /RESET, /CS1, and /CS2 are released
- almost immediately after, DS sends a BLOWFISH_PRELOAD (9F00000000000000) command
- after a little wait, DS sends some other commands, but it will eventually fail due to garbage results caused by floating data pins; measuring should end here, as the cartridge emulator must've already booted fully by this point

Note: you'll HAVE TO push in the cart detect pin (NOT the /IRQ pin) using the plastic shell of the cartridge (or like I did, solder it together, as my cart slot snapped off), otherwise it will be refused to detect at all.

* or at least in ntrboot mode, after a reset it immediately starts spamming commands as fast as possible after a reset, so it's a really good indicator

 

[DobaMuffin]

Measure Vcc and /RESET, the rest aren't important for timing analysis*.
Vcc and /RESET should rise at the same time, then after 5ms or 27ms (I forgot) /RESET should go low for 1024 (or 4096 ?) cartridge cycles, then rise, then after maximum ~1.3ms (I didn't time it correctly) it will start spamming commands.

But yeah, I'd appreciate if you could do more precise timing analysis, that would be useful.

Here's the expected rundown:
- Vcc and /RESET rise at the same time, cartridge is in undefined state
- /RESET, /CS1, and /CS2 are pulled low, and it's clocked for 1024 (or 4096 ?) clock cycles
- /RESET, /CS1, and /CS2 are released
- almost immediately after, DS sends a BLOWFISH_PRELOAD (9F00000000000000) command
- after a little wait, DS sends some other commands, but it will eventually fail due to garbage results caused by floating data pins; measuring should end here, as the cartridge emulator must've already booted fully by this point

Note: you'll HAVE TO push in the cart detect pin (NOT the /IRQ pin) using the plastic shell of the cartridge (or like I did, solder it together, as my cart slot snapped off), otherwise it will be refused to detect at all.

* or at least in ntrboot mode, after a reset it immediately starts spamming commands as fast as possible after a reset, so it's a really good indicator

I have an original DS motherboard I have modified for 1 screen operation with no case. So I think I'll just remove the cartridge slot, solder it to a protoboard, and then solder wires to it. Essentially make my own breakout board for it while still passing signals to the cartridge. Either that or I'll design myself a breakout cartridge with passthrough like an action replay.



Edit: what cartridge should I use for the capture. I'm planning on a full capture so I need a cartridge that I can share part of the ROM of. Which probably means an existing flash cartridge or something.

 

[xbmbmx]

Very short update: current idea for prototyping:

 

[Sono]

Very short update: current idea for prototyping:

View attachment 394789

You accidentally routed the useless pin (pretty sure that pin is not connected *at all* on the SoC) but left /IRQ floating (left of Vcc). Please use a 10k (?) resistor to pull it high. You can also route it for later use.

 

[xbmbmx]

You accidentally routed the useless pin (pretty sure that pin is not connected *at all* on the SoC) but left /IRQ floating (left of Vcc). Please use a 10k (?) resistor to pull it high. You can also route it for later use.

I thought /IRQ just went to GND (src: http://www.hardwarebook.info/DS_Game_Card )? (The 3 floating pins rn are ones I intend to stick to the GND plane -> blue part of layout on the right)

I guess I could ignore Vhh indeed and use a 5-pin header instead of a 6-pin header

If /IRQ does not go to GND, what is it used for then and why should it be pulled high?

 

[SylverReZ]

Very short update: current idea for prototyping:

View attachment 394789

@IS1982 would truly love this.

 

[Sono]

I thought /IRQ just went to GND (src: http://www.hardwarebook.info/DS_Game_Card )? (The 3 floating pins rn are ones I intend to stick to the GND plane -> blue part of layout on the right)

I guess I could ignore Vhh indeed and use a 5-pin header instead of a 6-pin header ...

If /IRQ does not go to GND, what is it used for then and why should it be pulled high?

The link is dead for me (404), lol.

https://www.3dbrew.org/wiki/Gamecards

You only need to connect /IRQ high with a 1k or 10k resistor (I forgot which, resistor says 103 on it), you can leave the rest floating with no problem.
With the 1k resistor though make sure your microcontroller can supply enough current to drive it low though.

/IRQ is used mostly if the cartridge has additional hardware requiring immediate attention. Otherwise, some DS games may use it for removal detection (source: everyone keeps repeating it, probably true, considering DSi introduced physical cart detect, DS didn't have one).

 

[xbmbmx]

The link is dead for me (404), lol.

https://www.3dbrew.org/wiki/Gamecards

You only need to connect /IRQ high with a 1k or 10k resistor (I forgot which, resistor says 103 on it), you can leave the rest floating with no problem.
With the 1k resistor though make sure your microcontroller can supply enough current to drive it low though.

/IRQ is used mostly if the cartridge has additional hardware requiring immediate attention. Otherwise, some DS games may use it for removal detection (source: everyone keeps repeating it, probably true, considering DSi introduced physical cart detect, DS didn't have one).

 

[Sono]

- attachment -

Yeah, that must've been used on original DS for cart detect reasons.
It's also /IRQ.

I'd still recommend pulling it up via resistor, and tie to ground using a jumper wire if needed.

Speaking of which, I recommend using separate header for GND and Vcc, so you can more easily attach things to it without having to splice up jumper wires.
In my case that wasn't possible, so I had to make a flaky adapter for that. But since you're designing a PCB, you have the freedom to add the extra headers.
I recommend at least 3 pins for each for future-proofing.

 

[NathaanTFM]

wouldn't pulling IRQ high (or not connecting it to GND directly) cause issues with cart detection on platforms that implements it? (such as the DSi, or maybe even the original DS?)

every online documentation says it's connected to GND in cartridge (gbatek and that one are the only i'm aware of), and it can even be checked on retail cartridges

 

[SylverReZ]

wouldn't pulling IRQ high (or not connecting it to GND directly) cause issues with cart detection on platforms that implements it? (such as the DSi, or maybe even the original DS?)

every online documentation says it's connected to GND in cartridge (gbatek and that one are the only i'm aware of), and it can even be checked on retail cartridges

View attachment 394893View attachment 394894

That second game, if you want to know what it is, the game code is etched onto the mask ROM.

 

[Sono]

wouldn't pulling IRQ high (or not connecting it to GND directly) cause issues with cart detection on platforms that implements it? (such as the DSi, or maybe even the original DS?)

every online documentation says it's connected to GND in cartridge (gbatek and that one are the only i'm aware of), and it can even be checked on retail cartridges

View attachment 394893View attachment 394894

DSi and 3DS have actual cart detection, so there it's pointless to have /IRQ grounded.
Also no, it should not cause cart detection issues, as it's only checked at boot-time (that's why you must reboot your DS / Lite if you insert a cartridge).

 

[xbmbmx]

DSi and 3DS have actual cart detection, so there it's pointless to have /IRQ grounded.
Also no, it should not cause cart detection issues, as it's only checked at boot-time (that's why you must reboot your DS / Lite if you insert a cartridge).

in your opinion, would it make more sense to have IRQ pulled HI already on my pcb, or make my PCB just a "dumb extension" and handle everything for resistors etc on the breadboard/devboard I attach to it?

 

[Sono]

in your opinion, would it make more sense to have IRQ pulled HI already on my pcb, or make my PCB just a "dumb extension" and handle everything for resistors etc on the breadboard/devboard I attach to it?

I'd say pull it high on board, so it's 1 less GPIO to waste on the chip if you don't need it.

If you need it pulled low anyway, just use a jumper wire (or hell, even steal a motherboard jumper plastic thingy and put that in, if you design the board that way) if you need it tied low for some reason.

 

[DobaMuffin]

I'd say pull it high on board, so it's 1 less GPIO to waste on the chip if you don't need it.

If you need it pulled low anyway, just use a jumper wire (or hell, even steal a motherboard jumper plastic thingy and put that in, if you design the board that way) if you need it tied low for some reason.

I'd actually recommend having 2 resistors and a 3 pin header. That way it can be safely tied to ground, 3.3v or used for other reasons

Edit: a sp3t switch could be used instead.

 

[xbmbmx]

True, I'll just have my main pcb (the one with the pin-outs) behave as a dumb extension board, and attach a breadboard to it that has a 3-way switch that allows me to toggle between the "irq modes". I'll hook up my Actel ProAsic to it or a RPi Zero. My first goal is serving a header properly (first to a self-made cart reader, after that to a nintendo ds).

To test my "dumb extension board" I'm also going to sacrifice a retail cart, solder jumper wires to the pads of the retail cart and hook it up to my extension board. If all is good, the retail game should "flow through" the extension board and popup on the DS through the extension board.

If it doesn't, something is wrong.

Post automatically merged: Sep 21, 2023

Hi! Posting this here for a final "community correction", feel free to post any comments if you spot a mistake or leave a like to the post (or a comment) if you've seen it and approve of it (helps me know if no one saw it yet, or if people saw it but think that it's okay).

I just wired up all pads to their own individual header pin, except for the two ground pads. The two ground pads are connected to the ground layer (marked in blue) and are accessible through J3 (top right).

All other pads are served through headers pins connected by the traces indicated in red.

(Also, if someone wants design some simple yet cool logo in PNG to stick it on here, feel free to do so I'm not really good with visuals and logos)


Layout:

Front render:

Back render:

 

[xbmbmx]

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.