Why Can't The Pandora Emulate The Ps2?

[elwing]

No, you are right. The ARM-7 part is provided by nintendo.
But it is also needed to run the games. Most of them simply won't work without it.

of course, but you can replace the ARM7 with some hle if commercial game only use the provided nintendo api... not sure they do through...

 

[fiveseven]

Hypothetically, if some kind of FPGA were incorporated into a device, how much would that benefit emulation?

 

[bzar]

Hypothetically, if some kind of FPGA were incorporated into a device, how much would that benefit emulation?

I have no idea what I'm talking about, but I'd guess it would take quite an FPGA to give actual benefit. One could theoretically give some advantage if it could replicate 1:1 the functionality of an entire chip, but somehow it sounds like it's more trouble than it's worth.

 

[Jourdy288]

AAAUGGGHHHHHH!!!
This thread hurt my iMac, too much tech talk...
:lol:
I doubt that we'll have playable PS2 emulation, though... I like to compare emulation to fitting one shape into another, i.e. ARM is a triangle, x86 is a long, flat rectangle, and cell is an origami swan.

 

[Exophase]

Actually Exo, the GBA mode couldn't be removed from the hardware, because if it were no DS games would run on it.
The DS uses an ARM-9 and an ARM-7 processor. DS games use both, with the ARM-9 handling most of the grunt. The ARM-7 is usually reserved for just the simplest processing (though it is used quite well in some games, from what I understand). (Interestingly, the code used in each game's ARM-7 section pretty much never changes).

But the ARM-7 was also placed in there to enable GBA games to be played. The ARM-7 processor Nintendo used was, while not quite the same as the GBA's, close enough to it to virtualize GBA games.

And yes, there is a lot of talk about adding GBA games to the DSi's VC (believe me, everybody wants it), but Nintendo has been holding back. Perhaps for the 3DS?

Sorry if I missed something important in your post, but I thought that as a GBATemp forum-er I had to post here.

What you said is only sort of true.

DS games do rely on the ARM7, which only executes official Nintendo library code (in commercial games anyway). And by and large the DS is close to GBA compatible, but there are some differences that prevent it from running GBA games outright. The clock speed of the ARM7 is sort of one of them, but also there are some nuances in the 2D core, and the DS audio doesn't have all of the same original Gameboy audio features that the GBA has (and most GBA games rely on). The DS ARM7 BIOS is also a little different.

There's no "virtualization" employed on DS, there's an actual "GBA mode" that the DS can enter which everything GBA equivalent on a hardware level. Technically it would have been possible for Nintendo to remove this GBA mode, but it would have only saved a small amount of die space compared to all the things they added to DSi. On GB Micro there's evidence that the hardware can still play GBC games despite having less hardware overlap, but this is probably because it wouldn't have made sense from a cost perspective to rev a new chip. On DSi Nintendo may have done a new chip to incorporate the new functionality, but it also may have all been added externally and to already available interfaces.

So it's not likely DSi removed the GBA mode, but as I said in the previous post the only way DSi can play GBA games natively is if its 16MB of RAM is accessible in the memory region where the slot 2 bus used to be.

of course, but you can replace the ARM7 with some hle if commercial game only use the provided nintendo api... not sure they do through...

I doubt it's so simple. Just because ARM7 only runs Nintendo code (this is true for all games, Nintendo doesn't allow anything else) doesn't mean there's just one binary every game is using. And the IPC interface isn't really simple to patch with software.

It's moot though, there's no question that the DSi has the ARM7.

 

[elwing]

It's moot though, there's no question that the DSi has the ARM7.

yup but the question was more for the upcoming DS3 (is that its name?)

 

[Exophase]

yup but the question was more for the upcoming DS3 (is that its name?)

"3DS."

It could end up using software emulation for DS entirely, complete hardware compatibility, or something in between. Everything I said about the difficulties HLEing ARM7 apply. For reference, Nintendo's officially sold DS emulator, Ensata, HLE's ARM7 and is known to have terrible compatibility.

 

