Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
80 user(s) are online (47 user(s) are browsing Forums)

Members: 0
Guests: 80

more...

Headlines

Forum Index


Board index » All Posts (Maijestro)




Re: Bug-fix updates for Odyssey?
Quite a regular
Quite a regular


@kas1e

A few days ago Odyssey 1.26 was released for Aros 32bit and contains some bug fixes.

https://github.com/deadwood2/OdysseyWebBrowser

Can't we also use the source code for the PPC version of Odyssey and compile it for AmigaOs4.1 ?

@Gregor

At the moment I am using Odyssey version 1.23, I am using all the relevant Amiga sites and have also added the latest scripts available for Odyssey, even my email account (Emailn) can be used with Odyssey without any problems. I also use YouTube often via Yt.rexx and aiostreams amiga project. I have never had any problems like you described.

MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE
Go to top


Re: Qemu GTK/SDL display problems
Quite a regular
Quite a regular


@Hans

Yesterday there was a patch that fixes some mouse problems especially under Qemu with Virtio GPU support.

https://patchwork.kernel.org/project/q ... tyeshwar.singh@intel.com/

So they are working on that too, so if they submit issues there is a good chance they will be fixed quickly. As mentioned, there is still some time until Qemu 9.0 and they can still get some issues fixed before then.

In addition, the large ppc Patch series I told you about is included in Qemu Master and the Sam460 engine has made great progress, execution is now very fast, but there are problems with direct access to memory that leads to mouse hangs and the SmartFileSystem cannot be used at the moment.

I just wanted to let you know that.

MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE
Go to top


Re: AK DataType vs. WarpDT
Quite a regular
Quite a regular


@kas1e

Quote:
kas1e
They "was updated" , that should be enough :) (sarcasm mode)


Since this is a relatively large version jump, there must have been some changes.

But don't be so skeptical, maybe we'll get some more information.

MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE
Go to top


Re: AK DataType vs. WarpDT
Quite a regular
Quite a regular


@amigakit

Quote:


AK-ILBM Datatype V54.19 / V46.19
Datatypes Library V54.24 / V46.24
Picture Datatype V54.9 / V46.9


What relevant changes have been made to the PPC version?

MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE
Go to top


Re: Qemu GTK/SDL display problems
Quite a regular
Quite a regular


@HansQuote:
Hans wrote:@all

I'm pleased to say that updating to QEMU 8.2.1 fixed the GTK display.

Unfortunately, the GTK display backend is now almost as slow as SDL2 when using the Virtio GPU device. Also, the Virtio mouse pointer is indeed completely unusable, as per this bug report.

Looks like I have to put up with the slowness for now...


It's good that some problems with the Display Manager GTK have already been fixed. The GTK output was also completely unusable for me under Qemu 8.1.

As for Virtio GPU and its use on your machine, of course we can't check if it's fast or slow as we don't have those drivers. Nobody currently knows how far along these drivers are and if and when A-EON will release them....I guess when they are ready

I am also not sure what exactly you are testing with your Virtio GPU drivers is it still the 2d part or 3d part of your driver?

Other than that there are a lot of Virtio patches waiting to be added to Qemu Master. Also for the Qemu PPC emulation there is currently a very large patch series that is in pull status, I have never seen such a large series.

https://patchwork.kernel.org/project/qemu-devel/list/?series=827360

Balaton Zoltan told me that we still have about 2 months to fix things before the freez and release of Qemu 9.0. Maybe you should report your problems under Qemu Devel or contact Qemu developers directly and describe the problem.

MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE
Go to top


Re: ScummVM and AmigaOS4.1 F.E.
Quite a regular
Quite a regular


@MickJT

Quote:
MickJT wrote:I'll build libcurl on the weekend with a couple of different compile time options, and that can be tested to see if that helps.


That's great, thanks for the help.

MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE
Go to top


Re: BreakHack
Quite a regular
Quite a regular


@walkero

Quote:
walkero wrote:@Maijestro
The game is compiled with SDL2 static libraries. That means that the version you have installed in your system doesn't really matter. The only thing that can change its behaviour is the SDL2 prefs and the selections you made there. Probably you changed your configurations there.

