I'm not sure if this question has been discussed here before, and if so, then I'm sorry, I'd like some information on it.
As the title suggests, it's specifically about the Sam460 with AmigaOs4.1. Is it generally possible to use the SmartFileSystem on this machine?
There was some dispute about the version on the AmigaOs4.1 Final Edition, but what about Enahncer Software 2.1, which also provides SFS? Can this be used without restrictions or are we limited to FFS on Sam460? ?
One final question about the NGFS file system is it limited to AmigaOne x5000 or could it also be used on computers like AmigaOneXe/Pegasos2/Sam460/x1000?
@Maijestro Pirate copies of my software, incl. SFS, which, despite explicit prohibition to continue using them, were illegally included in AmigaOS 4.1 FE and newer distributions by Hyperion are of course supposed to fail.
SFS itself doesn't include any CPU specific code, but diskcache.library does. It has optimizations for several different CPUs, incl. the 440ep (which should work the same way on a 460ex), which may not work as it should, or even not at all, on emulation. Please try if SFS works on QEmu/Sam460 without using diskcache.libary.kmod: Remove it from the Kicklayout, or add a ';' in front of it's entry to disable it.
NGFS should work on any system as well, but AFAIK it's still only available to OS4 beta testers. The only public versions is the one included with the X5000, and even that one is just an old version (IIRC NGFS V1 instead of the current NGFS V2) which shouldn't be used any more. Ask the author of NGFS if you can get a current version of it.
The problem is , it does not work on QEMU emulation Sam460. I do not own pirated versions , I have legally zakuipony system for Sam460 and ES. Believe me , it works everything even JXFS in write mode (without swapping binary files so that it is not that I have a broken system) SFS does not work. I have checked almost everything possible. If it is not a secret is something that can cause ze SFS does not work where other systems even yours (JXFS) works ?
Thank you for the information
*) about the consequence of using JXFS as a system partition I know. I've written in the past that it is purely my whim. I learned to use it by learning its problems.
@smarkusg Did you try without diskcache.library? Some versions of it include CPU specific bcopy()/memcpy() and bzero()/memset(,0,) functions, the 4x0 versions use DCBA, DCBT and DCBZ which might not be emulated correctly by QEmu.
If it doesn't even work without diskcache.library try if older versions of SFS work on QEmu, for example version 1.277 from OS4Depot or Aminet which probably was built with older versions of GCC, binutils and vlink. If that doesn't work either you could try the AmigaOS 3.x/m68k version included in the Aminet archive, which has to be installed in the RDB with MediaToolBox and the PPC version disabled in the Kicklayout. Even the m68k version of SFS should be much faster than the PPC native FFS
Thank you for the information. I know I have already done the work but ... I will do everything again according to your checklist - it's always better to check 10 times - AOS4FE SAM460 installation CD , SFS with ES without diskcache - Clean installation on FFS, replacement of previous versions from OS4Depot(2007) with and without diskcache.library. - SFS replacement with AmigaOS 3.x/m68k and
If this list should contain anything else, please let me know Thanks for your help
I have checked using the AOS4 FE Sam460 installation CD by modifying the files and changing the options related to diskcache.library. SFS AmigaOS 3.x/m68k option works. The system installed correctly. Checking the same thing several times sometimes comes in handy
It's a pity that SFS doesn't work in the version for AOS4. but it's good that the option with the one from AmigaOS 3.x is available.
Just a question. > Ask the author of NGFS if you can get a current version of it. Who is the author of NGFS ? Out of curiosity, I would ask if a version is available for testing. It doesn't even have to be the latest version.
Did you try without diskcache.library? Some versions of it include CPU specific bcopy()/memcpy() and bzero()/memset(,0,) functions, the 4x0 versions use DCBA, DCBT and DCBZ which might not be emulated correctly by QEmu.
DCBA and DCBT do nothing in QEMU which is probably OK as there's no cache so it can't do anything. The data is still in memory where it should be. (Or should these update some TLB entries too?) DCBZ should work but it's slower than not using it (it's the "tricky" measurement in ragemem as far as I know). This could be optimised but not sure how many things use it to help but it should still work as it is.
If it does not even recognise the volume even without diskcache.library then maybe it's not becuse of these instructions. Any other idea why it might not work?
Thanks for this information, my suspicion has been confirmed that something must be missing in the Sam460 CPU emulation or something else that we are currently unable to use SFS on this machine. We had exactly the same problems with the Pegasos2 machine and the wrong CPU setting.
SFS 68K works without issue and it doesn't matter if DiskCache is enabled or disabled as a module in the KickLayout.
I am also interested in NGFS and would like to try it out as a file system. Otherwise, I am also very happy with SmartFileSystem on my main computer Pegasos2.
If you know who is currently developing NGFS or who we can contact, I would be very grateful for your help.
Wrong PVR? But that could only be the reason diskchache.library doesn't use the correct CPU specific memcpy()/memset() functions, SFS itself shouldn't include any CPU specific code. Edit: I don't remember if it's the 440/460 or other CPUs, but at least on one of the PowerPC CPUs for which I implemented CPU specific memcpy()/memset() functions DCBA works the same way as DCBZ, but faster than using DCBZ itself, i.e. the allocated cache line doesn't include random data but is set to 0.
Instead of a (qemu emulated) harddisk did anyone try whether SFS also fails when creating/mounting inside AOS4 a SFS disk image file (using something like "diskimage.device"). Maybe SFS doesn't like something about qemu emulated harddisks.
I think they also mentioned in another thread that diskcache.library makes no sense under Qemu/Pegasos2/AmigaOneXe/Sam460 unless Qemu supports it.
Not even if a real hard disk is used? I currently have diskcache disabled on the Pegasos2 machine, but I'm not sure if it's right.
It depends on the host OS. If the host OS uses it's own disk cache, like for example Linux does, it doesn't make any sense to use an additional guest OS disk cache as well since that wouldn't cache the actual disk (file) contents but just the contents of the cache of the host OS instead, making disk accesses slower instead of faster. I don't know how it works on MacOS. On some host OSes the host OS cache may only be used if you use image files for the AmigaOS partitions, other OSes may cache direct accesses of real HDs as well.
@GeorgQuote:
Maybe SFS doesn't like something about qemu emulated harddisks.
SFS only supports 512 bytes/sector disks, but except for that there should be no difference between real or emulated, incl. diskimage.device, HDs. Additionally it can't be a general QEmu problem since SFS is working with the AmigaOne XE and Pegasos 2 QEmu emulations.
Edited by joerg on 2024/2/27 17:55:27 Edited by joerg on 2024/2/27 17:59:55
Wrong PVR? But that could only be the reason diskchache.library doesn't use the correct CPU specific memcpy()/memset() functions, SFS itself shouldn't include any CPU specific code.
In QEMU CPU_POWERPC_460EXb = 0x130218A4 which I think matches real CPU. Both in logs I've seen from real machine and QEMU, U-Boot idenfifies it as "AMCC PowerPC 460EX Rev. B" so that should be correct. If SFS does not include CPU specific code then why did it not work with previous default CPU on pegasos2? It seems to do check CPU. What exactly is it looking for on sam460ex?
Quote:
Edit: I don't remember if it's the 440/460 or other CPUs, but at least on one of the PowerPC CPUs for which I implemented CPU specific memcpy()/memset() functions DCBA works the same way as DCBZ, but faster than using DCBZ itself, i.e. the allocated cache line doesn't include random data but is set to 0.
I've checked the PPC docs and they say that on 440 dcba is no-op, on some older BookS CPUs like G4/G3 it may be the same as dcbz but does not generate exception and it's removed from newer BookS CPUs (but AmigaOS does not run on those). So if anything this could cause problem on pegasos2 and amigaone not sam460ex as dcba is treated as no-op now in QEMU.
why did it not work with previous default CPU on pegasos2?
It doesn't include CPU specific code, but may still check the CPU type (PVR register) to check if it's something it can work on. IIRC the initial versions of the Pegasos 2 QEmu emulation used a default CPU never supported by AmigaOS 4.x but only by PPC MacOS and PPC Linux (7400 instead of 74[45][157]?) instead.
It depends on the host OS. If the host OS uses it's own disk cache, like for example Linux does, it doesn't make any sense to use an additional guest OS disk cache as well since that wouldn't cache the actual disk (file) contents but just the contents of the cache of the host OS instead, making disk accesses slower instead of faster. I don't know how it works on MacOS. On some host OSes the host OS cache may only be used if you use image files for the AmigaOS partitions, other OSes may cache direct accesses of real HDs as well.
In fact, the hard disk is not mounted under the host system MacOs and MacOs itself has no access to it and is no longer displayed.
The only access is with Qemu/Pegasos2 AmigaOs4.1. As far as I know, real hardware such as graphics cards/USB/hard disks etc. that are handed over to Qemu should not be available or logged off in the host system.
So it could well be that the guest system could use the diskcache in the case of AmigaOs4.1.
Ok thanks I will test that...
with activated DiskCache.library it seems to work a little better, I see it when several loading times and tools are used e.g. when starting AmigaOs4.1 up to the built workbench.
Pay attention to the notification window when the workbench is uploading, if there are a lot of read/write processes, it seems to run better with DiskCache enabled.
Edited by Maijestro on 2024/2/27 19:19:44 Edited by Maijestro on 2024/2/27 19:21:42 Edited by Maijestro on 2024/2/28 18:24:53
If I understood correctly SFS could be run on the specific machines that AmigaOS 4 was running on. I came across a topic on another forum where one of the new x5000 users has to edit the AOS4FE install CD to add SFS with ES to make it work for him. JXFS has no restrictions and no assignment to the specific processor it can run on. This is also your file system. Would it not be possible to remove this from SFS and make versions available as part of an ES update? You are the rights holder for SFS , you have the source code.... I just don't know if you want to do this.
Thanks for the information regarding the NGFS author. I will try to ask him somehow about the possibility of testing NGFS. However, there may be a problem with this I came across a thread in the hyperion forum about NGFS The older version was only temporary for the X5000 as an alternative to SFS. The second version as an update is available for X5000 and possibly A1222 owners. It will not work on other machines. NGFS is supposed to be available for other machines as AmigaOS 4.2.
If NGFS is again assigned to specific processors and machines in a few years, the problem will return like with SFS when a new machine or emulator is created. Unless AmigaOS 4.2 is released or the restrictions are removed.
If I have misunderstood something or I am wrong about something please correct me
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.
DiskCacheOn breakhack:
DiskCacheOff breakhack:
When I run breakhack from the RamDisk everything is fine with DiskCache disabled. I just wanted to let you know since you recommended me to disable DiskCache in another thread.
Would it not be possible to remove this from SFS and make versions available as part of an ES update?
Not as long as Hyperion is involved in AmigaOS 4.x development and/or distribution. They are still trying to sell pirate copies of my software (AmiDVD, CDFileSystem, diskboot, diskcache, JXFS, PartitionWizard, SFS, etc.), as well as pirate copies of software owned by several of the other AmigaOS 4.x developers, as part of "AmigaOS" 4.1 releases, for which they either never had any licence at all (AmiDVD, diskboot, diskcache, SFS, ...) or which were revoked at least after AmigaOS 4.1 update 4 (not 4.1 FinalEdition and updates of it). Some AmigaOS 4.x developers revoked their licences even 5-10 years earlier already. For example on https://www.hyperion-entertainment.com ... e-to-buy/direct-downloads they are still selling pirate copies of "AmigaOS 4.1 Final Edition for Classic". Of course that's not really for classic Amigas, but for WinUAE emulation instead. This "AmigaOS" 4.1 distribution includes pirate copies of at least 10 AmigaOS 4.x developers. Hyperion's AmigaOS 4.x licence from Amiga Inc./Colanto, as well as all of the licences of the software created by the AmigaOS 4.x developers, were always limited to "AmigaOne" branded hardware and classic Amigas (A1200/A4000 with Blizzard/CyberStormPPC), and limited to AmigaOS 4.x (no AmigaOS 5.x/DE nor AmigaOS 3.x ports allowed) and PowerPC CPUs (no m68k, x86/64, HP-PA, MIPS, ARM, Java JIT/Elate, or whatever other (virtual) CPU, allowed) . Even all Sam440/460 (except for the "AmigaOne 500" branded complete systems), Pegasos 2, etc., versions of AmigaOS 4.1, as well as the ports to AmigaOS 3.[12].x/m68k, which are partially even based on sources stolen from AmigaOS 4.x developers, are illegal.
Thank you for your information. I may not agree with it, but you are the creator of SFS and owner of the rights to it, and I accept what you wrote and your decision. I am grateful that you wrote it directly. There is also a version of SFS which you have made available on aminet/os4depot which can be used.
I also hope that all the things you described will eventually end in a happy ending for everyone.
@smarkusg It still doesn't explain the problems with SFS on the Sam460 QEmu emulation, the old SFS versions on Aminet/OS4depot should work on any system, there was no need to add copy protection in 2007 yet (SFS version 1.277), and the current Enhancer Software versions of SFS should work on any system as well.
Unless both versions wouldn't work on real Sam460 system either, but I never got such bug reports, something has to be wrong in the Sam460 emulation of QEmu.
Only the special versions of SFS, and several other of my AmigaOS 4.x software, Hyperion is illegally distributing in AmigaOS 4.1 FE and newer intentionally don't work any more. Since I was 100% sure they don't care about licences and continue to use my AmigaOS 4.x software even after explicit prohibition to continue using them for AmigaOS 4.x distributions newer than 4.1 Update 7, released in 2012 or 2013, they got those unusable versions
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
