Native Amiga Filesystems on macOS / Linux / Windows with FUSE(github.com)
github.com
Native Amiga Filesystems on macOS / Linux / Windows with FUSE
https://github.com/reinauer/amifuse
51 comments
Replace Amiga with BeOS and you're describing me.
BeOS is pretty neat, Haiku too, and I wish them the best, but never quite had the same appeal to me, primarily because I hadn’t really heard of it until I was in my 20’s. As such I never got to mythologize it in my brain like Amiga.
I do hope Haiku does catch on though; I heard they have a decent browser now, so there’s a shot.
I do hope Haiku does catch on though; I heard they have a decent browser now, so there’s a shot.
I was a big BeOS user and have my R4 and 5 CD's somewhere. It was impressive to open a bunch of videos or the video cube thing as a demo and watch pulse peg to full CPU while the system and UI remained snappy. Another cool thing was the universal codec where you drop a PNG codec into the codec directory and now all your image programs can open PNGs. I really enjoyed it but the magic died when Palm bought it and I never looked back.
BeOS fans still exist!
AROS runs well hosted on Linux. Couple it with a tiling wm, and a couple of keybindings and you can pretty much just pretend the browser is on another Amiga-ish screen...
(I'm slowly making my Linux setup more Amiga-ish...)
(I'm slowly making my Linux setup more Amiga-ish...)
In a world obsessed with AI and distributed everything, simple problems like "mount this USB drive on every OS without headaches" still feel unsolved. That’s both humbling and oddly comforting.
It's solved, though. The only reason it feels unsolved is because Apple won't document APFS to save their life.
macOS Sequoia refused to mount a FAT32-formatted microSD card from a security camera because the partitioning wasn't compliant or something.
I installed Windows 11 in a VM, and it mounted just fine in there.
I installed Windows 11 in a VM, and it mounted just fine in there.
Precisely to my point. On OSes that don't arbitrarily filter which filesystem you can use, it is a solved problem.
It only feels like an unsolved problem because some OEMs benefit from the fragmentation.
It only feels like an unsolved problem because some OEMs benefit from the fragmentation.
Pretty cool. This isn't what I first thought of as native Amiga filesystem support - this is support for the native Amiga filesystem drivers, through m68k emulation.
In case you don't follow the link: The novel thing here is they're running the actual Amiga filesystem code in a 68K emulator, rather than relying on their own implementation.
Because AmigaDOS filesystem handlers are pluggable it's possible others could work, too. I wonder if you could get CrossDOS[0] working and use this to access FAT filesystems for Inception-like fun.
Edit: Oh, shit! I haven't used AmigaDOS in years, but I'm seeing NTFS-related commands in the AmigsDOS 4.0 documentation[1]. I wonder if this means there's a 68K NTFS filesystem handler this could run! That would be fun.
Edit on Edit: I am continually amazed by the forethought that went into the Amiga. I first ran into them around '92, after having grown up on Apple II, Commodore 64, and finally PCs. Pluggable file systems, data type handlers, AREXX, and the general extensibility of the ecosystem absolutely blew my mind. Plus there was still juxtaposition of games and demos that booted from disk and ran directly on the metal. It felt like it had a leg in the past and in the future. (I always wished for memory protection on the Amiga, though. It could have been so much more stable, albeit I know that in '85 the cost would have been prohibitive...)
[0] https://en.wikipedia.org/wiki/CrossDOS
[1] https://wiki.amigaos.net/wiki/AmigaOS_Manual:_AmigaDOS_Comma...
Because AmigaDOS filesystem handlers are pluggable it's possible others could work, too. I wonder if you could get CrossDOS[0] working and use this to access FAT filesystems for Inception-like fun.
Edit: Oh, shit! I haven't used AmigaDOS in years, but I'm seeing NTFS-related commands in the AmigsDOS 4.0 documentation[1]. I wonder if this means there's a 68K NTFS filesystem handler this could run! That would be fun.
Edit on Edit: I am continually amazed by the forethought that went into the Amiga. I first ran into them around '92, after having grown up on Apple II, Commodore 64, and finally PCs. Pluggable file systems, data type handlers, AREXX, and the general extensibility of the ecosystem absolutely blew my mind. Plus there was still juxtaposition of games and demos that booted from disk and ran directly on the metal. It felt like it had a leg in the past and in the future. (I always wished for memory protection on the Amiga, though. It could have been so much more stable, albeit I know that in '85 the cost would have been prohibitive...)
[0] https://en.wikipedia.org/wiki/CrossDOS
[1] https://wiki.amigaos.net/wiki/AmigaOS_Manual:_AmigaDOS_Comma...
CrossDOS was a combination of mfm.device (asking the disk hardware to do funky things) as well as CrossDOSFileSystem (FAT12 filesystem handler).
What's interesting is not so much the 68K emulator (though that is interesting for Python), but rather that it's using VAMOS - the most amazing thing about the amitools project.
VAMOS is a full-on pretend version of AmigaOS in Python, that hooks everything up so that e.g. dos.library's Open() actually calls Python's open(), and so on.
https://github.com/cnvogelg/amitools
Here is, for example, its fake implementation of dos.library: https://github.com/cnvogelg/amitools/blob/main/amitools/vamo...
The "libcore" code reads a .fd file (which on the Amiga is a parseable description of the API calls in a library, for generating include files and stubs), then it creates a fake library base in memory with fake jumptable entries... which jump to two instructions, an "ALINE" trap (any two bytes from 0xA000 to 0xAFFF, which trigger the 68000's ALINE trap handler, one is allocated for each library call), then RTS... That's enough to let Python take back control from the emulator when the trap arrives, and emulate the API call.
It does make me wonder how scalable VAMOS if there are no more than 4096 library calls possible.
Anyway, what concerns me about amifuse is that VAMOS has no BCPL internals. pr_GlobVec isn't filled out. AmigaDOS 1.x was written in BCPL (it's an Amiga port of TRIPOS), and AmigaDOS 2.x/3.x went to great pains to pretend BCPL internals were still there, even though they weren't. I'm sure I've seen a number of filesystem handlers that relied on BCPL internals... these just won't work in VAMOS as it stands, and therefore won't work in amifuse.
It's a little bit odd that amifuse only demonstrates working with PFS. Does it work with AFS (AmiFileSafe), SFS (SmartFileSystem)? What about FastFileSystem, CacheCDFS, CrossDOSFileSystem, MultiUserFS and so on?
For that matter, the native filesystem handler in AmigaOS 2.x/3.x was ROM resident. How would one extract it and patch it up to run outside the ROM, so that it could then be use with amifuse?
What's interesting is not so much the 68K emulator (though that is interesting for Python), but rather that it's using VAMOS - the most amazing thing about the amitools project.
VAMOS is a full-on pretend version of AmigaOS in Python, that hooks everything up so that e.g. dos.library's Open() actually calls Python's open(), and so on.
https://github.com/cnvogelg/amitools
Here is, for example, its fake implementation of dos.library: https://github.com/cnvogelg/amitools/blob/main/amitools/vamo...
The "libcore" code reads a .fd file (which on the Amiga is a parseable description of the API calls in a library, for generating include files and stubs), then it creates a fake library base in memory with fake jumptable entries... which jump to two instructions, an "ALINE" trap (any two bytes from 0xA000 to 0xAFFF, which trigger the 68000's ALINE trap handler, one is allocated for each library call), then RTS... That's enough to let Python take back control from the emulator when the trap arrives, and emulate the API call.
It does make me wonder how scalable VAMOS if there are no more than 4096 library calls possible.
Anyway, what concerns me about amifuse is that VAMOS has no BCPL internals. pr_GlobVec isn't filled out. AmigaDOS 1.x was written in BCPL (it's an Amiga port of TRIPOS), and AmigaDOS 2.x/3.x went to great pains to pretend BCPL internals were still there, even though they weren't. I'm sure I've seen a number of filesystem handlers that relied on BCPL internals... these just won't work in VAMOS as it stands, and therefore won't work in amifuse.
It's a little bit odd that amifuse only demonstrates working with PFS. Does it work with AFS (AmiFileSafe), SFS (SmartFileSystem)? What about FastFileSystem, CacheCDFS, CrossDOSFileSystem, MultiUserFS and so on?
For that matter, the native filesystem handler in AmigaOS 2.x/3.x was ROM resident. How would one extract it and patch it up to run outside the ROM, so that it could then be use with amifuse?
For those wondering what AmigaOS looks like, it's beautiful[0].
>CrossDOS was a combination of mfm.device (asking the disk hardware to do funky things) as well as CrossDOSFileSystem (FAT12 filesystem handler).
The "disk hardware" is a pretty dull DAC/ADC. The track format is different in Amiga and IBM PC floppies, but from the perspective of the Amiga hardware it is identical, as it does not deal with that.
The encoding/decoding is always done in software, and mfm.device just implements the IBM PC track format.
0. https://www.datagubbe.se/wbshots/
>CrossDOS was a combination of mfm.device (asking the disk hardware to do funky things) as well as CrossDOSFileSystem (FAT12 filesystem handler).
The "disk hardware" is a pretty dull DAC/ADC. The track format is different in Amiga and IBM PC floppies, but from the perspective of the Amiga hardware it is identical, as it does not deal with that.
The encoding/decoding is always done in software, and mfm.device just implements the IBM PC track format.
0. https://www.datagubbe.se/wbshots/
These days CrossDOSFileSystem also supports fat32, long filenames and even can parse MBR partition tables if you want to mount something else than the first partition. :-)
mfm.device is naturally not needed or used if you aren't using floppy disk. The filesystem handler uses whatever storage driver your mass storage is connected to if the mass storage is not accessed at a low level.
mfm.device is naturally not needed or used if you aren't using floppy disk. The filesystem handler uses whatever storage driver your mass storage is connected to if the mass storage is not accessed at a low level.
I also note that the most recent changes to amitools / VAMOS are from the amifuse guy, e.g. https://github.com/cnvogelg/amitools/commit/7be270c4c844127e...
That's a lot of PRs from him: https://github.com/cnvogelg/amitools/pulls?q=is%3Apr+author%...
There's a lot more AmigaOS API calls and infrastructure that filesystem handlers rely on than just BCPL, e.g. I see here he added a fake input.device to make FFS happy: https://github.com/cnvogelg/amitools/pull/231/files#diff-938...
And to answer my earlier question, how does one get the filesystem handler out of ROM, the answer is amitools's "romtool" based on data taken from the Amiga ROMSplit tool.
So I guess he's working hard on beefing up VAMOS's AmigaOS emulation to get filesystem handlers working. Great stuff!
That's a lot of PRs from him: https://github.com/cnvogelg/amitools/pulls?q=is%3Apr+author%...
There's a lot more AmigaOS API calls and infrastructure that filesystem handlers rely on than just BCPL, e.g. I see here he added a fake input.device to make FFS happy: https://github.com/cnvogelg/amitools/pull/231/files#diff-938...
And to answer my earlier question, how does one get the filesystem handler out of ROM, the answer is amitools's "romtool" based on data taken from the Amiga ROMSplit tool.
So I guess he's working hard on beefing up VAMOS's AmigaOS emulation to get filesystem handlers working. Great stuff!
Most hard disk based Amigas have a more recent version of FFS installed into the RDB that supersedes the ROM based filesystem handler.
The handler file is shipped on the OS install disk and it is automatically added to the RDB by HDToolBox when you initialize a new drive.
The handler file is shipped on the OS install disk and it is automatically added to the RDB by HDToolBox when you initialize a new drive.
AmigaOS made dynamic libraries to great use across many OS extension points, pity not every system is that configurable.
Having to deal with COM/WinRT, XPC, Binder, D-Bus is much more complex.
Having to deal with COM/WinRT, XPC, Binder, D-Bus is much more complex.
There's another cool thing here that's pretty amazing to me if I'm understanding correctly: Rather than being part of the OS, the filesystem handler code is located on the disk itself within the RDB partition.
Honestly, that seems like a surprisingly forward-thinking way to do things; preservation and archival become a lot easier if you can run the code. I've honestly not heard about this approach before, but it makes so much sense.
Can we pretty-please do this for all filesystems?
Honestly, that seems like a surprisingly forward-thinking way to do things; preservation and archival become a lot easier if you can run the code. I've honestly not heard about this approach before, but it makes so much sense.
Can we pretty-please do this for all filesystems?
Meanwhile, also in 2026, we still don't have a filesystem that works on Mac OS, Windows, and Linux.
NTFS is the closest you can get, and it's read-only on Mac OS.
NTFS is the closest you can get, and it's read-only on Mac OS.
We don't have a good filesystem that works without caveats and annoyances on NT+Darwin+Linux. Depending on your pain tolerance, FAT32, exFAT, and ZFS are all reasonable choices.
> NTFS is the closest you can get
Disagree, exFAT has been r/w on all 3 OSes for many years now, and it also supports files >4GB.
We shipped an appliance about 15 years ago and it had a requirement that it must be able to write large video files to USB thumb drives in a format that was read/writable from all 3 OSes, we chose exFAT and never had any complaints.
Disagree, exFAT has been r/w on all 3 OSes for many years now, and it also supports files >4GB.
We shipped an appliance about 15 years ago and it had a requirement that it must be able to write large video files to USB thumb drives in a format that was read/writable from all 3 OSes, we chose exFAT and never had any complaints.
Doesn't FAT32 work on everything? I'm not saying it's a "good" filesystem but I'm pretty sure that works out of the box on Linux and macOS, and I would assume Windows as well?
FAT32 was developed by Microsoft for Windows 95, so yes!
https://en.wikipedia.org/wiki/File_Allocation_Table#FAT32
https://en.wikipedia.org/wiki/File_Allocation_Table#FAT32
ZFS.
NTFS is r/w with Paragon. Same with Ext4FS.
In the end, it is a matter of FUSE.
Either way, I don't think Amiga(OS) was known for its FS.
I do remember there being a r/o driver for Amiga FS back in Linux 2.2 (end of 90s?)
NTFS is r/w with Paragon. Same with Ext4FS.
In the end, it is a matter of FUSE.
Either way, I don't think Amiga(OS) was known for its FS.
I do remember there being a r/o driver for Amiga FS back in Linux 2.2 (end of 90s?)
I've lost data multiple times with Paragon.
And I lost data with XFS.
Doesn't tell us anything. Which product, version.
Paragon's NTFS driver is now (after open sourced) part of the Linux kernel, and this one is rw.
(My data loss with XFS was some 20 years ago with Linux 2.4.x after a power loss. I've also had RAID5 write hole ZFS data loss a couple of years later, on FreeBSD, and that was with a BBU for the hardware raid. Ever since, I learned to disable write cache, until I've seen NVMe with PLP for cache.)
Doesn't tell us anything. Which product, version.
Paragon's NTFS driver is now (after open sourced) part of the Linux kernel, and this one is rw.
(My data loss with XFS was some 20 years ago with Linux 2.4.x after a power loss. I've also had RAID5 write hole ZFS data loss a couple of years later, on FreeBSD, and that was with a BBU for the hardware raid. Ever since, I learned to disable write cache, until I've seen NVMe with PLP for cache.)
Several Mac versions of the commercial Paragon NTFS driver. It's always been flaky on Mac.
Fair. Well, I can't get my license to work, so I swapped to Fuse (which I also use on Windows). Works with sshfs, too. Though since I already use Wireguard, NFS should suffice.
btrfs has a real driver at least https://github.com/maharmstone/btrfs
It's what my steamdeck is formatted to so I could plop the drive into windows and rip steamapps across to shortcut a lot of downloading.
It's what my steamdeck is formatted to so I could plop the drive into windows and rip steamapps across to shortcut a lot of downloading.
exFAT?
> we still don't have a filesystem that works on Mac OS, Windows, and Linux.
One of these things is not like the others.
In fact, that option supports the others as well as it can, despite stiff opposition from the other two.
Choose the "works as well as it can with everyone" option instead of the two options that try to keep their users trapped, at least, if you want to see increased interoperability.
One of these things is not like the others.
In fact, that option supports the others as well as it can, despite stiff opposition from the other two.
Choose the "works as well as it can with everyone" option instead of the two options that try to keep their users trapped, at least, if you want to see increased interoperability.
I could really use a USB "flash drive" that has two connectors on it. You would plug each of the connectors into two different devices. They could both see the same file system. You could implement this in a number of ways. Trying to edit the same file at the same time would not really work well, but otherwise it would work great. And it does not depend on any network and it is cross platform.
You wouldn't be able to edit from any side, because the other side would get its tables confused.
But you could mount readonly and have it work both sides. Or disconnect the side not writing, then reconnected when write has finished.
But you could mount readonly and have it work both sides. Or disconnect the side not writing, then reconnected when write has finished.
You could have three parts to this "black box".
Part A emulates a USB drive to Device A.
Part B emulates a USB drive to Device B.
Part C is the eventually-consistent synchronizer. It can "see" into Part A and Part B.
If file exists on A but not B, copy the file from A to B. If file exists on B but not A, copy the file from B to A.
To each device, the files magically show up.
To resolve conflicts, it would have to do it based on timestamps.
The synchronizer could be anything. Heck, it could even be rsync. This device could be 3 Raspberry Pi's crammed into a single box.
I would happily pay $100 or so for a device that could do this.
Part A emulates a USB drive to Device A.
Part B emulates a USB drive to Device B.
Part C is the eventually-consistent synchronizer. It can "see" into Part A and Part B.
If file exists on A but not B, copy the file from A to B. If file exists on B but not A, copy the file from B to A.
To each device, the files magically show up.
To resolve conflicts, it would have to do it based on timestamps.
The synchronizer could be anything. Heck, it could even be rsync. This device could be 3 Raspberry Pi's crammed into a single box.
I would happily pay $100 or so for a device that could do this.
Yes, it could work. You would have to "disconnect" A and B for files to magically show up, because the drivers on A and B don't expect the filesystem to change "under their feet". It doesn't monitor the disk blocks for changes and rebuild directory indexes, file tables etc.
If you want a truly "automatic" solution, your magic USB device would have to pretend to be a network device to both A and B, perhaps with DHCP or ipv6 autoconfig, and export NFS and/or Samba to both ends.
If you want a truly "automatic" solution, your magic USB device would have to pretend to be a network device to both A and B, perhaps with DHCP or ipv6 autoconfig, and export NFS and/or Samba to both ends.
I don't mean this to be funny. But given that this is running the actual drivers. Would it be possible to take a standard PC floppy drive, and have it read at Amiga OS disc?
The disk drives can do it no problem.
The IBM PC floppy controller, however, normally cannot: While it has a debug raw read operation, it only reads once it finds a triple sync word in the floppy; Amiga track format uses double sync words.
However, if there is another floppy drive, it is possible to start the read on the other drive, with a standard IBM PC formatted floppy in it, and then poke a register to switch to the drive with the Amiga floppy.
The IBM PC floppy controller, however, normally cannot: While it has a debug raw read operation, it only reads once it finds a triple sync word in the floppy; Amiga track format uses double sync words.
However, if there is another floppy drive, it is possible to start the read on the other drive, with a standard IBM PC formatted floppy in it, and then poke a register to switch to the drive with the Amiga floppy.
Thanks!
How does this compare to the Amiga filesystem support built in to the Linux Kernel? https://github.com/torvalds/linux/blob/master/fs/affs/Kconfi...
It looks like it shoehorns proprietary binary blobs into Linux, but what is missing from the built-in drivers?
It looks like it shoehorns proprietary binary blobs into Linux, but what is missing from the built-in drivers?
The biggest problem we have had is, that the most popular filesystem (PFS3 and its variants) and the second popular filesystem (SFS) never made it to the Linux kernel.
Just about everyone uses a flavour of PFS3 in their Amigas these days and it is a bit of a pain that we haven't been able to just mount hard disk images natively. Instead we've had to run a full Amiga emulator to transfer data to and from disk images or hard disks/memory cards, which eats into file transfer performance.
Just about everyone uses a flavour of PFS3 in their Amigas these days and it is a bit of a pain that we haven't been able to just mount hard disk images natively. Instead we've had to run a full Amiga emulator to transfer data to and from disk images or hard disks/memory cards, which eats into file transfer performance.
It's fun to think of the alternate universe where Commodore had been competently managed, and we wouldn't have the codified mediocrity of POSIX driving everything today.
It would be hard for me to justify the time sink, but I would like to port over the most recent Firefox/IceWeasel and bring Amiga into the 21st century.