[tasken]

Adds support for the SD card of a DSpico flashcart.

• Detects a DSpico in the cart slot and mounts its SD card on 7:/, where it works like a regular SD card
• R+X unmounts or remounts it, and a warning appears if the cart is removed while mounted
• Failed transfers reset the card and retry
• It shares 7:/ with FAT images, so only one can be mounted at a time

Fixes #968

[Wolfvak]

It shares 7:/ with FAT images, so only one can be mounted at a time

I don't own a DSpico, what is the intended usecase here?

If it is moving data to/from the external cart SD to the internal SD or NAND, I think it makes more sense to share the drive with #9 (the RAMdrive) as people might still want to access the NAND partitions at the same time as the DSpico, but I can't imagine a usecase for moving data from the DSpico to the RAMdrive.

But I'm happy to be proven wrong on this too.

[tasken]

It shares 7:/ with FAT images, so only one can be mounted at a time

I don't own a DSpico, what is the intended usecase here?

If it is moving data to/from the external cart SD to the internal SD or NAND, I think it makes more sense to share the drive with #9 (the RAMdrive) as people might still want to access the NAND partitions at the same time as the DSpico, but I can't imagine a usecase for moving data from the DSpico to the RAMdrive.

But I'm happy to be proven wrong on this too.

The use case is moving files between the DSpico SD and the internal SD/NAND, yes.

My concern with 9:/ is that in my PR the DSpico automounts, and current GM9Megascript stages files in 9:/sdcompiled and then moves them to 0:/ for some operations. With the DSpico on 9:/, that would write to the DSpico card instead. The downside of 7:/ is that a NAND image can't be mounted at the same time.

Please let me know what you think.

[tasken]

• DSpico transfers now wait with no timeout, same as the official DSpico dldi driver
• Failed transfers and listing the cart don't reset the card anymore, that was causing the resets while copying
• The cart drive now shows "DSPICO CART" so it doesn't get mixed up with the DSpico SD

[Wolfvak]

My concern with 9:/ is that in my PR the DSpico automounts, and current GM9Megascript stages files in 9:/sdcompiled and then moves them to 0:/ for some operations. With the DSpico on 9:/, that would write to the DSpico card instead. The downside of 7:/ is that a NAND image can't be mounted at the same time.

Please let me know what you think.

Then yeah, looks like we'll have to reuse this one.

DSpico transfers now wait with no timeout, same as the official DSpico dldi driver

I'm not against time-based timeouts, I think they're a good thing, but they shouldn't affect the critical path and ideally should only affect the error paths. If the official DLDI driver does this, then I think it's reasonable.

Failed transfers and listing the cart don't reset the card anymore, that was causing the resets while copying

Do you have any performance numbers? I'm not expecting a huge change as this sounds very bus limited (4 MHz / MiB/s?) but the higher the number, the better for us, as long as it's stable.

[tasken]

Did some extra debug, performance numbers on a 624 MB:

• read: ~4.5 MiB/s (file hashing)
• write: ~3.7 MiB/s (virtual to pico)

clock is the default 6.7 MHz, so ~6.4 MiB/s at most if it moves one byte per clock (haven't checked the gap cycles). I think the rest is the pico's per-command latency: the firmware serves one 512 byte sector per E5 and the read loop polls E4 before each one

[tasken]

Last commit: DSpico SD can now save the .sha file, like on the regular SD card

[fox8091]

Any chance we could just add a new drive? I know @Wolfvak mentioned not seeing a reason to transfer between RAMdrive and DSPico, I could see users wanting to transfer between two DSPicos or even two different flashcarts if support is ever added. That'd also give a new place to cleanly support Gateway carts, which I've wanted to implement for a while anyways, and a new drive letter would make a nice place to standardize on.

[Wolfvak]

Did some extra debug, performance numbers on a 624 MB:

* read: ~4.5 MiB/s (file hashing)

* write: ~3.7 MiB/s (virtual to pico)

clock is the default 6.7 MHz [...]

I think this is perfectly acceptable, nobody's expecting the NDS cart to be ultra fast, especially not when running on a microcontroller that has to deal with protocol overheads.

Sorry about not making many updates here but I'm still racking my brains trying to figure out a trivial way to add this drive without messing too much with GM9's insides, but do ping me here, on Discord or IRC if I haven't gotten back to you in a timely manner.

(if you figure out a way I'd be more than happy to hear it)