@amigang

I agree with you, setting up Qemu is currently a bit complicated and not very user friendly. A useful GUI like WinUae has is simply missing and makes installation complicated. Qemu is open source. Anyone with programming knowledge can participate in this project if they want. Or write a GUI for installing Qemu AmigaOs4.1.

For MacOs there is a very nice OpenSource GUI (UTM) https://mac.getutm.app If you contact the developers of UTM you might be able to add AmigaOs4.1, but at the moment there are too many dependencies that wouldn't allow that.

On Linux it is KVM that simplifies setup. Windows is currently the worst option. But again there is a Qtemu GUI that could make this possible. Untested by me.

Otherwise it might be possible to write an installation script that satisfies all dependencies and makes everything a bit more automated. Otherwise, I will continue to work on the installation instructions that will make the installation as easy as possible, even if I already hate it for it.

And yes, currently the Pegasos 2 version runs very well under Qemu 8.1 with 8.2 the AmigaOneXe version will be added, which runs just as well. I'm testing it right now...

@Maijestro

Sounds like what you mostly need to do is just add a few new machine types and default configs to virt-manager/

@Thread

Isn't the AmigaOS4 KVM Edition just a re-imaged Amithlon for 2023 by different people? Many were dead set against emulation but the market has failed to grow for AmigaOS 4.1 for 20 plus years. I believe the largest current Amiga market is the Vampire V4 and A500 Mini. I heard the Mini has sold over 100,000 units already and that's before the very aggressive Amazon Prime Day price. It would not surprise me if sales are over 500,000 units by now. The 100,000 figure is an old estimate.

Last edited by DiscreetFX on 19-Oct-2023 at 01:15 AM.
Last edited by DiscreetFX on 19-Oct-2023 at 12:33 AM.

_________________
Sent from my Quantum Computer.

What is KVM again? Oh…

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

kolla Quote:

What is KVM again? Oh…

Keyboard, Video and Mouse. Probably the other KVM which is Kernel based Virtual Machine. It's hypervisor support built into the Linux kernel since 2.6.20.

QEMU/KVM for absolute beginners
https://www.youtube.com/watch?v=BgZHbCDFODk

A C64 is shown in the above video at 2:33 if wanting to skip the boring parts.
https://youtu.be/BgZHbCDFODk?t=153

Maybe there is room in the AmigaOS 4 microkernel for hypervisor support since there is already a 68k emulator in there. Maybe they can add Linux hypervisor compatibility with Linux driver support. The monolithic Linux kernel should fit right into the Amiga microkernel after all. You will be assimilated, resistance is futile, at least without affordable hardware.

Last edited by matthey on 19-Oct-2023 at 01:43 AM.
Last edited by matthey on 19-Oct-2023 at 01:13 AM.
Last edited by matthey on 19-Oct-2023 at 01:05 AM.

I have sam460 and rpi.
Quake on my sam460 1 GHz makes 56 fps in 640x480 8 bit.
Old port from 2009 not optimized for ppc.
Quake on emu68 on my rpi3 makes 62 fps in 320x240 8 bit.
Fresh port from Aminet from 2022 hand optimized for 68k.
emu68 on my rpi3 is 4 to 5 times slower than my sam460.

I don't have to prove anything to scumbags that don't have ppc hardware
and spread anti ppc propaganda bullshit.

One good thing come from this tests.
640x480 8 bit on my lcd monitor has the same pixel size
as 320x240 on my crt in 1996.
Quake looks wonderfull almost exactly as in 1996.

my thoughts about pistorm.
It is slow. It is 4 to 5 times slower than sam460.
sam460 is not fast.
4 to 5 times slower hardware is to be honest too slow for modern things.
but it is emulator so it is fake not real thing.
I will buy another amiga 500 from commodore and 68030 card for it.
and recomended this for other people.

@ppcamiga1
Quote:

I don't have to prove anything to scumbags that don't have ppc hardware and spread anti ppc propaganda bullshit.

Do you realize PPC is is a dead platform? There's no hate, just 'told you so' at most, there's no success, there's not much value being added to it.. The most value you could had iis to run away from it the fastest possible. You don't work any faster on PPC then you work on 68k, workbench is fast enough as is.

Quote:

Quake on emu68 on my rpi3 makes 62 fps in 320x240 8 bit. Fresh port from Aminet from 2022 hand optimized for 68k. emu68 on my rpi3 is 4 to 5 times slower than my sam460.

