@OlafS25

a mix of different things.. System54 as AmigaKit calls it.

but the point is it depends on ARM based libraries
and acceleration from the host OS.

@LiveForIt

Amibench is as I understand it a Aros 68k distribution, similar to apolloos or my distribution, running in full emulation. The problem is not how fast it is but how good it integrates and how the feeling for the users is. Is it still feeling very much the same or not? Feelings are very important to retro users who we all are today in one way to the other.

@OlafS25

Quote:

it can be quite fast... and feel quite normal, if you don't go for a full emulator. A600GS / A1200GS - AmiBench is moving in that direction.

After I wrote the message below, I realised everything has been said already.
I'll post it anyway.

I am using a lot of 68k software too.

WordWorth
TurboPrint
ArtEffect
AREXX
CubicIDE
PageStream4 (Since PGS5 is buggy at least)
To name a few.

What bothers me most is being stuck with a system where a single misbehaving program can bring the whole thing down. Then there's the nice hardware with multiple cores and being limited to just one.

The OS should move on.
Then developers would also be more interested in it when better development tools are available, and this too seem to be related to the OS being stuck too much in the past.

AmigaOS 3 is being developed further, so there is the alternative with Vampires and other "68k" hardware.

All other OSes have moved forward; we should too. To me, it seems silly to have two parallel OS 3.x and 4.x, with the only difference that one does run natively on hardware that can only be supported partially, at half the speed.

To have fairly modern browsers, especially since a few of us in the thread want one, we need to move forward. And we need a 64bit os for modern browsers. I don't think there is a way around it. we might be able to to get along for limited amount of time, but sooner or later nobody will be able to to take webkit and make it run on 32bit.

I vote for moving forward, but I wish a better and faster e-uae was available.
Judging from the explanations of kas1e, I think that is a good way forward. So count me in with kas1e and Andrea. and thanks to LiveForIt for cooking up some mystery better development tools.

@LiveForIt

Ditching 68k has advantages and disadvantages

To name a example where I come from... AROS

it is about being API compatible but not binary compatibility. That finally means integrating 68k only by emulator. The advantage you can basically make changes to the OS without caring about breaking compatibility with 68k. That makes it possible to do currently a migration from 32bit to 64bit. But this of course comes with a price. You can as example not use original 68k libraries in the system like those needed for arexx. I think this is possible in amigaos because of petunia. There is a replacement for it but it is not fully compatible. You also must run emulation to use 68k. That is creating a different feeling at many users obviously.

So short... if you want to move forward you have to ditch 68k compatibility and the way 68k is currently integrated in but it will also feel different if you still use 68k apps.

I do not know if 68k integration like it is currently done in amigaos has still the same meaning as it had in the past. I know that at least in past 68k integration was a reason why people preferred one system to the other.

@FlynnTheAvatar

Looks it runs really good, looks like load pages pretty fast too.

@FlynnTheAvatar

Now THAT is really satisfying... I like the mood, it makes me feel so - saturated! It also gives me the impression, that this is something really, really valuable to look at, here in my nightgown getting ready to voluntarily shut down my circuitry until the day tomorrow, where I have to perform dastardly feats against an unbeknownst enemy. I have to say, that is extraordinary! I am just waiting for everyone else to join in and have a caballesque (whatever that is).

@elfpipe

I added one the free Youtube songs to the video. I hope this fits the moot

Was about to record same kind of video (alfkil gives me test bins as well), but as Flynn was faster, i only can add that yea, speed is ok. Not slideshow or whatever, pretty ok. Of course can be a bit improved here and here, and a bit more integration with visuals and os4 design can not hurt, but hey hey, that pretty good.

@FlynnTheAvatar

That's fabulous! Now - for the devil within me: Could we have some music on top of that?? Not the slightest of what I'm after, so anything will do, just any music at all! Can you do that for me!? Oh the joys of laughter, wo-ho-ho, beyond the wild canyon where the roses grow....!

...And perhaps also tell me: How do people normally upload images in posts here?? I had to let go of my homepage service, so I am left with cloud storage, that doesn't play so well with the [img] function here.

@elfpipe

