levi
Still fresh, damnit!
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.
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.