#73310 - Nushio - Fri Feb 24, 2006 4:13 pm
Hello!
I was thinking on doing a concept game that bases itself on collecting stuff.
Anyways, part of the game involves (to unlock) different (stuff), to insert different DScarts, since the gbaslot is used by the flashcart...
Is there some way to determine which DScart is being used? I've used Rain (the save backup program), and it at least gives a checksum (a checksum would be enough for this game i'm making)
Does the DS care if I read the DSCart, and without turning it off, you put a second DSCart, and I read it again?
Do different... lets say... Mario Karts provide different Checksum(supposing they are both (USA) versions, rather than Europe or Japan differences).
And finally, can this code be used on PA_Lib? :D
Thanks for your time...
-Nushio
#73313 - m2pt5 - Fri Feb 24, 2006 4:33 pm
Something like this would make a great Monster Rancher game for DS, but the other way around. (Read the cart in the GBA slot and generate a monster based on that. The Monster Rancher PS games read CDs to generate monsters, and the GBA slot is hot-swappable as long as it's not being read at the time.)
_________________
Don't sign your posts, it's dumb.
#73340 - Nushio - Fri Feb 24, 2006 10:52 pm
| m2pt5 wrote: |
| Something like this would make a great Monster Rancher game for DS, but the other way around. (Read the cart in the GBA slot and generate a monster based on that. The Monster Rancher PS games read CDs to generate monsters, and the GBA slot is hot-swappable as long as it's not being read at the time.) |
Yes, its something like that, based on that principle.
Remember that we are using the GBA slot with the flashcards (be it SC, M3, GBAMP or EZflash) unless someone uses the download play, which leaves me with the option of using DScarts instead of GBA carts...
#73349 - Dark Knight ez - Sat Feb 25, 2006 12:07 am
| Quote: |
| the GBA slot is hot-swappable |
Meaning that you could load a part of your program up in NDS RAM, run that part of the program, let the user insert a different GBA cart, let the program read it, and after it has been read by your program, let the user swap back the original cart in the GBA slot which contained your entire program.
#73359 - Nushio - Sat Feb 25, 2006 1:28 am
True, but I'd preffer to keep it with DS carts. (Mainly because I only have 1 GBA game: Wario Twisted, and around 8 NDS games... :P)
Are DSCarts hot-swappable as well?
Anyone know any code I can use (preferably with PA_Lib, but I'm willing to learn Libnds (or ndslib or whatever its called now :S))?
#73366 - caitsith2 - Sat Feb 25, 2006 3:40 am
One issue with DS cards is the encryption. What happens when you remove, then reinsert the game card, is that the gamecard thinks it has been reset, and is in the mode to read the 0x200 byte header. This means you also have to reset the encryption registers, and resend the commands to get the game card into key2 encryption mode. The only way to successfully do this requires the blowfish key contained in the arm7 bios. This is why nintendo made games tell you to shut off the ds and reinsert the gamecard.
Now, if you don't mind the lockout or are willing to figure out how to work around it, and generate the required key to encrypt the key1 commands, to go back into key2 mode, then initialize the key2 register again, you could theoritacally get the gamecard back into a usable state without powering the system off then back on again.
You should still be able to Read from/write to the gamecard eeprom without doing that work, and all you would need from each gamecard is the header data.
So, an easy way this could work, if it were officially developed, would be as follows
| Code: |
1. User selects load monster.
2. User is instructed to remove monster rancher gamecard.
3. User inserts other game card of his choice.
4. Monster rancher reads the header off the gamecard.
5. User is instructed to remove his selected game card.
6. User is then instructed to reinsert monster rancher.
7. Monster rancher then writes the retrieved header data to the gamecard eeprom.
8. User is given choice of whether to load another gamecard or to power off.
9. If user selects to load another, Repeat Steps 2-8 again. There would be a set max number of monsters that can be loaded in this session.
10. If user selects power off, then the DS is powered off, after all game card header data has been written.
11. User powers on, then finds out what each of his selected game cards gave him, in relation to monster data.
|
The above would be the only thing that nintendo would have far less power for going against. If the developer decides to dump the bios, and reverse the encryption and all, to avoid the power off and on sequence, then nintendo could go after them for having copied the critical key in the bios, as well as a few other important values.
#73367 - caitsith2 - Sat Feb 25, 2006 3:50 am
Forgot to mention, the unofficial developer has that alternative route, which is the gba flashcart containing the program/assets. In such a case, the Poweroff/on and working around the encryption steps can both be skipped, as the game would not be running from ds card.
The official developer could also follow this route as well, by storing the save/assets onto an "option pak", and the game card would only be for booting the game itself.
#73390 - HyperHacker - Sat Feb 25, 2006 6:52 am
Or you could just use the hole to read the key right out of the BIOS. I don't think it's illegal to simply call a piece of code the developers didn't expect you to. ;)
Also when I take the cart out during a game, it just powers off instantly. O_o
#73395 - m2pt5 - Sat Feb 25, 2006 7:59 am
| HyperHacker wrote: |
| Also when I take the cart out during a game, it just powers off instantly. O_o |
If the DS is reading from a slot when the cart is removed, the system will either shut down or reboot. Mine usually reboots.
_________________
Don't sign your posts, it's dumb.
#73397 - Nushio - Sat Feb 25, 2006 9:04 am
| Quote: |
| Or you could just use the hole to read the key right out of the BIOS. I don't think it's illegal to simply call a piece of code the developers didn't expect you to. ;) |
I'd like to do that, it sounds like the easiest way out of this.
Now, I dont mind at all having the user power cycle every time he wants to unlock something (but I think the users would be a bit annoyed ;) )
| Quote: |
| If the DS is reading from a slot when the cart is removed, the system will either shut down or reboot. Mine usually reboots. |
If a homebrew program is loaded into the RAM, would it use the DScart even if I dont 'call' it? And even if i DO call it... Would it still reset AFTER i stopped doing whatever I want to do with the code I will probably get from the BIOS?
#73398 - olimar - Sat Feb 25, 2006 9:14 am
Last edited by olimar on Wed Aug 20, 2008 10:13 pm; edited 1 time in total
#73444 - Nushio - Sat Feb 25, 2006 7:35 pm
| olimar wrote: |
| If all you want to do is tell which DS card is inserted, you don't need to do any of the encryption stuff caitsith2 wrote about. Just pop in a card and read the header, which is unencrypted. No power cycling necessary. |
Alright, excuse my ignorance for a moment and allow me to ask...
Are headers from the same game different from each other? (This is just for mere info, I really dont mind if they are)
And how would I be able to read them, using say... PA_Lib, for example? :D
#73445 - olimar - Sat Feb 25, 2006 7:45 pm
Last edited by olimar on Wed Aug 20, 2008 10:13 pm; edited 1 time in total
#73577 - HyperHacker - Sun Feb 26, 2006 8:22 pm
Does anyone know how to actually boot the inserted card?
#73585 - olimar - Sun Feb 26, 2006 8:38 pm
Last edited by olimar on Wed Aug 20, 2008 10:14 pm; edited 1 time in total
#73769 - HyperHacker - Tue Feb 28, 2006 1:50 am
Do you have to if you haven't removed the DS card? I recall hbfirmware wouldn't boot mine if I started it from WMB even though I didn't remove the card; not sure if Download Play might just be disabling it so people can't easily copy the cards.
And does anyone know if it would somehow be illegal to just decrypt it using the key in the BIOS and run it? I fear such a thing might violate DCMA (does that apply in Canada?) given that you're not supposed to be able to read the BIOS.
#73821 - olimar - Tue Feb 28, 2006 6:46 am