Thanks a lot for your kind words. But I managed to capture a smoother version:

@FlynnTheAvatar

You did an absolutely amazing job. We can all see everything loud and clear! Nothing is hidden, everything is written - in vast codes of orbital noise, beridden with fearless joy and laughter... Ho-ho-ho! Do the moose dance and join the quest for glory -

IN THE TAQTUC Challenge 2026........(!!)

On my X5000 the animation is really smooth. Sorry, I have just a crappy USB capture device and/or crappy record software.

@LiveForIt

Well, I call parsimony, and the fact that I have done absolutely nothing to prevent the blue bar from going under. As a matter of fact I have followed the logic prepared by whomever took the liberty and do the jumble for the rumble of putting things in certain places in the window-holder factorization entities.

If, on the other hand, parsimony is not an option, I could also give the conceptual argument, that the lower part of the window is where the Qt specific status bars go in QMainWindow driven settings. So it would not be good value of visuality to put another bar there to puke on.

If it is good value to you to keep things straight up and running, I will do absolutely nothing about it. I think there should be an entry on this put in the documentation of the subject - not to clearly cut the differences involved, but rather to haunt you in your sleep, when you least want to see bars of blue turn golden in an abstained vision of corporeal nature in the hidden unknown.

Over and easy.

Fantastic work mate!

@LiveForIt

IMO having the wider border on the right is preferable to having it at the bottom, as on a widescreen monitor you have way more horizontal area available than you have vertical.

@elfpipe

For goodness’s sake, can’t someone move the blue right border to the bottom. QT apps look crazy..

@OlafS25

I’m in between.

I see no point in dropping support for legacy programs. But I do see the need for change.
if look at the belly of the beast it's not pretty. From security and system stability point of view.

This is about system stability... the OS simply does not care about concurrency well, it was never built for SMP.. asking developers to manage L1 cash manually, in all shared list and public structures as well as message structures. Is a big ask, and not likely that is going to be success.

We might even want a true 64bit OS, the web browsers need all the memory it can get.

Compatibility can be maintained by sandboxing, it’s not same as emulation, we not talking about CPU emulation or hardware emulation, we just translate API A to API B.. if possible. Basically, a window manager that talks to host OS, and handles IO, keyboard, mouse, serial, parallel, network.

The main reason why it’s necessary is system stability, it’s far too easy to crash the OS, corrupt memory and file systems.

I’m not too worried about hacking, we have lived with this OS for decades knowing it limitations, and community has been tiny, but changing how the process stack works, can improve security. And improve stability. I think it might be worth it, even if you break a few eggs.

When it comes to AmigaOS3.x I see no reason why we can’t bring it on for the ride.. encourage better API’s there ensure portability, I see no reasons why improvements in OS4, cannot benefit OS3 as well.

Becoming UNIX / Linux… no that’s not the point… nor is it a good idea to build a card house on top..

It is the old Amiga users who insist on 68k compatibility and do not want to allow any changes. Personally, I still see myself as a newcomer to AmigaOS 4.x, even though I already owned PPC hardware (AmigaOneXe) 20 years ago.

At that time (AmigaOS 4.0pre), it was unthinkable to rely solely on native software because there were virtually no alternatives. Things have changed in the meantime, and there are native alternatives for just about everything.

Of course, it's great that we still have the option to run 68k software through Petunia or E-Uae. But if this means hindering the growth of AmigaOS 4.1, then I am against this ancient 68k layer. By Amiga standards, we already have powerful X1000/X5000 hardware where everything can be emulated cleanly and quickly.

As already mentioned, if it should still be possible to use 68k software in the future via a sandbox or other means, but the user notices as little of this as possible, then this should be done. Everything, and I mean everything, that hinders the further development of AmigaOS 4.1 should be dropped.

I know the comparison is a bit off, but Apple did the same thing with MacOS when switching from PPC to Intel and ARM. However, with the next major operating system versions, this support will be dropped in the future.

Of course, this is all wishful thinking and none of it will happen, but I still wanted to share my thoughts on the matter from a user's perspective.

@elfpipe did an amazing job porting and integrating the QT6 WebView: