Information For Anyone Who Wishes To Attempt Ds Emulation


Snu

Member
Joined
Jan 28, 2008
Messages
172
Age
42
Location
Oregon, USA
Website
www.snuq.com
note: i did not write this, and i know almost nothing about the DS, so don't go arguing any points with me.
this is from a reputable source who prefers to remain anonymous, and i cant guarantee any more contact with them.

QUOTE

For everyone in here wondering wether nintendo DS emulation is possible or not on the pandora, I believe it's perfectly possible. Here are some tips on how to do it which are based on common knowledge, and legally reverse-engineered information:

Everyone knows the DS runs on ARM9/ARM7, and the open specs of the machine are here:
http://nocash.emubase.de/gbatek.htm

Handling the ARM7:

The truth, though is that there is not any need to emulate the ARM7, since all nintendo DS games run pretty much the same ARM7 code, which handles sound, networking and some of the input. The protocol used to communicate ARM9<->ARM7 is also pretty standard and works through a 32k, swappable between both CPUs, shared memory area. Nintendo will probably release a Nintendo DS without ARM7 at some point, which contains a much simpler processor/firmware to handle what the ARM7 did, and without GBA compatibility.
So, in short ARM7 can be handled with HLE, intercepting the ipc area.

Handling the ARM9:

The ARM9 mainly does video and some math, through pretty high level registers similar to opengl API. I really don't know which CPU does the Pandora use, and the compatibility to the CPU in the DS. In the worst case, some interpreter work or dynamic recompiling will be needed.
In the best case, the ARM9 code can run natively in a virtual address space, and the register areas can be emulated by using memory protection (handle the registers at a pagefault).

So that's pretty much it! Hope it's useful.
 
When I see this:

QUOTE
Nintendo will probably release a Nintendo DS without ARM7 at some point, which contains a much simpler processor/firmware to handle what the ARM7 did, and without GBA compatibility.


I have some doubts about the reliability of the information. I don't think there's anything simpler and smaller than an arm7 core :) Anyway compared to the size of the rest of the SoC containing it, it's probably small enough that redesigning the SoC without it would not bring any significant cost reduction.
 
Not directed at you, but there's no reason why what he's saying shouldn't be countered or refuted here, if necessary.

I'll throw the usual "why virtualization has problems for emulating gaming platforms coded at a low level" sentiments, in addition to the "why virtualization takes flexibility away from emulation" ones. But that doesn't mean that more controlled methods (recompilation) can't work, especially if the Pandora is overclocked enough.

There's no way Nintendo is going to do a DS without the ARM7, the SDK code that uses it is part of the binary, not the firmware (and there are lots of SDK versions), and it's not like it can just put the same functionality on the ARM9 without sacrificing too much CPU that existing games will depend on.

No offense to the poster, but this kind of informed opinion holds very little weight unless the person has actually done DS emulation on an ARM device using these techniques (unlikely).. whatever he's done, I'm sure there are a significant number of people here who can match or surpass it.
 
Exophase said:
Not directed at you, but there's no reason why what he's saying shouldn't be countered or refuted here, if necessary.
i agree

Exophase said:
No offense to the poster, but this kind of informed opinion holds very little weight unless the person has actually done DS emulation on an ARM device using these techniques (unlikely).. whatever he's done, I'm sure there are a significant number of people here who can match or surpass it.
he is a licensed dev for the ds, along with other systems, and has worked on multiple games for them. he also is an experienced programmer, tho i dont know if he has ever written an emulator.

my (uninformed) guess on the possible removal of the arm7 would be due to a combination of size, cost, and power... like they removed the original gb hardware from the gb micro.
 
Last edited by a moderator:
Snu said:
note: i did not write this, and i know almost nothing about the DS, so don't go arguing any points with me.
this is from a reputable source who prefers to remain anonymous, and i cant guarantee any more contact with them.

QUOTE

For everyone in here wondering wether nintendo DS emulation is possible or not on the pandora, I believe it's perfectly possible. Here are some tips on how to do it which are based on common knowledge, and legally reverse-engineered information:

Everyone knows the DS runs on ARM9/ARM7, and the open specs of the machine are here:
http://nocash.emubase.de/gbatek.htm

Handling the ARM7:

The truth, though is that there is not any need to emulate the ARM7, since all nintendo DS games run pretty much the same ARM7 code, which handles sound, networking and some of the input. The protocol used to communicate ARM9<->ARM7 is also pretty standard and works through a 32k, swappable between both CPUs, shared memory area. Nintendo will probably release a Nintendo DS without ARM7 at some point, which contains a much simpler processor/firmware to handle what the ARM7 did, and without GBA compatibility.
So, in short ARM7 can be handled with HLE, intercepting the ipc area.

Handling the ARM9:

The ARM9 mainly does video and some math, through pretty high level registers similar to opengl API. I really don't know which CPU does the Pandora use, and the compatibility to the CPU in the DS. In the worst case, some interpreter work or dynamic recompiling will be needed.
In the best case, the ARM9 code can run natively in a virtual address space, and the register areas can be emulated by using memory protection (handle the registers at a pagefault).

So that's pretty much it! Hope it's useful.



for the ARM7 code i don't agree : it is true for commercial games but not for homebrews ....
for emulators it is not emulating code how take time , but emulate video ( saying by emulator's coders ;) )
so convert call list to openGL ES must take time i think ....
 
Last edited by a moderator:
Snu said:
he is a licensed dev for the ds, along with other systems, and has worked on multiple games for them. he also is an experienced programmer, tho i dont know if he has ever written an emulator.
I've encountered quite a number of DS devs, they are of course skilled at what they do and must know at least a certain amount about the hardware. Still, it's not necessarily enough to know for sure the ins and outs about DS emulation. One dev said it'd be well within the range of possibility to emulate DS on PSP, and I think this is pretty far off the mark.

Snu said:
my (uninformed) guess on the possible removal of the arm7 would be due to a combination of size, cost, and power... like they removed the original gb hardware from the gb micro.
The thing is, it's not just there for GBA compatibility, DS games really do use it in their normal operation. GBA games could not access any of the GB hardware in any way, save for the PSG hardware (which is partially emulated on the DS). Interestingly, it was actually almost conclusively proven that GB Micro does have GB hardware, it just doesn't have a way of interfacing with GB carts (lacks the voltage and cartridge pin arrangement). This is known because it's possible to crash one into rebooting into Gameboy Color mode.
 
Last edited by a moderator:
Exophase said:
Interestingly, it was actually almost conclusively proven that GB Micro does have GB hardware, it just doesn't have a way of interfacing with GB carts (lacks the voltage and cartridge pin arrangement). This is known because it's possible to crash one into rebooting into Gameboy Color mode.
That's stupid of Nintendo. Why include the Z80 instead of removing it and making it smaller/less expensive? :unsure:
 
Last edited by a moderator:
atomicthumbs said:
That's stupid of Nintendo. Why include the Z80 instead of removing it and making it smaller/less expensive? :unsure:
Why redesign an already working chip at great cost and potentially introduce more bugs into the core? Seriously, a Z80GB is not that complicated and won't have cost much to do. Any smaller and the Micro wouldn't be usable anyway.
 
Last edited by a moderator:
I know of several homebrew applications which handle mp3 decoding, wifi, and similar functions entirely on the arm7, implemented in different ways oftentimes. Not emulating the arm7 let some official games play, but would keep many homebrews from working!
 
Back
Top