Pi 1/Zero | Emulation/Pi freezes after selecting picasso mode

[jarokuczi]

Hi, Like in title emulation freezes after switching to picasso video mode.

Clean Workbench/Kickstart 3.1 with Picasso 2.0 from Aminet. Raspberry Pi1B

[CypherXG]

Do you have rtg.library 40.3994. With your Picasso Install 2.0 from Aminet you only have rtg.library 40.3945. You must update your rtg.library. Here. I've uploaded version 40.3994

https://www.file-upload.net/download-12395503/rtg.library.html

Do you installed Binary package dependencies?

libsdl1.2debian libsdl-image1.2 libsdl-gfx1.2-5 libsdl-ttf2.0-0 libmpg123-0 libguichan-sdl-0.8.1-1 libxml2 libsdl-dev libguichan-dev libsdl-ttf2.0-dev libsdl-gfx1.2-dev libxml2-dev libflac-dev libmpg123-dev

Do you compiled for your Version of Pi with: make PLATFORM=rpi1

Picasso works perfectly with the latest Version of amiberry.

Greets...Markus

[jarokuczi]

i have installed version bundled with dietpi. I was using old rtg.library with upgraded after switch screen mode to one of picasso modes screen showed up for a moment and goes black like before and emulator freezed.

[CypherXG]

Then update all to new versions.

[jarokuczi]

tried latest released version 2.1 without luck.

[jayminer81]

I have the same problem, I used an existing installation from FS-UAE and just copied my Workbench-installation over, everything works as long as I don't try to switch to a Picasso96 screenmode. If I do I only get a black screen and even if I kill uae4arm-rpi I still don't get any picture on the screen. All I can do is reboot. I tried replacing rtg.library as mentioned here but it made no difference. I'm using amiberry downloaded yesterday on a Raspberry Pi 1.

[midwan]

Thanks for the feedback. This seems like a pattern on the Pi 1 model, unfortunately I don't have such a model to test with here, but I have a Zero (which share the same CPU). We'll see if I can recreate it on that.

[CaelThunderwing]

been getting this Issue w/ latest Amiberry on the Pi3 as well, its not present in uae4arm but Does infact warn me about the RTG lib version

[midwan]

This issue (about the RTG library version) should have been fixed in the latest "dev" version. Regarding Pi 1/Zero, I noticed that we'll have to include the "arm_helper.s" file separately, it won't work with combining the two (neon_helper and arm_helper) into one, like I had done.

We'll get this tested more thoroughly before the new stable release.

[jarokuczi]

Where I can download latest "dev" version?

[midwan]

@jarokuczi Currently you can only compile it from source, there's no binary available yet. We will release a new binary when this version is stable enough, and it will be moved to the master branch also at that point.

If you want to compile it from source, you'll have to clone the "dev" branch of this github repo locally, then follow the instructions in the README. Otherwise, I'd recommend you wait a bit until the stable release comes out.

[jarokuczi]

tried to compile dev branch by myself but got error. I assume that there is some dependency problem but i installed every package listed as required in readme.

[midwan]

@jarokuczi hmm, page not found on the link you posted?

[jarokuczi]

shame on me, entered link as name and name as link. Correct link in updated comment. I am compiling with this cmdline: make all PLATFORM=rpi1

[midwan]

@jarokuczi Almost there, the link you have above ends with a dot (".") which should not be part of it (otherwise it doesn't exist as well). But I managed to see it now :)

First of all, it looks like you cloned the "master" branch, not the "dev" one. The references to "pandora" are no longer there in the "dev" branch. Try this: git clone https://github.com/midwan/amiberry -b dev

Then it looks like the guichan references were not found? Make sure that the package libguichan-dev is installed in your system, if you're building the SDL1 version. If you go for the SDL2 version, that's not needed since we use "guisan" there, and that's included in the sources.

[jarokuczi]

After solving dependency problem, new issue appears https://pastebin.com/TriYprPq

[midwan]

@jarokuczi Thanks for the feedback. Those errors are related to the known issue I mentioned above, about including the "arm_helper.s" file because the neon_helper includes instructions that cannot be compiled on the Pi 1/Zero processor. :)

I'll get that fixed a bit later today I believe...

[midwan]

@jarokuczi it should be fixed now (I tested a compile for rpi1 myself) :)

Please let me know when you get a chance, so we can close this issue if nothing else is wrong.

[jarokuczi]

@midwan tried once again without luck (probably next dependency issue) https://hastebin.com/oloyegisar.rb. Maybe you can send me your binary? Little bit offtopic is there chance to run amiberry on other single board computers like Allwinner H3 based Orange Pi?

[midwan]

@jarokuczi That's strange, it says it can't find bcmhost...

Do you have the following paths in your system?

/opt/vc/include 
/opt/vc/include/interface/vmcs_host/linux 
/opt/vc/include/interface/vcos/pthreads

They are standard paths for Raspbian distros, which contain the Broadcom headers (to use Dispmanx). Are you running another distro?

[jarokuczi]

i am using chrooted Raspbian installed via debianbootstrap on AMD64 PC. I will copy those files from my rpi installation.

[midwan]

You'll need those headers and the library, if you want to use Dispmanx. If you have them in another path, you can update the Makefile for your target accordingly. If you don't have them, then you can't use Dispmanx, the only alternative would be to build the SDL2 target for RPI1 (which means you'll have to install SDL2 first).