Since when Quake runs in standalone rpi? So you say that PPC port is unoptimized, implying they were lousy coders... lol but forget that emu68 has yet to have dedicated gfx drivers like you have on SAM, plus you compare emulation with native code, how deranged one have to be?

PS- you don't even question why there's still optimizations being made on 68K and complete stagnation on PPC? You should be able to add 2 and 2 together

Last edited by pixie on 19-Oct-2023 at 01:53 PM.
Last edited by pixie on 19-Oct-2023 at 09:33 AM.

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@ppcamiga1

I mean, it is good that you feel passionate about your platform. All platforms should have passionate fans,

but

it is not a platform war anymore. It is all dead platforms from yesteryear. Some deader than other.
Which does not mean that they are bad platforms. Just means they are dead retro platforms.

I don't understand why you use Quake as the club to decide which platforms are great and which are poor. You realize this is a 30 year old game that NO ONE outside of retro hobbies compare about?
If you "win" over the pi-storm people, it is not a win. Your platform is still a dead retro platform that
normal people will never want to use. Just like all other retro platforms.

You sound like a deranged Amstrad owner that does not realize that the platform war against Spectrum48k ended 40 years ago. Here is a clue: every side lost.

@V8

Great points, sad but true. We have to make the most of what we have.

It is interesting on how everyone wants new hardware (not a bad thing), yet even if we get a faster offering the software and productivity will not really provide a good experience. Sure Quake will provide faster fps, but for anything other uses your looking mostly looking at old code and little usefulness.

This is where I think a lot more of the concern and energy should have been channeled with the other flavors. This is the reason why I adopted MorphOS after testing them all as my main system.

pixie Quote:

Do you realize PPC is is a dead platform? There's no hate, just 'told you so' at most, there's no success, there's not much value being added to it.. The most value you could had iis to run away from it the fastest possible. You don't work any faster on PPC then you work on 68k, workbench is fast enough as is.

It depends on the definition of dead. NASA may still use specialized radiation hardened PPC CPUs in new projects and the U.S. military may still use PPC processors in newly produced hardware (F35?). It is the lack of development and a product pipeline that gives it a death sentence even if is not dead. ARM processors have already replaced PPC processors and their mid-performance lower power than x86-64 embedded niche with a somewhat similar, and in my opinion improved, AArch64 so there is practically zero hope of a PPC return. PPC was already dead on the desktop as a result of the IBM G5 CPU design being disappointing for high end computers and PPC has always been disappointing for the low end due to poor code density, high memory requirements and difficult to program, debug and optimize code.

pixie Quote:

Since when Quake runs in standalone rpi? So you say that PPC port is unoptimized, implying they were lousy coders... lol but forget that emu68 has yet to have dedicated gfx drivers like you have on SAM, plus you compare emulation with native code, how deranged one have to be?

Darkplaces Quake supporting many mods has been running on the RPi since at least 2014 (20-30 fps at 1080p on RPi model B without overclocking).

https://forums.raspberrypi.com//viewtopic.php?f=78&t=72301

pixie Quote:

PS- you don't even question why there's still optimizations being made on 68K and complete stagnation on PPC? You should be able to add 2 and 2 together

Most of the 68k optimizations are old and were necessary because the silicon of 68k CPU chips stopped at ~500nm where there are sub 50nm PPC CPUs and ARM CPUs at 5nm today. Optimizations are for CPU hardware where optimizing for an emulator is usually not worthwhile as the underlying hardware has the largest affect on performance and often changes from one computer to the next.

https://en.wikipedia.org/wiki/2_+_2_=_5

@Matt3k

Catch 22.

you need developers, but no developers if no market.
no market, if no software.

and nothing at all if there something better, like Android, Apple, Windows.

What we are left with is the crazy, just need to accept it.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

There is some catch 22 to it and fully agree that Android, Apple, and Windows all the the appeal of large use base and that is where most everyone will go to work and play.

The point is for those like me who grew up with Amiga in the 80's and have invested in the platform over the years and rather like it and want to use something Amiga like for work and play where possible, there really is only one choice if you want to use a native solution without cheating :) .

It does provide me at least with hope, that a group of developers would just plug along and do amazing things that can do so much for maybe 7,000 paying customers. The effort alone by Jaca to create all he had to, is very encouraging to me. 3.19 has been worked on and 3.20 will be worked on next. I really couldn't ask for more to keep me happy... With the software and OS that I use daily being remarkably good, and the team standing behind their product.

