Possible Ps2 Emu?

[WizardStan]

It's much more complex than that. Nerds think that people are stupid because they don't take the time to 'discover' an OS fully. People think nerds are stupid for spending time discovering an OS.

Using the word "stupid" to describe people who have different priorities is... well... stupid

A more accurate version of the car analogy would be this. Person X who has only driven an automatic before tries a manual and thinks "nah it's not really for me". Person Y who has only driven an automatic before tries a manual and thinks "wow this is so much better for me". Notice the "for me" in each case.

The point I was getting at is that people in general believe that they know Windows, and even when it changes it is still Windows, and that makes them comfortable. A person used to automatic transmission may try a dozen automatic cars before considering a manual transmission. They may not even get to the "try it and decide whether it is or is not for them" stage because they've found an automatic that works for them already. And that's fine for cars, because there are so many options a person can choose from, and they can just hop in one and decide how it feels, that a person can reasonably stick within their comfort zone, whether it be brand or style or manual vs automatic or any combination thereof, and still find something that works for them. If their favorite make has changed, it's no problem trying a different make from the same brand, or even a similar make from a different brand, or whatever your comfort zone is.
But buying a car with the steering column and shifter in awkward places, the gas and brake swapped around, and a radio that can only be tuned to a few different stations that need to be programmed in, before even trying it, simply because it carries a familiar brand name is stupid. If the reversed gas and brake work for you, great! But it should be because it does work for you, and not because that's how the company that you're loyal to thinks it should be.
Unfortunately that's not how a lot of computer purchases work. People hear Windows, they think they know it, and regardless of whether it is right for them or not, they just take it, because there is no way to test drive a half dozen different operating systems. Although this post has given me some things to think about.

 

[openthebox]

:blink: I just built my brother a computer for under $1000 that can run any PS2 game that actually work with PCSX2 at >60 fps with max settings and the internal resolution set to 1920x1080. This computer is nowhere near top of the line.

Just curious, what are the specs for this computer you built? A better question is what important parts are needed to run PCSX2 decently?

 

[Chip]

