Another source of delay could be reading EDID. Are you using latest sm502 driver? I think one of the changes was reducing delay on machines other than sam460ex where the driver was not tested before. I don't know if EDID could be disabled and a fixed resolution set in the Monitor file instead to avoid that delay. If the driver has no way to disable EDID QEMU may have one switch but I don't know how to set that. It may need -global parameter as the DDC that provides EDID info is created implicitly by sm501. But it only seems to have a property to set EDID data not one to disable it. Or you can try commenting out the part that adds ddc to the i2c bus in qemu/hw/display/sm501.c to disable it (better add a property to control that and send a patch to QEMU if that works).
Other than that try finding some tool that adds timestamps to lines and pipe the serial output through that to see which part adds the most delay and try to find what is causing that. If the delay is after the screen mode is changed then maybe it's not the EDID as I think that's read before changing the mode to find the modes, the sm502 driver logs it I think so you should be able to see it where it's read.
If faster CPU does not help it may either be slow IO or fixed delays somewhere.
Try if compressing the kickstart modules reduces the boot time (less data to be loaded, but more CPU time and RAM required), IIRC gzip and bzip2 were supported on the A1 (U-Boot and/or SLB_v2). It's unusable slow on real hardware because U-Boot is executed with CPU caches disabled, but for emulation that's irrelevant.
Unlikely to help as he's already using BBoot which just uncompresses the modules from Kickstart.zip that's not loaded from disk but written in memory by QEMU so this part should already be quite optimised. You may try if using uncompressed zip (with zip -0 using store method) helps as then data only needs to be copied which may be a bit faster as avoids running inflate in emulated code.
If you are using image files (cached by the host disk caches already) for your AmigaOS disks, instead of direct HW access like a passed-through AmigaOS-only nvme, remove/disable any AmigaOS disk caches, in case of SFS comment out diskcache.library.kmod from the kicklayout. Probably wont help much for booting though, maybe 0.5 sec. less, but disabling such useless double disk caching should help for general disk access speed.
I remember Maijestro tried this before and got unexpected problems with a game that worked well with diskcache.library but without that it got choppy sound or something like that. While caching in the guest may not be fast, if it reduces accessing the emulated IDE and avoids MMIO and IRQ load that's still desirable so I think you should not disable cache in guest.
could help. Not using it made huge differences in some QEmu benchmarks. Use NFS, FTP, Samba, etc. instead for file transfers between host and guest.
How about mounting a network share for file sharing instead? That should work better than the vfat drive which is quite limited anyway and then if you don't need other USB devices you can get rid of all the USB stack that should remove a lot of delays. I guess that's the same what Joerg suggested above. But maybe there are still issues with network on Windows hosts that's why that does not work?
balaton wrote:@joerg I remember Maijestro tried this before and got unexpected problems with a game that worked well with diskcache.library but without that it got choppy sound or something like that. While caching in the guest may not be fast, if it reduces accessing the emulated IDE and avoids MMIO and IRQ load that's still desirable so I think you should not disable cache in guest.
You have a good memory With “diskcache” disabled in the kicklayout, there are problems with the game Breakhack, where the game runs extremely slowly.
With “diskcache” enabled, the game runs quickly.
I have also disabled “Diskcache” on my real machine there are no problems with Breakhack here.
Edited by Maijestro on 2025/8/9 7:47:28
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
Except for the delays in old AmigaOS SM502 driver versions which were only working correctly on real Sam460 hardware, but are fixed in the current sm502 drivers, DDC/EDID should only be a possible issue with real hardware like a VFIO-PCI passed through gfx card. Using emulated gfx cards, incl. the SM501/502 one, QEmu just provides fake EDID data (for example monitor model="qemu") which should take next to no time at all.
@Balaton Thanks for suggestions, will try it out, as for:
Quote:
How about mounting a network share for file sharing instead? That should work better than the vfat drive which is quite limited anyway and then if you don't need other USB devices you can get rid of all the USB stack that should remove a lot of delays. I guess that's the same what Joerg suggested above. But maybe there are still issues with network on Windows hosts that's why that does not work?
Yeah, at least for me none drivers i tried (be it old ones, beta ones, etc) didn't work good enough on windows build of qemu : or crashes, or simple stalls, or simple madness slow. So only way usb stick :(
@joerg Quote:
Why USB keyboard? Is PS/2 keyboard and mouse emulation not supported by QEmu? If it is PS/2 should be faster than USB.
Reason is i weren't able to make alt key as amiga key to work with ps2 keyboard even if i have necessary settings in prefs for. Once i switch to USB one, it start to work as expected (i use amiga key offten for spawn a shell, like amiga+e , newcli, etc).
Reason is i weren't able to make alt key as amiga key to work with ps2 keyboard even if i have necessary settings in prefs for. Once i switch to USB one, it start to work as expected (i use amiga key offten for spawn a shell, like amiga+e , newcli, etc).
Using emulated gfx cards, incl. the SM501/502 one, QEmu just provides fake EDID data (for example monitor model="qemu") which should take next to no time at all.
In theory, but in practice a simple bit banging driver hitting mmio on QEMU a lot can be slow. E.g. when booting AROS on sam460ex it stalls on reading the RTC over i2c because it's not using the high level i2c interface of the SoC and maybe its low level driver it's using is not the best. I don't know if the same would happen for DDC/EDID for sm501, the emulation part is similar but drivers are different. It's just a guess, so to prove it one would need to profile it or test it by avoiding DDC and using fixed mode instead and see if that helps but I don't know if DDC can actually be disabled in the SM502 driver but can be commented out in QEMU then it's disabled for sure (but the delay trying to read it may still be there).
Yeah, at least for me none drivers i tried (be it old ones, beta ones, etc) didn't work good enough on windows build of qemu : or crashes, or simple stalls, or simple madness slow. So only way usb stick :(
What's different on Windows that it does not work there when it works on macOS and Linux? Which QEMU build is it (you built it or got from somewhere) and do you get any errors from latest beta rtl8139 driver (I think that's version 53.7 which the author tested on QEMU as well)? Have you tried -device ne2k_pci instead which should be rtl8029 compatible?
I don't want to get this wrong. I also use the Windows version of Qemu, and it's much faster than the Linux one. I don't have any display stutters. The network works well, and I have an old TP-LINK TL-WN722N Wi-Fi USB stick Version 1. The connection is stable.
With Linux, however, the SM501 driver sometimes stutters and stutters. When I use the RADEON R9 GPU, it works fine.
POWERSHELL 7.5.2 Windows10 LTSC 2021 21H2 end life 2027
This one can't be done, the other one can't be done either, then it depends. Now we'll see.
Guys, it's a bit of collaboration.
I don't want to overdo it because it doesn't seem polite. If someone could send it to me privately, I'd be happy. Thanks.
Then maybe we'll waste hours testing things when we find out there's a new version. It doesn't seem right to me. Of course, what kind of testing can we do if everyone uses different things ?
It makes me laugh.
Just as a day well spent brings a happy sleep, so a life well used brings a happy death.
but first you have to waste hours understanding what you need and then you have to hunt for missing pieces around the web and maybe then you can try to emulate it.
This should be put at the top of any documentation regarding qemu for AmigaOS.
The author of the updated Silicon driver is Italian. (m3x)
Thank you for your work, I really appreciate it; you did it, you released it, you put it on OSDepot.
But what is it in Germany there is a sect in the Amiga forums. I'd be ashamed to be part of it.
Learn to share and not waste people's hours (like children)
Edited by white on 2025/8/10 0:45:57 Edited by white on 2025/8/10 0:48:04 Edited by white on 2025/8/10 0:52:37 Edited by white on 2025/8/10 0:56:31 Edited by white on 2025/8/10 2:19:57
Just as a day well spent brings a happy sleep, so a life well used brings a happy death.
and do you get any errors from latest beta rtl8139 driver (I think that's version 53.7 which the author tested on QEMU as well)?
I tried those the versions of rtl8139:
53.6 53.7 (qemu fix) 53.8 (removed qemu fix as it cause issues on real hardware, and one who reported about qemu issues, says that after proper reconfigure of qemu bug is gone, while i can't confirm it, as at least on windows). 53.9 53.10 and 53.11
All of them fail in one or another way : or simple crashes, or stalls after few mb of downloading for few seconds, then speed drops, and bit by bit continue.
Quote:
Have you tried -device ne2k_pci instead which should be rtl8029 compatible?
Of course, i noted it "in better file sharing thread" about:
Quote:
so i tried it firstly with ne2k_pci, and were able to add it to interfaces through this driver, and start the network, and be able to do ping myself, but, can't ping anything else (even gateway) (while of course, with rtl8139 can). For sake of tests i tried "new2k_isa", but that as expected even wasn't found by os4's rtl8029 driver..
OK so you are in contact with the driver author as these are not otherwise available versions. If so, why don't you two look at fixing the emulation in QEMU to work like real hardware, then you don't need to try random patches to the driver hoping it will fix QEMU while not breaking anything else. If the driver works with real cards then it's maybe the emulation that needs to do something differently to match what real hardware does and QEMU is open source so anybody can contribute fixes. The same goes for ne2k_pci.
Actually, my connection is fragmented, too. However, on AmigaONE, it has no problems. Obviously, the driver is RTL 8139 version 53.6 (November 14, 2016)
I'm missing something because I can use bboot-0.7 But not bboot-0.8 I don't remember how to update the kickstart.zip.
Can anyone help me?
Thanks
Because there are two worlds: one is the world of problem-free file sharing. And the other is the world where you can't access them.
It's as if I decide that I like all Internet users. And I share all my purchased material with everyone. Including games like Shogo, etc., and more.
This would be really bad behavior.
Just as a day well spent brings a happy sleep, so a life well used brings a happy death.
Actually, my connection is fragmented, too. However, on AmigaONE, it has no problems. Obviously, the driver is RTL 8139 version 53.6 (November 14, 2016)
Maybe there's a problem with interrupts on pegasos2 despite the workaround in BBoot to configure it level sensitive and I assume kas1e uses latest kernel that should also fix this. But problems were also reported on the German forum even on Linux host here: https://os4welt.de/viewtopic.php?t=2749&start=390 so there could be some problem somewhere. If it works on AmigaOne maybe the only difference is the shared IRQ 9 on pegasos2 so you could try changing it to use similar IRQ assingment on pegasos2. This could be done in a Forth script or in pegasos2 kernel (or maybe in BBoot but then it should replace the device tree which is more work than I want to do so unless someone sends a patch I'd leave it for now, it's easier to patch it in Forth before BBoot runs then can be part of bboot.fth).
Quote:
I'm missing something because I can use bboot-0.7 But not bboot-0.8 I don't remember how to update the kickstart.zip.
Everything should be in the BBoot README. You need version 0.8 for using -kernel/-initrd with -machine amigaone, otherwise it should work the same. To create Kickstart zip you just zip the Kickstart dir after adding siliconmotion502.kmod driver as documented on my page at the URL in my signature.
News feed
OS4 Feedback forum
OS4Depot Feedback 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
Donate
With “diskcache” disabled in the kicklayout, there are problems with the game Breakhack, where the game runs extremely slowly.
