Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
62 user(s) are online (44 user(s) are browsing Forums)

Members: 0
Guests: 62

more...

Headlines

Forum Index


Board index » All Posts (Maijestro)




Sam460 which file systems can be used
Quite a regular
Quite a regular


I'm not sure if this question has been discussed here before, and if so, then I'm sorry, I'd like some information on it.

As the title suggests, it's specifically about the Sam460 with AmigaOs4.1. Is it generally possible to use the SmartFileSystem on this machine?

There was some dispute about the version on the AmigaOs4.1 Final Edition, but what about Enahncer Software 2.1, which also provides SFS? Can this be used without restrictions or are we limited to FFS on Sam460? ?

One final question about the NGFS file system is it limited to AmigaOne x5000 or could it also be used on computers like AmigaOneXe/Pegasos2/Sam460/x1000?

Any help will be appreciated.....

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:@joerg
Waiting for Maijestro to report back if the last .so I sent works properly.


I did my usual tests by always being able to reproduce a DSI or a program crash. Nothing like that happened, their new libcurl.so.12 works and ScummVM runs very stable.

So next I tried the download function of the iconpack and yes, it works without problems. I created a new folder in ScummVM with the name "Icons" and defined the path in ScummVM. Thank you for your help, it makes me happy.

Resized Image

Perhaps you would like to make the source code available to Raziel so that he can use it for future versions. Maybe you have a better idea how we can use your libcurl.so.12 permanently. ?

It is not yet included in SDL2 from Capehill and some applications use statically linked SDL2 libraries, as I was told. So we should include this library permanently to avoid problems with newer versions of ScummVM.

Edit: I forgot to mention that I am currently using 2 exe files...one with stack 1024000 and 4000000 with stack 4000000 everything seems to be ok with 1024000 there is a DSI again

Symbol info:
Instruction pointer 0x77944810 belongs to module "ags.plugin" (HUNK/Kickstart)

Stack trace:
    
module Programme:Emulatoren/ScummVM/plugins/ags.plugin at 0x77944810 (section 0 0x33380C)
    
module Programme:Emulatoren/ScummVM/sobjs/libpng16.so.16 at 0x78298808 (section 0 0x2BF38)
    
module Programme:Emulatoren/ScummVM/sobjs/libpng16.so.16 at 0x7828714C (section 0 0x1A87C)
    
module Programme:Emulatoren/ScummVM/sobjs/libpng16.so.16 at 0x78278974 (section 0 0xC0A4)
    
ScummVM:_ZN5Image10PNGDecoder10loadStreamERN6Common18SeekableReadStreamE()+0x82c (section 10 0x358FAC)
    
ScummVM:_ZN5Cloud9CloudIcon8loadIconERN8Graphics7SurfaceEPhm()+0xe8 (section 10 0x21B2AC)
    
ScummVM:_ZN5Cloud9CloudIcon9initIconsEv()+0x44 (section 10 0x21B428)
    
ScummVM:_ZN5Cloud9CloudIconC2Ev()+0x80 (section 10 0x21B4E0)
    
ScummVM:_ZN5Cloud12CloudManagerC2Ev()+0x68 (section 10 0x21B594)
    
ScummVM:scummvm_main()+0x3ef4 (section 10 0x7BCA4)
    
ScummVM:main()+0x198 (section 10 0x73A7C)
    
native kernel module newlib.library.kmod+0x00002614
    native kernel module newlib
.library.kmod+0x000032f0
    native kernel module newlib
.library.kmod+0x00003864
    ScummVM
:_start()+0x1e0 (section 10 0x3288)
    
native kernel module dos.library.kmod+0x0002a458
    native kernel module kernel
+0x0005b3e8
    native kernel module kernel
+0x0005b460


It must also be tested on real hardware...to confirm that it really is a bug. Or the stacksize needs to be increased, not sure.

@joerg

Thanks for the tip with current curl-ca-bundle.crt I have updated this certificate in Sys:devs/ it was from 2014 and is now from 2023, but I'm not sure if Odyssey uses it too.


Edited by Maijestro on 2024/2/26 16:18:09
Edited by Maijestro on 2024/2/26 18:35:14
Edited by Maijestro on 2024/2/26 18:36:59
Edited by Maijestro on 2024/2/26 18:39:20
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:@Maijestro
If you have that crt bundle file (can probably find one that comes with Odyssey), just put it in S: and see if that works.


It's not so important for now, but it had only been tried out briefly.

Quote:

Also in the new .so I sent you, I had disabled threaded resolving. So I'll want to send you at least one more version of the library for you to test, soon.


Of course I am still willing to do tests so that we get a stable ScummVm version for AmigaOs4.1. As I said with your libcurl.12 version there are currently no problems and ScummVM is now running very stable.

"disabled threaded resolving" I don't understand this, maybe you could explain it to me briefly?

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 @Raziel

MickJT was kind enough to recompile libcurl.so.12 and it works perfectly with ScummVM 2.8.0. I can't reproduce any DSI or crashes like I could before. Thanks for the recompile, good job

@Raziel

I'm not sure but libcurl.so is generally responsible for downloading the icon packs, was this function ever added to ScummVM? So did it used to work with ScummVM or was this function never there.

I only ask because I have tested it with the new version libsurl.so.12 from MickJT and it only gives me one error request.

Resized Image

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


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



TopTop
(1) 2 3 4 ... 39 »




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project