Saying that, I checked locally and the game doesn't have any issue with the 2.30.0 being installed.


Strange I downloaded Breakhack again from Os4Deopt and now it works. I I hadn't changed anything in the SDL2 settings.

Thank you anyway.


Edited by Maijestro on 2024/2/22 18:09:04
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE
Go to top


Re: BreakHack
Quite a regular
Quite a regular


@walkero

I wanted to ask you if you could check your port breakhack on real hardware. I noticed that BreakHack doesn't work anymore it just gives me a window with black content. Maybe changes within SDL2 made it unusable.

Things I usually use under AmigaOs4.1 like MilkyTracker/LiteXL/ScummVM etc. which are based on SDL2 work without problems with sdl 2.30.0 only your BreakHack doesn't work anymore.

If you have some time I would be happy if you could have a look at it. I would like to play a round of BreakHack again

MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE
Go to top


Re: ScummVM and AmigaOS4.1 F.E.
Quite a regular
Quite a regular


@Raziel

Quote:
Raziel wrote:@Maijestro
Ok...so a lot of ground to cover, please bear with me.


Don't stress yourself, I'm waiting for your test build and will test it at my leisure For now there is a WorkRound for libsurl.so.12 by replacing it with version 11 which makes ScummVM work very well.

Quote:
1) Nope, nothing special, just do your usual testing where you reach the crash, save the log and post it here or over at the crashlog site of os4depot.net


I will then make the protocols available here, which is why we have this forum.

Quote:

3) Just for the sake of completeness, could you, if time permits, compile a list of crashes with their exact steps to reproduce?
I'd like to do a comparision to rule out shortcomings of the internet access under emulation - it might still be not 100% accurate/error prone and could possibly produce crashes where there are none on native hardware)
Not that i say there are, just to be sure...and if there are emulation triggered bugs, you could post them to the WinUAE bugtracker instead...


Don't be angry with me, but I would like to briefly explain the differences between the two emulations WinUae and Qemu.

WinUae:

Deals exclusively with 68k emulation up to Amiga 4000 with extended turbo cards PPC and is developed by Toni Willen. A Qemu plugin is also used for PPC emulation, but it is very old.

Qemu:

Deals exclusively with the first generation of NG hardware AmigaOneXe/Pegasos2/Sam460 and is developed by Balaton Zoltan.

Of course there can always be bugs under emulation that don't exist on real hardware, but since I use Qemu, using the WinUae bug tracker would be the wrong way to go.

Otherwise all bugs have already been detected on real hardware:

https://www.amigans.net/modules/newbb/ ... id=145629#forumpost145629

I can also confirm that the first start of ScummVM is a bit bumpy, but if I use an already configured .ini file there are no problems. And the main problem with libcurl.so.12 which we have recognized and leads to different crashes under real hardware, as well as under Qemu/Peg2. I also noticed that your installer creates a ScummVM.info in the installed directory without a folder. But let's take care of the main problem first...

It would of course be helpful if someone with real hardware can confirm that if ScummVM 2.8.0 (Os4Depot) can run better by replacing libcurl.so.12 with version 11.


Edited by Maijestro on 2024/2/21 21:00:06
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE
Go to top


Re: ScummVM and AmigaOS4.1 F.E.
Quite a regular
Quite a regular


@joerg


Quote:

Using DebugLevel 20 doesn't make sense, unless you are beta testing a kernel and are told by the kernel developers to use such a high debug level, and only slows down you system a lot due to the huge amount of debug output.
For debugging applications using a DebugLevel higher than 5 usually doesn't include more information which could help the application developper, in most cases even DebugLevel <= 3 is enough.


Thanks for the little reading, I still have a lot to learn how things are done under NG Hardware and AmigaOs4.1. I will keep it in mind for the future....thanks

@Raziel

On their original source where they usually provide their test builds I am not able to download anything. Can you please check this ? Or has the link changed....?

MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE
Go to top


