GAMESHARQ said:Why won't it exist?
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.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.
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...Exophase said:I still imagine no FPU has to hurt for at least something.
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.
Ari64 said:You'd also have to reduce the amount of code the dynarec caches, which will slow things down due to more recompiling.
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...
Memory usage in mupen on pandora looks roughly like this: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.
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.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.
Ari64 said:Memory usage in mupen on pandora looks roughly like this:
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.
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.
Ari64 said:What is the 3D hardware on the Wiz capable of? Shaders?
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: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.
I know that, but what I was wondering was how large the cache is and how often it has to recompile code.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.
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.
Ari64 said:I know that, but what I was wondering was how large the cache is and how often it has to recompile code.
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.
But on the Wiz 32 MB is reserved for... um, what exactly is the 32MB reserved for? Or was that only on the GP2X?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.
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.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?
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?
Ari64 said:You could avoid the register writebacks by not caching registers, but that wouldn't be very efficient...
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.
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.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.
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.Exophase said:A compromise is to use static allocation, but it's a pretty moot discussion.
What do you feel would be an appropriate response to "Why won't it exist?"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
Ari64 said:What do you feel would be an appropriate response to "Why won't it exist?"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