Quote:

Wow, good thing I'm not running OS4, or for that matter an HD 6870.
I'll probably initially use either an HD 8490 or an HD 6750.

"2D Driver with compositing" I guess they really don't have better Northern Islands support than that.

So we'll have 3D from the R200 up to Terascale 3, and then hopefully we'll see similar support for GCN cards.

While they have a huge gap in their 3D support.

Curious.

Both OSes have/will have gaps at various points.
The MorphOS gap is currently in newer cards and the AmigaOS 4.1 gap in older cards .
A-Eon had two different developers working on initial 3D support .
Support for cards in the Radeon HD5000-6000 series has not borne fruit.
Support for the Radeon HD 7000 series and beyond is producing a fine crop.
It has taken 5 years to reach this stage from the start of the attempt for the Radeon HD5000-6000 Series 3D up to Warp 3DNova for radeon SI cards .
Two different 3D product have been produced. Warp3D SI and Warp3D Nova(SI).
There is also a wrapper for Warp3D via the more advanced Warp3D Nova in the works by another developer.
This will atomically be able to take advantage of the full graphics memory of the video card introduced in the version of the RadeonHD 3.x driver and should also result in much better performance for Warp3D software including existing binaries.

There will be more fun when we have an overlap in 2D and 3D support for the same cards by the the two Oses .


Quote:



[ Edited by Spectre660 27.10.2017 - 20:58 ]

Quote:

Thanks for the clarification. I missed the fact that the older drivers did not get 3D support.
But I have been paying attention to Han de Ruiter's work, on both the GCN video card drivers and Warp 3D Nova.
The OS4 community is very lucky to have Hans.
There are more gaps than the one you mentioned.
MorphOS has not updated its OpenGL support in some time, and does not support more than one Radeon video card.
2D and 3D comparisons between the two OS?
Considering the differences between MorphOS and OS4, that could be complicated.

Particularly since it seems you are aquiring an edge.


[ Edited by Jim 28.10.2017 - 08:10 ]

> There will be more fun when we have an overlap in 2D and 3D support
> for the same cards by the the two Oses .

Absolutely.

Quote:

I’m not really certain if I understand your point, but a word of caution here: The OS4 forked SFS may use the same name as SFS, but just like ”MUI” their version is not fully compatible. Do not use their FrankenSFS handler on your MorphOS partitions.

The SFS file systems are not included with AmigaOS 4.1FE for X5000 .
FFS and the new NGFS are.

The SFS filesystems are now part of the A-Eon Enhancer software package so now a separate third party
installation .


Quote:



[ Edited by Spectre660 29.10.2017 - 21:01 ]

Quote:

I doubt their would be an issue if the drive was set up a partitioned by MorphOS.
Even if the partition used by OS4 was altered.

In any case, I'll be using separate drives on any dual install, so its not really important for me, outside of being able to create partitions both OS' can read.

Quote:

The important thing is that you *don’t access* your real SFS MorphOS partitions from OS4 with FrankenSFS handler, and vice versa. To be sure you never mix up, don’t even mount your OS4/FrankenSFS partitions in MorphOS, and don’t mount your MorphOS SFS partitions using FrankenSFS-handler in OS4. Keep’em invisible to each other, and keep’em separated! In other words: do *NOT* try to use SFS and FrankenSFS “to create partitions both OS' can read”.

Quote:

Quote:

Wow, that's a pretty moronic post, even by your standards.

By all means, please go right ahead and fuck your file system up all you want, and see if I care.

Quote:

Could not care less what you think is moronic. And, since I always have backups, its no big deal.
Further, I intend to work across multiple OS', so I'll figure something out.

As this will be a exchange volume, trashing it wouldn't be all that big a deal.
Not that you would know, since you seem to think this would 'fuck up my file system'.
Then again, I'm the moron, right (even though I've successfully done this with a countless number of other applications)?

Dare say, I think you're just pissy because it involves an 'alien' OS.
Specifically OS4.

If that sets you off...good.

> I've successfully done this with a countless number of other applications

Could you be more specific regarding "this", and whether "this" involved different implementations or forks of SFS?

Quote:

Not all all, but SFS exists in multiple OS'. Actually, I've had a bigger challenge with other operating systems where finding a common filing system was much more difficult.
What grandma seems to think is a monumental task, shouldn't be that challenging, since both MorphOS and OS4 should support SFS as it exists in OS3.X.