Sure MorphOS will never be Android, Apple, or Windows, but for what I use it for I am a happy customer and grateful and look forward to updates to Wayfarer, Iris, PolyOrga, Pagestream updates. If they ever add a new architecture that would be really sweet, but I'm good right now with my PowerMac stuff.

@ppcamiga

You are comparing the wrong things. Compare the same 68k build of quake on the RPi to the Sam460, running at the same resolution and on the same hardware (e.g. RTG mode for both).

Then and only then can you make a valid comparison. Otherwise I can compare your PPC native quake build to an ARM64 native build. Or Nightdive's remaster on PC. Which, like your comparison , would prove nothing we don't all already know.

Last edited by Karlos on 19-Oct-2023 at 06:33 PM.

_________________
Doing stupid things for fun...

@matthey

Quote:

Darkplaces Quake supporting many mods has been running on the RPi since at least 2014 (20-30 fps at 1080p on RPi model B without overclocking).

I was talking running quake on emu68k in a standalone rpi.

Quote:

Most of the 68k optimizations are old and were necessary because the silicon of 68k CPU chips stopped at ~500nm where there are sub 50nm PPC CPUs and ARM CPUs at 5nm today. Optimizations are for CPU hardware where optimizing for an emulator is usually not worthwhile as the underlying hardware has the largest affect on performance and often changes from one computer to the next.

Yes the optimizations were and should be made for 68k, but he was made to imply that the gap would be even further add the ppc been optimized... you're right, the optimization is done on 68k physical, but we also have optimizations being done to the emu core, as it is normal, soon it will have also access to a gfx driver also, so it will be interesting to see how much improvement it gets

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@pixie

With optimization you pick your battle, and different types of optimizations, for example, you can optimize an algorithm, without touching assembly.

It’s little to no point optimization something for the sake optimizing, if you get 500 fps, what will 1000 fps give you, if you only need 60 fps to make it playable.

Generally writing in assembler just make game less portable, harder to read, and often have more bugs, because you have perhaps removed a few checks to gain a few extra clock cycles. Optimizing for X can make it slower on Y, for example if unroll loops on CPU with little instruction cache, it can result in a less performant code. But can be faster on CPU that does not have instruction cache like 68000. Optimizing for 32bit can good on 32bit 68020, but horrible idea on 68000 with multiplexed bus.

Most stuff is only optimized for one target, and not for other targets, because that will make the code incompatible.

for example, 32bit is best bus optimized on 68020 on PowerPC or ARM, using 64bit or 128bit is better for moving data. Because this your code after optimizing will have lots of

#if #else #endif, and junk for etch cpu and platform that optimize it for, and as result you will look like a mess, that no one can read.

Last edited by NutsAboutAmiga on 19-Oct-2023 at 08:07 PM.
Last edited by NutsAboutAmiga on 19-Oct-2023 at 08:04 PM.
Last edited by NutsAboutAmiga on 19-Oct-2023 at 07:57 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

NutsAboutAmiga Quote:

Catch 22. you need developers, but no developers if no market. no market, if no software. and nothing at all if there something better, like Android, Apple, Windows. What we are left with is the crazy, just need to accept it.

There is a 68k Amiga retro/hobby market for likely hundreds of thousands of units with hardware starting around $100 USD as THEA500 Mini shows. THEA500 Mini is only a quick to market toy offering limited value while better hardware could offer much more value for a similar or lower cost.

THEA500 Mini deficiencies
- lacks Amiga branding
- no AmigaOS for productivity software
- low end emulation (poor performance, poor performance/W, increased latency, decreased compatibility, increased cost)
- not particularly cheap
- lacks easy internet access
- non-functional gimmick keyboard

The RPi shows that the retro, hobby, educational and embedded markets can sustain yearly sales in the millions of units with competitive hardware.

There has been no demonstrated desktop market for PPC AmigaNG hardware. If it was possible, it was not achieved when PPC was almost competitive and the desktop market is incredibly difficult to enter even with competitive hardware and a competitive OS. Trevor is the baby that kept trying to stick a square peg in a round hole and he hasn't learned much since then.

pixie Quote:

Yes the optimizations were and should be made for 68k, but he was made to imply that the gap would be even further add the ppc been optimized... you're right, the optimization is done on 68k physical, but we also have optimizations being done to the emu core, as it is normal, soon it will have also access to a gfx driver also, so it will be interesting to see how much improvement it gets