Minimal Specs:
AMD 64 or Intel Pentium 4 (VM Build will not work with non SSE2 CPU's)
512MB of RAM
Pixel Shader 2.0 supporting card

Recommended Specs: (For reasonable performance in many games, but not all)
AMD64 X2 or Intel Conroe E6600+ (Multi Threading is supported in PCSX2)
512-1024MB of RAM (more RAM allows for VM mode to be stable)
Pixel Shader 2.0 supporting card (recommended GeForce 6600-8800 or equivalent ATi card)

Possible Ideal Specs:
64bit OS such as Vista or winXP64, to allow for future support of 64bit recompilers.
Future AMD or Intel Quad Core maybe needed, but currently the support of 4 threads is not handled by PCSX2, and the effect of threading out EE / VU is not yet known.
We don't forsee you requiring a GPU more powerful than the current generation of cards, up to and including the nVidia GeForce 8800.

A more in-depth guide to system specifications can be found here.

From here.

 

[mali]

Unfortunately that's not how a lot of computer purchases work. People hear Windows, they think they know it, and regardless of whether it is right for them or not, they just take it, because there is no way to test drive a half dozen different operating systems. Although this post has given me some things to think about.

I think that assumption is based largely on speculation. The problem for the user is:
1. availability
2. support

Regarding availability the problem is that Linux versions of similar hardware have often lesser specs(less RAM, less HDD space, see some Netbooks).
Regarding support the problem is that some manufacturers toss an outdated distro on their devices that self-destructs after a few weeks of use(see Aspire One A110L's Linpus).

Put a device with the same specifications as the Windows version on the market with a solid distro and people will buy it

 

[ldesnogu]

They can reach over 1GHz. I stand by my claim that only a few hundred MHz would be very useful.

I'm not familiar with FPGA, but are you sure commercially available ones are exceeding 1GHz? For instance, Virtex-6 are 600 MHz and Virtex-5 are 550 MHz.
Also I wonder what power they'd use (even though programming probably requires a fair amount of power, it could be done with the machine plugged).

I wasn't referring to something that'd be external to the CPU die. The actual interface isn't really that important, but the coprocessor interface is still part of the instruction set as far as I'm aware.

Having instructions that are in the coprocessor instruction set space doesn't mean there's a coprocessor interface. A9 hasn't for instance though it has many "coprocessor" instructions (CP14, CP15, VFP, AdvSIMD). So if you put an FPGA on the same die as an A9, you'd have to memory-map your FPGA. OTOH that doesn't mean performance wouldn't be there.

 

[Exophase]

I'm not familiar with FPGA, but are you sure commercially available ones are exceeding 1GHz? For instance, Virtex-6 are 600 MHz and Virtex-5 are 550 MHz.
Also I wonder what power they'd use (even though programming probably requires a fair amount of power, it could be done with the machine plugged).

Achronix claims 1.5GHz:

http://www.achronix.com/products/speedster.html

Of course, this is utterly bleeding edge, just announced, not out yet, but I was talking about future designs anyway, and I obviously wasn't talking about taking an exact existing FPGA design and plugging it next to a CPU, but a new design meant specifically for a particular CPU. Nonetheless, I would say that the current 600MHz high-end offerings from Altera and Xilinx are fast enough to be useful.

FPGAs can be programmed off of SRAM and easily reconfigurable, I don't think it'd take a lot of power considering reconfiguration wouldn't last very long. You'd obviously benefit from having the ability to have programs arbitrarily reconfigure.

Having instructions that are in the coprocessor instruction set space doesn't mean there's a coprocessor interface. A9 hasn't for instance though it has many "coprocessor" instructions (CP14, CP15, VFP, AdvSIMD). So if you put an FPGA on the same die as an A9, you'd have to memory-map your FPGA. OTOH that doesn't mean performance wouldn't be there.

Or, a company can license ARM source and modify it to mount the FPGA in the internal coprocessor instruction space. The instruction set availability is the relevant part here, IMO. I'm thinking of an FPGA that talks to the CPU directly and that's it, not something that has access to other parts of the system. It would really be a custom defined coprocessor.

 

[ldesnogu]

Or, a company can license ARM source and modify it to mount the FPGA in the internal coprocessor instruction space. The instruction set availability is the relevant part here, IMO. I'm thinking of an FPGA that talks to the CPU directly and that's it, not something that has access to other parts of the system. It would really be a custom defined coprocessor.

That's not how things work: a licensee can buy a design, but doesn't have the right to modify it; or it can buy an architecture license and then develop a CPU; the latter option obviously costs a lot in terms of money and time, and even then there are some serious restrictions on what can be done to the instruction set.

 

[Exophase]

That's not how things work: a licensee can buy a design, but doesn't have the right to modify it; or it can buy an architecture license and then develop a CPU; the latter option obviously costs a lot in terms of money and time, and even then there are some serious restrictions on what can be done to the instruction set.

That's strange to hear, given that by my understanding Snapdragon has a tremendous amount in common with Cortex-A8, with the changes mainly being in VFP in NEON. If what you say is true then they would have had to reconstruct the core from scratch as well in order to have custom versions of the aforementioned coprocessors.

 

[ari64]

It's possible to do a dual-processor dynamic recompiler. One CPU begins running an interpreter and sends the addresses that are executed to the second processor. The second processor recompiles the code, then signals the first CPU to execute the compiled blocks instead of the interpreter. After awhile the second CPU is mostly idle, but it improves the startup time.

That approach has an issue: you'd need to sync dcache of CPU1 with icache of CPU0. This means cleaning dcache of CPU1 and invalidating icache of CPU0 (on A9 you'd only need to invalidate icache but the coherent traffic will have a non-negligible impact...).

First the dcache needs to be written out to the L2, then the code needs to be loaded into the icache. When a new block is compiled, those addresses will not be in the icache, so the icache does not need to be invalidated. Most of the bugs I have encountered with this have been due to dcache lines which did not get written back before they were loaded into the icache. I am not sure how this issue is avoided on the A9.

 

[ldesnogu]

Snapdragon was developed from scratch by Qualcomm. It's not because it looks similar to A8 that it has any single line of Verilog coming from it

 

[ldesnogu]

First the dcache needs to be written out to the L2, then the code needs to be loaded into the icache. When a new block is compiled, those addresses will not be in the icache, so the icache does not need to be invalidated.

Hum good point.

Most of the bugs I have encountered with this have been due to dcache lines which did not get written back before they were loaded into the icache. I am not sure how this issue is avoided on the A9.

It's not avoided, I was making a stupid assumption about A9 (there were internal discussions about this issue), forget what I wrote

OTOH there still is an issue: you'd probably have to make sure code generation is done on distinct cache lines. That means some later wastage in icache usage. BTW QEMU already aligns blocks of generated code, does mupen do the same?

 

[ari64]

OTOH there still is an issue: you'd probably have to make sure code generation is done on distinct cache lines. That means some later wastage in icache usage. BTW QEMU already aligns blocks of generated code, does mupen do the same?

No, if there is remaining space in a cache line, it will fill it with the next block. It doesn't make much difference since it's on a single CPU and the icache is invalidated. Also there is usually a small literal pool between the blocks (most constants are loaded with movw/movt, but there are a few values that I want to read/modify later, so I put them in a pool at the end of the block.)

A dual-core JIT compiler could easily be designed to avoid these issues.

 

[Wheels]

Some things I want to add: Intel has already broken the Wintel alliance by creating Moblin, so MS won't have too many qualms before entering the (still largely hypothetical) ARM sector in a more thought through attempt.

No sure I agree. Intel started the Moblin project, yeah, but since handing it over to the Linux Foundation they've taken a less hands-on approach, and they've also basically abandoned Linux support for the GMA 500 chipset (granted, it's not strictly their design so they may not even have permission to make open drivers for it, but the level of compatibility is still abysmal; incidentally, the GMA 500 uses a PowerVR design, the same company that does the graphics for OMAP, and they seem to be allergic to open drivers). I'm not sure you can call Moblin an Intel attempt at breaching the Wintel alliance, especially since historically Intel has had pretty good Linux support in terms of hardware drivers and upstream projects like GEM.

Even Canonical will support Chrome OS on ARM, which might lead to abandoning Ubuntu NBR. Extrapolating things, this leads to Android on Smartphones, Chrome OS on Netbooks and later a merge of Android and Chrome for all platforms. Full fledged Linux will become even more niche than it is right now.

Not sure I agree with that one, either. Both Android and ChromeOS seem to be targeting computers with a kind of "appliance" usage in mind like mobile phones, "nettops," or netbooks that are used exclusively for internettin'. I can't see Canonical giving up their niche-leading Netbook Remix just because Google's their competition (especially since NBR seems to out-perform ChromeOS builds in almost all respects right now, and has a great interface). That's the way things are now, but because ChromeOS is limited to browser-based tools and Android is mostly for Java widgets (perhaps a bit of C if you want), I can't see them evolving into nearly the kind of flexible OS people use for general computing. Add to that the fact that traditional distros already have a huge library of existing software that can't be easily ported to Android or run in a browser, and I don't think Google will be stealing the general Linux market away from the established players. It might, however, increase the facetime Linux gets on other devices where people don't traditionally think about which operating systems they use. If that works out on Google's terms, doesn't mean much to me right now. Either way I'm just not worried about Google stealing "Linux" away from "us."

 

[mali]

No sure I agree. Intel started the Moblin project, yeah, but since handing it over to the Linux Foundation they've taken a less hands-on approach, and they've also basically abandoned Linux support for the GMA 500 chipset (granted, it's not strictly their design so they may not even have permission to make open drivers for it, but the level of compatibility is still abysmal; incidentally, the GMA 500 uses a PowerVR design, the same company that does the graphics for OMAP, and they seem to be allergic to open drivers). I'm not sure you can call Moblin an Intel attempt at breaching the Wintel alliance, especially since historically Intel has had pretty good Linux support in terms of hardware drivers and upstream projects like GEM.

The opposite is true. Since Moblin was handed over, development accelerated. On the mobiledevcamp09 Quake III was demoed in 1080p resolution running at 35-40fps on GMA500+Moblin and also 1080p video decoding works now.

Not sure I agree with that one, either. Both Android and ChromeOS seem to be targeting computers with a kind of "appliance" usage in mind like mobile phones, "nettops," or netbooks that are used exclusively for internettin'. I can't see Canonical giving up their niche-leading Netbook Remix just because Google's their competition (especially since NBR seems to out-perform ChromeOS builds in almost all respects right now, and has a great interface).

You miss the point that Google and Canonical are cooperating on Chrome OS now, so their NBR development will most likely slow down.

That's the way things are now, but because ChromeOS is limited to browser-based tools and Android is mostly for Java widgets (perhaps a bit of C if you want), I can't see them evolving into nearly the kind of flexible OS people use for general computing. Add to that the fact that traditional distros already have a huge library of existing software that can't be easily ported to Android or run in a browser, and I don't think Google will be stealing the general Linux market away from the established players. It might, however, increase the facetime Linux gets on other devices where people don't traditionally think about which operating systems they use. If that works out on Google's terms, doesn't mean much to me right now. Either way I'm just not worried about Google stealing "Linux" away from "us."

Sergey Brin said that Android and Chrome OS will merge sometime, which means that a local computing part will be integrated besides cloud computing. Google Gears will be discontinued, afaik.

I really see a possibility of some kind of monopoly forming in the ARM segment. The good thing is, though, that it should be possible to hijack most of the ARM devices and put a different OS on them(if google doesn't lock down the hardware sometime in the future, that is ).

 

[juniorm33]

Snapdragon was developed from scratch by Qualcomm. It's not because it looks similar to A8 that it has any single line of Verilog coming from it

Oh ok, I was under the impression also that it was a modified A8. I thought they had different licensing for their IP depending on what you wanted to do with it.

 

[Pimpsahoy]

I am a PSP guru of sorts, I've worked on the firmwares and the hardware of almost every model of PSP inside and out. In fact I used to crack the firmware open for for money using the Pandora's battery method. Well at that I used too, I dropped off the PSP scene a while ago and came onto the pandora scene as I began to feel the restraints that the PSP hardware had even with an overclock running @333. A while back We (the psp Homebrew community) had tried to emulate the the PS2 on the PSP, we knew from the very beginning it wouldn't work, we did it for the fun. We managed to get a frame rate of about 2 on one of the early CD based PS2 games, the project was eventually dropped, there is an exponential difference between the two systems.

 

[Jumpman]

Welcome to the community Pimpsahoy, I always wanted to mod my psp, but felt it was to limited in the long run. I stuck with my GP2X, until the Pandora came along and swept me away. Hopefully you haven't been waiting as long as the rest of us. I would hate to see anyone give on this system before it is even released. I'm sure we have lost a few good community members over the last year due to the delays, but what can you do! We're for sure in the home stretch!



Jumpman

 

[relliker]

If I may ask, why must an emulator always run the "original" game code?. Since it is "emulating", couldn't it be feasible to code something like an "on the fly" code translator?

Maybe I'm talking crap here (my programming is still limited to bash scripts) but say for example the original game is using a PS2 system call to fill a particular polygon with a solid colour. Would it make sense that instead of running the "original" code directly by simulating the hardware, the emulator could like parse this code and produce a Pandora-specific system call to do a similar thing on its own screen and hardware?

This could be done once (like you would be disassembling the original code, and porting it to the Pandora by translating it to equivalent arm code) and the result saved as a Pandora-specific game simulating (not emulating) the original.

Now tell me to shoot myself and that it is impossible but as I see it, this is the same as when a game is ported from one console system to another. The hardware is different but the source code can be recompiled on another console with maybe very minor changes. The missing step here is that the source code will not be available (hehe, just a minor hiccup no?!) but isn't that what reverse engineering is? To produce a believable look-alike by seeing how the original was made and doing the same thing but your way?

So, before I shoot myself, I say SIMULATE, not EMULATE. Now I'm ready to face the fire.

 

[juniorm33]

What your describing is static recompiling I believe to some extent and it's still an emulator. Dynamic recompilation does it on the fly though. It's been described the cons and pro's to both a couple times here.
So no your not mad or crazy, just describing one type of emulation :lol:

Edit: here you go mate, this link should cover some of it, there's a few pages on it, it does start to get pretty deep if I remember correctly though, but could still give you a good idea of the different types of emulation techniques link

 

[Tom`]

...

That's what HLE is, basically. There are still a lot of problems, though - you need to use a dynamic recompiler to translate the code, because it's not all going to be using instructions that translate exactly to ARM instructions. Not only that, but the hardware can be totally different, so a lot of ways of doing things on the original hardware will not work at all on whatever you're emulating it on. Also, the graphics operations are going to be different (in their implementation, not the actual effect), so you still need many times the CPU power of the original.

(I'm sure one of the people who are actually knowledgeable about this stuff will explain in detail, but that's my understanding as someone who has only the most general idea of how a recompiler works.)

edit: yeah, what you are talking about is static recompilation, but that can never work perfectly because code can be modified while it's running - you don't have any way of knowing this at compile time. Also, it pretty much has to be done by hand, even where it is possible, which as you might imagine is a huge amount of work.