Comment by EvanAnderson | Hacker News Reader

Comment by EvanAnderson | Hacker News Reader

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!

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.

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/

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.

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?

Reply on news.ycombinator.com