[fearofshorts]

What you said is only sort of true.

DS games do rely on the ARM7, which only executes official Nintendo library code (in commercial games anyway). And by and large the DS is close to GBA compatible, but there are some differences that prevent it from running GBA games outright. The clock speed of the ARM7 is sort of one of them, but also there are some nuances in the 2D core, and the DS audio doesn't have all of the same original Gameboy audio features that the GBA has (and most GBA games rely on). The DS ARM7 BIOS is also a little different.

There's no "virtualization" employed on DS, there's an actual "GBA mode" that the DS can enter which everything GBA equivalent on a hardware level. Technically it would have been possible for Nintendo to remove this GBA mode, but it would have only saved a small amount of die space compared to all the things they added to DSi. On GB Micro there's evidence that the hardware can still play GBC games despite having less hardware overlap, but this is probably because it wouldn't have made sense from a cost perspective to rev a new chip. On DSi Nintendo may have done a new chip to incorporate the new functionality, but it also may have all been added externally and to already available interfaces.

So it's not likely DSi removed the GBA mode, but as I said in the previous post the only way DSi can play GBA games natively is if its 16MB of RAM is accessible in the memory region where the slot 2 bus used to be.

of course, but you can replace the ARM7 with some hle if commercial game only use the provided nintendo api... not sure they do through...

I doubt it's so simple. Just because ARM7 only runs Nintendo code (this is true for all games, Nintendo doesn't allow anything else) doesn't mean there's just one binary every game is using. And the IPC interface isn't really simple to patch with software.

It's moot though, there's no question that the DSi has the ARM7.

ACK! I knew I shouldn't have tried to correct Exo!

But on the matter of the ARM-7 binary- there actually are only about 6 or 7 different ones out there. And the interesting part is what happens when you replace one.

In the DS-community, one of the most popular ways to get a game to run on a flashcart that doesn't support it yet (yes, I am talking about pirates. No, I'm not one of these people) is to split up a rom into it's ARM-9 and ARM-7 components and replace the ARM-7 binary with another one. I'm not sure why it works, but it does.

Also, from what I've read, there's one binary that works for about 90% of games.

 

[Exophase]

ACK! I knew I shouldn't have tried to correct Exo!

But on the matter of the ARM-7 binary- there actually are only about 6 or 7 different ones out there. And the interesting part is what happens when you replace one.

In the DS-community, one of the most popular ways to get a game to run on a flashcart that doesn't support it yet (yes, I am talking about pirates. No, I'm not one of these people) is to split up a rom into it's ARM-9 and ARM-7 components and replace the ARM-7 binary with another one. I'm not sure why it works, but it does.

Also, from what I've read, there's one binary that works for about 90% of games.

That's interesting information. There definitely seems to be more than just 6-7 binary sizes - maybe unused functions are trimmed out. I've never heard of replacing the ARM7 binary. I'd like to find out more about this.

I think that usually < 3m per second are executed on ARM7, so if you're otherwise emulating everything in software then it shouldn't be a huge hit to do ARM7 low level as well.

