Search results

I recreated the PND. Now it's visible in PNDManager. I don't know what I did wrong in previous attempt.

I don't know, but if you look at the host part of socket emulation in WinUAE, there's a lot of code required. It's on my todo-list, but only with low priority.

I increased the last digit, so the new number is 1.0.0.2

I have no idea why PNDManager can't see the new version. I added this to the Repo the same way as always...

Ok, found the bug (uninitialized pointer in hardfile.cpp). Corrected version in Repo.

It seems that the new version of gcc did something unexpected. I try to compile again with gcc 4.9. Strange... compiling on my VM (with gcc 4.3), HDF is ok, compiling on Pandora (with gcc 4,9 or 5.2) HDF crashes entire emulator.

In Repo is a new version of UAE4ARM with these changes:  - Switched to newer picasso code from WinUAE. Works much better, even with JIT.  - Minor update of sprite handling  - Corrected cpu cycle count in exceptions  - Minor graphic gliteches fixed (Love-Demo)  - Compiled with gcc 5.2 Source: 

1. The Pandora has only 256 MB (Classic) or 512 MB of RAM. I don't want to allocate such an amount of memory. This will result in heavy use of the swap partition. 2. The interface between bsdsocket on Amiga side and network on host side has changed between different versions of UAE. When I have...

The cycle count for 68000 opcodes are corrected, added option to disable fast copper, fixed handling of switching between configs with and without HDs and some minor changes.   The slowdown of sound isn't fixed now. I wasn't able to find the reason for this problem till now. Hope to get this...

Here you find the first release version of UAE4ARM, a new Amiga Emulator based on UAE4ALL. The main differences to UAE4ALL:  - Different 68000 core (newcpu instead of FAME/C) with support for 32 bit addressing mode  - Support for 68030 and 68040 cpus  - FPU (68881, 68882 and internal 68040)  -...

Here is another alpha version with these changes:  - JIT: minor optimization of emitted ARM code  - JIT: bugfix for cycle count  - JIT: bugfix in emitted code (CMP.W, CMP.B, TST.W and TST. B)  - JIT: disabled option which caused many problems in Picasso96 (JIT now ~15% slower...)  - Fixed...

I'll have a look at this code and try to find a solution. Thanks for the hint.

I have no idea how to solve this one, because I get the mouse movements from SDL and in some situation, these calls reports no changes in one direction anymore. Perhaps something with calibration...

This indicates the idle time in percent of the Pandora CPU (there is a bug somewhere, because in some situation, this shows 100 and needs some time to recover to show correct values)

Thanks for the feedback. Hope to fix this in next release.

Can you post a link to the download of the version you used?

Here is another alpha version of UAE4ARM with following changes:  - Commandline options available:    -config=/path/file.uae to load specific config file (set option use_gui=no in config file to start without showing gui)    many other options like in WinUAE  - JIT now save for 24-bit CPUs...

Commandline switches will come in one of the next releases.

I will port UAE4ARM to the Pyra as soon as I have a device and a development environment setup. This was one of the reason I start with UAE4ARM and I think we will get cycle exact emulation on the Pyra because of higher cpu speed and two cores.

If you check the option "Custom controls" in Input settings, the mapping works fine.