Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: Piru on April 21, 2011, 10:56:33 AM
-
I've been working on PFS3 by using a cross compiler on AMD64 linux box. This has prevented me from testing much of the changes so far, but I will do that shortly when I'll have access to my MorphOS box again.
So far I've:
- replaced all assembler parts with C code
- fixed several small bugs in the original code
- ported the code to compile with GCC, while making sure the original SAS/C build works ok as well
- ported the filesystem and the tools to MorphOS
- removed all static data from the filesystem making it possible to include it in the MorphOS boot.img
To do:
- add support for new MorphOS dospackets
- add a resethandler to commit any pending changes to disk before reboot
- testing all the new code and port, fixing any issues
- fixing the remaining serious bugs (MakeAnodeBitmap superindex array out of bounds access, beta warning #1, softlink support, PFSDoctor zeropage hits)
- possibly create a MUI GUI for PFSDoctor
Some links that might be of interest:
- SVN tree (http://pfs-amiga.svn.sourceforge.net/viewvc/pfs-amiga/)
- Bug tracker (http://sourceforge.net/tracker/?group_id=532591&atid=2163215)
- Feature requests (http://sourceforge.net/tracker/?group_id=532591&atid=2163218)
-
you've got to be kidding? the Perfect File System 3 code? you ported it?
i tried many many times to contact the author to get this released to public over many many years!!
i thought it was closed source, i.e. proprietary, paid for software.
i always used this file system, was so much faster and more reliable than ffs, tests i have done show it to be faster than sfs too.
Err, i'd love to see this file system back in development if you did manage to contact the author and get the code!
All i can say is wow. well done!
-
you've got to be kidding? the Perfect File System 3 code? you ported it?
i thought it was closed source, i.e. proprietary, paid for software.
It became open source recently: See http://www.amiga.org/forums/showthread.php?t=52358
i always used this file system, was so much faster and more reliable than ffs, tests i have done show it to be faster than sfs too.
Indeed. It's far the best filesystem on amigoid systems. It has some small tiny issues I intend to fix though.
Err, i'd love to see this file system back in development if you did manage to contact the author and get the code!
All i can say is wow. well done!
Getting the code wasn't my doing (see the other thread for details) but now that the source code is available I intend to help as much as I can.
-
Awesome news there Piru!!! I was expecting your contribution but wasn't expecting it so soon :)
Btw the SourceForge milestones are really great! I can't wait for the future releases \o/
Are you gonna include binaries for both 3.x and MorphOS platforms in the future releases? (I hope so).
-
Are you gonna include binaries for both 3.x and MorphOS platforms in the future releases? (I hope so).
This hasn't been decided yet and needs some careful planning. A filesystem is such a critical component that some serious testing should be done before a new version is released. No such testing/release planning has been done yet.
My plan is to include the PFS3 is some future MorphOS release at least. The filesystem will be inside the boot.img, making it possible to use PFS3 easily with the supported Mac systems, too. Without being inside the boot.img you would be limited to systems with RDB support or to mounting via mountlists.
Also the current 68k version functions just fine with MorphOS already, and since the filesystem is translated by the Trance JIT is likely to be exactly as fast as the native version will be.
For now I've omitted committing the MorphOS Makefiles in the SVN. This is because I have been unable to test much my new code. I wouldn't want anyone to hose their data with a buggy filesystem. Once I've tested and bugfixed the code I'll add the Makefiles. At that stage anyone with the SDK installed can build the filesystem and play with it. Obviously even then I'd seriosly recommend only doing that with some spare partitions and avoid using the SVN version in production environments.
-
Great work Piru, thanks! :)
What gcc arguments do you recommend to compile it with for fastest performance on a CS 060?
Just a simple -m68060 will suffice?
-
What gcc arguments do you recommend to compile it with for fastest performance on a CS 060?
Just a simple -m68060 will suffice?
Last I played with 68k target gcc it was back in the 2.95 time. Back then gcc produced far worse code for 68k than SAS/C. I don't know if things has changed since, but in general -O2 with the flag specifying the CPU target (in this case -m68060) is usually the best choice. -O3 is worth trying as well, but usually it only leads to very minimal speed up with the expense of the binary bloating up. As always try couple of different optimization flag combinations and benchmark your code.
-
@Piru
Thank you for your support to further develop PFS3. I was checking the project SVN and Bugtracker on a daily basis, and I am pleased you are both working on it. I just hope some more developers join in!
-
Last I played with 68k target gcc it was back in the 2.95 time. Back then gcc produced far worse code for 68k than SAS/C. I don't know if things has changed since, but in general -O2 with the flag specifying the CPU target (in this case -m68060) is usually the best choice.
I think the geekgadgets build I used was 2.95 and I found that building for 68000 with gcc was quicker than any sas/c build & any other gcc build. At the time gcc probably didn't know to avoid 020 stuff that was removed in later processors.
-
Anyone experience with vbcc? Got a mail from Stefan Haubenthal who wants to make PFS compatible with it. The site http://sun.hasenbraten.de/vbcc/ claims pretty good performance.
Michiel
-
Last I played with 68k target gcc it was back in the 2.95 time. Back then gcc produced far worse code for 68k than SAS/C. I don't know if things has changed since, but in general -O2 with the flag specifying the CPU target (in this case -m68060) is usually the best choice.
I don't think it ever got a lot better in later versions. Last time I checked, it wouldn't even output scaled indexed addressing modes on 020+.
-
Anyone experience with vbcc? Got a mail from Stefan Haubenthal who wants to make PFS compatible with it.
I think my GCC fixes should go a long way fixing it for VBCC as well. I also made sure that the alignment patches (#pragma pack(2)) work with VBCC, too. No doubt there will be some things to fix with VBCC still.
I haven't used VBCC myself though.
-
I hope the free PFS will be available for 68000 stock AmigaOS too.
-
Thanks Piru,
Your support of MOS is a tremendous asset. I love PFS for the Amiga and look forward to it being used in MOS.
Regards,
Matt
-
:hammer: Good stuff - thx!!
-
I've been working on PFS3 ...
Some links that might be of interest:
- SVN tree (http://pfs-amiga.svn.sourceforge.net/viewvc/pfs-amiga/)
Thanks, nice work!
I know it's geeky, but I just spent my lunch break browsing the code starting from the given link. I see there are old RCS tags in many files, such as 'boot.c'. Since it is under SVN(?) now, I assume those are obsolete, but I always found it helpful to include text descriptions of changes. Vewing the source using 'annotate' lets you view the changes, but is there a way to have that included in the file when downloaded?
-
I hope the free PFS will be available for 68000 stock AmigaOS too.
As a Minimig owner with the arm addon board for HD support I too would also like to see continued support for a basic 68000 CPU.
I would also like to see a support for using less buffers like FFS so it can be used on a 1.5MB Amiga such as a unexpanded minimig or my old A500 HD system which also has less than 2MB of RAM. I know it will be slower with less buffers but it should still hopefully be faster than FFS.
-
Thanks, nice work!
I know it's geeky, but I just spent my lunch break browsing the code starting from the given link. I see there are old RCS tags in many files, such as 'boot.c'. Since it is under SVN(?) now, I assume those are obsolete, but I always found it helpful to include text descriptions of changes. Vewing the source using 'annotate' lets you view the changes, but is there a way to have that included in the file when downloaded?
When putting it on the sourceforge SVN I decided not to bother with even trying to convert the old RCS repository, but yes, I still do have it.
Michiel
-
Well I have it up and running on my A4000 and it works like a dream. I partitioned a 80GB drive as 2x40GB, copied the data off my old SFS drives and when I've finished backing up the data then I'll reformat the other drives as PFS.
Thanks very much. :)
Note: I had been getting some issues with my large partition SFS drives with regards to checksum errors. I wasn't sure if it was the drives, SFS or my FastATA4000 combined with the Mediator, but so far everything is perfect.
-
@Michiel & @Piru
A friend of Michiel Pelt (PFS3 author) said to me few weeks ago that he found a bug :
'By the way... pfs3 progress is slow, we found a bug in it at the 4gb disksize threshold. We are working on it'
It's fixed ?
-
@Michiel & @Piru
A friend of Michiel Pelt (PFS3 author) said to me few weeks ago that he found a bug :
'By the way... pfs3 progress is slow, we found a bug in it at the 4gb disksize threshold. We are working on it'
It's fixed ?
Well, depends on if he talks about these bugs:
https://sourceforge.net/tracker/?func=detail&aid=3290333&group_id=532591&atid=2163215
https://sourceforge.net/tracker/?func=detail&aid=3291407&group_id=532591&atid=2163215
I don't know of any "4gb disksize threshold" bug, but these are the closest. They're related to large filesystem (needing superindex blocks) and not 4GB disksize limit, though.
-
just wondering if there has been any progress made with partition sizes, AROS intergration etc. There is very little to be found on sourceforge
-
Just went through the sourceforge pages and the last progress seems to be from 1.3.2012(?). Is there chances for fixed PFS3 to see daylight on 68k?
-
@Bamiga2002 Have you tried the updated 68K version on aminet? http://aminet.net/package/disk/misc/pfs3ks13
-
No haven't tried it yet...but isn't it for kick 1.3 so would it work on kick 3.x anyway? Now I have the 18.5 version 060-optimized.
-
No haven't tried it yet...but isn't it for kick 1.3 so would it work on kick 3.x anyway? Now I have the 18.5 version 060-optimized.
It works on my my kickstart2 A600, so no reason why it wouldn't work on 3.0/3.1.
-
Just went through the sourceforge pages and the last progress seems to be from 1.3.2012(?). Is there chances for fixed PFS3 to see daylight on 68k?
I have build pfs3 from the latest svn. Needed some time for testing. I've just put some stuff in a package. Maybe I'll update it later in the week. Shame the progress class includes are nowhere to be found, so pfsdoctor can't be built.
:afro:
-
It works on my my kickstart2 A600, so no reason why it wouldn't work on 3.0/3.1.
I put the latest pfs3ks13 to me RDB replacing the original one and it's working so far :). But can I use PFSDoctor with this version?
-
Is there a donate section for thos roject at all, I tried the links however, I could not get them to work :(
I really hope this hasn't stalled
-
Not stalled at all.
Today Toni Willen, shared a new version of PFS3-AIO (All in one) that is also romable :)
http://eab.abime.net/showthread.php?t=66561
-
So any news on larger disk partitions? Perhaps people are too busy working on it for a change log :-p
I'll just be happy it's still being developed although I'd be happy to donate for it.
-
Only issue I've been having lately is that I have to warm boot for the PFS3 drives to be useable.
When I first turn the 1200 on from cold it says they're not initialized, warm boot they're fine.