Then again, I'm a moron, so hey, wtf, huh?

Again, just the pot calling the kettle black, because the pot is prejudiced.
No big deal, I face challenges from REAL intellects everyday.
Frankly, YOU'RE a lot more stimulating Andreas.

The reason TMHG used the unflattering descriptor "FrankenSFS" was because we have no real idea how Joerg Strohmayer diverged from the original - he wasn't exactly vocal or helpful about it. SFS2 was certainly NOT compatible with SFS.

Mix SFS implementations at your own risk. If you really want to cross-mount them, do so with a mountlist and specify them as read-only.

Quote:

Hey, no that is a good (and not at all hostile) idea.

And don't worry, I don't really concern myself about what people say whether its flattering or otherwise.
What is comes down to is what I want to get from something, if someone else thinks its too challenging, no big deal.
And a completely divergent SFS (SFS2) is kind of pointless, isn't it? Why not just give it a new name?

Anyway, again, no real problems here as I won't even be using my primary volume/drive.

If it crashes or becomes unreadable, BFD.

> both MorphOS and OS4 should support SFS as it exists in OS3.X.

According to MorphOS team members, there seem to be potential compatibility problems between implementations/forks:

http://morph.zone/modules/newbb_plus/viewtopic.php?topic_id=5694&forum=9&start=7
http://morph.zone/modules/newbb_plus/viewtopic.php?topic_id=7796&forum=9&start=8

@Jim

Acill above wasn’t the first by far, it happens from time to time that people who don’t really know the history gets confused about OS4 SFS. Also, people come to these forums to search for info, to learn. Search engines points here. Integrity of file systems are *extremely* important to anyone caring for their data, which most people do! And here you are, actually telling people it’s OK to jump over a cliff because *you* have a parachute or *you* don’t care about safety, fighting the warnings repeatedly with ridiculous “racial” arguments?! That *is* a moronic behavior! Risc your own data all the way you want, but please stop fighting the warnings to clueless people who actually do care!

Quote:

'Racial'? More like rabid. And as I've already stated, based on mounting a secondary volume and using it as an exchange medium I don't anticipate loss of anything that can't be restored.
While I appreciated your advice, I think you underestimate both myself and Acill.
Neither of us would be likely to experiment blindly with important data.
And an exchange filesystem needs to be explored for multi-boot systems using MorphOS, OS4 and Linux.
If not SFS, something else will have to serve.
I can already save to media that is readable by all OS, and taking this one step further is not an insurmountable issue.
In the meanwhile, your tone is more than a bit insulting and condescending.

I think I've managed to learn to approach tasks like this methodically, since I've been using computers for over forty years now.

@ Andreas, thanks for the initial pointers. It doesn't look completely gloomy. But experimenting with these options will need to be done with caution.
I'd hate to have to resort to an 'alien' filesystem like the one poster suggested.

[ Edited by Jim 01.11.2017 - 06:57 ]

At the risk of being, yet again, berated, what issues would interfere with using FFS?

And are there any inherent issues with sharing an SFS partition with both MorphOS and Linux?

> what issues would interfere with using FFS?

According to http://library.morph.zone/Filesystems, Fast File System 2 (FFS) seems not so bad. It should be the same implementation by Olaf 'olsen' Barthel as used in OS4, up to and including DOS\6 and DOS\7 modes (long filenames). Unfortunately, the Linux FFS implementation lacks DOS\6 and DOS\7 modes, so if Linux should be able to access the partition, file name length is restricted to 31 characters.

> are there any inherent issues with sharing an SFS partition with both MorphOS and Linux?

The most inherent issue is probably that Linux doesn't know SFS by default. There is a kernel module available, but I don't know if it can be made to work with current kernel versions.

Quote:

Thanks, that's about the most useful post made so far in this matter.
Now I have something to work with.
Linux isn't essential.

Quote:

I think the asfs module is no longer maintained, and the affs one certainly doesn't support the DOS/06 and DOS/07 dostypes. When I tried they were simply not accessible, don't know if that has changed.

Apart from that, lack of disk tools such as recovery and defrag are quite a knotty problem. Disksalv won't work with the newer FFS dostypes either, and was never 64-bit aware. Linux of course can't fix problems in FFS and SFS.

@KennyR:

So, basically, count Linux out on those two filesystems.
Well, there's always FAT.

And to summarize, FFS is probably a better choice than SFS for cross compatibility between OS4 and MorphOS.

Quote:

FFS DOSType 03 is indeed the best you can go for in terms of compatibility. Classic can read it, Linux can read it, MOS and OS4 can read it. Even WB1.3 can read it, assuming you have FFS v34 around and a mountlist. There are no different implementations, it's all the same, with FFS2 actually having some bugs fixed. Its performance is pretty poor compared to SFS (despite what I've heard from people who should know better - seriously, go get Diskspeed and bench it against PFS/SFS yourself).

Here's my results from many years back:
https://www.dropbox.com/s/q7et37y8u6oxq3y/DiskSpeed.Results.pdf

What totally put me off using FFS or FFS2 was the validation time. If you happened to crash while writing, validation would take AAAGES. I remember it took hours on an old Amiga drive, but with a modern drive and 10,000s of files, it can very literally take days - and think what it's doing to your drive. If it fails to validate, which is relatively rare but not unknown, you won't be able to use Disksalv as it's 32-bit; you can still get the files out but it'll still take forever to copy them with the partition in an unvalidated state.

So while FFS is definitely your go-to for compatibility, if I were you I'd put anything likely to write a lot on an SFS partition to save you that validation headache. Biggest offender is browser cache. As for the performance loss, as long as you don't stick hundreds of files in one directory, chances are you won't even notice.

[ Edited by KennyR 03.11.2017 - 10:06 ]

Addendum:

> Fast File System 2 (FFS) [...] should be the same implementation by Olaf 'olsen' Barthel
> as used in OS4, up to and including DOS\6 and DOS\7 modes (long filenames).

I just read something interesting which was new to me:

"A few years ago I had a go at disassembling FastFileSystem 45.13, the final version released by Amiga Inc. in OS 3.9 Boing Bag 2. [...] One interesting feature I found is code for DosType DOS\8, which seems to be intended to support longer filenames; up to 54 characters vs 30 for normal FFS."
http://eab.abime.net/showpost.php?p=858582

"Enabled and fixed hidden partially implemented long file name support. If partition dos type is DOS\8, max file/directory name length gets increased to 54 characters (from 30) by using previously unused bytes of file/dir header block."
http://eab.abime.net/showpost.php?p=1188826

"DOS\8 is identical to DOS\3 (international FFS) when there are no files with long names. So you can in-place convert an existing DOS\3 partition to DOS\8 just by changing the DosType in the first longword (and edit your mount file to reflect the new DosType). Similarly, you could convert back to DOS\3, providing you're certain that there are no files or directories with long names in the partition. Programs like DiskSalv and ReOrg won't of course work with DOS\8 partitions."
http://eab.abime.net/showpost.php?p=1188965

"DOS/8 was "sort of present" already in the Os 3.9 version, but there not fully functional. It has 54 character long file names (so more than the usual 30), but is backwards compatible in the sense that the block layout is just like the one in DOS/1, except that unused fields are populated with the extra characters, so old tools will at worst damage the file name, but nothing else. Probably we'll keep DOS/8 inofficial, as it used to be."
http://amiga.org/forums/showpost.php?p=833207

"About the only thing that was present of DOS/8 in the 3.9 release is ExAll() and friends, and the computation of the maximum file size. Everything else on file names in DOS/8 was there borken... Open, Rename, Lock, .... you name it. I cleaned this up for V46, so it now works quite fine on my HD since probably a year or so. [...] DOS/8 is most likely not going to become official [...] because we have another alternative that is more flexible."
http://amiga.org/forums/showpost.php?p=833258

"there is one "hidden" feature we do not support officially, and this is DOS\08. Nobody remembers how, but Os 3.9 already supported it, albeit incompletely. It is an FFS variant that supports long file names limited to 54 characters, but that is backwards compatible to the older flavours of the FFS such that you can easily upgrade from DOS\03 to DOS\08, gain additional length, but do not need to reformat. Unlike the Os 3.9 variant, this version works, however. We still do not support it officially as diskdoctor [...] does not support it, but it is otherwise in fine working condition."
https://forum.amiga.org/index.php?topic=73694.msg840687#msg840687


Edit: added one more

[ Edited by Andreas_Wolf 13.10.2018 - 14:40 ]