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?

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?

Having to deal with COM/WinRT, XPC, Binder, D-Bus is much more complex.

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.

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?)

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.

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.

But you could mount readonly and have it work both sides. Or disconnect the side not writing, then reconnected when write has finished.

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.

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.