Pandora outdated?


levi

Still fresh, damnit!
Joined
Oct 6, 2008
Messages
13,709
Location
Somewhere off the coast of the EU
Quite a lot of old systems had multiple general purpose CPUs on board. For example the Megadrive/Genesis had a 68000 and a Z80 coprocessor, although I don't know how much the latter was used in practice outside of the Master System adaptor. Similarly, the DS has an ARM9 and an ARM7 coprocessor, the latter used for GBA compatibility in the original models, and also to handle sound and wi-fi for DS games, according to wikipedia. Like the Megadrive, the Saturn also contained a Megadrive processor, although clocked a little faster and this time handling sound duties, alongside the twin SH2 main processors and two video processors, a peripheral controller and one SH1 processor, although that was tasked with handling the CD drive only, so probably not applicable to an emulator.


Emulators have handled running sounds at the same time as gameplay since pretty much forever, but emulating sound on the same processor as the game does slow the game down, as seen with a number of early emulator releases on the Pandora. But it seems to me that if you can run separate emulated cores on separate processors it's likely to make writing those emulators well and maintaining them simpler (although perhaps I'm underestimating what you can do with multithreading these days).


On another note, since dynamic recompiling seems to be one of the latest emulation techniques, couldn't one core handle dynamically converting the code, while the other actually runs the code, so the system doesn't have to continually pause and translate more code? I'd guess the core handling the recompilation would take longer than the core actually running the equivalent code, so the running core would be idle quite a lot of the time, but I'd have thought being able to convert the next section of code while the current section is still being run, as well as avoiding the cost of context switching would make this idea worth investigating. I'm no expert though, so there's a lot of presumption in this proposal.
 

Exophase

Nothing good will ever come of Exophase.
Joined
Sep 21, 2006
Messages
10,308
Age
37
Location
Cleveland OH
Quite a lot of old systems had multiple general purpose CPUs on board. For example the Megadrive/Genesis had a 68000 and a Z80 coprocessor, although I don't know how much the latter was used in practice outside of the Master System adaptor. Similarly, the DS has an ARM9 and an ARM7 coprocessor, the latter used for GBA compatibility in the original models, and also to handle sound and wi-fi for DS games, according to wikipedia. Like the Megadrive, the Saturn also contained a Megadrive processor, although clocked a little faster and this time handling sound duties, alongside the twin SH2 main processors and two video processors, a peripheral controller and one SH1 processor, although that was tasked with handling the CD drive only, so probably not applicable to an emulator.


Emulators have handled running sounds at the same time as gameplay since pretty much forever, but emulating sound on the same processor as the game does slow the game down, as seen with a number of early emulator releases on the Pandora. But it seems to me that if you can run separate emulated cores on separate processors it's likely to make writing those emulators well and maintaining them simpler (although perhaps I'm underestimating what you can do with multithreading these days).

Assigning different CPUs to different threads for emulation is tricky because a lot of consoles will have tight synchronization loops, where one CPU expects the other CPU to respond pretty quickly. In the single threaded case the emulation looks like this:



Code:
emulate_cpu(cpu_a, CYCLES);

emulate_cpu(cpu_b, CYCLES);



While in the threaded version each thread would look something like this:





Code:
cpu_thread->done = 0;

emulate_cpu(cpu_thread, CYCLES);

cpu_thread->done = 1;

while(other_cpu_thread->done == 0);


You could use condition variables or some other OS assisted signaling instead, but the problem is that the OS scheduling may be too coarse, so both threads end up spending a lot of time waiting after they're done executing a block of CPU time. And they could have a lot of overhead.


It's not that this code wouldn't still give a good benefit, making the execution more like max(a, B) than (a + B) . But if the typical execution times of a and b are very different (even if the CPUs are the same speed, if their workloads tend to fluctuate a lot) it's something you'll want to do only if you have nothing better to do with the available CPU time, because in those cases one of the threads is going to spend a lot of time waiting on the other. And it's not very power efficient.


Most consoles so far, at least those before the current gen and excluding Saturn, really are of the type where one CPU runs a lot more code than the others.

On another note, since dynamic recompiling seems to be one of the latest emulation techniques, couldn't one core handle dynamically converting the code, while the other actually runs the code, so the system doesn't have to continually pause and translate more code? I'd guess the core handling the recompilation would take longer than the core actually running the equivalent code, so the running core would be idle quite a lot of the time, but I'd have thought being able to convert the next section of code while the current section is still being run, as well as avoiding the cost of context switching would make this idea worth investigating. I'm no expert though, so there's a lot of presumption in this proposal.

In my experience, recompiling doesn't take that much time unless you're constantly flushing all of your translation cache because the games are aggressively modifying code. In those cases you should focus on finding some other strategy of dealing with it. Thing is, when the recompiler needs to be called you don't really know what code isn't going to be needed really soon. And if you can be aggressive in compiling as much as possible directly some other optimization opportunities become available. But the only way to do this is to compile in one big block and not let the emulator start running pieces of the compiled code.
 
Last edited by a moderator:

McLovin

Member
Joined
Aug 28, 2010
Messages
278
Location
Germany
isn't this discussion a little off? it's not like pandora2 production has much of a choice. The mobile-SOC-market doesn't look like the pc-market a few years back where you could choose between a 3-4 ghz single-core and and 2-3 ghz dual-cores. from what i see, all soc-devs are increasing the indiviual bandwith and number of cores pretty much in parallel. Everything we already have, including N64, should be no real problem for those modern cpus, we don't know where dreamcast-emulation is heading and most pc-emulators for anything up from game-cube are already asuming a multicore-setup by design.
 
Last edited by a moderator:

Binky

Death's Steed
Staff member
Joined
May 28, 2003
Messages
6,964
Location
16A (TO)
I think the question in the topic title is (or should be irrelevant)


The question is:

Can anything else do what the pandora does better than a pandora?

Answer:

No

The P1 is a dreadful smartphone, a pathetic gaming PC; but this is not a problem, so why fix it?
 
Joined
Apr 8, 2007
Messages
436
The P1 is so outdated that I actually have to use my hands to use it...
 
Last edited by a moderator:

Binky

Death's Steed
Staff member
Joined
May 28, 2003
Messages
6,964
Location
16A (TO)
Why isn't OP eligible for a lawsuit with apple inc?


Think of all the nail-biting exciting we're missing!
 
Joined
Apr 8, 2007
Messages
436
achievment unlocked


- 1 year wait -


achievment unlocked


- 2 year wait -


achievment unlocked


- 3 year wait -


achievment unlocked


- 4 year wait -


achievment unlocked


- got pandora -
 
Last edited by a moderator:

elwing

Rabbit Addict
Joined
Feb 23, 2009
Messages
3,118
I'll beat you, I'm aiming for the 5 year wait now...
 
Last edited by a moderator:

_wb_

Microbe
Staff member
Joined
Apr 5, 2012
Messages
5,390
Age
39
Location
Brussels, Belgium
isn't this discussion a little off? it's not like pandora2 production has much of a choice. The mobile-SOC-market doesn't look like the pc-market a few years back where you could choose between a 3-4 ghz single-core and and 2-3 ghz dual-cores. from what i see, all soc-devs are increasing the indiviual bandwith and number of cores pretty much in parallel. Everything we already have, including N64, should be no real problem for those modern cpus, we don't know where dreamcast-emulation is heading and most pc-emulators for anything up from game-cube are already asuming a multicore-setup by design.

Sure, it's quite likely that the Pandora 2 will be multi-core. However, the above discussion would be relevant when we're deciding between, say, dual core and quad core.
 
Top