Hacking DSTwo (and other flashcards) accessing the additional RAM of the 3DS

[kerneldev]

Hi,

I've asked for information at the DSTWO forum, without much look save for vague answers which seemed mildly misinformed about OS internals and how MMU works (and more or less confused mixture of mentions to virtualization and unrelated concepts).

I've got a 3DS recently, and being more of a coder rather than a gamer I obviously looked for the available capabilities (after all, the 3DS is still much cheaper than a Pandora device). I've got a DSTWO and recently I proposed developing an improved fork of Lameboy if the original developer provided the source code under the GPL. However, I've so far got no satisfactory answers for my question about the extra RAM available in the 3DS.

1. Are there any details on the 3DS and/or DS MMU? How the firmware handles memory management with the architecture/processor, etc.
2. The DSTWO is a DS card, therefore it should behave just like any other DS card memory-wise. Is there any limiting factor that would prevent the extra RAM from being used by DS cards (homebrew, mostly)? For instance, I would appreciate having details about how the old Slot 2 RAM expansion packs worked (I suppose the DS firmware had ABI to enable those and it was called from the homebrew/flash card software when necessary).
3. Is the architecture used to run 3DS games the same as DS ones? Meaning, same MMU, same RAM banks accessed, etc.
4. How can we test from a DS homebrew how much RAM is available in the system? (besides running a sequential allocation program until it hangs or reports -ENOMEM, or whichever error happens when a DS/3DS application runs out of memory, if any at all).

Thanks in advance. Since It's my first message in the forum I would like to avoid sounding harsh, but I would prefer that people who aren't familiar with these concepts at technical level abstain from replying.

I would like to keep noise to a minimum so this issues can be discussed clearly and sorted out as soon as possible. Since one of my would-be projects involves emulation, accessing the extra RAM is key to succeed in emulating complex platforms (or even support current emulators, like Scumm VM a bit better to do image scaling).

 

[CollosalPokemon]

Wait what? The DSTWO do NOT use the 3DS's addition RAM. No one truly knows if the architecture to run 3DS games is different than DS ones BUT it's a very, very high chance it is different. The reason is (aside from a very recent accomplishment by neimod) no one has ever seen what the 3DS does with its RAM or running anything.

Sanboxing would prevent extra RAM on DS cards. gl hacking through the sandbox, it was never done with the DSi so I can't imagine the 3DS being any easier.

For the DSTWO, if I remember right, 16MB RAM is available. However it does NOT use the 3DS's RAM to increase from DS RAM so 16MB is your maximum amount with it aside from a 1 to 1000000 chance you can hack through the sandbox.

 

[kerneldev]

You're not answering any of the questions with factual information. Could you please reason your response?
Where does your "1 to 1000000 chance" probability come from? ;-)

I don't think you understand the technical scope of the question, no offense meant here.
So where can I find the hardcore reverse engineering people here? The ones speaking the right lingo.

 

[CollosalPokemon]

You're not answering any of the questions with factual information. Could you please reason your response?
Where does your "1 to 1000000 chance" probability come from? ;-)

I don't think you understand the technical scope of the question, no offense meant here.
So where can I find the hardcore reverse engineering people here? The ones speaking the right lingo.

"1 to 1000000 chance" is an exaggeration but if you're serious about working on things, there's only been 1 "hardcore reverse engineering" person so far who's actually shown his work with the 3DS. That would be neimod. (http://www.flickr.com/photos/neimod/)

All I was saying is the DSTwo does not use the 3DS's additional RAM. Currently it is difficult accessing the extra RAM available on the 3DS through homebrew or DS mode. If it was so easy, it would have already been done already for the public.

I am pretty confident you know about sandboxing, if you are as smart as you implied with your previous post. I should not need to tell you that DS cards are sandboxed, which is the "limiting factor that would prevent the extra RAM from being used by DS cards" . In my previous post, I said the sandbox between DS and DSi modes have yet to be broken. Honestly, it would be hard to imagine the sandbox between DS and 3DS modes to be any easier to break.
Of course, DSi mode has more RAM access than DS mode, and 3DS mode has more RAM access than DSi mode. It is unlikely a DS flash cart could access the extra RAM of the 3DS...

 

[DiscostewSM]

