On the above 2 videos you could not see it clearly, but I have tested it further and now have the final proof that DiskCache also works under Qemu/Pegasos2 or the guest system takes over the settings.
In the next 2 videos you can see it clearly using SFS from Enhancer Software 2.1. That was also the reason why I accidentally informed@walkero that breakhack is not working properly anymore.
As I wrote I don't know how disk caching works with QEmu on MacOS, and you may be the only one using a complete HD or SSD for AmigaOS 4.1 with QEmu. If you use image files instead of a real HD/SSD passed through to QEmu, any host OS should cache the image file(s) contents and using diskcache.library on AmigaOS 4.1 as additional disk cache probably wont increase the speed.
As I wrote I don't know how disk caching works with QEmu on MacOS, and you may be the only one using a complete HD or SSD for AmigaOS 4.1 with QEmu. If you use image files instead of a real HD/SSD passed through to QEmu, any host OS should cache the image file(s) contents and using diskcache.library on AmigaOS 4.1 as additional disk cache probably wont increase the speed.
You could of course be right that it is different with virtual HD,s .... I will test it the days.
But since I use a real SSD and we happened to talk about the FileSystem, I noticed that and of course I wanted to try it out and that was good, because now with activated DiskCache it is again much more performant than with deactivated DiskCache.
I myself would not have expected such differences as soon as a real HD was passed to Qemu, but it shows that the guest system AmigaOs4.1 takes over the settings completely and takes care of them. So it was good that we discussed the topic again and I thank you for that.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
I do use/have #version sys:Kickstart/SmartFilesystem full SmartFilesystem 1.293 (19-11-2015) AmigaOS4 PPC A-EON Technology Ltd
I'm using the same version and it's configured with SFS\02 on the Pegasos2 machine with a real SSD via Media ToolBox. But I seem to remember reading in another thread that SFS\00 would probably be the better choice. Perhaps the size of the partitions also plays a role. I'm currently using a 500 GB SSD.
This whole FileSystem thing always raises questions, and very few people know how to configure it properly. Nonetheless, I left you an example of what my current configuration looks like. A lot of it was recommended to me by @joerg, e.g. the buffer settings.
Perhaps @joerg can write something about what would make the most sense.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
You could of course be right that it is different with virtual HD,s .... I will test it the days.
But since I use a real SSD and we happened to talk about the FileSystem, I noticed that and of course I wanted to try it out and that was good, because now with activated DiskCache it is again much more performant than with deactivated DiskCache.
I myself would not have expected such differences as soon as a real HD was passed to Qemu, but it shows that the guest system AmigaOs4.1 takes over the settings completely and takes care of them. So it was good that we discussed the topic again and I thank you for that.
On real hardware disk cache is used because the disk is slower so it keeps things in memory for faster access. This is a common technique done by all modern OSes. If you access the disk image through you host OS (like when using an image file) then the host OS's cache would already do this so caching in the guest again won't make much difference (it may even add some overhead). If you pass the disk to the guest so the guest will handle it directly without the host's upper layers then there's no cache on the host so you may need one in the guest. It's like running the guest on real hardware as it accesses the disk directly. Even if you already have cache on the host having one in the guest too should not hurt too much so I'd say just don't bother and leave it alone, no need to disable the cache in the guest unless it's not working correctly or you've measured it's actually faster without the disk cache in the guest. I wouldn't expect it to have a big overhead even when not needed but didn't actually measure it.
I'm a bit lost on what works and what doesn't currently. So far I think we have:
- @smarkusg confirmed that 68k version works with QEMU master - @jabirulo confirmed that Enhancer version works on real machine - @joerg said that the version that comes with the Sam460ex version of AmigaOS4.1FE does not work even on real machine (!? what do people do who bought it or got it with their boards?) but also said that older version and the Enhancer version should work - @maijestro and @smarkusg tested it and seems only 68k version works on QEMU sam460ex
Is that correct?
I've found a problem with current QEMU with MorphOS that I've bisected to a change between QEMU 8.1 and 8.2, see here: https://lists.nongnu.org/archive/html/ ... ppc/2024-02/msg00703.html so there might be some issue but not sure yet what. Can you test if SFS works with QEMU 8.1 with sam460ex (not the CD version but one that's supposed to work) to check if this may be the same bug?
But I seem to remember reading in another thread that SFS\00 would probably be the better choice. Perhaps the size of the partitions also plays a role. I'm currently using a 500 GB SSD.
@smarkusg The commit in question was also backported to stable and is in QEMU 8.1.2 and later. Try with original 8.1.0 (git checkout v8.1.0) or with 8.1.1.
AFAIK SFS\00 is a must if I want to boot on my SAM460ex using SFS.
It depends on the 2nd level boot loader, I don't know which one is used on the Sam460ex. - SLB_v2 used on the AmigaOne SE/XE/µA1 and Sam440ep supports both SFS\0 and SFS\2. - AFAIK amigaboot.(ub|of) used on the X1000, X5000 and probably A1222 only supports SFS\0. - ACube's Parthenope boot loader only supports SFS\0.
One more question in Linux kernel regarding pvr for 460ex rev. B is set 0x13202004 i checked out of curiosity setting such value in qemu and AOS got up. I also checked for certainty by setting a random value and AOS did not boot - so I set everything right. uboot was also initialized without any problem
As I understood the pvr mask 0x1320 applies to 4xx series porceosrs. This means that for AOS it does not matter pvr only in specific programs that try to check it ? thank you for your reply
@joerg SAM460 4.1FE Install CD:System/L/slb_v2: $VER: slb_v2 1.19 (26.11.2008) Compile options: CD booting, HD booting, SFS support, Linux on RDB booting, TFTP boot support Seems to be same as on AmigaOne 4.1FE install CD.
@smarkusg 0x1302 not 0x1320. There's also pvr_mask in linux which does not care about 0 bits in that mask so it masks out bits that may be some patch level or manufacturer dependent. Maybe U-Boot does the same, did not check. But I got the PVR value we have in QEMU from some real hardware logs and should match the real chip PVR value.
I thought I read here that we shouldn't use DiskCache (maybe only if you use FFS?).
Don't know what you refer to but maybe it was when running on QEMU when using image files that should already be cached by the host then having additional cache in the guest is not needed. On real hardware or when passing through disks to guest so it handles it like on real machine I think disk cache is still useful but @joerg is the expert on that. He said SFS uses diskcache.library so it should be useful for it. I think it's best to not mess with it and leave it as it is on real machine unless it's proven to slow down access whith disk image files on QEMU but I think the difference might be small if any so may not worth the hassle and confusion of when to use it or not.
@smarkusg Thanks for testing. Then maybe we have more than one problem and I don't know how to debug any of them. The MorphOS boot problem may be debugged by trying to follow what code it runs and what the commit that caused it changed but hope that somebody on QEMU list will have an idea how to fix it. For the SFS issue I don't even know what could cause it so no idea what to do about it. It would probably need to be debugged in AmigaOS by somebody who knows how to do that. Does SFS print any logs somewhere that could help to get closer to the cause?
I think it's best to not mess with it and leave it as it is on real machine unless it's proven to slow down access whith disk image files on QEMU but I think the difference might be small if any so may not worth the hassle and confusion of when to use it or not.
If it's the same speed, or a little bit slower, with diskcache.library you should disable it. Since it's not part of the kernel memory allocator it can't only use otherwise unused memory for the disk cache as the disk caches of most OSes do but uses a fixed percentage of the installed memory instead and if you disable it, because it doesn't increase the speed with image files, you have more free memory for other software.
Does QEmu support emulating a PCI PATA (SII0680, IT8212), SATA (SII3112/3114/3152) or SCSI (LSI/NCR/SYM 53c8xx) controller for which there are AmigaOS 4.1 drivers? If yes it should be tested if SFS works with one of them instead of the Sam460ex onboard SATA emulation.
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
Donate
