Ds Emulator Interface
- Thread starter Reknel
- Start date
@Reknel: You have some attitude problems and need to fix those.
1. Everything isnt about you, you need to understand that people dont joke to make you look like a retard, there is lots of hypothesises that humans invented jokes to deal with things feelings. In this case I guess the thread pissed people off a little, so they joked to deal with it.
2. Understand when you have done something wrong and apologize. People dont have any issues with others doing wrong or making something stupid (a few exceptions) at all as long as the person apologize for it.
Your response to all jokes to avoid flaming(and make yourself look as a retard, cause the OP actually didnt do that) should have been something like:
"Wups my bad, sorry. but I read some posts about that fitting the screens was the only problem, I didnt understand they werent serious, its hard to read sarcasm on the internet"
But your way of responding only tries to make your acting correct by implying ALL of us others did wrong.
I have made this mistake myself several times, even here on this forum, diffrence is I understood that I might have done something wrong.
1. Everything isnt about you, you need to understand that people dont joke to make you look like a retard, there is lots of hypothesises that humans invented jokes to deal with things feelings. In this case I guess the thread pissed people off a little, so they joked to deal with it.
2. Understand when you have done something wrong and apologize. People dont have any issues with others doing wrong or making something stupid (a few exceptions) at all as long as the person apologize for it.
Your response to all jokes to avoid flaming(and make yourself look as a retard, cause the OP actually didnt do that) should have been something like:
"Wups my bad, sorry. but I read some posts about that fitting the screens was the only problem, I didnt understand they werent serious, its hard to read sarcasm on the internet"
But your way of responding only tries to make your acting correct by implying ALL of us others did wrong.
I have made this mistake myself several times, even here on this forum, diffrence is I understood that I might have done something wrong.
Reknel said:
Yes, that how it works. But, you forgot one thing. Both Nintendo DS and Pandora are ARM-based. So we dont realy need to translate mashine code, because it is already ARM code. What we are realy need is some form of Partial Virtualisation. But there is still a problem. Even if we can run ARM code on pandora we still need to emulate other peripherals like 3D cop, input sound wifi etc. The second problem that we need to run MULTIPROCESSING code on SINGLE processor. Well, the good thing is that Licensed Nintendo DS Developers Can use only 1 kernel (ARM9) The code that is running on ARM7 kernel is just IO system libraries, means, sound, touchsccreen, buttons, mike, etc (But i dunno if they running from BIOS ROM and are always constant, or they linked with the game and updated with the new versions of NITRO SDK (Official DS SDK)). So, the ARM7 code behavior can be predicted and multiprocessing work can be tuned well. The main work (if emulator project ever be started) will go at four directions:
1)Paravirtualisation (partial virtualisation) of ARM code
2)Solving the two cpu problem
3)Solving problems with possible "hacked" code (nerdy code, written with knowing ds hardware perfomance and timing capabilities and such shitty to emulate)
4)Solving problems with periphereal emulation
The last two are still pain in the ass even for current up-to-date DS emulators on PC.
PS. For guys, who interested in this there are full hardvare specification
Last edited by a moderator:
rabidpoobear
Active Member
I know this is rather confusing but there are actually a lot of different ARM instruction sets.apexsol said:
We use the ARMv7 instruction set and the ARM7 uses the ARMv3 instruction set. Not sure what the ARM9 uses.
Anyway, so it's not quite that simple. Unless ARMv7 is fully backwards-compatible with whatever the 2 DS processors use.
Last edited by a moderator:
rabidpoobear
Active Member
You quoted the ARM article out of context.
rabidpoobear said:
Last edited by a moderator:
Exophase
Nothing good will ever come of Exophase.
apexsol said:
You linked interpretation to translation. Interpretation is not translation (common error though). There's a big difference between compilation and execution. A dynamic recompiler is a translator/compiler, which changes program code from one language to another. An interpreter transforms computational state by executing a program. When running native code a CPU is behaving as the program interpreter in hardware. When running an interpretative emulator a software program is behaving as the program interpreter. In effect interpretation is being done twice here.
apexsol said:
The paravirtualization you describe is impossible. ARM7 only abstracts some of the hardware - and its interface is itself through hardware (IPC and shared memory), not function calls that can be detected and recompiled statically. 3D and gamecard in particular are both accessible from the ARM9. DS emulation absolutely requires low level hardware emulation.
ARM7 HLE may be possible, and that would apply to any kind of DS emulator, but it's not that interesting when ARM9 tends to consume a lot more CPU time than ARM7. Instead of full HLE just detecting/patching a few common inner blocks in a recompiler would be a lot simpler.
Full Virtualization has several compatibility obstacles and feature limitations that make it undesirable. These are things I've mentioned in several other posts and won't go into here. So let's pretend that virtualization ends up working. The real driving difference in performance between virtualized code and good recompiled code is how much overhead there is in memory accesses. With virtualization accesses to simple memory regions are much faster but accesses to I/O regions or anything with side effects are much slower. DS games can and do access these I/O regions a lot - some push a lot of data to the 3D unit through the CPU directly (hundreds of thousands of writes per second). When this happens you have to go through Linux's exception handler then signal callback then decode and emulate the instruction to see what to do with it. Injecting interrupts, especially frequent ones like hblank, sounds even more problematic - I'm not sure you'd even be able to do it reliably (what happens if you get an interrupt while you were in the middle of emulating a hardware access for instance.. those were supposed to be atomic)..
Punting Linux would make things slightly more doable but I think once you were on raw OMAP3 metal you'd quickly regret it. Especially if you wanted to use the SGX for something.
BTW, 3D geometry and rasterization emulation is the real performance killer. Expecting to do that with 3D acceleration is a whole different can of worms that has serious problems (and hence why No$ then desmume moved away from that idea)
Last edited by a moderator:
Phawx
Professional Derailer
- Joined
- Oct 1, 2008
- Messages
- 1,345
@Exophase I'm not sure what any of that has to do with properly displaying two screens on Pandora's screen. The real problem we have now is the DSi XL. How would we fit two of those monsters on one Pandora screen? I mean now ONE of the DSi XL screens is basically the same size as the Pandora screen.
We are completely boned. You should probably scrap you DS emulator you were making for the Pandora. Probably better to work on the 3DO one anyway.
We are completely boned. You should probably scrap you DS emulator you were making for the Pandora. Probably better to work on the 3DO one anyway.
Exophase
Nothing good will ever come of Exophase.
Phawx said:
What are you talking about? I'm working on a Gamecube emulator.
Last edited by a moderator:
Loonie
Active Member
- Joined
- Apr 1, 2003
- Messages
- 753
Guys, please don't deviate from the subject.
Clearly the way forward is to alternate the DS screen being rendered every scan line, and use a complex set of refracting glasses to create a composite of two whole separate displays to the retina. I know, "what if the user moves their head". Well, simply employ a high-resolution 3-axis gyro in the glasses to detect player head movement. The Pandora could take the gyro data and recalculate the offsets, then adjust the scan line rendering accordingly.
Clearly the way forward is to alternate the DS screen being rendered every scan line, and use a complex set of refracting glasses to create a composite of two whole separate displays to the retina. I know, "what if the user moves their head". Well, simply employ a high-resolution 3-axis gyro in the glasses to detect player head movement. The Pandora could take the gyro data and recalculate the offsets, then adjust the scan line rendering accordingly.
Mr.Confuzed
stoked and confused
Ha! I knew it!Exophase said:
Last edited by a moderator:
Exophase
Nothing good will ever come of Exophase.
Jourdy288 said:
Yeah, it's really hard to emulate those mini-DVDs that Gamecube games came on when they have special chips inside them. Fortunately the games were usually designed with the extra chip capability optional as they usually stopped working within 3 seconds of play.
Last edited by a moderator:
fusion_power
Advanced Member
You are soooooo Mean! :lol:Exophase said:
Last edited by a moderator:
fusion_power
Advanced Member
No, you need one Pandora and one TV and one TV-Out Cable, nothing could be more easy I guess. I think its the most logic way if you don't want 2 tiny-non-strechts DS Screens onto the Pandora.SomeGuy99 said:
Last edited by a moderator:
Exophase
Nothing good will ever come of Exophase.
SomeGuy99 said:
Or at slightly lower cost, one Pandora and one DS.
Last edited by a moderator:
Pickle
Mega GP Mania
I read cube, does that mean compiz works :-O
What an excellent idea! That way you'd have one extra screen on the DS that you could use to display web pages or something.Exophase said:
Or you could connect that screen to another Pandora, and emulate two DSes! Now we have multiplayer!
Last edited by a moderator:
