Nintendo 64?


GAMESHARQ

Still Fresh
Joined
Jun 3, 2010
Messages
45
Anyone know where I can find an N64 emulator for the Wiz? or if one even exists?
 
GAMESHARQ said:
Why won't it exist?

CPU too slow
Not enough RAM
3D acceleration too limited
 
Last edited by a moderator:
The RAM isn't really a big problem, since I guess ROM isn't really accessed that much and so it doesn't cost a lot to page it in. Linux can even do this for you using the MMU. gpSP has never had a major problem with ROMs that can't fit into memory, and those games rely more on accessing ROM directly.

I still imagine no FPU has to hurt for at least something.
 
Exophase said:
The RAM isn't really a big problem, since I guess ROM isn't really accessed that much and so it doesn't cost a lot to page it in. Linux can even do this for you using the MMU. gpSP has never had a major problem with ROMs that can't fit into memory, and those games rely more on accessing ROM directly.
Yeah, as long as you don't have v64 roms. Stupid Bung reversed the byte order when sending roms over the parallel port, so every two bytes are swapped. Most N64 emulators load the entire thing into memory, then swap the bytes if necessary.

You'd also have to reduce the amount of code the dynarec caches, which will slow things down due to more recompiling.

Exophase said:
I still imagine no FPU has to hurt for at least something.
Most N64 games don't have a lot of FPU code. Emulating the FPU in the integer unit might cost you an extra 50 million cycles at most, not insurmountable if you can overclock the processor a little. A bigger problem is the 3D transforms...
 
Last edited by a moderator:
Ari64 said:
Yeah, as long as you don't have v64 roms. Stupid Bung reversed the byte order when sending roms over the parallel port, so every two bytes are swapped. Most N64 emulators load the entire thing into memory, then swap the bytes if necessary.

Unswap it and cache it to SD instead, if you really want that, but byte swapping after page loads is pretty minimal compared to the cost of loading it yourself. But yes, it means you can't just mmap it anymore.

Ari64 said:
You'd also have to reduce the amount of code the dynarec caches, which will slow things down due to more recompiling.

Why? To make more room for the ROM? Just leave as much room as you would for the largest thing in memory.


Exophase said:
Most N64 games don't have a lot of FPU code. Emulating the FPU in the integer unit might cost you an extra 50 million cycles at most, not insurmountable if you can overclock the processor a little. A bigger problem is the 3D transforms...

50 million cycles per what, second? How many FP ops does that correspond to, 1m? 500k? What number are you using? ARM9 is surely a little slower at them than a Cortex-A8 would be, although I doubt the code was optimized for ARM in the Cortex-A8 case so maybe things could be improved a bit (especially if clz is used).

I wonder what potential there is for having T&L on the GPU instead. Wiz can do that much at least.
 
Last edited by a moderator:
Exophase said:
Ari64 said:
You'd also have to reduce the amount of code the dynarec caches, which will slow things down due to more recompiling.

Why? To make more room for the ROM? Just leave as much room as you would for the largest thing in memory.
Memory usage in mupen on pandora looks roughly like this:

1 MB .text
16 MB dynarec cache
2-3 MB dynarec block/address lists (dynamically allocated)
1 MB hash tables (mips->native code pointer mapping)
1 MB MIPS code cache (compare to original to check for self-mod)
few MB TLB maps (if TLB used)
<1 MB write-protect map (if no TLB used)
4-8 MB N64 RAM
8-64 MB N64 ROM
2-3 MB other stuff in .bss not listed above
few MB texture cache
20-30 MB shared libs

A lot of it (like the TLB maps) consists of large zero-filled pages that are mapped but don't get allocated by the kernel until some data is written there. Hard to estimate the actual memory usage of stuff like this. The dynarec uses malloc() for the lists of blocks that it compiles, but most everything else is statically allocated. I don't know how much of the shared libraries (X11, SDL, etc) need to be in memory either, but it's not unusual to see the RSS at 80MB or so (the vsize is well over 100 MB).

On the wiz you can get rid of a lot of the X11 libs, gtk, etc. I don't know exactly what daedalus is doing on PSP, obviously the dynarec is caching a lot less stuff, so it must be recompiling code more often.


