Gathering DS flashcard knowledge - DIY "opencard" idea

[SylverReZ]

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!

Its okay. Take the best break you need for both your health and time with family.

 

[NathaanTFM]

I've put the original SM64 ROM on the flash memory and managed to boot to the Nintendo logo. Unfortunately, probably the lack of the backup EEPROM prevents the game from going further.

It doesn't seem like my current setup allows me to "simulate" this chip with the microcontroller - I'll give it a few more tries when I can, though.

As for performance, I have made a test ROM for the cartridge. Seems like I can load a same area at least 3500 times in a row (chunks of 200h bytes, with key2/enPNG encryption) with either GAP1=0000h GAP2=18h, or GAP1=0017h GAP2=01h (these are the two most common values for commercial games).

I hope I'll be able to fake the backup EEPROM without having to order a new PCB..

EDIT: the crashes are due to unstable code ; I will have to make better test ROMs

 

[xbmbmx]

I've put the original SM64 ROM on the flash memory and managed to boot to the Nintendo logo. Unfortunately, probably the lack of the backup EEPROM prevents the game from going further.

It doesn't seem like my current setup allows me to "simulate" this chip with the microcontroller - I'll give it a few more tries when I can, though.

As for performance, I have made a test ROM for the cartridge. Seems like I can load a same area at least 3500 times in a row (chunks of 200h bytes, with key2/enPNG encryption) with either GAP1=0000h GAP2=18h, or GAP1=0017h GAP2=01h (these are the two most common values for commercial games).

I hope I'll be able to fake the backup EEPROM without having to order a new PCB..

Cool to see you're still making progress . My progress has halted for a bit as University is taking a very large chunk of my time. I will eventually pick this up again full-force, but it might be a while before I do so.

Brief sidetrack, today I saw this:

which I again think is SUPER F-ING COOL!!!

Flashcards will forever have a special place in my interests.

 

[genistopitauniverfrocrami]

Would it be a more feasible approach to base the "opencard" on an existing flashcart?

For example, one could obtain the relevant electronics skills, and then create an open source, clean room, hardware clone blueprint. Then the firmware can be reused; not included, but usable as separate binary blobs (which can be worked on later). Kernel can be TWiLightMenu/nds-bootstrap.

That should technically be an open source flashcart; at least something that could get things going. I doubt that there would be any patents involved.

 

[Hiccup]

That might be a good idea, but any of the existing flashcarts actually "proper" flashcarts - i.e. emulating the cartridge protocol like flashcarts for retro consoles? Or do they all "just" patch the games' code in-memory? I know there are very compatible ones (Acekard2i/AKAIO being the best?), but I'm not sure.

 

[Apache Thunder]

That might be a good idea, but any of the existing flashcarts actually "proper" flashcarts - i.e. emulating the cartridge protocol like flashcarts for retro consoles? Or do they all "just" patch the games' code in-memory? I know there are very compatible ones (Acekard2i/AKAIO being the best?), but I'm not sure.

The only cart I know of that doesn't patch games at all and handles things on the hardware side is N-Card.

That old flash cart uses NAND for storage and thus doesn't need to patch games to patch them since MicroSD protocol requires extra steps to access them that would break timing and such on games if you didn't patch them.
N-Cards don't save patch either from what I can tell. N-Cards use a battery backed save system.

Despite them not seeing any software updates since 2008/2009, Xmenu (the kernel menu software for N-Cards and their clones) can still launch most games. Even SDK5 games like Pokemon Black will boot. Though since Xmenu is ancient and doesn't do AP patches you still have to pre-patch them for that. Also xmenu won't know what save type to set for some newer games so you have to manually set the save type for them like some newer Pokemon games.

512MB games (Pokemon Black 2/White 2) and games that use nand based saving like some WarioWare games are the only games I've found that don't work on N-Cards.

It would be tricky to design a MicroSD based flashcart that doesn't need to patch NDS games before launching them. You can get away with that if you use nand for storage but then you'd give up making your loader compatible with other flashcarts.

 

[Hiccup]

