N64 runs at about 100 MHz yet...
- Thread starter !REVENGE!
- Start date
Toasty
Sony battery
The ROM is "written" in VR4300 machine code. Those basic instructions have to be translated into x86 machine code, and then executed. The translation itself takes time, and usually the produced code cannot be as efficient as the original, due to architectural differences. (An operation that could be accomplished on the N64 using 2 instructions and last for 2 cycles might require 30 instructions and 40 cycles to be accurately reproduced on an x86 PC, for example.) So, the actual execution of the translated code also is much more intensive than on the original platform. For these reasons, the host platform must often be many times more powerful than the emulated platform to ensure real-time emulation.
That said, if you're having trouble reaching full speed on a 3 GHz machine though, there's a special reason, because my old 1.6 GHz Pentium 4 could run just about any game I threw at it at full speed. (Even Goldeneye and other intensive titles.)
That said, if you're having trouble reaching full speed on a 3 GHz machine though, there's a special reason, because my old 1.6 GHz Pentium 4 could run just about any game I threw at it at full speed. (Even Goldeneye and other intensive titles.)
Why do you say the n64 is 100 mhz ?
the r4300i is running at 97 mhz .. if you take out the rest I am sure it will take a lot less requirements ...
the r4300i is also 64 bit machine .. which is being emulated on a 32 bit system.
is a dual core cpu .. the second cpu the RSP is 67 mhz which has heaps of vector processing ops.
then I bet your not displaying the gfx in 320x240 ?
You are also running through an OS which adds extra overheads as well.
Last edited:
You quote 2 games which make heavy use of the TLB in a way that causes slow down in emulators. Then say a lot of games .. these do not make good examples .. It is some of the Rare games that do this .. like maybe 5 games that has this issue. There is tricks to help this but this has nothing to do with clock speed.
You forget it also depends on what type of emulation is being done. HLE is a whole fuckload faster than LLE.
!REVENGE!, your system has serious problems if you're not able to emulate games at full speed if you've got a CPU like that. Pretty much every 3 GHZ CPU, even a Northwood Core Celeron(I've had one of those. Used it for years. They are slow as can be.), can do fullspeed N64 emulation if you have a semi-decent graphics card(Anything above a GeForce 2 MX series card). Also, remember that a lot of N64 games had serious frame rate problems. Goldeneye and PD are the best examples among games that everyone knows about and/or has played. You can get fullspeed N64 emulation and still only get 13 FPS in the game itself.
Sad but true.
- Thread Starter
- #10
Guys, I'm not bitching about emulator bloat or nuthin like that. My old 1.5 GHz can run every game at fullspeed (except Goldeneye) with occasional but very minimal lag during intense scenes, and my new 3 GHz was problematic because my onboard video card was a cheap piece of shit that didn't support 3D textures. I was just wondering why it's so difficult to emulate the N64 system -- and wanted more insight in general, as the ins and outs of Nintendo consoles have always been full of wonders and very interesting to me.
How do x86 instructions differ from VR4300, and how come that architecture was chosen for the N64? Is the programming language they use to write the games automatically compiled to the VR4300 machine code?
How do x86 instructions differ from VR4300, and how come that architecture was chosen for the N64? Is the programming language they use to write the games automatically compiled to the VR4300 machine code?
Toasty
Sony battery
x86 instructions differ from VR4300 instructions in the same way that English words differ from Russian words. An instruction that tells an x86 CPU to add two numbers might look like this: 5F 01 B4 00 8A, while the equivalent instruction running on a VR4300 would be formatted like this: 32 11 B4 01 8A 00. (That's only meant as an example; I have no idea what the actual opcodes would look like.) CPUs for consoles are usually chosen based on cost, performance and suitability for gaming. At the time the N64 was released, Nintendo no doubt felt that that CPU would offer the best 'bang for the buck' and they were probably right.
Writing programming for a game console works the same as writing programming for any computer. You can either write the program using a programming language, like C, and then compile that into native machine code, or you can write in assembly, which is basically just human-readable machine code (with a few extra bells and whistles to make things easier), which gets directly assembled into native machine code. In the case of older consoles, a lot of assembly was used, since it can be written to work more efficiently than the code produced by a compiler, and CPU cycles were at a premium on those older consoles. Nowadays, I'd guess that a lot more higher level code is used, since it's typically easier to manage, and consoles are fast enough that they can afford to waste a few cycles here and there for the sake of quicker development.
Writing programming for a game console works the same as writing programming for any computer. You can either write the program using a programming language, like C, and then compile that into native machine code, or you can write in assembly, which is basically just human-readable machine code (with a few extra bells and whistles to make things easier), which gets directly assembled into native machine code. In the case of older consoles, a lot of assembly was used, since it can be written to work more efficiently than the code produced by a compiler, and CPU cycles were at a premium on those older consoles. Nowadays, I'd guess that a lot more higher level code is used, since it's typically easier to manage, and consoles are fast enough that they can afford to waste a few cycles here and there for the sake of quicker development.
- Thread Starter
- #12
What is the purpose of having so many different instruction sets? Can't there be a universal one like x86?
Wait, if it's written in Assembly/C then can't it be compiled into x86 code and take only 100MHz on a PC like on the N64?
x86 is NOT universal. It's merely the instruction set that is the most popular in the PC world. The reasons for having more than one instruction set are varied. For one, a particular instruction set may only be good at one thing, and crap at others. For another, unless your competitor has gained a huge amount of market share, it's not always a good idea to use your competitor's instruction set. After all, you'll have to pay licensing fees, be partially subject to your competitor's whims, etc.
As for compiling Assembly/C... Oh, gods no. For one thing, you're forgetting that these games were coded specifically for one platform. You can't just compile the code and expect it to run on the platform you want it to. there's going to be code in there that is specific for the platform. You'd have to rewrite it. For another, Assembly is specific to the instruction set/CPU/processor it's coded for. Assembly is only one or two steps above pure 0s and 1s, after all.
There's also libraries to consider. If your program is dependent on a library from Sony(For example), unless you've coded your game so that you can use another company's library(Say, Sega) that performs the same functions, you could be boned if you want to port it. You'd have to rewrite the game and possibly make the library from scratch.
There are many, many issues when it comes to porting. It's rarely easy unless you're porting from one system to another that's vastly superior(For example, NES to the X360), or to one that's very similar(GC to Wii, for example).
You've also got to take into consideration that what you've said assumes access to the source code. That's just not gonna happen unless you've licensed the game(And even then it's not guaranteed.).
I may not be totally correct with the examples I gave, but what I've meant will stand regardless. It's never as simple as compiling the code.
As for compiling Assembly/C... Oh, gods no. For one thing, you're forgetting that these games were coded specifically for one platform. You can't just compile the code and expect it to run on the platform you want it to. there's going to be code in there that is specific for the platform. You'd have to rewrite it. For another, Assembly is specific to the instruction set/CPU/processor it's coded for. Assembly is only one or two steps above pure 0s and 1s, after all.
There's also libraries to consider. If your program is dependent on a library from Sony(For example), unless you've coded your game so that you can use another company's library(Say, Sega) that performs the same functions, you could be boned if you want to port it. You'd have to rewrite the game and possibly make the library from scratch.
There are many, many issues when it comes to porting. It's rarely easy unless you're porting from one system to another that's vastly superior(For example, NES to the X360), or to one that's very similar(GC to Wii, for example).
You've also got to take into consideration that what you've said assumes access to the source code. That's just not gonna happen unless you've licensed the game(And even then it's not guaranteed.).
I may not be totally correct with the examples I gave, but what I've meant will stand regardless. It's never as simple as compiling the code.
Toasty
Sony battery
What's the purpose of having so many real world languages? In the past in particular, it has typically been more cost effective not to use the same general purpose CPUs as desktop PCs use, but rather to use something a bit more tailored to the tasks that the console really needs to perform. There are hundreds of different applications for CPUs, and using the same general-purpose architecture in all of them is simply not practical.
Most games are not open source. If gaming companies decided to freely release their source code (which would basically mean saying goodbye to whatever profits they hoped to make) then it might be feasible to port the code to PC.
squall_leonhart
The Great Gunblade Wielder
thats not to forget that its not just the games primary functions being emulated, but also Audio and Video, which on the actual n64, aren't done the same way as a PC handles them.
- Thread Starter
- #16
Ohhh, now I understand. I incorrectly assumed assembly was a universal language, when it's actually a low-level language specific to the architecture. The libraries, and lines of code specifically written for its instruction set would have to be tweaked, and the fact that the games are closed-source further complicates that problem. I see.
Thanks I.S.T and toasty for all the information. I've learned alot.
However, if I knew exactly what the instruction sets consisted of (I assume x86 and n64 both have a subtract and add function for example) I'd have a more in-depth comprehension. But it all shows how easy it is to look at system specs and complain. N64 emulation as it is (taking up 10x more power on a PC) is probably the best practical solution available.