Dynamic Recompiler not working for me...

[X-Fi6]

When I've tried to build the Mupen64-amd64 1.1 and 1.2 under Windows, for some reason Dynamic Recompiler doesn't seem to work. Whenever I load a ROM, after it says 100%, it stops, and not even the FPS counter comes up. It's just a black screen.

When I switch to Interpreter it works fine.

And when I switch to Pure Interpreter the program completely crashes.

This is when it's compiled as x86 (for some reason I can't get it to freaking compile in x86_64--I changed all the x86's to x86_64s in mupen64.dev and makefile.win and loaded the custom makefile but that still doesn't work)

Ideas?

Also whenever I load a ROM, when I reset Mupen, it says "Unknown Dump" as its name (so I have absolutely no idea which ROM is which), but when I refresh the ROM list it works again.

 

[Richard42]

When I've tried to build the Mupen64-amd64 1.1 and 1.2 under Windows, for some reason Dynamic Recompiler doesn't seem to work. Whenever I load a ROM, after it says 100%, it stops, and not even the FPS counter comes up. It's just a black screen.

When I switch to Interpreter it works fine.

And when I switch to Pure Interpreter the program completely crashes.

It's not good that the Pure Interpreter doesn't work - that should be the most stable of all 3 cores, because it is the simplest.

The only way to fix these things is for somebody to bust out the good old Visual Studio debugger, find the problems, and fix them. For the dynamic recompiler, I would bet that the problem lies in r4300/x86/rjump.c - this is the entry/exit point for the dynamically recompiled code, and is the trickiest part to get right.

Getting Mupen64 to compile and run for 64-bit under Windows will be hard. For one thing, it will require a 64-bit Windows installation. To run 64-bit applications requires both a 64-bit CPU and a 64-bit OS. Secondly, you may have to re-write a boatload of code, because all of the 64-bit porting changes that I made assumed the use of GCC, which uses 64-bit 'long'. If the compiler used for the Windows build does not have the same data model, then a lot of code will have to be changed. But the final unfortunate fact is that even if someone did all the work to make this compile and run under Win64, it would mostly be a waste of time because the 64-bit ABI (the interface between C function calls) sucks for Win64, and unlike Linux, any applications that are ported from 32-bit to 64-bit Windows will probably not be any faster than their 32-bit counterparts. Their are exceptions (high-precision scientific computing apps), but for most general-purpose applications, it's better to stick with 32-bit in Windows.

 

[smcd]

But the final unfortunate fact is that even if someone did all the work to make this compile and run under Win64, it would mostly be a waste of time because the 64-bit ABI (the interface between C function calls) sucks for Win64, and unlike Linux, any applications that are ported from 32-bit to 64-bit Windows will probably not be any faster than their 32-bit counterparts. Their are exceptions (high-precision scientific computing apps), but for most general-purpose applications, it's better to stick with 32-bit in Windows.

VC++ uses LLP64 (since Windows uses LLP64) and Linux uses LP64. There will be several caveats to a compiled version on Windows for the ported 64 bit code. http://en.wikipedia.org/wiki/64-bit

 

[Richard42]

VC++ uses LLP64 (since Windows uses LLP64) and Linux uses LP64.

Yeah, I know VC uses 32-bit ints and longs. But it seems people have been using Dev-C++ to build Mupen64 on Windows, and I don't know what compiler that toolkit uses. It's also possible to use GCC on Windows via Cygwin/MinGW, and I don't know what data model is used in this case.

 

[Hacktarux]

Dev-C++ is simply a gui packed with mingw gcc port. Last time i checked there was no mingw for 64 bits windows.

 

[X-Fi6]

Ah since I saw there was a Linux port for x86_64 I thought it already worked for Windows (I'm using XP x64 in case you're wondering). So nevermind that.

Simply put, Dynamic Recompiler doesn't work for me (I got Pure Interpreter to work), and whenever I load a ROM, when I reset Mupen it says "Unknown Dump", and I have to refresh the ROM list to get it back.

 

[smcd]

I would hazard a guess that if there's a GCC port to Windows 64 it would have to use the LLP64 mode so Windows wouldn't freak out, but that's entirely speculative

 

[nmn]

Correct. Or so I think, considering the data model would effect the data structures of windows.h. Though in practice, not counting windows.h it shouldn't cause binary incompatibilities (though i think theres another set of headers for amd64)

 

[X-Fi6]

So, Richard42, did you add those two bugs to your list yet?

1. In the Windows port, Dynamic Recompiler does not work.

2. After loading a ROM and closing it / loading a ROM and restarting the emulator, the ROM appears as an invalid dump in the Good Name. You need to refresh the ROM list to reset it back to its normal Good Name.

 

[ebenblues]

So, Richard42, did you add those two bugs to your list yet?

1. In the Windows port, Dynamic Recompiler does not work.

2. After loading a ROM and closing it / loading a ROM and restarting the emulator, the ROM appears as an invalid dump in the Good Name. You need to refresh the ROM list to reset it back to its normal Good Name.

Just wanted to note that the major refactor I just did to combine the gui/nogui versions of mupen64 did not take the Windows port into account at all, so getting a Windows port for the next version of mupen64 will be non-trivial. Btw, is it possible to compile mupen64 using cygwin and gcc, statically link it and run it on Windows machines that don't have cygwin/gcc installed? Just wondering if this might be an easier route for a Windows port or if that's a terrible idea...

 

[smcd]

I think if you compile it through cygwin you may have to include the cygwin dll(s) along with it, which probably isn't *too* big a deal.

 

[ebenblues]

I think if you compile it through cygwin you may have to include the cygwin dll(s) along with it, which probably isn't *too* big a deal.

That's why I was suggesting to statically compile it, but that will (greatly?) increase the size of the exe.

 

[Richard42]

So, Richard42, did you add those two bugs to your list yet?

1. In the Windows port, Dynamic Recompiler does not work.

2. After loading a ROM and closing it / loading a ROM and restarting the emulator, the ROM appears as an invalid dump in the Good Name. You need to refresh the ROM list to reset it back to its normal Good Name.

I added the Good Name problem to the TODO list. Regarding the Windows port, it seems increasingly likely that we'll officially drop it. We've been working on this thing and moving it forward for the last 6 months, with testing and development only being done under Linux. The Win32 port is very broken now - Rice Video won't work for Win32, the GUI has totally changed and needs to be re-written, etc. I want to continue to focus on making this the best possible N64 emulator for Linux because it's the only one.

Unless a Win32 developer volunteers to refactor the Win32 GUI for the new architecture, fix all of the porting issues, and maintain the Win32 port going forward, then most likely Mupen64Plus will be unix-only.