Interesting. So the timings required by the SDK code are that strict, and SD is that slow? Yeah, I'm not sure how you could have user upgradable storage without using microsd. Unless you could just clip NAND chips in? Depends how standardised they are I guess.

Or I wonder if the SD overhead could be avoided if it was accessed at a lower level?

 

[Apache Thunder]

Interesting. So the timings required by the SDK code are that strict, and SD is that slow? Yeah, I'm not sure how you could have user upgradable storage without using microsd. Unless you could just clip NAND chips in? Depends how standardised they are I guess.

Or I wonder if the SD overhead could be avoided if it was accessed at a lower level?

Well you could pull off what Acekard did. AceKard R.P.G has a nand chip along side a MicroSD card. Must be a pretty expensive hardware design though...sucks that card is super rare these days. Can't find one for sell anywhere.

 

[Hiccup]

Well you could pull off what Acekard did. AceKard R.P.G has a nand chip along side a MicroSD card. Must be a pretty expensive hardware design though...sucks that card is super rare these days. Can't find one for sell anywhere.

Oh that's a good idea - copy the ROM from the SD to faster storage when its launched.

 

[genistopitauniverfrocrami]

[Edit]

 

[Hiccup]

Oh that's a good idea - copy the ROM from the SD to faster storage when its launched.

Following up to this - I wonder how feasible it would be to use RAM for the faster storage, because NAND would eventually wear out.

 

[genistopitauniverfrocrami]

Following up to this - I wonder how feasible it would be to use RAM for the faster storage, because NAND would eventually wear out.

Playing commercial roms was not OP's intention. So regarding flashcart accuracy, perhaps you could ask in a new thread.

 

[TheStonedModder]

Playing commercial roms was not OP's intention. So regarding flashcart accuracy, perhaps you could ask in a new thread.

Probably a dumb question but wouldn’t you want the flashcart as accurate as possible so that whatever homebrew is developed on it has a better chance to properly work on real hardware ?

Or am I just high and confused?

 

[genistopitauniverfrocrami]

Probably a dumb question but wouldn’t you want the flashcart as accurate as possible so that whatever homebrew is developed on it has a better chance to properly work on real hardware ?

Or am I just high and confused?

I meant flashcart accuracy when it comes to running commercial games. Things like having an on board NAND to not require save patches, or having it be similar enough to a real cart to not require AP patches. Perhaps not related here but might be worth discussing.

When it comes to homebrew compatibility then that might be a good question. Is homebrew compatibility taken care of by the kernel (which just needs to be ported to the cart)? Are there other factors?

If cloning an existing cart, then homebrew compatibility shouldn't be a problem, assuming you can properly clone a cart that already runs homebrew.

Thanks for asking.

 

[Hiccup]

If you like, you could consider it useful for creating homebrew to retail cart specifications.

 

[Apache Thunder]

I meant flashcart accuracy when it comes to running commercial games. Things like having an on board NAND to not require save patches, or having it be similar enough to a real cart to not require AP patches. Perhaps not related here but might be worth discussing.

When it comes to homebrew compatibility then that might be a good question. Is homebrew compatibility taken care of by the kernel (which just needs to be ported to the cart)? Are there other factors?

If cloning an existing cart, then homebrew compatibility shouldn't be a problem, assuming you can properly clone a cart that already runs homebrew.

Thanks for asking.

Onboard nand wouldn't help with save patches but with not needing cart read patches. N-Card handles saves via a battery backed SRAM chip and handles saves similar to retail carts and avoids save patches in a similar way to the read patches in that it handles that on the hardware side via the mystery ASIC blob chip which may or may not be an FPGA of some sort.

The downside is xmenu has to write the save from the last played save onto nand on next boot which can fail if the battery ever dies.

I'm not sure why they used a battery backed SRAM chip for this. Retail carts didn't use batteries which Nintendo moved away from after the GBA era. I guess the kind of save chips retail carts used weren't cheaply available yet or they did this as some odd cost cutting thing. Anyways yeah avoiding save patches wouldn't be resolved with NAND unless you dedicated nand solely to saves...which would be supreme overkill for what capacities NAND chips usually come in.

