Print

[CyRUS64]

Saturn is tough but girigiri has shown it potentially possible. However Saturn gfx has to be cpu rendered so the celeron 733mhz would struggle even with that - unlike n64 where the dlists/alists can be hle'd saving a *lot* of cpu resources, and putting the xbox's powerful gfx card to use
Once Satourne has a good dynarec then we'll see.

[Lowen Na]

QUOTE (rhawk79 @ May 18 2003, 12:16 AM)

yea that's true, for a port, obviously there are no working pc emulators so there's nothing to port in the first place.  i was saying that in case anybody is trying to build one for the xbox from the ground up.

I am sure that this is real likely to happen.

[HeLiuM]

QUOTE (CyRUS64 @ May 17 2003, 12:23 PM)

Yep, the total internal memory for a dc comes to ~35MB alone  (this is what my savestates come to anyhow uncompressed), and then there is a lot more ram required for the program itself, aswell processing ram, cached texture storage,etc... and a half-decent  dynarec alone would want a lot more megabytes too. Its just not feasible. Nevertheless the fact that on ~2ghz systems we get 10-15fps only

thats 10-15 fps for a highly unoptimized engine. eventually im sure we could get a near full speed emu on say a 2.6ghz comp

QUOTE

you will NEVER see Gamecube let alone Dreamcast on the XBOX.

that should definately be the other way around  

[CyRUS64]

QUOTE

thats 10-15 fps for a highly unoptimized engine. eventually im sure we could get a near full speed emu on say a 2.6ghz comp

Certainly on some games we are aiming for ~2ghz, but a celeron 733 is still out of the question =)  

[BenzineX]

just have to say well said deusprogrammer  

[XDelusion]

Lucas: I think your onto something there. I sincerely hope that the X2 features a place for your road kill, that would no doubt be a good marketing ploy.

[CyRUS64]

Dynamic recompilation is exactly the same as a standard interpreter emu except when emulating the cpu which is often the bottleneck in emulating nex-gen systems. Thus instead of continuously fetching and executing the asm instructions one by one, it just fetches them in blocks (up to jmp/bra instructions) compiles them to native x86 blocks and then each time that same block gets hit, they just executed the compiled x86 block.
There is HLE which can mean a variety of things ranging from intercepting display lists and just high-level processing them and sending them direct to a 3d gfx card, and also function-level hle which detects pre-known library functions and replaces them with pre-written fast code.
I don't have time to go into any more detail though
These two techniques are what have been used in all n64 emus.

[AlphaWolf]

QUOTE (Hodr @ May 22 2003, 10:38 PM)

However, that is not the only method of emulation, nor is it necessarily the prefered method.  There are emulators that work through Dynamic recompilation of the original software. What this entails is an interpreter that reads the source and converts each "hardware" call to the equivalent call on the native hardware (which is often straight forward unless you are dealing with systems that do strange things like store 128bit registers etc.).  The process need only be done once, then the new program can be run natively.  This is old hat to most linux/unix/bsd/etc. users who must recompile for different systems.  And before you start screaming about needing "source code" to do this, you dont.  There are decompilers for most languages and the ones that don't have them usually have problems with the fact that parts of the code can be stored in multiple locations (.dll files for etc.) that the decompiler may have no knowledge of.  But being that this decompiler would be written for a closed sytem you wouldn't have those problems.

Even if this did work the way you are describing it, most processor instructions do not have an exact equivalent function on another processor. You'll need to execute another 2-8 or so instructions on the host processor just to perform the same function as the emulated processor. Even if you wrote an emulator that was as fast as it could possibly be (e.g. code fully optimized to the teeth), you still won't get full speed on a different-yet-equivalent host processor.

[Hodr]

CyRUS64- I was using the wrong term when I said "Dynamic" Recompilation, which you so nicely pointed out as meaning recompiled on the fly (hence the Dynamic I suppose, instead of static), but that doesn't mean the rest of what I said was invalid.  I havn't messed with any 64 emulators since the first came out, but I dont think I remember hearing about any that actually recompile the entire rom before executing so that it would not have to waste cycles doing it while executing.  There are speed increases to be had through this method because of the differences in hardware (for instance, in your 64 emulators your running code that has been optimised to run on 64 hardware so it was not written to take advantage of a prosessor that can do out-of-order execution or perhaps they waste cycles doing bit manipulation that isn't necessary on the new cpu etc.)

And to AlphaWolf- As I mentioned before, barring things like differences in register sizes or entire missing functions (like the inability to do integer addition or something) most processors have the same basic functions.  And even if it does take 2-8 instructions to perform the equivalent some of them, that doesn't mean it will be slower/faster.  Thats like saying RISC cpu's are always slower than CISC because they require more instructions to get something done (BTW, most will say RISK are faster....).  But your forgetting that it may also be the case that something that takes 2-8 instructions on the emulated cpu can be done in 1 on the intel cpu.  Besides which, any wildely different low level instructions are probably only going to deal with memory subsystems and calls to the graphic rendering devices, all of which are going to be replaced by different calls that do not perform the exact same function, as the hardware is different.

I didn't say it was easy, or that it would be pretty, all I said was that it is possible.  I had to do something similar years ago in school.  I was tasked to write a virtual machine that would execute Sparc assembly on an x86 system.  I did that, but I also wrote a line by line interpreter that converted the assembly so that it could be compiled and run natively (which re-used about 90% of the code from the vm).  Can you guess which one worked better?  Even ignoring the time spent to interpret the code in the VM, the compiled version was still faster because the native x86 compiler was able to optimize the code (instead of just running it as it came like the vm) for that platform, which had different strengths and weaknesses.

[ector]

The N64 emulator Corn does static recompilation, and is the fastest of them all. But in doing this, it also sacrifices compatibility (it only runs Mario64 and a few others AFAIK). Selfmodifying code and many other things are very problematic.

[AlphaWolf]

QUOTE (Hodr @ May 25 2003, 01:25 PM)

And to AlphaWolf- As I mentioned before, barring things like differences in register sizes or entire missing functions (like the inability to do integer addition or something) most processors have the same basic functions.

General purpose processors, maybe, but application specific processors are a whole other ballgame, and you are going to have to deal with that if you want to emulate these consoles.

[jp110099]

[AlphaWolf]

QUOTE (Hodr @ May 25 2003, 10:27 PM)

Alpha- Which application specific processors are you talking about... DSP's for audio (I think thats easily taken care of considering the xbox does have onboard sound...) special graphics chips (didn't we cover that three times now?), special chips for handling nontraditional memory structures (I mentioned that in my last post....)  Which other application specific processors are there?

I am talking about all of the above. Odds are not even one of these is going to be similar enough to the emulated system to get even close to 1:1 emulation. Graphics chips especialy, these always differ a hell of a lot. Even general purpose processors are a big maybe.

[CyRUS64]

QUOTE

I havn't messed with any 64 emulators since the first came out, but I dont think I remember hearing about any that actually recompile the entire rom before executing so that it would not have to waste cycles doing it while executing

I have the src to an n64 'emu' that tries to preconvert n64 games to a x86-runnable .exe. However something like Zelda comes out to be ~500+MB and doesn't work much
As Ector says you just can't do it that way. You're having to predictively try and trace through all the possible routes through the code and its just not really very feasible for nex-gen consoles.

QUOTE

Besides, it really doesn't matter if they have one general purpose processor or 40 specific processors, if we worked from the premise that the systems are basically equal in "Power" (as was stated in the initial post) then the functions of these specific processors should be able to be mapped to the general processor of the Xbox or one of the supporting processors (sound/GPU).

Even if you could do all this 'mapping' you still need to simulate the central cpus and that takes time

[Mage]

QUOTE

I guess the bottom line is that, if the graphic processing capabilities of the xbox are similar in strength to that of the ps2 (and have sufficiently similar effects, I.E. each has a "form" of volumetric lighting etc.) and the main cpu can keep up with that of the PS2, then it would be technically possible to write an emulator that could work full speed.

Uh, you don't know much about the PS2 do you?  In theory it is easier to write an xbox emulator on the ps2.  There is one major bottleneck you run in to when emulating the PS2 on any DX8-based arch, you CANNOT use hardware to do vector unit emulation.  The issue there is the fact that DX8 has a very limited vertex and pixel shader languages, which causes many things which can easily be done in the vector units impossible to do in the gpu on the xbox.
There are 4 COMPLETE processors (R5900, IOP, VU0, VU1) running in the ps2, to emulate all four on a 733Mhz system, isn't possible.  There aren't enough cycles to makeup for the fact that it has smaller GPRs, and that it has to emulate 3 different ISA.  I could continue about other reasons the xbox itself isn't powerful enough, but those reasons alone are enough if you know anything about hardware. (The R5900 has 32 128-bit GPRs which are being used nearly all the time.)

Don't just speculate, do some hard research before you try to compare specs, since the specs alone are useless.
Xbox2 might be able to emulate it, depending on the specs and amount of ram.  But anyone who honestly thinks there is going to be a ps2 emulator for xbox, needs to learn about hardware.