Search results

Has Hydro Thunder ever worked reliably in any version of mupen? #define CLOCK_DIVIDER 1seems to make it work better, at the risk of making the emulator run slowly.

So it works for paulguy... did you figure out what was wrong with your build? How did you fix that? I've noticed that problem with OoT and never knew what caused it.

There must be something unusual about your setup, because the GUI is unmodified from mupen64plus v1.5, and works on many different Linux distributions. Try clearing your configuration files.

That's it. You should only need the first three patches. Crashes after what logo? I haven't seen anything like this. The GTK GUI works fine for me. What triggers this crash?

This has been a problem with Angstrom for a long time. You need to compile mesa from source, or at least that's what I did. You can then install libglu-dev with opkg install --force-depends. Alternatively, you can remove the OpenGL code from the mupen64plus core. There's a patch to do this...

A8 has a latency of 3 cycles for instructions which access the L1 cache. Assuming the first cycle is for address generation, the actual L1 access takes 2 cycles. The instruction cache is also 2 cycles, but they manage to squeeze in some minimal instruction decoding to check for branches during...

That was the result of banchmarking the dynarec without video or audio output. I'm not sure what the speedup would be in terms of framerate.

I suspect that most of the speedup comes from eliminating the branch (mis)prediction penalty and stack overhead of calling C functions for a lot of the floating point stuff. Also the way gcc tested for NaNs was horribly inefficient. I now do it with fcmp/fmstat. There are still C functions...

Install gcc and the required libraries (see first post) and then do 'make mupen64plus'. You will need to compile gles2n64 and the input plugin seperately. I'm actually not sure which versions of these were used in the PNDs that are on apps.openpandora.org, so I can't help you there.

It now generates VFP instructions properly, which is around 5-10% faster. Also fixed issue 333.

http://bunnitude.com/ari64/mupen64plus-arm-20100929.tar.gz Changes since 20100819: - Optimized floating point code - Save state / load state - Improved constant propagation - Properly detect self-modifying code in virtual memory

Well, there's this one... https://tuxnes.sourceforge.net x86 only though That's what it seems to be doing. Which games need exact timing precision?

It's a bit unusual, but not necessarily a bad design. They are using a 'Micro TLB' cache to quickly handle frequently-used mappings. It might add one cycle to the load pipeline. The overhead from something like this typically isn't going to be more than a few percent in the average case. I...

I tried setting the flags earlier and saw no difference, at least not for correctly-predicted branches. http://www.arm.com/files/downloads/Cortex-A9_Devcon_2007_Microarchitecture.pdf The prefetch stages look pretty similar to the A8, except that the GHB/BTAC is now two pipeline stages instead...

So you're asking if slow memory would make a Dreamcast emulator slow? I fail to understand why you think it would not.

The branch predictor appears to operate directly on the data coming out of the i-cache. If the branch is predicted taken, then the target is looked up in the BTB. Presumably the BTB lookup takes one cycle, so there's a delay before the next pair of instructions is fetched. It wouldn't...

Generally no. The RAM in the Pandora is clocked low, but that's not the only problem. The cache is small compared to other CPUs like Intel's Atom, and there is only a 32-bit data path to the RAM. Most laptops have at least 64-bit RAM nowadays.

After reading this thread, I benchmarked a memcmp that I have been using. This is part of the dynarec and checks if a previously compiled block is unmodified. The relevant portion is: /* r1 = source */ /* r2 = target */ /* r3 = length */ tst r3, #4...

I can send you the patches that I use to benchmark the dynamic recompiler, if you want. It's basically just some timers that add up how much time is spent in certain parts of the code. I'm curious too, but not enough to spend $180.

My beagleboard is a rev C3 - It has a 3530 like the Pandora. But if you want to send me a Beagleboard-XM, I'll benchmark it.