You could just use NAND for both cart reads and saves but probably would still require save patching of some sort and perhaps some onboard ram for temp storage because then you'd have to worry about a save happening during a cart read and you cant read nand while a nand write is in progress so in that case you'd might still need save patching. N-Card avoided this by using an SRAM chip and writing the save to nand on reboot instead of during gameplay.

 

[NathaanTFM]

Hey, I've finally got some good news!

I'm working on a budget so I can't afford debugging tools and that's one of the reasons it takes so much time. But I've bought some cheap logic analyzer clones and it helped me debug the remaining issues!

Turns out I was handling incorrectly some ARM state register (xPSR in an IRQ) and that this was causing the code to crash if it got interrupted during a multi-cycle instruction. But now that the issue is fixed, it seems like the cartridge supports max speed games!

There's always more debugging to do, and maybe I can even consider working on the SPI save chip simulator. But once I've cleaned up the code a bit, I should be able to release the source code to (at least) the uC software. The cartridge PCB is probably garbage (I don't have any experience with this), but I might consider releasing it anyway.

Thanks to @Sono for their help - this actually wouldn't have been possible without your work!

 

[2k_intentions]

Hey, I've finally got some good news!

I'm working on a budget so I can't afford debugging tools and that's one of the reasons it takes so much time. But I've bought some cheap logic analyzer clones and it helped me debug the remaining issues!

Turns out I was handling incorrectly some ARM state register (xPSR in an IRQ) and that this was causing the code to crash if it got interrupted during a multi-cycle instruction. But now that the issue is fixed, it seems like the cartridge supports max speed games!

There's always more debugging to do, and maybe I can even consider working on the SPI save chip simulator. But once I've cleaned up the code a bit, I should be able to release the source code to (at least) the uC software. The cartridge PCB is probably garbage (I don't have any experience with this), but I might consider releasing it anyway.

Thanks to @Sono for their help - this actually wouldn't have been possible without your work!

Great

I hope you can sell some units on Aliexpress

 

[NathaanTFM]

It's definitely more of a novelty than an actual product (the initial goal was to find a way to distribute my homebrew game without buying a bunch of aliexpress R4s because those usually suck).

Making a flashcard could be interesting, but it would require "on the fly" game patching (like the flashcards do, apparently) and to use a whitelist bypass exploit. If the 3DS has the same whitelist system as the DSi, then it could be compatible with 3DS units too.

I've been working a lot on this lately and I've got some more technical updates :
- Using the SPI backup (game saves) definitely won't be possible with a single chip ; I can still send a non-volatile savefile that's stored into the microcontroller's flash memory (or even in the external NOR Flash) to the console, but there's definitely no way to make it writable. The timeouts are too short, and it takes 15x times longer to program a sector on a NOR Flash than it takes to write a few bytes on an EEPROM.

- I have implemented 1000h bytes transfers - which allows Unlaunch to run the cartridge! I also removed some optimisations that turned out to be unnecessary. Right now, the fastest I could go was 4000 consecutives 200h bytes transfers with GAP=13h (which is smaller than all games, apparently). I couldn't go any further because my test ROM didn't allow that.

- I might look at using a NAND FLASH memory chip instead, but due to how slow they are, those might not even work with the slower roms (GAP1=657h - leaves me 242 µs to work with reading up to 1000h bytes). NOR FLASH chips are still too expensive to me, but it seems like they're the fastest solution available. I also need to test with a bigger NOR FLASH chip that needs 4-bytes addresses - my 16Mbyte chip only has 3-bytes addresses commands.

- I need to measure power usage T_T

I'll eventually look at adding a MicroSD port and patching games, but it definitely won't be until a few months. This project has already been quite costly to me (w/ 5 different prototypes, debug and flashing tools). I'm gonna spend the next weeks re-writing the code so it's readable (and can be released). Thanks to everyone who's following this project and has helped me!

 

[Apache Thunder]

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.