blitterstudio / amiberry Goto Github PK
View Code? Open in Web Editor NEWOptimized Amiga emulator for Linux/macOS
Home Page: https://amiberry.com
License: GNU General Public License v3.0
Optimized Amiga emulator for Linux/macOS
Home Page: https://amiberry.com
License: GNU General Public License v3.0
Uae4arm seems to miss support for more complexe HDF which contains more than partitions and files bigger than 2Gb.
Currently keyboard input does not work correctly.
It needs to be updated to SDL2 standard calls.
The CD emulation is only(?) for CD32 pr. date. Would like to be able to mount a iso (AmigaOS 3.5 and 3.9)
I can't install the Amiberry... The rasp starts with the SD card, but at the end of the script, eth0: not found... same with wlan.
an other sd card wirh a standard system works...
I haven't tested this myself, but a lot of people say that it only supports HDF's up to 1 GB in size. I have always used a 1 GB HDF formatted to PFS3 but it would be good if it supported larger harddrives with RDB as there is also a 5 HDF mount limit.
AmiKit X (and probably older versions also) show a significant slowdown when redrawing the Picasso screen.
We should try and optimize the functions responsible.
Any chance to add free assign key to entry GUI when Amiga working ? For users (like me) which using keyrah2 is not possible to us F11 or F12 key to entry GUI.
Investigate how plausible the following scenario is:
Have the emulator itself control the host system's screen resolution.
E.g. change to 800x600 50Hz for PAL resolutions, 800x600 60Hz for NTSC, but switch to native (1080p 60Hz max) for Picasso96 ones.
Note: The emulator currently opens a "dummy" SDL screen on the host's native resolution and uses that to render the RGB surface requested. If a PAL resolution is requested, the RGB Surface uses the PAL width & height, which is then scaled to the SDL screen using DispmanX (if using that back-end).
If instead the emulator closed the SDL screen and opened a new one with the requested dimensions, it should improve the performance as less effort in scaling would be required.
In the config GUI->ROM, when clicking the "..." button to browse for a ROM file the screen goes black.
Add these new Picasso96 modes:
1366x768
1360x768
So libretro API expects to serialize state directly into memory and and all UAE forks have file based API (due to compression I suppose). Hence non of the libretro ports out there support savestates. Is it possible to implement this?
Edit: this is an issue with DispManX in general, not specific to the emulator.
There are a few problems if the (experimental) OpenGL driver is installed in the system:
xinit
.Note: The above apply when using the (currently default) approach of DispManX + SDL (v1). Tests showed that the SDL (v1) compile works without those problems, though it's many times slower.
Suggestion: move the emulator to SDL2. It should provide us with a nice speed boost also, since we can use GPU accelerated functions for the display.
When enabling the drive lights they appear at the bottom middle of the screen with a black bar all the way to the right of the screen.
Hi all!
Well, my suggestion is pretty simple: Would be possible to add support for floppy drive sounds like WinUAE ones?
I would love hearing my Pi like my old A500 when the floppy was loading :3.
See ya!
The keyboard LEDs (Scroll Lock, Num Lock) do not work as expected when they are assigned functions like drive activity, from within the emulator.
This works if the emulator is running under Raspbian, but not in DietPi. However, the following scenario applies:
xinit
, but not when running in the console framebuffer. However, the functions assigned to the LEDs do not work when running under xinit
.xinit
.Note: The code uses calls to ioctl()
(#include <sys/ioctl.h>) to get and set the keyboard LED status.
Hi all!
I don't know if this is a bug or there is another working key combination, but i tried restarting the emulation with Ctrl+Left windows+Right window (would correspond to Ctrl+Left Amiga+Right Amiga i think) and the key combination doesn't seem to be recognized. Nothing happens.
See ya!
Hi, I just compiled your SDL2 version on the Pi 3 and noticed the following -
'Fast Copper' has been removed. Is this going to make the emulation a lot slower, especially on a Raspberry Pi ? On testing the demo 'Big Time Sensuality AGA' the sound slows right down (which didn't happen on the latest UAE4Arm) and the game 'Jim Power' is over 20fps slower.
When enabling the drive lights they appear at the bottom middle of the screen with a black bar all the way to the right of the screen.
Frameskip is on by default ? This reduces the frame rate to 25fps.
When starting a game the screen is about 640x256 even though the Display Options say the screen is 640x200. Is the screen supposed to automatically change resolution ?
Very small mouse pointer in GUI.
Keep up the good work.
Just like WinUAE and FS-UAE have.
Ref no: ccc1f11b-b7bb-4963-8e0c-eecc80de8920-0
I have just tried Amiberry so I can get 1920 x 1080 working which seems to be fine. However if I try opening a game through igame the pointer seems to get stuck in an invisible box on the desktop after the game has closed down.
It seems to happen after trying to get out of the game and I usually have to reset the session using F12 and soft rest in the settings. The invisible box survives multiple resets until the machine is hard rebooted then it goes away.
I'm trying to cross compile this using the LibreELEC toolchain, but running into a build error:
Any ideas? Using GCC 5.4.
Hi all!
Would be possible add support for inserting/ejecting floppies with a key combination like WinUAE?
Like End+F1-4 for inserting a floppy in DF0-3 and Supr+F1-4 for ejecting the floppies.
See ya!
Sorry, more controls stuff. Unfortunately in it's current state, i find it difficult to use uae4arm because of these issues!!
This time it's the "other way around" ... It is not there in the GUI, but maybe it already existing in .uae file config settings ?
The joystick/joypad controller for my PiGrrl machine 'fakes' keyboard presses, by using the GPIO , so not a conventional 'controller' input.
This is pretty easy to do in winuae/fs-uae etc, but i would like to simple add something like keyboard_key_a = joy1_fire_button etc
in the days of E-UAE, i could do something like this:
input.1.keyboard.0.button.17=JOY1_UP
input.1.keyboard.0.button.11=JOY1_DOWN
input.1.keyboard.0.button.3=JOY1_LEFT
input.1.keyboard.0.button.4=JOY1_RIGHT
If this can already be done via the config file, please let me know, otherwise this goes down as a another new request!
thanks
I have recently installed Retropie onto a PiGrrl machine, which has an Adafruit 2.8" PiTFT display 320x240.
Obviously this causes chaos when I press f12, so I'd like to support the case for even a minimal size menu display when either an host option is set (I.e. Not with the game config!) or better still, when a small display is auto detected.
It could probably suffice for this to be like the fs-UAE option screen (although not as pretty!!) and only have options for control changes and disk swapping.
I would be happy to help design something, even if I can't code it, it it would help!
Thanks
Hi. Just checked today Amiga keyboard function keys F1-F10 and doesn't work. Can someone check may i have wrong keyset in Amiberry distro or something wrong in code Amiberry SDL.
Hi - using your precompiled binary here: https://github.com/midwan/amiberry/releases
Placing this in a folder, making it executable and running it results in the error "SDLTrueTypeFont::SDLTrueTypeFont. Couldn't open data/FreeSans.ttf".
I assume this is supposed to be packaged with the binary? I have installed all of the dependencies you mention.
Instead of the expected double-click to start the selected config file, sometimes if it's already selected and the user clicks on it once, it launches the emulation as well.
Please to check Technological Death demo. In scene at the Devil I see dissynchronizing scene (timer and animation) and scene still staying. For ex. FS-UAE nad WINUAE demo playing normal.
As requested, the controller issues to be raised here:
For context, I am using a PS3 pad on uae4arm. In all examples i am setting 'port 1' as the most common option.
-- there is no 'cd32 red' 'cd32 blue' or 'cd32 play' available in the custom drop downs.... please note that red/joy fire 1 and blue/joy fire 2 are not the same input.
Although they often operate the same, the code to read the (amiga side) differs, and this does cause 'fire' not to work in some games where 'red' does. (there is common CD32 WHDLoad asm reading code that has this difference)
If it helps, i have a small program for testing cd32 inputs, you are welcome to use
https://www.dropbox.com/s/3o505q9h8hh1of9/CD32-tester%20%282016%29.adf?dl=0
[link updated to latest version - 14/05/2017]
This was needed for resolving similar issues on PSPUAE development, some years ago.
I would also welcome the ability to map to all available host inputs, and not ony the ones 'equal' to the Pandora, as some controllers have extra buttons we cannot yet map to.
Similarly, the abilty to map some UAE controls (quit program, 'pause' , display menu etc) would be welcomed.
FOL, the final developer of PSPUAE added these comments on the same topic:
"Theres also an issue with multi-key press games, i.e. Microcosm, Subwar 2050. You can not press FWD and say Yellow at same time. It may be related to RED and BLUE input code. Every game I have tried that requires RWD or FWD + Colour keys do not work."
Many thanks for your work on this project.
The game "Jim Power" has a slowdown on the title screen.
The audio is breaking up while trying to keep in sync with the video.
Frameskip helps resolve this, but we should try and to optimize the areas causing it.
Version tested:
Jim Power - Mutant Planet (1992)(Loriciel)(Disk 1 of 2)[cr FLT]
All the games I have are running in 200
height resolution (I'am yet to find one that runs at 256
). We currently have it set to 256
and results in black bar at the bottom of screen.
Could we change the default to 640x200
( currently 640x256
)?
Applies only to SDL2:
When switching resolutions, e.g. from Picasso96 to PAL and back, after the 3rd change the screen goes black (i.e. on the 4th time)
If it's possible to scale up the resolution as an exact multiple (emulator vs native resolutions), we should use nearest neighbor which provides a sharp picture.
In other cases "linear" should be used to avoid an ugly distorted image.
Example:
PAL modes scale up to 1280x1024 exactly (320x256, 640x512, 1280x1024 are exactly multiples) and if the native resolution of the monitor is such, we can easily use "nearest neighbor" scaling without problems.
Picasso96 modes such as 800x480 on a 1080p native resolution, should not use "nearest neighbor" as it would give an ugly result - instead, "linear" scaling works best in those conditions.
Suggestion:
Implement an mechanism to calculate requested vs native resolution and switch scaling method automatically, in order to provide the best image output.
When we exclude PAD XBOX 360 when Amiberry work and re-run again then configuration file in Amiberry is not working. All assign keys (entry GUI or QUIT) not working. We should get out of AMIBERRY and re-run again Amiberry then the PAD is on and all work like before.
This resolution should also be in the list of available Picasso96 options.
There is a problem with programs like demos or games with WHDLoad.
These are running slower than normal.
I use ClassicWB with WHDLoad.
In PAL High-Res Mode the WHDLoad games/demos runs fine, but when i use any Picasso Mode WHDLoad rund about only with a Speed about 80-90 Percent.
I think there is a Timing Problem with the Picasso Mode
Same with MOD playing. With Picasso Screen (any Resolution) MOD's runs slow. Without Picasso Mode all works perfectly.
Add support for parsing config (.uae) files from the command line, without specifying "-config " (or "-f ").
Hi, I tested these two games. First Samurai completely exits the emulator for some reason. Second Samurai AGA has completely corrupted graphics.
All these games I think also suffer from the 'Play Too Fast, need Cycle Exact'. But that's a whole new problem. Will AmiBerry ever get some sort or Cycle Accuracy ?, maybe DMA/Memory Accesses just to get the many games to play at the correct speed on WHDLoad, or will it make the Raspberry Pi 3 slow down to a crawl ?
Idea: Add a button in the Config GUI to shut down the host machine (power off).
Hi, I tried this game on Amiberry 2.1 but at the beginning of the intro it completely locks up with no warning. I tried the same game on the Android version of UAE4Arm and it gave a warning saying "Superhires resolution requested. Not supported in UAE4ARM". I clicked OK and it continued, the graphics were corrupted but it didn't lock up. Once in game it's fine. I just wondered why AmiBerry never gave this message and locked up ?
I am currently writing on a keyboard interface for an Arduino to steer an Amiga 500 keyboard as HID interface.
Unfortunately, there is a small problem.
I can definitely not control the right Amiga button for a typical Amigareset.
The typical Amiga Reset on a Windows keyboard is done with CRTL + Win + WinMenu
The normal Winuae is thus clear that on a normal keyboard the right Windows key or the right Windows menu key together with CTRL and the left Windows key may be pressed, so the reset works.
The UAE4ARM can not do this because I have programmed my Amiga keyboard to the right Windows key and with the combination CRTL+LeftWin+RightWin the Reset don't work.
Now my little concern:
Can you possibly integrate both right keys (Windows key and the menu key) for a reset as well as the Winuae?
Then the Amiga 500 Keyboard would work perfectly.
Would be super if that would fold.
Greeting Markus
Hi all!
I was testing something in Workbench (i'm using an ADF of Workbench 1.3), and when i was going to save the changes, AmigaDOS told me that the floppy was write protected.
I thought: "No problem, i have to open the emulator GUI and un-tick the write-protection checkbox and i will be able to save my changes".
The problem came when i noticed that the checkbox... was... greyed out :S.
I tried enabling DF1 and DF2 as well, but... can't untick their write-protection checkbox neither :( .
Maybe a bug?
See ya!
P.D: Yes, i'm using Workbench and Kickstart 1.3, the ones of my beloved A500 :3 <3.
P.D 2: Also i wanted to ask if UAE4ARM is compatible with RDB for making hardfiles recognized by HDToolBox :) .
The emulator currently uses SDL1 internally, for input events, graphics drawing (combined with DispManX), audio and joystick support.
We should move it to SDL2 which provides a more modern approach, hardware acceleration and enhanced joystick input features.
If JIT is enabled, the installers will give you an error.
After the latest merge from Pandora sources, the emulator fails to start.
A segmentation fault error appears right after the title and version information.
Saving a new configuration sometimes creates duplicate entries in the menu.
The duplicates do not exist as physical files in the conf/ folder.
I tried your repo on raspbian and get many issue:
it doesn't compile due to RASPBERRY switch not pass into gcc command line (DEFS is not included into CFLAGS). Adding it to flags solve this.
Then it fault when starting. Removing USE_PROFILE=1 solve this.
Then i tried your rpi1 target (on a real rpi1) to try PICASSO96 and it doesn't success to start my A4000 HDD with RTG memory...
In which environment are you compiling ?
Instead of using the Display Preferences width and height in the emulator, we should be using the requested resolution's width/height.
This only applies to non-Picasso96 modes, as those are handled correctly.
Right now, the emulator uses a preset from a user-controlled slider (in the GUI->Display->Width and Height settings), but that has to be manually adjusted to get the correct aspect ratio. For example if the setting there is 640 x 270 and we open a game with a 320 x 256 resolution, the aspect ratio is 2 : 1 since the screen still stretches to 640 pixels wide.
If we use the requested width and height for the SDL Surface, we have have the aspect ratio calculated correctly automatically by the framework.
For Picasso96 screens, this is already correct as the surface is drawn based on the requested (Picasso96) resolution instead.
I'm using a RPi 3 with DietPi.
I have noticed that the screen don't get cleared when you resume the emulation, as there are chunks of the config GUI around the screen.
I have experienced another strange bug: If i configure the autostart config to not use the GUI, when i try to exit the emulator the systemd-journald process starts eating the 99% of the CPU and i cannot exit the emulator unless i open another console and kill the systemd-journald process.
Then, if i execute "journalctl -r", i get a lot of entries like these ones:
bash[101]: IP: 0x76ece624 [e5820000] 0xa7804664
bash[101]: processed: 0x76ece620
As i said, this only happens when i quit the emulator after the autostart config was autoloaded.
See ya!
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.