For this I would have to use a graphics card that also supports AmigaOs4.1, that won't work with a MacStudio M1 that is only slightly larger than a MacMini M1.
External graphics card solutions do not exist here. This part would have to be tested by someone with Pc hardware, I'm not even sure if it's possible.
I don't own any real hardware, but I can also confirm that the keyboard input doesn't work. The game starts normally but stays in the intro screen no matter what key I press on the keyboard.
OWB_USER_AGENT "Dalvik/2.1.0.(Linux; U; Android 6.0.1; Nexus Player Build/MMB29T)".
It does indeed run a bit better, I don't want to offend anyone, but the main problem is Odyssey or the internal player and WebCore, it doesn't seem to have been optimized and implemented well. Maybe there is just no better way at the moment.
You can see the comparison as soon as you run YouTube streams directly through MPlayer/YT. I know that software development is very complex and the Amiga community does a very good job with the resources available.
The bottleneck is currently the sm501 support, as already mentioned Qemu is optimized for 32 bit window output. Nevertheless, what is possible under certain hardware is remarkable. I find this really amazing this emulation is very young and yet it already works very well.
Also from me again a short video about it:
@Forum Admins
Of course, I would like to abide by the rules of this forum. Is it ok if I embed my YouTube videos in the forum, or should I just provide the link ?
Edited by Maijestro on 2023/6/10 22:03:07 Edited by Maijestro on 2023/6/10 22:07:12 Edited by Maijestro on 2023/6/10 22:08:16 Edited by Maijestro on 2023/6/10 22:11:23
For me the speed of UAE was acceptable, an A1200 (040) was emulated correctly and the things I tested via "runinuae" were very usable, e.g. the game Heirs of the Earth and some demos.
I didn't test a 68k Amiga system on it and also not the uaegfx support.
geennaam wrote:@Maijestro The shell is a command line interface and works just like the window cmd or powershell or whatever you use on macos. Open it by clicking on the shell icon in the docky bar. Change directory to where you have stored CPUbench. Then type CPUbench.script and press enter. Once finished, you can either type the command again or press "arrow up" and run the script again. Like Linux, use can use "tab" to complete a command. Unlike Linux, you do not need to use "./" or sudo.
I started the benchmark script now directly from the AmigaOs4.1 shell and did the whole thing 3 times. As already mentioned, this error does not exist here.
I see it the same way, almost every household already owns a PC and the fewest want to invest in additional hardware like an AmigaNG system which is unfortunately also very expensive.
@smarkusg also used and tested the Qemu AmigaOs4.1 emulation in the beginning, now he is already developing for AmigaOs4.1, there are some projects already running, but I am not allowed to give details. What I want to say is that there could be more users and also developers.
Also I don't own any real hardware, because I don't have the space for it, but I really wanted to use AmigaOs4.1 and this emulation was the fastest way for me to realize it. In addition, the new development of hardware for Amiga is slow.
geennaam wrote:@Maijestro Reproducing the issue on my system is easy: Run CPUbench.scipt in a shell. Once it has completed run it again in the same shell. The second or third time, it will hang at the drystones benchmark. The system will not freeze. It just will not finish the test anymore. But this can be related to the windows build and might not happen on your MAC.
I could not reproduce it, I ran the script 3 times in a row and it ran completely all 3 times. However, I started the script directly by clicking on it. How do I start it directly through the shell, just in the shell by drag and drop does not work.
@all
I'm sorry if I've given you a wrong impression which is not true for your hardware. I will leave the topic Qemu from now on and only ask for support if it is needed directly under AmigaOs4.1. My intention was never to offend or annoy anyone. Since I like to use AmigaOs4.1 as much as others do under real hardware I felt very comfortable here and could also show approximately what is possible with AmigaOs4.1 and how things already work.
Thanks for the help so far with some software under AmigaOs4.1.
Edited by Maijestro on 2023/6/8 23:13:15 Edited by Maijestro on 2023/6/8 23:15:02
Ok thanks first of all for the detailed explanation. It is not only about the Pegasos2 emulation, but also Sam460, unfortunately this is still very slow at the moment, I guess their hardware is just much more complex than the 20 year old Pegasos 2 hardware. Nevertheless both emulations could profit from it. Sam460 uses the firmware "uboot" which would be more like a real AmigaNG. If you had a working graphics driver that was supported by qemu sam460 and AmigaOs 4.1, it would most likely be usable with the Pegasos2 emulation. And we are not talking about full 3d accelerated drivers or RX drivers that is not needed. What would be sufficient is a driver that can display 32 bit screens and maybe support 2d acceleration.
As you wrote, I was just lucky to buy my Mac M1 and to get involved with the AmigaOs4.1 emulation in the first place.
That you had to buy an AmigaOs 4.1 Pegasos2 version for it is of course stupid. If it's any consolation I had to buy 2 licenses without having proper hardware for it. But I showed from the beginning everything on my Mac with M1 and info I always gave with, I did not know myself that it runs on i5,i7 etc. so limited and sluggish.
Still what the Mac M1 I bought exclusively to work the Qemu emulation took place only out of curiosity, but since it already works very well I am of course glad that I have dealt with it at all.
The test with the CPU benchmarks script I will try to reproduce later on my hardware and will let them know if the same error occurs here.
Edited by Maijestro on 2023/6/8 21:01:21 Edited by Maijestro on 2023/6/8 21:27:40
There are different opinions about it, I can only reflect my experience that I have personally made under my hardware and it is very good. The working speed is consistently positive. There are many example videos from me already.
Many users believe that if they use their 4 year old laptop with Qemu Peg2 they will get a faster emulation than under real hardware (Peg2,Sam460) and that on a CPU that works completely different. This cannot and will not work.
Of course, it is an emulation and there are many limitations that do not exist on real hardware. But that has already been discussed here.
In order to solve problems we would have to investigate them further and also report these errors. Or reproduce them clearly. I do not have this problem with the workround of the older Pegasos2 rtl8139 driver in use.
We don't know exactly where this bug comes from and it would probably have to be investigated directly from the Qemu site, but also from the AmigaOs 4.1 site.
If no one wants to support the Qemu Peg2 Project then nothing will change.
Maybe someone has an idea how we can better investigate the problem ?
Edited by Maijestro on 2023/6/8 15:32:44 Edited by Maijestro on 2023/6/8 15:50:18 Edited by Maijestro on 2023/6/8 15:54:43 Edited by Maijestro on 2023/6/8 16:47:34
Would it make sense to install Linux instead? Does it bring any benefits?
No their hardware is a bit weak. The best experience is currently achieved with current Ryzen CPUs or M1/2 CPUs.
I use the latter, even on the cheapest MacMini with M1 (699€) about my values are reached and AmigaOs4.1 feels really very good under emulation. Benchmarks prove that the emulation is far beyond real hardware (Pegasos2/Sam460/AmigaOne).
Also running Qemu under Linux would not speed up the emulation, Qemu is not dependent on the operating system used but on its hardware, the faster the hardware the better the emulation.
Since host and guest use different CPU,s x86/ppc we can only emulate it and not virtualize it using e.g. KVM Linux or Apple's hypervisor (virtualization framework).
Thanks for the comparison test, since I was also unsure, I also compared CPU g3 and g4 7457 and my results show that sometimes the G3 cpu is faster, sometimes the 4G CPU 7457.
RageMem:
SortBench:
QuickSort:
Whetstone:
I have both CPU results packed side by side, left side CPU G3, right side CPU G4 7457.
I've read your conversation on amigans.net forum so I answer a few questions:
> Maijestro: > @white ? > Quote: > > white wrote:@Maijestro > > I'd like to know because otherwise I have to recompile the FPU > support from scratch. > Not so much for its compilation because it takes 10 seconds. > > But it takes at least an hour to replace the files > > Ask BALATON Zoltan
Indeed, it's best to ask me if you have some question because writing it to random forums is not the best way to get an answer. I may read some forum threads and answer if I happen to know your email address but may not find all questions that way. If you prefer a forum there's also one at https://osdn.net/projects/qmiga/forums/ but it's not yet used.
> Otherwise I have no information about it, as I said there were only minor > changes. Some patches were questioned. All changes will probably take > place in Qemu 8.1.
QEMU 8.0.x are stable releases and only contain back ported bug fixes that may be important for those running a stable version but no new features. So pegasos2 related changes are usually not included in stable versions only in next version with new features which will be 8.1 in August (see: https://wiki.qemu.org/Planning/8.1 ) and only when they are merged until July 11th. Anything missing that deadline will be in 8.2 due in Decembet.
> - shutdown via shutdown Linux/AmigaOs4.1
This is not merged yet but maybe still can be in next release
> - CPU 7457 as default setting
This will be there as it's merged already
> - code cleanup, speed improvement
There are some pending patches for this but don't expect very big speed improvement, maybe a few percents are realistically possible.
> White: ? For example, for a long time it was believed that with WinUAE selecting > in Z3 RAM "automemory" > > Was the best choice for 4.1 while actually if you select "Real Memory" > > Emulation speed doubles which I always selected. In the end even "Toni" > understood that with 4.1 it is better to choose "Real Memory" in Z3 RAM. > > Now I don't know how ram is managed in "qemu Pegasos2" > but i think i have the same problem.
What makes you think we have the same problem?
> I think ZBalaton should investigate this. > And figure out if there's a correlation to that in memory management.
I can only investigate what I know about and what I also understand.
> Although always available ZBalaton sometimes does not understand in good > faith I mean. And he is a really helpful person, mine is not a criticism > of him.
Yes I can't fix problems I don't understand so then I need more info on those to help me understand it. Telling me that some setting works in UAE or VMWare are not too helpful as I don't know or use UAE or VMWare so I dan't help with those and also don't know what would that mean for QEMU so I can only guess which is usually not enough to undrstand the problem.
> But I've been emulating 4.1 for many years > The suggestions I try to give him sometimes fall on deaf ears. > > For example, the problem of the SFS filesystem was from the 3.0 version > of qemu that I had reported the problem.
This was also a problem which wasn't understood but it was also not possible to fix, SFS still does not work on sam460ex where you've reported it and the reason is not a problem in QEMU but in the SFS driver included in AmigaOS 4.1 which only supports specific processors as was now found and confirmed. I could not figure this out from your report telling me that it does not work, it needed more information and experimenting that was only done by some people now that we had pegasos2 that could use different CPUs. If this theory is true then SFS also does not work on a real sam460ex so I wonder if that's really the case but it would need somebody with a real hardware to confirm that.
> Now I'm talking about the memory to be selected in "Real" mode > I have no idea how it is handled by qemu but this needs to be fixed in > the code of "qemu Pegasos2"
And I have no idea what's Real mode in WinUAE and not sure it can be fixed in QEMU the same way.
> So you should see what part of WinUAE code manages this option and > import it into qemu Pegasos2. Because it's essential. > > This would double the emulation speed.
This may not work like that because UAE emulates a classic Amiga and QEMU emulates a pegasos2. The pegasos2 does not have Z3 RAM as it also does not have Zorro bus. The RAM in pegasos2 is just mapped from address 0 and can go up to 2GB but the firmware can only detect 1GB SIMMs and QEMU only emulates one SIMM. You can tell it to emulate a 2GB SIMM but the firmware then does not detect it so we'd either need to split it into two SIMMs or do something with the firmware to make it work with 2GB SIMMs. (Newer firmware versions also seem to have this problem maybe because 2GB SIMMs were not common back when pegasosII was a supported machine).
But back to the Real mode issue. First of all what is that? Does that mean disabling usage of MMU and just map RAM one to one? I'm not sure AmigaOS4.1 can do that on pegasos2 but if you can somehow disable use of virtual memory or MMU that may improve speed a bit but probably less than two times. I'd still need more info on what you mean to understand the problem better, without that I can't do much about it.
Regards, BALATON Zoltan
BALATON Zoltan is very open minded and if you have any questions please contact him directly.
If it's not too much to ask maybe we could create a new category for the forum on Amigans.net for the Qemu Peg2 AmigaOs4.1 stuff?
version 8.0.2 should be updated with cpu changes 7457 is 6 days ago
have you tried it?
I have now tested Qemu 8.0.2, as I had already suspected relevant changes that mainly affect Qemu Peg2 have not yet been merged. Will probably only changed with Qemu 8.1.
joerg wrote:@white The problem with SFS (only the versions illegally sold by Hyperion as part of AmigaOS 4.1 FE and beyond) in qemu were simply that qemu emulated complete nonsense, for example a 600 MHz 7400 CPU with 0 bytes L2 cache, which neither exists nor was anything even close to any of the CPUs supported by AmigaOS 4.x (in case of the G4 CPUs only V'ger and Apollo versions are supported) and therefore failed the copy protection tests in illegal SFS distributions.
It was luck that AmigaOs4.1 could handle this G4 CPU 7400 at all, leading of course to a very unstable and incompatible system.
The funny thing is that @smarkusg found out because they first started to work intensively with the Pegasos2 AmigaOs4.1 emulation.
As I also tested the sm501 part, which then added sound and network support. About 1 year ago this emulation was totally unusable.
Have you ever asked BALATON Zoltan and explained it to him ?
The problem with Qemu used to be that not many people used it with AmigaOs 4.1 and reported bugs, so it remained a poor emulation until Qemu 7.2, when like you I could reproduce most of the problems with Qemu 3.
Many things have been improved since then, SFS, network, sound, CPU/FPU the main problem unfortunately remains and that is the sm501 with its low resolutions and 16 bit output.
Thanks for the benchmark on a real Pegasos 2 hardware. The Quicksort Bench could have been shortened a bit, the many numbers are not necessary only "Total time taken by CPU" is decisive.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
