nesdev.org

Anyone every try doing one ? just for the heck of it ?

just recompile an emu's code for a 64-bit target. i don't really think you're going to gain much with a 64-bit NES emulator. there isn't really anything a NES emu would need to do that is going to gain performance. in my emu for example, the only 64-bit calculations i'm doing are keeping track of how many CPU clocks have been executed and getting timestamps via QueryPerformanceCounter.

well yeah i understand that but just for the heck of it
maybe someone did , just curious

FHorse has 32-bit and 64-bit binaries for linux in his PuNES thread.

http://dl.dropbox.com/u/21595068/punes.64bit.tar.gz

Yes, let's use the full 64-bit set of registers just so we can then proceed to the use low 8-bits of each register. Even 32-bit math is overkill for the CPU part of a NES emulator, since the x86 can natively use the low 8 bits of a register for 8-bit math, almost as if it's a Z80.

Dwedit wrote:Yes, let's use the full 64-bit set of registers just so we can then proceed to the use low 8-bits of each register. Even 32-bit math is overkill for the CPU part of a NES emulator, since the x86 can natively use the low 8 bits of a register for 8-bit math, almost as if it's a Z80.

yeah. hell, you could even compile to 16-bit real-mode code and you probably wouldn't see a bit of difference between that and 32-bit.

I seem to recall using the 32bit size of integers for helping in rendering. I forget what exactly now, but it had to do with drawing strips of tiles.

miker00lz wrote:you could even compile to 16-bit real-mode code and you probably wouldn't see a bit of difference between that and 32-bit.

It's just that the 64-bit operating systems shipped on PCs nowadays have dropped support for 16-bit modes. Home versions of Windows went 32-bit in 1995 (Windows 95) and 64-bit in 2006 (Windows Vista). I wonder how long latest version of majority OS will continue to support 32-bit code without needing a separate copy of the operating system run in a virtual machine.

The 64-bit version of nemulator is slightly faster (a couple of %, IIRC). Presumably the additional registers help.

James wrote:The 64-bit version of nemulator is slightly faster (a couple of %, IIRC). Presumably the additional registers help.

if you're very clever, you could probably figure out a way to get a small boost with 64-bit regs; maybe in some video filtering/stretching algorithm or something, but there is nothing in the basics of NES emulation that is going to benefit.

I found that QuickNES was a good 50% faster when built with MSVC 64-bit, compared to 32-bit. Of course that was in 2009, so it was obviously built with MSVC 2008.

For example, running Battletoads (U) into a null output with no throttling, for 4 seconds:

32-bit:
Performance: 8684 frames per second, which would use 0% CPU at 60 FPS

64-bit:
Performance: 12621 frames per second, which would use 0% CPU at 60 FPS


Did I mention that QuickNES also benefits from having more registers to play with?


I should recompile these benchmark tools with MSVC 2010, and also see if the cycle count changes I've made since then affect anything much. Also note that GCC 64-bit, at least when I tested it back then, performed barely better than the MSVC 32-bit build.

Any better suggestions for a demo or test or whatever which would be more taxing on the emulator, without requiring any user input?

Of course, all this is irrelevant for real-time emulation, until you get to the high speed fast forwarding and movie seeking that QuickNES also supports, enhanced by keeping snapshots every 5 minutes or so.