Search results

thanks. Don't think that gnostic keeps the github up to date, hence the rapidshare link. Hopefully some work optimising p-UAE will give a decent speed amiga emu in the same mould as winuae, rather than just an A500 emu...

p-UAE is based on e-UAE and winuae, not uae4all. I believe.

So... are you using the original UAE (0.8.29), reportedly with iffy AGA support... or... E-UAE, 0.8.29-WIP4 (with SDL backend/OpenGL I think, meant to be faster than UAE, and includes improved emulation fixes ported from WinUAE....) .. Either way, any chance you could take a look at Gnostic's...

Pandora is still - just about - hitting the sweet spot, although less so than since the original "world's fastest handheld" - I doubt it is anymore. Nvidia has made a Tegra 2 SOC - Dual Cortex-A9, and six other chips (Image/HD decode/HD encode/Audio/Gfx/Arm7) all in one SoC. Very low power...

Just a heads up that Gnostic released puae 2.0.1 a few days ago to the UAE mailing list. It's picked up some interest in the non-pandora world as someone has finally ported all the latest WinUAE core features/compatibility to a Linux platform... No info on speed/stability yet. Here is his...

They've fixed some bugs in Rice Video as well which stopped some games working, so good news all round. Hopefully not too much hassle for the devs here to align their code to the new version, although I suspect there is not much point at this stage, at least until either Pandora's ship (in 2...

Adventus has a GL -> GLES wrapper. No idea how complete it is, currently producing some graphics for Mupen64plus. If it does the job, probably the quickest way to get something running.

Rom changes are a good reason to settle on a sweet-spot mame. Then it should only be a handful of games which need an older version compiled for speed reasons. Seeing as ARM Asm cores for 68000 and z80 exist and are regarded as highly accurate (cyclone 100% compared to Mames C core I believe)...

good point, although will interesting too see how it does on multiple 68k/z80 games, although there are not that many... Are you planning to port yourself?

There was a lot of chat about mame versions a year ago. see this thread (slaanesh knew his stuff): http://www.gp32x.de/board/index.php?showtopic=44848 Basically, Pandora is capable of running a later version than the mame4all (gp2x) is based around. Also, here is a post I made about pacman...

The image is clearly being stretched horizontally. It is not rendering for a wider view (which is, as commented before, very glitchy when implemented on other emulators). It's easier to see on the Title - look at the "super mario 64" text, or marios face, in the videos and then compare to an...

Thanks, no I hadn't - not from this thread, it seems. So it's cpu bound. Roll on profiling... Probably worth noting that a big rewrite of Mupen64plus kicked off this month, re-structuring the project for v2. Probably worth avoiding any work optimising anything that isn't part of the ARM dynrec...

Yes, I'd always for resolutions scaled from the original - 640x480 in this case. But I figured I minor point at this stage - surely it's just a setting in the video plugin? Also: Interesting that there now is a significant speed increase with clock speed increase, which was reported as not...

Sorry, my post was not clear. I believe the Cortex-A8 has compile-time options for generating Thumb or ARM code (or a mixture). I believe both can do FP operations on the Cortex-A8. However, I have read that for FP intensive programs, using Thumb opcodes can have a significant negative impact...

Bit OT, but does Cortex-A8 default to Thumb-mode on? I assume for this (an other emus, floating point work) you'd want it off?

Really impressive performance so far. Great work. Will be interesting how close you get to 100% DC speed once the FPU opcodes are Neon-ised/optimised. I would think HLE would be a likely candidate for sound, as I can't see much call for an Arm7 dynarec for Coretex-A8 outside this emu? It might...

Well 50% free for the audio/video/overhead sounds quite good at this stage. (esp as I think you are running on a 600MHz Beagleboard). Interesting this is faster than the x86 mupen core. And yes, would make sense to mature the code before incorporating back into anything else. Thanks for your...

Nice to see you've picked up a 5% and then another 3% on that through various suggestions in the thread. Maybe not your prime concern, but always nice to see... Can I ask if you are submitting your core the mupen64plus project to incorporate, or will it be a branch project? I note that...

Thanks, that has cleared it up for me.

That sounds quite PSP specific to me... you're not going to be running the embedded elf on anything else, unless you replace it with an appropriate-platform executable. And if you do that you have basically changed the format anyway.... I asked as I've only heard of eboots being used on PSP's.