logoalt Hacker News

EvanAndersonlast Wednesday at 8:18 PM3 repliesview on HN

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...


Replies

amiga386last Wednesday at 11:10 PM

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?

show 2 replies
pjmlplast Thursday at 8:42 AM

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.

Sophiralast Thursday at 5:44 AM

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?