Very tangential, but Amiga has been a recent fascination of mine. I've been playing with a few AROS distributions in QEMU; a part of me wants to take the plunge and run it full time as my primary operating system, but the lack of a decent web browser is a pretty hard limiter in 2026. I guess my brain has sort of fetishized the platform; I didn't grow up with an Amiga, but I did get to play with one when I was a kid and I always thought it seemed cool, and as a grown-up who roughly understands how operating systems work I do think it was somewhat ahead of its time. Yes, I realize that there was a lot wrong with the design as well (e.g. no protected memory and programs being able to modify each others pointers), but even still I think it was pretty neat.
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.
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 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.
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.
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...)
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.
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?
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!
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.
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.
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.
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?
> 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.
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.
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.
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 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 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.
Very tangential, but Amiga has been a recent fascination of mine. I've been playing with a few AROS distributions in QEMU; a part of me wants to take the plunge and run it full time as my primary operating system, but the lack of a decent web browser is a pretty hard limiter in 2026. I guess my brain has sort of fetishized the platform; I didn't grow up with an Amiga, but I did get to play with one when I was a kid and I always thought it seemed cool, and as a grown-up who roughly understands how operating systems work I do think it was somewhat ahead of its time. Yes, I realize that there was a lot wrong with the design as well (e.g. no protected memory and programs being able to modify each others pointers), but even still I think it was pretty neat.
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.
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 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.
I have always seen BeOS as a spiritual successor to the Amiga.
2 replies →
BeOS fans still exist!
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.
1 reply →
AI reply
ai comment
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...
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?
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!
1 reply →
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/
1 reply →
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.
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?
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.
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.
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
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?)
I've lost data multiple times with Paragon.
2 replies →
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.
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.
> 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.
exFAT or UDF?
If only exfat had symbolic links.
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.
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.
1 reply →
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.
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?
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.
What’s the common take on SFS vs PFS? SFS came along after I sold my Amiga and I wondered which one I want to use with UAE.
1 reply →
Thanks! This was very informative.