Logically, the performance gap would widen with better optimized PPC code for the PPC440/460 and without emu68k improving. PPC optimizations for a particular PPC CPU usually involve instruction scheduling for that PPC core. Most PPC cores use limited OoO execution so superscalar instruction scheduling remains important. Some superscalar CPU cores are not as sensitive about instruction scheduling which is true for the PPC440/460 core. There are 2 integer pipes and both integer pipes allow the most common integer instructions unlike some low end cores like the PPC 603(e) core. Only the primary integer pipe can execute multiply, division and instructions affecting control registers but this is standard behavior for higher end PPC cores and I expect normal G3/G4 scheduled code to run pretty well. The PPC440 7 stage pipeline is also more like higher end PPC cores rather than the PPC 603(e) 4 stage pipeline so avoiding load-to-use penalties in the load/store pipe with instruction scheduling is likely also similar. Generic PPC scheduling should work pretty well on this core and there likely isn't much to be gained by instruction scheduling for the PPC440/460.

I can't say how much room there is for optimizing emu68k but the underlying hardware can cheaply be replaced with a RPi 4 or RPi 5 for less than 1/10 the cost of AmigaNOne hardware and giving 2-3 times the performance of a RPi 3.

NutsAboutAmiga Quote:

With optimization you pick your battle, and different types of optimizations, for example, you can optimize an algorithm, without touching assembly. It’s little to no point optimization something for the sake optimizing, if you get 500 fps, what will 1000 fps give you, if you only need 60 fps to make it playable.

Some fps gamers consider 60fps low usually because that is the average fps and worst case fps will be lower. Sometimes further optimizing for performance with more loop unrolling and function inlining is not worthwhile as larger code diminishes performance gains. Some game programmers go right for max optimization options in compilers even though this is slower in some cases. This can also make code run slower on older hardware with smaller caches which is a CPU upgrade driver.

NutsAboutAmiga Quote:

Generally writing in assembler just make game less portable, harder to read, and often have more bugs, because you have perhaps removed a few checks to gain a few extra clock cycles. Optimizing for X can make it slower on Y, for example if unroll loops on CPU with little instruction cache, it can result in a less performant code. But can be faster on CPU that does not have instruction cache like 68000. Optimizing for 32bit can good on 32bit 68020, but horrible idea on 68000 with multiplexed bus.

If "checks" are removed then that is an algorithm optimization which can be done just as well in higher level languages. Algorithm optimizations should be done before assembler optimizations. Sometimes an assembler programmer will notice algorithm improvements but they should still be done in the higher level language first.

The 68000 may have a 32 bit ISA but it is a 16 bit CPU. Optimization gains are likely to be low when optimizing for 68000-68060 vs 68000 or 68020-68060. The general categories of 68k performance optimizations follow.

68000 (16 bit, 68000 ISA, no barrel shifter, small code faster)
68020, 68030, 68060 (32 bit, 68020 ISA, small code faster, 68060 missing instructions)
68040 (32 bit, 68020 ISA, fewer simple instructions faster even if larger, missing FPU instructions)

Most multi-68k CPU compiled code should have instruction scheduling for a 68060 but that is rarely available in compilers. If the 68060 had the missing instructions, especially 64 bit MUL and DIV, then 68020/68030 code would be nearly perfectly optimized on the superscalar 68060. Unfortunately, code compiled for the 68060 is larger because of the missing instructions. Optimized code for the 68020/68030 is usually the smallest, followed by 68060, followed by 68000, followed by 68040.

NutsAboutAmiga Quote:

Most stuff is only optimized for one target, and not for other targets, because that will make the code incompatible. for example, 32bit is best bus optimized on 68020 on PowerPC or ARM, using 64bit or 128bit is better for moving data. Because this your code after optimizing will have lots of #if #else #endif, and junk for etch cpu and platform that optimize it for, and as result you will look like a mess, that no one can read.

Obviously, the best performance should come from optimizing for a particular CPU. Compiling/optimizing for multiple CPUs may be acceptable if they are similar (testing to verify is a good idea). For PPC CPUs, the biggest performance difference between CPUs likely comes from instruction scheduling needs which are mostly similar as the shallow pipeline limited OoO designs are similar except for unusual CPU cores like the 603(e), 604(e), PPC970/G5, Cell/Xenon and P1022/e500v2. There are likely others I missed.

