speed

/moved

...to a more appropriate forum.

Hellpme said:

Hello

I have bin interested in emulation for many years and was just looking at PJ64 and it said it was running a recompiler, which means the PC sees the N64 code and the PC CPU terns the code in to code the PC CPU can run right?

I do not now if you now about FX!32 for 64bit Alpha CPUs but it recompiles win32bit code to run on the Alpha 64dit CPU. The big difference between them is that FX!32 saves the code so the next time the code is run the CPU will not have to recompile it but just run it. So it is fast!

So Y don’t N64 emulators run like this or do they? I am not the world’s best coder and I can not code as well as the people how do the N64 emulators but I do think it mite be a good way of making the emulators run faster.

How are the best people for me to talk to about this?

Thank you

Click to expand...

1. This has been done in an N64 emulator called CORN. It was noted as being quite fast but largely incompatible.
2. This is a VERY difficult proposition, the ROM format is partly to blame. To create a new executable one technically needs to be able to translate the code smoothly between each system. For Win32 this is actually QUITE easy as they leave information throughout the binary image as to what you are looking at. This includes embeded forms etc. WinAPI calls are well documented as well. However we are talking a system that is proprietary in nature not one that follows standards.
3. The above reason is why HLE exists in N64 emulation. It works because most of the graphics etc are handled by library calls. This circumvents having to actually perform the code contained in the library.
4. The N64 has a lot of hardware that simply doesn't exist on the PC Enough said.
   [/list=1]

Well, Cyberman's inaccuracies aside...I will tell you that compilation is actually done on the fly in most n64 emulators.

schibo said:

Well, Cyberman's inaccuracies aside...I will tell you that compilation is actually done on the fly in most n64 emulators.

Click to expand...

Hey if I were perfect I wouldn't be here

LOL!

Dynamic is simpler because at run time you know what the data is doing, statically speaking it's more or less a guessing game. I suppose one could make a static image of the code from dynamically recompiled data. (thinks a bit) It would be a PITA though because you never really no WTH they are doing.

An example is Conkers Bad Fur Day or Resident Evil 2. Lots of MP3 abuse in those, the N64 plays MP3 data stored in the ROM, I don't know for sure the details how they were able to get the games to work, (RE2 doesn't work .. too hot to be honest but that's not a big deal). I suppose for special cases such as these one would have to 'convert' the rest by hand or something like that.

Cyb

If you notice PJ64 has an intepreter and a Dynamic Recompiler mode for testing absolute maximum compatibility. Believe me the people who made these things really know there stuff.

Hellpme said:

I thick they must be gods because how do they now how a N64 gos? the MIPS 4300 is a doddle but the custom chips how??

Click to expand...

The R4300 in the N64 has some cute things done to it, namely it has custom instructions (like the Nintendo Game Cube does). That being said all the graphics are done using these custom instructions in a library. The same goes with sound. So.. how did they do it? Perhaps they had a N64 handy and single steped the code looking at what happened as a result? (heh). Well more recent Emu's (AKA post ULTRA HLE) have had the developer's library for making display and sound instructions available. From the instruction coding one can get most of the encoding. HLE works because one emulates the low level library instead of interpreting each instruction. Then the difficulty is with the real MIPS4 instruction set, Dynamic Rec works better because of the nasty use of self modifying code in the N64. This is a handy means for making switch statements (from a single jump instruction) etc. It's a pain to emulate. Hence Dynamic Rec. Things that change in the 'in RAM' code are marked if modified and when one is found to have changed it's recompiled (and then corrrect).

That is a simplified explaination. HLE did so well because it didn't actually interprete the instructions it interpreted any MIPS4 code and then used the HLE to just DO the function the code would have done anyhow. IE they knew what the results were and knew how the library code worked from single steping and used this to bypass the custom code. As for sound I think it was very similar.

Cyb

Cool

More, tell me More???

Just want to say something.

since most emulators run on Windows, in turn meaning that most people on the emulator scene run Windows in some shape or form, wouldnt it be possible to compile all roms to use DX? cuz, all N64 games call on the N64 Hardware in the same way evey time for every game. so, once one ROM is compiled to a Win32 app, the rest should be easy to do from there.

but this is just me. I have no coding experience, so I am probably just talking junk to you guys right now.

nope, i am afraid that can't be done. roms aren't compiled, instead they are read an interpreted by the emulator. plus, why would you want to do that? then you wouldn't be able to use other API's, like opengl or glide plugins, and would be forced to use DX (probably something microsoft would love, haha)

this ofcourse is a short, maybe even a little inaccurate answer. anyone else wanna fil him in?

Well, I understand now that ROM's are not compiled. but the deal wth DX would be that DX allows all games to be written one way but can be run on all systems with all different configurations. that is what is so great about DX.

but if you have ay info that can help fille me in, that would be great!

Vchat20 said:

Well, I understand now that ROM's are not compiled. but the deal wth DX would be that DX allows all games to be written one way but can be run on all systems with all different configurations. that is what is so great about DX.

but if you have ay info that can help fille me in, that would be great!

Click to expand...

I'm afraid this is in error.. DX is not created equal on all hardware.
There are GREAT variations between versions for example DirectX 8 looks a lot more like OpenGL (gee I wonder why?) than DX6 and DX7, God only knows what they did with DX9. Each manufacturer has to support direct X as much as they would OGL. So it's not the pancea that you might think.

I would like to point out something a LOT more important, N64 games are written with OpenGL in mind, the graphics hardware was designed by Silicon Graphics, the makers of the OpenGL standard. The meaning most N64 games used a library of function calls (this is where HLE comes from) and these calls are more likely to resemble OGL than DirectX function calls though I cannot verify this.

Cyb