Exophase said:
Ari64 said:
Most N64 games don't have a lot of FPU code. Emulating the FPU in the integer unit might cost you an extra 50 million cycles at most, not insurmountable if you can overclock the processor a little. A bigger problem is the 3D transforms...

50 million cycles per what, second? How many FP ops does that correspond to, 1m? 500k? What number are you using? ARM9 is surely a little slower at them than a Cortex-A8 would be, although I doubt the code was optimized for ARM in the Cortex-A8 case so maybe things could be improved a bit (especially if clz is used).

I wonder what potential there is for having T&L on the GPU instead. Wiz can do that much at least.
Per second. This corresponds to 500k-1m FP ops. Typically emulating a FP operation using integer instructions doesn't take more than a few dozen cycles.

What is the 3D hardware on the Wiz capable of? Shaders?
 
Last edited by a moderator:
Ari64 said:
Memory usage in mupen on pandora looks roughly like this:

Okay, I misunderstood you. I thought you meant paging ROMs would mean less space for everything else, not less space due to RAM constraints on Wiz. 16MB of cache seems like a ton. If I were recompiling N64 on Wiz I'd possibly be a little less aggressive in output than yours.

Ari64 said:
On the wiz you can get rid of a lot of the X11 libs, gtk, etc. I don't know exactly what daedalus is doing on PSP, obviously the dynarec is caching a lot less stuff, so it must be recompiling code more often.

Daedalus is a hot-spot recompiler.

Ari64 said:
Per second. This corresponds to 500k-1m FP ops. Typically emulating a FP operation using integer instructions doesn't take more than a few dozen cycles.

Okay, so no N64 game is very serious about using the FPU. I imagine double precision would need far more cycles to emulate.

Ari64 said:
What is the 3D hardware on the Wiz capable of? Shaders?

Vertexes are (optionally) processed by a geometry processor which has up to 512 instructions, consisting of vector arithmetic (including DP4s with clamping) over 24-bit floats. Backface culling and frustum clipping is performed on geometry afterwards, as well as homogeneous divide and screen space scaling (so the geometry processor doesn't have to do the divides, which it's not very good at)

Several 4bpp and 8bpp texture modes are supported, so you'd probably be able to get away with caching things smaller. Unfortunately, all texture post-lookup formats are 8bpp (luminosity/alpha) or 16bpp (RGB, RGBA, L + A, etc) and the rendering output is probably fixed to 16bpp (with optional dithering).

Pixel pipeline supports two textures.

Color blend operation is over three variables (A, B, C).

A
A * B
A + B
A + B - 0.5
(A * C) + (A * (1 - C))
A - B
And a couple weird ones that bias and average the modulation of the color components.

A and B can be texture, constant, or fragment color or alpha, or the complement of that value. Likewise for C, except it can't be fragment.

The constant seems to be shared between both textures. Strangely, I couldn't find any information on how the two shaded values are actually mixed. So I suppose it's either addition or modulation.

Color alpha blend operation is over the same operations, and all three inputs may be alpha from fragment, texture, or constant, or the complement thereof.

Alpha blending is (source * A) + (dest * B), where source and dest can be source color/alpha or dest color/alpha each (ie, you can make source dest and dest source if you wanted, or two source), or the inverse thereof, or zero or one.

Bilinear filtering is supported. So is fogging.

Z-buffering is only 16-bit. You can change the scale factor, so it might be a good idea to render the "near" and "far" geometry separately or something.

As far as I can tell, textures must be swizzled in address bits 8 and 9. To support render to texture the hardware actually allows swizzling the render output. Texture cache is 8KB.

I could probably write a lot more, but I suppose it'd be better if I just answered specific questions from here.
 
Last edited by a moderator:
Exophase said:
Okay, I misunderstood you. I thought you meant paging ROMs would mean less space for everything else, not less space due to RAM constraints on Wiz. 16MB of cache seems like a ton. If I were recompiling N64 on Wiz I'd possibly be a little less aggressive in output than yours.
The 16MB represents about 1MB of original MIPS code. About 2/3 of the space is used by exception handlers in the block epilogue. This code is necessary, but gets run infrequently. It would be possible to reduce the size by using a lookup table to determine the register mapping rather than generating an instruction to save each cached register. Of course that would add some complexity, and trying to cram the emulator into less than 32MB wasn't a design goal.