[jarokuczi]

Today tried to build on rpi1 with latest raspbian image. Still no luck :( https://hastebin.com/ikufocapaj.sh

[midwan]

@jarokuczi Thanks, that's something I found myself yesterday. I fixed it locally, but haven't committed the changes yet (I was testing some more stuff). I'll do so a bit later today.

[midwan]

@jarokuczi The a98d8bf2e2ea70fab45a49701420af6d8dd687ef commit should have fixed the issue for you, please give it another try when you can?

[jarokuczi]

Finally It's alive 😄. Compiled it just now, will test it later today.

[midwan]

Glad to hear that! I'm closing the issue for now, let me know if you have any problems and we can revisit it.

[jarokuczi]

Yesterday tested latest dev build. Everything works ok, including rtg modes, when running on xorg. But when I tried to run from command line (without xorg launched) there was only black screen without any GUI. Additionally performance was low (about 2.6 MIPS) maybe this is normal on pri1/zero?.

[midwan]

@jarokuczi If you're on Stretch, try using the fkms driver instead of the Legacy one. They changed some things there with the Legacy driver, and sdl1 apps won't show correctly (only a black screen) if started from the console. With the "fkms" driver however, they work.

Performance will be much better if started from the console, instead of X11... ;-)

[jarokuczi]

How to use this driver in stretch? Do i need to compile it again?

[midwan]

@jarokuczi No need to re-compile anything, just use "raspi-config" to select the "Fake KMS driver" in the GL Driver options (under Advanced)

[jarokuczi]

@midwan After switching to fake kms driver gui showed up, emulation started, emulation is faster (4.8 MIPS) but there are no rtg (uaegfx) modes available in screenmode despite of rtg ram set to 16 megs.

[midwan]

Hm, I'll give it another test tonight on a Pi Zero to double check... I did test the binary for RPI1 on my RPI3, and it worked normally (including RTG modes) the other day, so just to make sure I'll double check with the actual hardware and get back to you.

[jarokuczi]

@midwan Checked showconfig output and it seems to register some card with mem size equal to rtg setting. https://imgur.com/HQ3IijS maybe there is some problem with proper detection of rtg mode available?

[midwan]

@jarokuczi Certainly nothing that would be triggered by starting it from the console though... Is this the same system you tested with P96 (and worked) under X?

I assume you have the Picasso96 package installed?

[jarokuczi]

this is exactly same system with same configuration file just amiberry launched from shell without X11. Here is picture of amiberry launched from X https://imgur.com/a/q0Igm

[midwan]

Just tested it on a Pi Zero here... Picasso modes do work normally, though i had to open ScreenMode and select one (even though the .hdf I provided already had a Picasso mode saved in the prefs).

Could you please check if 1) You can see Picasso96 modes in ScreenMode 2) You can select and Test/Save one, and it's applied

Perhaps it's that simple.. :)

[jarokuczi]

There is no picasso modes at all, only PAL modes available when launched without X. When launching from X system boots up in picasso mode already and i can select from multiple picasso (uaegfx) modes.

[jarokuczi]

@midwan it looks like problem with mode detection in my case. When I manually add mode in Picasso96Mode it showed up in screenmode prefs. Here is movie showing issue: the issue

[midwan]

@jarokuczi that's interesting... It might be related to the Picasso96 driver in use, because the resolutions are saved in that (the file under DEVS:Monitors/).

The installation I used to test with comes with Amiga Forever, and it's the Workbench 3.xx system. It has Picasso96 pre-installed with the "uaegfx" driver, and the resolutions are listed in Screenmode (although the saved one did not get loaded, so perhaps the IDs differ?).

Are you using the latest Picasso96 package from Aminet?

[jarokuczi]

I am using Picasso96 from here

[jarokuczi]

Tomorrow I will try with Cloanto Workbench 3.X instead of H&P 3.9 maybe this will work. Strange thing is that when i start amiberry from X11 there are many modes available.

[midwan]

@jarokuczi Well, it makes some sort of sense:

• Before listing the available modes, we test that they are valid as Hardware Surfaces on the host system.
• Obviously, the system is reporting different things when running under X11 or from the console.

This is only an issue with SDL1, as in SDL2 the mechanism is different and we don't have that problem. You could try building the "rpi1-sdl2-dispmanx" target to test if you want, but you'd also need to build SDL2 from source first, which is a (one time) larger task. I wrote a Wiki article about that here: https://github.com/midwan/amiberry/wiki/Compile-SDL2-from-source

[midwan]

@jarokuczi I can probably push a small fix that might help with this on SDL1 also..

[jarokuczi]

@midwan Yesterday I compiled SDL2 and amiberry with "rpi1-sdl2-dispmanx" as a platform. RTG mode are working good even when I launch it from console. But way to achieve it is hard, maybe you could try to static link amiberry with proper compiled SDL2 on release?

[midwan]

@jarokuczi static linking is considered a bad idea, especially since different systems may have different configurations, the library might be updated in the future, etc. Building SDL2 is a one-time task, and some systems provide easy ways of getting it in place (e.g. RetroPie has a script). It's unfortunate that the default binary bundled with Raspbian is a) an older version and b) doesn't have the necessary flags enabled (kmsdrm driver or rpi driver), but we can't do much about that from our end...

[midwan]

@jarokuczi I've now also removed the check that caused the modes to be hidden in SDL1, so you should be able to work with that as well.