Re: Qemu GTK/SDL display problems
Quite a regular
Quite a regular


@Hans

I could observe the same behavior as you only this was with the display manager Cocoa under MacOs. It squeezed the output to the bottom left of the full screen. Even changing the resolution under AmigaOs4.1 did not help. Guest and host used the same resolution.

With the output "-display sdl,gl=on" I have no problems and it does not slow down as you described. The build was provided to me by @smakusg because you currently need external patches for the GL output under Qemu.

As far as I can remember the build is based on Qemu 8.1 which is not up to date anymore, meanwhile there is version 8.2.1. Maybe the problem has already been solved with newer builds.

Edit:Here you can see the "-display Cocoa,gl=on" zoom-to-fit in full screen. As already mentioned, there are no problems with the SDL output.

Resized Image


Edited by Maijestro on 2024/2/21 15:13:42
Edited by Maijestro on 2024/2/21 15:15:09
Edited by Maijestro on 2024/2/21 15:17:58
Edited by Maijestro on 2024/2/21 20:56:09
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE
Go to top


Re: ScummVM and AmigaOS4.1 F.E.
Quite a regular
Quite a regular


@Raziel

Quote:
Raziel wrote:@Maijestro

could you do the test with the prebuild i provided?

the release version doesnt have the debug flags compiled in and will always resukt in ?? addresses


No problem, I'll run all the tests with their debug build tonight. Is there anything to consider?

MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE
Go to top


Re: ScummVM and AmigaOS4.1 F.E.
Quite a regular
Quite a regular


@balaton

Quote:
balaton wrote:I think it might help more to get the debug log from the Grim Reaper More... button then save debug log or something like that than looking at kernel logs. (Unless the crash log is also printed on serial with debug logs redirected there.)


I've already tried that and yes the crash log is also redirected via the serial port and it also seems to be a bit more accurate.

MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE
Go to top


Re: ScummVM and AmigaOS4.1 F.E.
Quite a regular
Quite a regular


@MickJT

Quote:
MickJT wrote:Is it still the same address in the stack trace? 0x7A3BAEF0 ? If I use ppc-amigaos-addr2line -e libcurl.so.12 -j .text 0x7A3BAEF0 I only get "??:0" which doesn't help! And libcurl.so.12 should be built with debug symbols.


If I only use the DSI internally from AmigaOs4.1, the same address is shown as yours, but the address is different via the serial output with Debug 20.

But still it points to libcurl.so. So I guess this is where the problem lies. I'm not familiar with addresses and conflicts because I'm not a programmer.

DSI AmigaOs4.1 output:

module Download:Testen/ScummVm2.8.0/install/sobjs/libcurl.so.12 at 0x76519EF0 (section 0 @ 0x8AA94)

Serial output debug level 20:

module Download:Testen/ScummVm2.8.0/install/sobjs/libcurl.so.12 at 0x7A723EE0 (section 0 @ 0x8AA84)

MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE
Go to top


Re: AmiUpdate 2.50
Quite a regular
Quite a regular


@samo79

Quote:
samo79 wrote:So what, me too i was forced to learn english at school ... and i learn it bad but at least is useful 😄


I also tried to learn English at school, but it didn't help much, I can't even really read and write my own native language perfectly

But it doesn't matter what nationality everyone is, today there are translators who work well to be able to communicate, even if sometimes a lot of nonsense comes out of it.

@smarkusg

It was wrong to compare your language with Russian and I don't know your language or the Russian language. I just thought it might be useful.

@Trixie

Thanks, I just didn't know any better.

We should get back to the actual topic...

MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE
Go to top


Re: ScummVM and AmigaOS4.1 F.E.
Quite a regular
Quite a regular


@MickJT

Quote:

I don't know what you mean by "additional protocols".


Balaton has everything available with BBoot and "-append" so I can debug under Qemu just as someone would under real hardware, only it's not as complicated.

Quote:

Perhaps updating libcurl again will magically fix things. I'll look at that later. .... but to be clear, there's no problem when you don't run Odyssey first?