Exophase said:
Ari64 said:
On the wiz you can get rid of a lot of the X11 libs, gtk, etc. I don't know exactly what daedalus is doing on PSP, obviously the dynarec is caching a lot less stuff, so it must be recompiling code more often.

Daedalus is a hot-spot recompiler.
I know that, but what I was wondering was how large the cache is and how often it has to recompile code.

Re Wiz 3D hardware: That's actually not that bad, although the N64 undoubtably has some texture modes that it can't handle natively. Most N64 games only have 16-bit color and 16-bit z-buffer.
 
Last edited by a moderator:
Ari64 said:
The 16MB represents about 1MB of original MIPS code. About 2/3 of the space is used by exception handlers in the block epilogue. This code is necessary, but gets run infrequently. It would be possible to reduce the size by using a lookup table to determine the register mapping rather than generating an instruction to save each cached register. Of course that would add some complexity, and trying to cram the emulator into less than 32MB wasn't a design goal.

Or at least, it's necessary based on your design. I don't know if there are other approaches that would have competitive performance otherwise, but there are certainly other approaches. But yeah, LUTs would use a lot.. anyway, no one's criticizing you for designing around the RAM constraints you did (and not Wiz's). I'm not sure where you get "less than 32MB" though, since Wiz has 64MB of RAM.

Ari64 said:
I know that, but what I was wondering was how large the cache is and how often it has to recompile code.

You said that it'd have to recompile code more often because it has a smaller cache. This isn't necessarily true because a) it doesn't recompile everything and B) by virtue of it not generating as much code to begin with. I don't know how often it has to recompile due to overflowing the buffer spcae - the impression I got from StrmnNrmn's posts is that at least for some games it's never.

Ari64 said:
Re Wiz 3D hardware: That's actually not that bad, although the N64 undoubtably has some texture modes that it can't handle natively. Most N64 games only have 16-bit color and 16-bit z-buffer.

Different formats are fine, since texture copying is inevitable due to required swizzling. It's surprising N64 games use 16-bit zbuffer given how bad I'd expect it to be; does it really help with RDRAM transfer speed or is it just a matter of saving space?

One thing about Wiz is that hitting the 3D hardware bare metal is at least a realistic option, much more so than it is on OMAP3 devices. And given how much time glesN64 is spending in the driver this could make a big difference. The command buffer on Wiz's GPU should allow for even the most complex state changes to be queued asynchronously (for the next frame) and without adding any substantial overhead. Vertex shading doesn't take any other resources from the chip, but 24bit floats may not be enough precision for the 3D emulation (I dunno, you tell me)
 
Last edited by a moderator:
Exophase said:
Or at least, it's necessary based on your design. I don't know if there are other approaches that would have competitive performance otherwise, but there are certainly other approaches. But yeah, LUTs would use a lot.. anyway, no one's criticizing you for designing around the RAM constraints you did (and not Wiz's). I'm not sure where you get "less than 32MB" though, since Wiz has 64MB of RAM.
But on the Wiz 32 MB is reserved for... um, what exactly is the 32MB reserved for? Or was that only on the GP2X?

You could avoid the register writebacks by not caching registers, but that wouldn't be very efficient...


Exophase said:
Different formats are fine, since texture copying is inevitable due to required swizzling. It's surprising N64 games use 16-bit zbuffer given how bad I'd expect it to be; does it really help with RDRAM transfer speed or is it just a matter of saving space?
I don't know if it's a hardware limitation or what, but every game I checked used 16bpp and 16-bit zbuffer. The z-fighting is quite obvious on a real N64.
 
Last edited by a moderator:
Ari64 said:
But on the Wiz 32 MB is reserved for... um, what exactly is the 32MB reserved for? Or was that only on the GP2X?

Yeah, GP2X.. it's "reserved" in the sense that it's not userspace allocatable in Linux but you can still mmap it. It's for sharing with the ARM7 and other peripherals like video. Obviously you don't actually need that much for normal tasks and it was just a silly design on GPH's part.