Actually, I thought the DSTWO had 32MB of RAM on its SoC. Might be wrong. As far as what the DSTWO can see on the 3DS, it'll only see what it would with either a regular DS or DSi, since the 3DS sets itself under virtualization mode.

 

[kerneldev]

Could you name sources and references for the information?
Specifications for instance would be nice. There must be something technical (meaning not hearsay, but information that can be verified independently).
One problem with the homebrew scene is that there are very few places to look for information free of fluff, and the signal/noise ratio can be horrible sometimes.

Anyhow back on topic, soo how does the MMU operate then? How does it decide the amount of RAM the DS cartridge gets? From the lack of definitive answers it isn't clear which upper limit is applicable then.

Let me give you a scenario to ponder and tell me how it would work (just so I can understand we are in sync:
You have the original Nintendo Browser for DS. You load the cartridge in the 3DS. How much RAM does it see? 4MB? 8MB? 32MB?
What if it is the DSi version?

You're not answering any of the questions with factual information. Could you please reason your response?
Where does your "1 to 1000000 chance" probability come from? ;-)

I don't think you understand the technical scope of the question, no offense meant here.
So where can I find the hardcore reverse engineering people here? The ones speaking the right lingo.

"1 to 1000000 chance" is an exaggeration but if you're serious about working on things, there's only been 1 "hardcore reverse engineering" person so far who's actually shown his work with the 3DS. That would be neimod. (http://www.flickr.com/photos/neimod/)

All I was saying is the DSTwo does not use the 3DS's additional RAM. Currently it is difficult accessing the extra RAM available on the 3DS through homebrew or DS mode. If it was so easy, it would have already been done already for the public.

I am pretty confident you know about sandboxing, if you are as smart as you implied with your previous post. I should not need to tell you that DS cards are sandboxed, which is the "limiting factor that would prevent the extra RAM from being used by DS cards" . In my previous post, I said the sandbox between DS and DSi modes have yet to be broken. Honestly, it would be hard to imagine the sandbox between DS and 3DS modes to be any easier to break.
Of course, DSi mode has more RAM access than DS mode, and 3DS mode has more RAM access than DSi mode. It is unlikely a DS flash cart could access the extra RAM of the 3DS...

 

[CollosalPokemon]

Could you name sources and references for the information?
Specifications for instance would be nice. There must be something technical (meaning not hearsay, but information that can be verified independently).
One problem with the homebrew scene is that there are very few places to look for information free of fluff, and the signal/noise ratio can be horrible sometimes.

Anyhow back on topic, soo how does the MMU operate then? How does it decide the amount of RAM the DS cartridge gets? From the lack of definitive answers it isn't clear which upper limit is applicable then.

Let me give you a scenario to ponder and tell me how it would work (just so I can understand we are in sync:
You have the original Nintendo Browser for DS. You load the cartridge in the 3DS. How much RAM does it see? 4MB? 8MB? 32MB?
What if it is the DSi version?

You're not answering any of the questions with factual information. Could you please reason your response?
Where does your "1 to 1000000 chance" probability come from? ;-)

I don't think you understand the technical scope of the question, no offense meant here.
So where can I find the hardcore reverse engineering people here? The ones speaking the right lingo.

"1 to 1000000 chance" is an exaggeration but if you're serious about working on things, there's only been 1 "hardcore reverse engineering" person so far who's actually shown his work with the 3DS. That would be neimod. (http://www.flickr.com/photos/neimod/)

All I was saying is the DSTwo does not use the 3DS's additional RAM. Currently it is difficult accessing the extra RAM available on the 3DS through homebrew or DS mode. If it was so easy, it would have already been done already for the public.

I am pretty confident you know about sandboxing, if you are as smart as you implied with your previous post. I should not need to tell you that DS cards are sandboxed, which is the "limiting factor that would prevent the extra RAM from being used by DS cards" . In my previous post, I said the sandbox between DS and DSi modes have yet to be broken. Honestly, it would be hard to imagine the sandbox between DS and 3DS modes to be any easier to break.
Of course, DSi mode has more RAM access than DS mode, and 3DS mode has more RAM access than DSi mode. It is unlikely a DS flash cart could access the extra RAM of the 3DS...

There is good information on www.3dbrew.org about what is currently known about the 3DS. Granted anyone can modify the text on pages but it has been accurate so far, as there are *some* tools made with the information.