The problem with 64 bit code is that it is larger most of the time while moving or calculating on 64 bits is only advantageous some of the time. Most of the time, the same operations are done with twice as much data which takes twice as much space in memory. Some ISAs allow 32 bit and 64 bit sizes giving the option to use 32 bit to gain the smaller data advantages of 32 bit but it is important to avoid partial register writes of 32 bit data to 64 bit registers. The performance advantage of 64 bit over 32 bit is often overestimated. A paper called "Performance Characterization of SPEC CPU2006 Integer Benchmarks on x86-64 Architecture" found less than a 1% performance gain in the SPEC CPU2000 int benchmark and a 7% performance gain in the SPEC CPU2006 int benchmark with 64 bit vs 32 bit compiled code on a x86-64 64 bit CPU. It looks like the SPEC CPU2006 int benchmark was changed to better support 64 bit code. The x86-64 code has 16 GP registers vs 8 GP registers in x86 code but x86-64 code is larger by 21% in the case of the SPEC CPU2006 benchmark. A 7% performance gain at the expense of 21% code size isn't bad but another paper showed a 4.4% int performance gain on SPEC CPU2000 from 16 GP registers instead of 8 GP registers so perhaps less than 3% 64 bit performance gain at the expense of 21% larger code ("Performance Characterization of the 64-bit x86 Architecture from Compiler Optimizations’ Perspective"). A naive recompile of code to 64 bit can easily result in an overall loss in performance. There is code that more than doubles performance with 64 bit code and more modern high end hardware can handle 64 bit code better without as much slowdown but 64 bit is not some magic bullet for performance. It mainly gives more than 4GiB of addressing with an increased hardware cost.

Last edited by matthey on 20-Oct-2023 at 01:15 AM.
Last edited by matthey on 20-Oct-2023 at 01:08 AM.
Last edited by matthey on 20-Oct-2023 at 12:55 AM.

@ppcamiga1

Quote:

ppcamiga1 wrote: It is qemu. It is 20 years old. And it is faster on rpi than emu68. So no reason to switch to emulated 68k. No reason to waste time and money on porting to 68k. If I own Hyperion I will be just pay for virtio, mouse, keyboard, paula drivers and sell Amiga Os 4.1 as is to pistorm users.

Your original claim was that QEMU on Raspberry Pi, emulating PPC, is faster than emu68, emulating 68k, on that same Raspberry Pi.

Quake running natively on a SAM460 is irrelevant.
Show us the benchmarks of your favourite game, Quake, running on emulated PPC and emulated 68k on the same Raspberry Pi.

Also, please try to be less subjective. I get it that focusing on the Raspberry Pi 3B helps your argument, but you need to acknowledge that there is a faster Raspberry Pi 4 and soon a Raspberry Pi 5.

If you acknowledge that, then I agree to ignore the cost-per-frame comparison between AmigaOS 4 running natively on PPC and emu68 on Raspberry Pi.

_________________
All the way, with 68k

My sam460 makes in quake 56 fps in 640x480 8 bit 2009 port no optimisation.
My rpi3 makes under emu68 in quake 62 fps in 320x240 8 bit 2022 port hand made 68k optimised.
My rpi3 makes in quake 89 fps in 640x480 24 bit 2022 native code no optimisation.
My sam460 is 4 to 5 times faster than emu68 on my rp3.
In real applications emu68 is about 6 times slower than native code.
My rpi3 is still slow computer.
web browser works slow on my rpi3 and have are problems with some pages.
It is stupid to switch from real 68k to emulator on arm.
It is not fast and not modern.
Keep your classic clean without arm crap.

@matthey

Quote:

matthey wrote: kolla Quote: What is KVM again? Oh… Probably the other KVM which is Kernel based Virtual Machine. It's hypervisor support built into the Linux kernel since 2.6.20. QEMU/KVM for absolute beginners https://www.youtube.com/watch?v=BgZHbCDFODk A C64 is shown in the above video at 2:33 if wanting to skip the boring parts. https://youtu.be/BgZHbCDFODk?t=153 Maybe there is room in the AmigaOS 4 microkernel for hypervisor support since there is already a 68k emulator in there. Maybe they can add Linux hypervisor compatibility with Linux driver support. The monolithic Linux kernel should fit right into the Amiga microkernel after all. You will be assimilated, resistance is futile, at least without affordable hardware.

Seems like my point went… swooosh…

KVM is what was created on Linux to have virtualization instead of emulation for CPU. So to make use of KVM for OS4, youneed a Linux/PowerPC system. That was my point.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC