Okay, the selection of analysis hardware is still open but it will simply depend on what't the easiest to learn and what fits for the job the best. If a logic analyser is simply cheaper for multi channel communication than I will get a logic analyser.
Now, if I can skip the logic through signal analysing that would be even better. It's just that so far, I have not found any documentation on e.g. how a cartridge (or flashcard for that matter) can understand (e.g. "decode") the signals sent to it. The I/O maps don't indicate how the 8 data pins communicate, and the 8 data pins protocol aren't as straight forward as e.g. a pin named "RST" .
I'm really just looking for a way to interact with the commands sent to the cartridge and reply to them from within an emulated cartridge (RP pico, FPGA). The analysing looked like a logical step to me but if I can get there another way (documentation, some libraries) that would be excellent too!
Next up:
I chewed through enough learncpp that I want to try and make a barebones homebrew application.
I have found some of my old nds homebrew projects (just some simple write to hello.txt and some other stuff). I've updated my devkitPro install and confirmed it working (can compile e.g. their hello world and run on my DSi and DS).
Now: the card (EEPROM.nds) example is what interests me the most currently.
First hurdle: it does not work on a DSi, apparently. I remember reading somewhere that ejecting a cartridge on the DSi had some side effects not present on a DS, but I'm unsure if I remember correctly and I'm also not sure if there's a workaround for this.
So basically what happens in my DS:
1) I run the homebrew off my flashcard, it asks me to eject the card and insert another card to read EEPROP info from.
2) I eject my flashcard and insert a retail card
3) info (game title, eeprom size) is reported correctly by the homebrew.
On my DSi on the other hand:
1) I run the homebrew off my flashcard, it asks me to eject the card and insert another card to read EEPROM info from.
2) I eject my flashcard and insert a retail card
3) info is displayed incorrectly, all values seem to be null and the game title is not reported.
A discussion on the DevkitPro forum about this very issue was started but doesn't seem to ever have come to a conclusion: here.
Can anyone explain to me why this is the case? I'm sure I've come across an explanation related to this already but I can't remember where or when...
I'd really like to know why this doesn't work on a DSi, and if there are any workarounds to make this work (or if that is for a technical reason impossible - e.g. a non-changeable bit that's set once the card is ejected or something - I think it had something to do with that but I just don't remember).
Anyways any explanation please, I'm really interested!
I've found it - GBATEK does cover it! (It was just hidden very well in my annotations):
There seems to be a solution to this: the DSi provides a software-controlled method to cut and return power to the cartridge resulting in the same behavior as an eject but without disabling the card slot. I'm only unsure if this feature was ever worked into DevkitARM's codebase.
I'll look for it - and report back if I find if DevkitPro has a command to manipulate this reset behavior documented in GBATEK. If any of you know what I'm looking for, please share !
Now, if I can skip the logic through signal analysing that would be even better. It's just that so far, I have not found any documentation on e.g. how a cartridge (or flashcard for that matter) can understand (e.g. "decode") the signals sent to it. The I/O maps don't indicate how the 8 data pins communicate, and the 8 data pins protocol aren't as straight forward as e.g. a pin named "RST" .
I'm really just looking for a way to interact with the commands sent to the cartridge and reply to them from within an emulated cartridge (RP pico, FPGA). The analysing looked like a logical step to me but if I can get there another way (documentation, some libraries) that would be excellent too!
Post automatically merged:
Next up:
I chewed through enough learncpp that I want to try and make a barebones homebrew application.
I have found some of my old nds homebrew projects (just some simple write to hello.txt and some other stuff). I've updated my devkitPro install and confirmed it working (can compile e.g. their hello world and run on my DSi and DS).
Now: the card (EEPROM.nds) example is what interests me the most currently.
First hurdle: it does not work on a DSi, apparently. I remember reading somewhere that ejecting a cartridge on the DSi had some side effects not present on a DS, but I'm unsure if I remember correctly and I'm also not sure if there's a workaround for this.
So basically what happens in my DS:
1) I run the homebrew off my flashcard, it asks me to eject the card and insert another card to read EEPROP info from.
2) I eject my flashcard and insert a retail card
3) info (game title, eeprom size) is reported correctly by the homebrew.
On my DSi on the other hand:
1) I run the homebrew off my flashcard, it asks me to eject the card and insert another card to read EEPROM info from.
2) I eject my flashcard and insert a retail card
3) info is displayed incorrectly, all values seem to be null and the game title is not reported.
A discussion on the DevkitPro forum about this very issue was started but doesn't seem to ever have come to a conclusion: here.
Can anyone explain to me why this is the case? I'm sure I've come across an explanation related to this already but I can't remember where or when...
I'd really like to know why this doesn't work on a DSi, and if there are any workarounds to make this work (or if that is for a technical reason impossible - e.g. a non-changeable bit that's set once the card is ejected or something - I think it had something to do with that but I just don't remember).
Anyways any explanation please, I'm really interested!
Post automatically merged:
I've found it - GBATEK does cover it! (It was just hidden very well in my annotations):
There seems to be a solution to this: the DSi provides a software-controlled method to cut and return power to the cartridge resulting in the same behavior as an eject but without disabling the card slot. I'm only unsure if this feature was ever worked into DevkitARM's codebase.
I'll look for it - and report back if I find if DevkitPro has a command to manipulate this reset behavior documented in GBATEK. If any of you know what I'm looking for, please share !
Last edited by xbmbmx,