Exactly if Odyssey is not running beforehand there are no problems with ScummVM. Only after the Odyssey is running are there problems, some users also reported that they had previously used AmigaAmp, perhaps music streaming?


Quote:

I also don't know how you managed to get this info in post #492:

Stack trace:
(0x66BD2C20) [audio/softsynth/mt32/srchelper/srctools/src/SincResampler.cpp:64] scummvm:_ZN8SRCTools13SincResampler5Utils22computeResampleFactorsERjRdddj()+0x324 (section 10 @ 0xDE9FB0)
(0x66BD2C50) module Download:Testen/TestScummVM/sobjs/libcurl.so.12 at 0x7A3BAEF0 (section 0 @ 0x8AA94)


As already mentioned, debugging with Bboot -append debug level 20 lets me see everything when debugging under AmigaOs4.1. Even if programs are executed under AmigaOs4.1, it is recorded and I can read it in the serial console. You can't debug this with WinUae even if it uses the Qemu plugin, this function is simply missing and it only emulates PowerPC 604e and not NG hardware. That's what I tried to explain.
Quote:


If I run

ppc-amigaos-addr2line -e scummvm -j .text 0xDE9FB0 I also get ??:0, but scummvm is built without debug symbols. Were you using a different scummvm binary than the one on OS4Depot?


No, I used ScummVM from Os4depot in version 2.8.0.


Edited by Maijestro on 2024/2/20 21:33:51
Edited by Maijestro on 2024/2/21 8:45:10
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE
Go to top


Re: ScummVM and AmigaOS4.1 F.E.
Quite a regular
Quite a regular


@MickJT

Tested with ScummVM 2.8.0 (Os4Depot) no files changed increased stack size standard 1024000 to 4000000 with libcurl.so.12...DSI Reproducible with Odyssey.

I can also publish some additional Protocols so that you can take a look at them.

The same problems also occur on real hardware, please follow this thread and please do not compare Qemu Peg2/AmigaOneXE/Sam460 with WinUae, it does not emulate NG hardware. An example: Run SysMon or lspci under WinUae and it will crash and many other things that access the hardware directly. But it's not an attack on WinUae, what I want to say is that NG hardware emulation works a little better.


Edited by Maijestro on 2024/2/20 21:01:58
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE
Go to top


Re: ScummVM and AmigaOS4.1 F.E.
Quite a regular
Quite a regular


@MickJT

Perhaps I expressed myself a little incorrectly and you didn't understand correctly. ScummVM 2.8.0 Os4Depot uses libcurl.so.12 with this version it leads to reproducible DSI and crashes without renaming or replacing files. As soon as this version is replaced by version 11 there are no problems.

I have not yet tested ScummVM with libcurl.so.12 and stack 4000000. Only with libsurl.so.11. I will repeat the tests with an increased stack for ScummVM and libcurl.so.12. Without having renamed or replaced files.

MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE
Go to top


Re: AmiUpdate 2.50
Quite a regular
Quite a regular


@smarkusgQuote:
smarkusg wrote:I hope that I will not jam this thread with this entry.
I noticed that there was never a Polish localization of AmiUpdate.
I have prepared for the latest version - only I have a request to contact a person from my country or knowing my language who could verify its correctness.


If you need help with the Polish translation, I would help you, we could compare it with the German local part and check everything with the help of a translator.

Otherwise there is a Russian translation we could use, it is not your language but has similarities.

http://os4depot.net/?function=showfil ... rkbench/amiupdate_rus.lha

You have my mail

MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE
Go to top


Re: ScummVM and AmigaOS4.1 F.E.
Quite a regular
Quite a regular


@Raziel

Quote:
Raziel wrote:@Maijestro

strange...
ill provide a new test build asap then


Cool thanks I will do all the tests for you. Simply because I want to use ScummVM on AmigaOs4.1 without any bugs. I could find some minor other bugs/problems, but the main problem at the moment is libcurl.so and we should solve that first. Just let me know when it starts

MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE
Go to top



TopTop
« 1 ... 4 5 6 (7) 8 9 10 ... 45 »




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project