Ds Emulator Interface


Willrandship said:
I always imagined that if an emulator was made (whether technical issues exist or not) you could just resize the screens to, say, 75% of their original size. They would still be side by side, allowing for a small HUD for emulator controls on the bottom.

Think this:
---------------------Pandora Screen------------------------------
|........................................................|........................................................|
|........................................................|........................................................|
|...............DS Screen 1..................|.................DS Screen 2................|
|........................................................|........................................................|
|........................................................|........................................................|
---------------------------------------------------------------------
Save State|Load State|Load ROM|Close/Open Lid|Settings|Exit

The reason I included the Close Lid option is that Phantom hourglass requires it to close for one point in the game. Other games might also implement some such anti-emulation feature.

Pandora has a lid-close sensor :)
 
Last edited by a moderator:
@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.
 
Reknel said:
So... nice! The original idea was about how to fit the DS screens in the pandora display in a "playable" manner. Responses have been only a lot of stupid comments trying to be funny eventhough they are not. Besides, since someone has on mind a Dreamcast emulator and a PSP one for the pandora (Check the Pandora Wiki, it's fucking true) why couldn't there be a DS emulator too? Everyone knows Dreamcast and the PSP are far more powerful and have better graphics. The 7x rule of Mhz needed for emulation doesn't always apply, you Exophase should know especially. In a post not so long ago applying that rule you said that the pandora would need about 4000 Mhz or something. Yeah... like many computers have that much frequency.

A little explanation of why it is IMPOSSIBLE according to you might have been good instead of pointing at newcomers calling them noobs and making fun of them. Who knows, maybe in three or four years a new pandora board will be made and DS emulation will not only be possible but it will even run twice the fullspeed.

But you know what? That's a nice way of attracting people to your open source community. Next time EvilDragon says at Cebit or someplace else how "wonderful" your community is I'll ask him: What about the lame elitist bunch of jerks that instead of welcoming they laugh at you and call you noob just for posting a simple idea? Is that wonderful too?

It's not that I was asking for a Dragon Age port, was I?And if I had, so what? A little nice advice and three fucking lines saying "Not possible because..." would have been fine. But you know, keep doing that to newcomers, I'm sure the community will grow SOOOO MUCH. I should have expected it anyways, anything that has a "Tux" or "GNU" or "K" or whatever other bullshit is doomed to have a shitty community of elitist fuckers that think they are better just because they use Linux distro Nº156164687. And I bet that from the 20000 or something users in these forums not even a third of you know jack about programming or computers, you will be all licking the butts of the few ones that do. You are just like all the other freetard communities out there, always spitting on others. It's a shame, because some people in these forums are actually nice people. They'd be better of in another kind of community. I was thinking of getting a pandora but I might as well get an iPhone and an iControlPad.


Farewell, LUSERS =)


PS: I have a low-end computer and DS emulation doesn't take too much CPU power. In fact it rarely rises above 20% CPU usage, it's always around 15%. And the pandora has more than enough memory to spare for it.


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:
apexsol 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.
I know this is rather confusing but there are actually a lot of different ARM instruction sets.

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 said:
apexsol 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.
I know this is rather confusing but there are actually a lot of different ARM instruction sets.

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.

The ARM Instruction Architecture is constantly improving to meet the increasing demands of leading edge applications developers, while retaining the backwards compatibility necessary to protect investment in software development.

The ARM 32-bit ISA is also supported in the Cortex™-A and Cortex-R profiles of the Cortex architecture for performance critical applications, and for legacy code. Most of its functionality is subsumed into the Thumb-2 instruction set, which also benefits from improved code density

from

http://www.arm.com/products/processors/technologies/instruction-set-architectures.php
 
Last edited by a moderator:
You quoted the ARM article out of context.

rabidpoobear said:
We use the ARMv7 instruction set and the ARM7 uses the ARMv3 instruction set. Not sure what the ARM9 uses.

The ARM 32-bit instruction set is the base 32-bit ISA used in the ARMv4T, ARMv5TEJ and ARMv6 architectures. In these architectures it is used in applications requiring high performance, or for handling hardware exceptions such as interrupts and processor start-up.

The ARM 32-bit ISA is also supported in the Cortex™-A and Cortex-R profiles of the Cortex architecture for performance critical applications, and for legacy code. Most of its functionality is subsumed into the Thumb-2 instruction set, which also benefits from improved code density
 
Last edited by a moderator:
rabidpoobear said:
You quoted the ARM article out of context.

rabidpoobear said:
We use the ARMv7 instruction set and the ARM7 uses the ARMv3 instruction set. Not sure what the ARM9 uses.

The ARM 32-bit instruction set is the base 32-bit ISA used in the ARMv4T, ARMv5TEJ and ARMv6 architectures. In these architectures it is used in applications requiring high performance, or for handling hardware exceptions such as interrupts and processor start-up.

The ARM 32-bit ISA is also supported in the Cortex™-A and Cortex-R profiles of the Cortex architecture for performance critical applications, and for legacy code. Most of its functionality is subsumed into the Thumb-2 instruction set, which also benefits from improved code density


ARM7 in nintendo ds is ARM7TDMI, which uses ARMv4T version of instruction set.
 
Last edited by a moderator:
apexsol 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.

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:
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

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:
@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.
 
Phawx said:
@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.

What are you talking about? I'm working on a Gamecube emulator.
 
Last edited by a moderator:
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.
 
Mr.Confuzed said:
Exophase said:
What are you talking about? I'm working on a Gamecube emulator.
Ha! I knew it! :p
But what about games with those special chips inside like Starfox?
 
Last edited by a moderator:
Jourdy288 said:
But what about games with those special chips inside like Starfox?

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:
Exophase said:
Jourdy288 said:
But what about games with those special chips inside like Starfox?

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.
You are soooooo Mean! :lol:
 
Last edited by a moderator:
What the hell?! This thread is crazy and stupid.

If you want to emulate a DS, you need two Pandoras.
 
SomeGuy99 said:
What the hell?! This thread is crazy and stupid.

If you want to emulate a DS, you need two Pandoras.
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.
 
Last edited by a moderator:
SomeGuy99 said:
What the hell?! This thread is crazy and stupid.

If you want to emulate a DS, you need two Pandoras.

Or at slightly lower cost, one Pandora and one DS.
 
Last edited by a moderator:
Exophase said:
SomeGuy99 said:
What the hell?! This thread is crazy and stupid.

If you want to emulate a DS, you need two Pandoras.

Or at slightly lower cost, one Pandora and one DS.
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.
Or you could connect that screen to another Pandora, and emulate two DSes! Now we have multiplayer!
 
Last edited by a moderator:
Back
Top