Also, if you look at the DSTwo's website you will see it has onboard CPU, which enables it to have more RAM capability than normal DS mode carts have. (http://eng.supercard.sc/manual/dstwo/faq.htm - some information on onboard CPU) There are also other places to look at more specific specifications for the DSTwo I think.

The DS Web Browser card should see a little more than 4MB RAM (it is expanded by an additional card in the GBA slot) while the DSi Web Browser might use a little more RAM than the DS Web Browser.
I don't think the DSi Web Browser was given access to see *all* of the RAM on the DSi (12MB I think) but maybe 8-10MB. It seems the 3DS web browser is hardly allowed any RAM compared to how much RAM the 3DS has.

 

[FAST6191]

As I understand it.
The DS browser is a combined GBA slot device and DS slot card with the browser on it. If you take the rom image of the DS cart you can patch it to use GBA slot ram from GBA flash carts that have it.
The DSi and 3ds browsers are different and run in DSi mode (it is a DSi shop download) and 3ds mode respectively (what levels/restrictions each has is unknown at this point in terms of browser sandboxing vs the main menu, game mode and such) at which point they do have access to at least some of the extra ram. Should you stick a DS browser DS card in one I believe it just says give me some ram please. This is also somewhat somewhat redundant or academic depending on your outlook on life as we do not have anything in the way of 3ds homebrew so you can consider it a DS (if you will allow an analogy think the difference between PS3 proper and the old limited PS3 linux or even PS3 blu ray java) and DSi stuff is not much better (there were a couple of DSiware save exploits now and forever closed http://dsibrew.org/wiki/DSiWare_VulnList and the cycloDSi that few will advise you getting so you are pretty much limited to buying in old hardware if you can find it or an outdated flash card).

The iplayer/iSMM and DSTwo as others have said have mini system on a chip style devices with ram actually in the DS cart itself (I did pull up the chip specs/manual for the iSMM/iplayer a few months back) unlike all the others out there (some programs like moonshell attempted a kind of virtual memory/page file/swap space using DLDI but it only had limited benefits for certain scenarios much like it does everywhere and commercial roms use overlays (homebrew can swap chunks out at will so that is better I guess but besides the point)) which when combined with the extra CPU can be used to boost abilities. I have not paid too much attention to programming these devices but what I did see what that trying to combine DS ram and enhanced flash cart ram it got to be tricky (IO/throughput, latency, management.... take your pick all leading to race conditions) so for the most part coders use one or the other kicking a simple loop to one and piping back data/imagery as necessary.

3. I would love to know the answer to that- on the one hand what little is known ( http://www.3dbrew.org/wiki/Hardware is probably the best info source right now) points much of the software side of things being very similar to the DSi, GC, wii and to some extents DS before it so that might be an indicator of something (you probably know as well as I engineers and programmers are loathe to create anything truly new) but on the other hand there have been rumblings of a separate data and executable section (modified Harvard architecture might be a bit strong but same parties) although that could just be a background menu being kept apart from the game.

4. Ignoring the enhanced flash cart stuff for a moment Lick's ram API which is probably what you will be using for GBA slot extra memory (several programs make use of it but you might want to look at quake II), regular DS I am afraid I either code for in ASM (usually for purposes of game hacking) or using something that more or less manages memory for you (I thought I would try learning python and well there is a python port https://www.develer.com/trac/dspython/ ) but I imagine there is something in there somewhere, enhanced flash carts seem to not manage memory that well (poke around some of the changelogs- most seem to be hunting memory related bugs that would probably not exist if proper management was doable). The 32 megs of GBA slot memory was mapped to memory in DS mode as the 08000000 to 09FFFFFF (hex naturally) which is the same as the GBA although that had higher waitstate mirrors of the memory. It is probably of no use at all to you but in the everything and the kitchen sink spirit of things the EZ3 SDK http://ezflash.sosuke.com/viewtopic.php?t=150 has a little bit on the internals of the EZ3 (and so the EZ4 and to a lesser extent the EZ3 in 1 which is the dominant expansion pack these days).

Also in case you had not seen it http://nocash.emubase.de/gbatek.htm (as that page does not seem to be playing ball right now you can find it http://www.romhacking.net/documents/217/ among many other places). I believe that link also goes somewhat further to taking care of 1 and 2 as well but there is a tiny bit on the DSi as well http://dsibrew.org/wiki/Memory but I will say DS mode is not that far off the likes of real mode back on pre pentium hardware with the DS firmware (just the menu, user settings and basic bootup really) and BIOS (a bit more although it only really provides a few software interrupts that can write memory as part of their function (stuff like decompression) but are not even the only method to do it by) doing very little/nothing in terms of management (hell there are barely any safeguards against writing to/reading from areas not mapped for such and most of those are more intended to stop the bios being read)- any checks are the fault of the programmer or the compiler.

Hopefully you get something from that waffle.

 

[kerneldev]

FAST6191, rock on. Thanks for the lengthy message.
I'll reply ASAP.

I got my 3DS by the way, it seems it doesn't use emulation by any means, games run native I think, so the connection between 3DS-DS has no airgap, but it isn't "privileged" either. I think the firmware is what decides what can be accessed when in DS mode. If that ever gets hacked... then it would be neat.

 

[Chaosruler]

Hi,

I've asked for information at the DSTWO forum, without much look save for vague answers which seemed mildly misinformed about OS internals and how MMU works (and more or less confused mixture of mentions to virtualization and unrelated concepts).[DSTwo's kerenel, like every other Supercard code, is nearly 100% copy of some other code, it's obviously based on Acekard RPG's kerenel]

I've got a 3DS recently, and being more of a coder rather than a gamer I obviously looked for the available capabilities (after all, the 3DS is still much cheaper than a Pandora device)[However Pandora device has a lower build quality and is a linux based device, meaning it's open source, so no interesting back-enginerring there, if I were you I'd go for the PSP\Vita, it's slightly more powerfull]. I've got a DSTWO and recently I proposed developing an improved fork of Lameboy if the original developer provided the source code under the GPL. However, I've so far got no satisfactory answers for my question about the extra RAM available in the 3DS.[a rear look at the arch would tell you this much: the extra RAM available on 3DS is used WHILE running roms, how can I tell that? 3DS got more space then any cart to hold cheat codes, which are basically commands to change the RAM addresses values, you need ramspace to hold that, normally a rom would take nearly all the DS(!) RAM and leave a tiny bit for some known reason I don't want to expand, the point is the cheats are ran there, DSTwo got at least 2MB more space then any other cart, and it's no efficency of OS, since the game iself even the lowest marking one requires at least 3.4MB of RAM, with that in bet, since the processor chip ID was released, the hardware seems very similar to the Dingo, again I would bet my ass its based on it, meaning 32MB of DRAM and 360 MHz MIPS processor (2k cache) hence why so much dingoo apps were recoded to the DSTwo]

