Search results

Yes, you can specify the rom name on the command line.

The current GUI is the gtk GUI from Mupen64Plus v1.5. I didn't modify it at all. One of the changes in 1.99.4 is that you can replace the GUI. Maybe someone wants to try writing one? I haven't looked into it.

He removed all references to mupen64plus too. He is not acknowledging any of the developers. Several people have asked him for the source code and he hasn't responded. This isn't some minor misunderstanding.

Yeah, there is nothing in the R4300 instruction set that is similar to the ARMv6 SIMD. Is SIMD with two 16-bit values or four 8-bit values in a 32-bit register really all that useful?

I made an option in the mupen64plus dynarec to compile without ARMv6/ARMv7 (so it can theoretically run on Caanoo). The difference was around 2% or so, not huge. Lack of FP/NEON makes a much bigger difference.

Two instructions per clock, hardware FPU, L2 cache, faster RAM, and the expanded instruction set gives somewhat better throughput.

Precisely. Paulscode and Cpasjuste told me why it wasn't building on Android, so I included a fix in the latest version. I never tried to run it on Android since I don't have any Android devices.

The genjmp() function existed before, but in 20110128 I added the jump table, which is one of the things required to accommodate Android's memory layout. If you can find this table, you can find pointers to most of the rest of the code, even if he stripped the binary. I wonder how difficult it...

There is evidence that it is, but yongzh reportedly stripped out the credits and is trying to pretend he wrote it himself. He is not sharing the $5.99 with any of the developers.

It has a working mmap, but the memory layout is a bit weird. Apparently there is something at 0x80000000 and you can't map the ram there.

You can drop the load_all_consts/wb_dirtys/wb_consts too. Those values are only used if a pagefault occurs. I added that because people were complaining that it wouldn't run on Android. It's not necessary for Pandora or Maemo.

This isn't necessarily a problem. The dynarec cache is invalidated by a write to this page (800d3000) however get_addr() later finds that the code is unmodified, so it marks the page as possibly valid. Another write then marks the page invalid again. The real work occurs in clean_blocks...

In most cases, new_recompile_block() is a small percentage of the total CPU time, so I haven't looked at where the time is being spent. A lot of things get inlined into this function, so you might have to remove "static" from some functions if you want them as separate symbols. If it's only...

The dynarec was designed to handle this. If the old code module is still in the cache, it will recognize this and not recompile it. Can you profile this and see where the time is being spent?

One goal is to merge with 1.99.4. Mostly that depends on improving x86-64 support and the graphics plugins. There are a few minor things to fix in the dynamic recompiler. There's the r31 in the delay slot issue, and I noticed that I missed a case where MFC1 can write r0. I don't have a good...

Yes, I built mesa from source. The maemo folks ripped out osd and screenshots also. I guess I should make it easier to compile without OpenGL. You said it wasn't easy to build, so I was wondering what would make it easier. If it's just libGL and cross-compiling, that's not too bad. I'm not...

huh? Hmm... The makefile is mostly the same as the original mupen64plus, which uses uname to determine the host cpu type. I don't know of a good way to do this in general when cross-compiling. OE sets TARGET_SYS, but I'm not sure that works for other build environments. Was there anything...

Yes I am building it on beagle. It's fairly straightforward; just install the dependencies then type "make mupen64plus". The plugins need to be built separately. I looked at the PND that jdbye and paulguy built, and it appears that they changed some of the pathnames (configuration files, etc)...

Separate patches: http://bunnitude.com/ari64/patches/patches-20101026-20110128.tar.gz I'm not against the idea, but to make a more generic emulator would require at least: - An option to reverse the endianness - An option to disable the TLB - An option to disable the FPU - An option to disable...

Yeah, because writing emulators is totally useless. Nobody would ever want to do that.