My guess about why replacing ARM7 binaries helps flash carts - most carts have to patch standard routines in order to redirect writes that originally went to EEPROM/Flash/whatever so that they go to files on an SD card (so this is an example where HLE does work, but it's still at a lower level than replacing the ARM7 interface altogether). If the routines aren't recognized then they wouldn't be patched right.

 

[laurencevde]

My guess is that Nintendo chose this kind of design (Nintendo-provided ARM7-binary that stays relatively constant across a large number of games) to be able to get rid of that ARM7-core entirely in some DS-successor. Also, N has full access to that code, and roms are packaged in a format that makes it relatively easy to replace parts, so it seems to me that N would be fully capabable of reimplementing the features handled by that ARM7-binary/core for a DS-successor...

 

[Exophase]

I don't think that's it. I think it's all part of greatly simplifying their QA procedure. PSP only gives you hardware access via libraries too.

You can replace an ARM7 binary but it's still an ARM7 binary that's interfaced via a low level hardware mechanism, not linked directly into ARM9 code.

 

[XxionxX]

Are you guys saying that it is the emulation software (the part that mimics the physical ps2 parts) that is making this impossible for the Pandora? If that is correct then I have another question, could you just (haha) recode everything (might as well remake everything at that point) so the software was optimized to run on the ARM architecture? What I mean is could you possibly re-code everything to run natively on the Pandora without the emulation software, and would that make it possible to run the games on the Pandora? If so then would it still be to much to processing power or am I just making no sense? :huh:

 

[WizardStan]

What I mean is could you possibly re-code everything to run natively on the Pandora without the emulation software, and would that make it possible to run the games on the Pandora?

What you're talking about is static recompiling. Long story short, no, it's just not feasible. Short story long, ask Exophase.

edit: quote trim

 

[edgex004]

Are you guys saying that it is the emulation software (the part that mimics the physical ps2 parts) that is making this impossible for the Pandora? If that is correct then I have another question, could you just (haha) recode everything (might as well remake everything at that point) so the software was optimized to run on the ARM architecture? What I mean is could you possibly re-code everything to run natively on the Pandora without the emulation software, and would that make it possible to run the games on the Pandora? If so then would it still be to much to processing power or am I just making no sense? :huh:

Nope.

If you are referring to recoding the games themselves for ARM, that is what is termed a "port." And to make one of those you would need the source code.

If you mean port the emulator and optimize it for ARM, that is exactly what could work... at a horribly unplayable speed.

EDIT: Hmm seems WizardStan understood the question better than I.

 

[Exophase]

What you're talking about is static recompiling. Long story short, no, it's just not feasible. Short story long, ask Exophase.

edit: quote trim

Just for that I'm not answering nothin

 

[Prometheus]

That's a double-negative.

 

[XxionxX]

What you're talking about is static recompiling. Long story short, no, it's just not feasible. Short story long, ask Exophase.

Hm... Nothing on Google for "static recompiling" but I found stuff on "static compiling" is that the same thing? There was some information, but it seemed to be above my pay grade. Should I just ask Exophase? Figure it out, got it!

Nope.

If you are referring to recoding the games themselves for ARM, that is what is termed a "port." And to make one of those you would need the source code.

If you mean port the emulator and optimize it for ARM, that is exactly what could work... at a horribly unplayable speed.

So it is impossible to get the source code from just looking at the compiled code? or illegal? or did WizardStan have a better answer to my question?

Edit: More responses.

 

[edgex004]

So it is impossible to get the source code from just looking at the compiled code? or illegal?

That's the way most of us here see it.

However, some open source implementations have been successful in producing engines similar to the original code.

Example: OpenMW

EDIT: More along the lines of impossible rather than illegal.

 

[mcobit]

What you're talking about is static recompiling. Long story short, no, it's just not feasible. Short story long, ask Exophase.

Hm... Nothing on Google for "static recompiling" but I found stuff on "static compiling" is that the same thing? There was some information, but it seemed to be above my pay grade. Should I just ask Exophase? Figure it out, got it!

Nope.

If you are referring to recoding the games themselves for ARM, that is what is termed a "port." And to make one of those you would need the source code.

If you mean port the emulator and optimize it for ARM, that is exactly what could work... at a horribly unplayable speed.

So it is impossible to get the source code from just looking at the compiled code? or illegal? or did WizardStan have a better answer to my question?

Are we in "The Matrix" now, Where you can just look at the compiled Code and se
e the Source?


Edit: More responses.

 

[XxionxX]

Are we in "The Matrix" now, Where you can just look at the compiled Code and see the Source?

....Maybe.... :blush: