What the fastest possible x64 emulation way of OS4 today ?

@smarkusg
Quote:

Probably what Martin mean, that you miss the entry in the first answer about boot loading speed of amigaboot.of , so the answer was looking like you showing only speed of bboot to do a compare with the speed on real pegasos2 :)

As for whole speed: On real peg2 there it's all IDE, and through i do use Sata2IDE adapter it still IDE speed. Plus i also have set debug level, so it also takes few seconds.. I do have IDE2CF adapter as well, so may try for sake of interest how fast it will be from CF, but since it all ends with IDE, it can be same result.

What i am interesting most it when this damn PCI<->PCIE adapter arrive and i can test RadeonHD with :)

@kas1e

You are most likely right.
Just booting from "pegasos.rom" on Qemu is long - detecting devices/settings etc.
Additionally, the boot settings need to be entered, as they are not saved during emilation.
Bboot boots under Qemu with practically all the necessary settings.

Reading the threads on the forum you were sceptical about Qemu PPC/Qmiga.
I hope you will change/change your mind

Good luck with the PCI<->PCIE adapter

@kas1e

You should remember that this is not about improving the Pegasos 2 hardware, it's about the Qemu Pegasos 2 emulation, that it works with real hardware is the result of Qemu, as they mentioned back then that if they ported SuperTux they wouldn't support emulation.

I understand your thinking of course, since everything 3D accelerated runs better under real hardware, but never say never. You just benefit from the Qemu Pegasos 2 emulation and should be open to support it.

Of course the information how things work on real hardware is important to make the Qemu emulation better and if this works on real hardware too.

We should all work together and everyone ultimately benefits. It's not a criticism, just my personal opinion.

@Maijestro, @smarkusg
Don't understand what you want to convince @kas1e about. He's been helping a lot so far and I think he uses both emulation and real hadware so no need to take sides or fight about anything or try to convince anybody that one way is better than any other. There's enough space for everybody here I hope so just be cool.

My primary goal for writing BBoot was to avoid the need for the non-free firmware for booting AmigaOS on QEMU but I realised that this could be useful for other things as well, such as allowing using so far unsupported gfx cards either via pass-through with QEMU or via bridges on real hardware or also to just boot faster even on real PegasosII so those are also usages I'm happy to support and glad to see if BBoot is useful beyond its original goal to boot AmigaOS without pegasos2.rom. I still want to keep it simple and small so maybe don't want to put in too many features but its usage is certainly not limited to QEMU and I've considered real hardware usage as well when writing it.

@kas1e
Could you please try this new version on real PegasosII?
http://zero.eik.bme.hu/~balaton/amiga/bboot/bboot-test1.xz
It should fix access to AGP card which was showing with all ff values before which also means that this is probably broken in QEMU now so maybe that's why @MartinW could not get a card work with bus=pci.0 so use the default bus for pci pass through for now.

(This is now a pre-release testing version, nothing new for using on QEMU in it and I plan to add more to this for an actual release so everybody else can ignore this, for them it's identical to last released version but will get all ff on QEMU for pci.0 devices, opposite of what's in real hardware I think but that's what should be tested.)

@balaton
Maybe you misunderstood something, or I misspelled something, or didn't share my thoughts....

@kas1e once wrote that he prefers WinUAE. He had some concerns about Qemu.
I hope those concerns are gone, WinUAE is also a very good emulation. I also use it occasionally.


One of the old "amigans.net" forum members recently wrote me a thought (I won't quote who because he may not want me to).

"...amigans.net is such a peaceful haven in the Amiga world compared to other Amiga forums...".
I have no intention of changing that.

So, have a nice day, a peaceful weekend, good health and for the StarWars fans "may the force be with you"...

@balaton
Quote:

There is output from bboot-test1:



All works as expected after boot

@kas1e
Hmm, then I'm puzzled how to actually access the AGP port on pegasos2. I think Linux just uses rtas for that, not sure if AmigaOS does the same. The openfirmware.resource in kernel mentions rtas but did not see calls from it so don't know what it actually does. At least one change now that BBoot will not try to write the wrong device (no ! value after ffffffff values) so it should be safer against breaking somehting but I'd still like to find out how this works as that may be the reason why pci.0 did not work with pass through. Any ideas anyone?

@smarkusg
That initial post by @kas1e was written more than a year ago when AmigaOS did not run on QEMU pegaos2 yet (at least not in a usable way) and it does run slower on sam460ex due to some issues in PPC440 emulation. I've found the issues earlier this year when did profiling to try optimising it a bit but did not have time to try to fix it yet. But since then we've made aome progress with pegasos2 which is still not fully there but should be more usable now so it's more the background or view point changing than opinions.

Yes communicating in English with it not being native languege for most people can be difficult so just wanted to clear any misunderstandings.

And for Open Firmware fans "may the Forth be with you".

@balatonQuote:

Did they actually make a joke once?

The revised installation guide is ready, I have already tested it and BBoot boots AmigaOs4.1 Pegasos 2 install.iso (unmodified) without problems. It's great that Peg2.rom is gone and we don't have to manipulate original iso installation media anymore, I always had a bad feeling about it.

Would you like me to email you these revised instructions?

@kas1e
I've made another bboot release 0.3 which is most interesting for using on real hadware as it fixes the forth script to not require editing (took almost the whole day to figure it out although it should be simple) and adds configurability to make it faster on real hadware and output to screen instead of serial. See README for details under Configueation section.
For use with QEMU there's not much change, It will just less likely to try to program a PCI device if it cannot talk to it to avoid breaking anything otherwise it's pretty much as before, the other new features are not useful on QEMU where it's already configured by default for best usage so no reason to change anything (and there's no way either as QEMU does not support setting options yet).

@balaton
Quote:

Tried on my peg2 firstly "as it" without configuration, and find out that seems there or some additional carriage return, or maybe some missed instead. Now for most of strings it didn't starts on the next line , but continue previous one from the last place of the previous. Forum's quote tags didn't give ability to show how it, so will show it on screeenshoot.

But for first an output:





And screenshoot of putty how it looks like in 0.3 now (in 0.2 it was ok with same settings of putty):

https://kas1e.mikendezign.com/pegasos2/bboot_03_serial_output.jpg

As for speed of loading, i think at least with the default configuration speed the same: about 25-26 seconds to show up workbench (0.2 version was 27 seconds).

And yes, forth scrip works as it, no need editing :)

ps. Probably the most fast boot will be with "Os V0 Ab" ? For now trying to find out how in OF set the new configuration variable, simple "setenv /options/bboot "Os V0 Ab" " gifing "error: no such configuration variable".


@All
Have anyone tips how create in /options a "bboot" entry with necessary content ? So far tryed all the "echo aa >/options/bboot", mkdir, whatever else , but still didnt' find a way. Casual "setenv /options/bboot aa" was a hope, but nope, also didn't work.

All i have for now is that i do have /options directory in root of OF, and can go inside, but it's empty and so far didn't find a way how to create a file there..

Any hint are welcome of course

@kas1e
Try with 0.4, also check README for answers to your question.

@Balaton
Thanks for ! 0.4 works fine , and print all ok, and Readme self-explain everything, thanks!

I will create now another thread about peg2 + radeonHD/RX things, as i start to go futher, and recieve a first (i order 2 different) pci 2 pcie bridge.

@kas1eQuote:

I also know someone with a Pegasos 2 who would be interested in this solution. I will make him aware of the new thread. Thanks for testing.

@balaton

Qemu 8.1.0 rc with bboot 0.2 doesn't work for me with vfio.

I've applied the first two "patches" in post #787 and that seems to solve the crash of the RadeonHD driver. RadeonHD driver loads but no display. Do I need to blindly apply all diffs in that thread of post #787? Because that thread is a bit of a mess.

@Maijestro

Me too please! I am also interested in real Peg2 + newer Radeon cards finally being supported.

@geennaam
You definitely should not blindly apply patches then report that it does not work without any detail. That does not help to find a problem. So first try with latest BBoot (currently 0.4) describe how you ran it and what's the problem you got and if relevant debug output where there are errors or showing what problem you got.

The freeze might be related to interrupts that aren't yet understood nor fixed any patch yet but @MartinW found that just using the single patch here

[PATCH v5 5/7] hw/isa/vt82c686: Work around missing level sensitive irq in i8259 model

works the best. The rest of that series is already applied on QEMU master so you should not be able to apply those without errors, if you could then you're maybe using wrong QEMU version to begin with but you did not include that info either so can't tell. To apply this one patch get it from the Download mbox link on above page then use "git am" to apply to the QEMU master git tree.

But first maybe try without any patches with QEMU master and give some more details about what you did and what result you got.

@RethQuote:

Please stick with @kas1e and @balaton and watch the new thread to be opened for these things and they can also assist with real hardware to be able to solve the problem.

@Balaton

Qemu 50% power loss

I don't know exactly how to describe it, but I'll try anyway:

Since I started using Qemu Pegasos 2 /7.2/.8.0 and finally 8.1 RC I observed that some sessions of Qemu Pegasos 2 are very fast, others are not.

The test was always the same, I start Qemu, boot AmigaOs4.1 and run a FPS benchmark with Quake Timedemo1. If I have a good session I get 32 FPS, if I have a bad session just 16 FPS.

During the test no other programs are running in the background and I made sure that the CPU display always shows the percentage value when I ran the tests under MacOs. Also it is hard to reproduce this partly I have to restart Qemu 5-6 times until I get back to the best performance of 32 FPS under Quake. I also tested it with sm502 update 3 and sm502 Same460 as I suspected it might be an initialising problem of the sm501.

Since this problem is hard to reproduce I am not sure how we can investigate the problem further. But I am sure that there will be similar problems on Linux. So this should be tested.

I will provide a video to better explain how this test went.



Anyone using Qemu Pegasos 2 should please test this to confirm that there is a performance drop within Qemu. Maybe there are shorter FPS tests we can use?