1. Are there any details on the 3DS and/or DS MMU? How the firmware handles memory management with the architecture/processor, etc. [With 3DS we are obviously clueless, the best we got is save-hacking with DSi as far as I am informed, but with DS, it's where the whole hacking process started - the RAM, examining it learning how the firmware handles the system, hence it's a soft hack]
2. The DSTWO is a DS card, therefore it should behave just like any other DS card memory-wise. Is there any limiting factor that would prevent the extra RAM from being used by DS cards (homebrew, mostly)? For instance, I would appreciate having details about how the old Slot 2 RAM expansion packs worked (I suppose the DS firmware had ABI to enable those and it was called from the homebrew/flash card software when necessary). [About slot 2, I am very sure it is ABI, exactly like you guessed, with DS card memory-wise? seeing as Pokemon games includes all kind of hardware built in along with extra RAM to the cart, I suppose the cart is not limited by software\firmware but by hardware and electrical current, meaning you can't make the total resistors on the cart exceed X unless you want to fuck the cart\DS\3DS like you would by using a low quality R4 copy that had a bad hardware and would short your device, note that on the GBA era, pokemon were one of the first games to use wireless GBA communication by using an exterenal [!] device that would connect to the GBA cart]
3. Is the architecture used to run 3DS games the same as DS ones? Meaning, same MMU, same RAM banks accessed, etc. [impossible to tell, it might even be exactly like this but encrypted, it might be based on it, it might be different at all, my bet is, since you can exit DS mode to 3DS menu, option you didn't have on the DS without a flashcart, that it is at least based on it, but a tiny chance would be if it were using most of the DS handling code and we wouldn't be able to track back RAM management on the 3DS, I myself don't have a 3DS to track it but I imagine enough hackers attempted to, if they didn't succeed, it means it's using part of the code or it's using a similar idea code like the Wii does to emulate the NES\SNES with a whole different arch, on this case it's a whole bet]
4. How can we test from a DS homebrew how much RAM is available in the system? (besides running a sequential allocation program until it hangs or reports -ENOMEM, or whichever error happens when a DS/3DS application runs out of memory, if any at all). DS Homebrew wouldn't require DSTwo's hardware therefore it wouldn't read or know how to read the DSTwo's hardware, DSTwo has an SDK, I would use it to build the homebrew or find one built already that uses the DSTwo's hardware to read `em and to know how to read `em, also overbuffing the 3DS or DS while running a flashcart would not work, neither Nintendo or flash cart developers are that stupid anymore]

Thanks in advance. Since It's my first message in the forum I would like to avoid sounding harsh, but I would prefer that people who aren't familiar with these concepts at technical level abstain from replying.


I would like to keep noise to a minimum so this issues can be discussed clearly and sorted out as soon as possible. Since one of my would-be projects involves emulation, accessing the extra RAM is key to succeed in emulating complex platforms (or even support current emulators, like Scumm VM a bit better to do image scaling).
again, SDK, it's not so easy to use their gibberish and single-wall-of-text SDK, but without it your out of hand, you can't use DS and DSTwo's or 3DS's processors to coproceassor each other since they don't sync their code, they send their results, that's it, meaning you could either use DSTwo's or 3DS or DS hardware to emulate, on 3DS you should get back to it after the system is hacked, since the DSTwo is more powerfull then the DS hardware-wise then by all means use DSTwo's SDK

 

[kerneldev]

Damn it, now I have to reply to you both in depth.

OK, so I'm going to write a quick test for the RAM and see what's the real situation there. Regarding the DSTWO, I wouldn't be surprised if they had cloned parts of a different flashcart. There's a reason Chinese developers are infamous for plagiarizing technology, or each other for that matter. Shame because they have the skills to do something good most of the time, they are just cheap. I wish the DSTWO developers werearound to listen for comments and requests, and I don't talk the slightest Chinese. They are also screwing up with the GPL in some cases, failing to release source code for stuff like the GBA emulator, etc.

---

 

[FAST6191]

Regarding the extra hardware for pokemon and such (I was not aware of any extra memory) that is fairly well documented on the GBA as a case of the GPIO being used (if you have GBAtek up there gbatek.htm#gbacartioportgpio )
The DS stuff was hooked into the save memory side of thing which is why we could not dump saves using the more traditional save dumping tools unless we physically bypassed the chip- http://gbatemp.net/topic/215641-pokemon-soul-silver-sav-tofrom-cartridge-success/ (hardware and software methods eventually caught up). Also some more on gbatek but not quite as useful.
Oh and the stuff I mentioned on the iSMM ram chips http://gbatemp.net/topic/282582-ismart-mm-exactly-the-same-as-supercard-dstwo/ (warning- large images with no thumbnails on my part) although most SDK type things will abstract it.

As for the browser being detected (and working) and an exception being made in the in what passes for a hypervisor on the DSi/3ds as opposed to simply erroring out or jumping to the browser proper then if indeed it is the case I should be quite curious if for no other reason than the browser should be pre any additional checks ( http://hackmii.com/2010/02/lawsuit-coming-in-3-2-1/ - short version the DS and DS lite did basic checks where the DSi and 3ds have proper hashes/checks in later roms and whitelist the earlier ones with the hack being a bait and switch/failure to check overlays properly and hooking one as soon as the game boots to load the cart menu).

 

[Chaosruler]

Damn it, now I have to reply to you both in depth.

OK, so I'm going to write a quick test for the RAM and see what's the real situation there. Regarding the DSTWO, I wouldn't be surprised if they had cloned parts of a different flashcart. There's a reason Chinese developers are infamous for plagiarizing technology, or each other for that matter. Shame because they have the skills to do something good most of the time, they are just cheap. I wish the DSTWO developers werearound to listen for comments and requests, and I don't talk the slightest Chinese. They are also screwing up with the GPL in some cases, failing to release source code for stuff like the GBA emulator, etc.

---