On Wiz the amount reserved is 16MB, and again you can still use it, although obviously you need more of it for 3D.

Ari64 said:
You could avoid the register writebacks by not caching registers, but that wouldn't be very efficient...

A compromise is to use static allocation, but it's a pretty moot discussion.

Ari64 said:
I don't know if it's a hardware limitation or what, but every game I checked used 16bpp and 16-bit zbuffer. The z-fighting is quite obvious on a real N64.

Is the Z-fighting better in emulation then? And do games use different Z ranges for sets of geometry? Since that'd involve some sorting I'd suppose not.
 
Last edited by a moderator:
Exophase said:
Is the Z-fighting better in emulation then? And do games use different Z ranges for sets of geometry? Since that'd involve some sorting I'd suppose not.
Most emulators use a 32-bit z-buffer. No glitches visible at all. On a real N64, stuff overlaid on floors and walls would flicker like crazy.
 
Last edited by a moderator:
I love how Ari64 and Exophase use to crash your everyday average Joe emulator questions with highly in-depth technical pro discussions/derailments, much like Zeus and Kronos descend from the heavens to unleash a fiery battle on the world of the mortals, leaving a trail of destruction on the minds of the technically incapable general population.

Go on.
 
Exophase said:
A compromise is to use static allocation, but it's a pretty moot discussion.
You brought this up before, but I don't remember if I replied. Doing a static allocation for N64 (or MIPS in general) isn't straightforward.

If the game follows the ABI (most do, but not all) then of the 31 registers, 2 are reserved for the OS and 10 are temporaries, so there's no point in keeping those in registers when jumping between blocks. Compilers often omit the frame pointer, so keeping that in a register isn't useful either.

Of the remainder, statically allocating the stack pointer would probably be useful. During a function call, the arguments and link register would be useful to have in registers, but during a return, the only thing you need is the return value (1 or 2 registers). If the function arguments were statically allocated, you'd have to load a bunch of stuff into registers only to discard it when returning to the caller.

I can see an argument for statically allocating the stack pointer register and link register, but I don't see any clear advantage with the rest. I don't think there is any magic register allocation that's going to solve these issues, so maybe it is a moot discussion, as you say.
 
Last edited by a moderator:
Wolfsclaw said:
I love how Ari64 and Exophase use to crash your everyday average Joe emulator questions with highly in-depth technical pro discussions/derailments
What do you feel would be an appropriate response to "Why won't it exist?"
 
Last edited by a moderator:
Ari64 said:
Wolfsclaw said:
I love how Ari64 and Exophase use to crash your everyday average Joe emulator questions with highly in-depth technical pro discussions/derailments
What do you feel would be an appropriate response to "Why won't it exist?"

After reading my post again, I felt that it would be read as criticism, but I couldn't bother to edit :)
Much less did I mean to critizise than to add my amusement about the fact that there are several Ari64 vs. Exophase superhero battles to be found throughout the forum, which are probably understood by less than 10% of the forum population, due to the very high tech-savvy level. It leaves some dev people nodding with a calm face, but the majority will be probably like "What the hell am I reading? LOL!", which, at least in my head, is a hilarious thought (also since noone dares to interfer with a "I DONT GET IT" under the fear of being titled a "n00b" by those that kept quiet out of the very same lack of knowledge).
Well, I probably just have a weird sense of humour. That's what my girlish roommate tells me anyway.

:D

For a more direct answer, "CPU too slow
Not enough RAM
3D acceleration too limited " was pretty much sufficient for those mentioned ~90%, as it summed up the answer and is understandable for everyone.

Nevertheless, the remaining ~10% will certainly be appreciating your detailed explanations. That's why I said "Go on.", which I did not mean ironic, if you picked it up that way, i'm sorry for not having myself expressed in a better way.

I hope I got my point across even with my limited english capabilities :) (Gee... thinking in English after having watched a French film with German subtitles is kind of confusing)
 
Last edited by a moderator:
After reading my post again, I felt that it could be read as criticism, but you already replied :)

Exophase likes to derail threads, but in this case the original poster did ask why it wasn't possible, so it wasn't off-topic.

My first thought was to write "Is the search function broken?" but I thought maybe that was too mean, so instead I answered his question.
 
Back
Top