Welcome, Guest. Please login or register.

Author Topic: AmigaOS filesystem layout  (Read 4806 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline Matt_H

Re: AmigaOS filesystem layout
« on: March 24, 2015, 11:14:53 PM »
For reference, here is the Tripos manual. I paged through it a number of years ago. It's a fascinating read, especially for me, since I think the Amiga's logical, human-readable file hierarchy is one of its greatest assets - but it comes almost verbatim from an older system!
 

Offline Matt_H

Re: AmigaOS filesystem layout
« Reply #1 on: March 25, 2015, 09:19:26 PM »
Check out page 1-14 of the Tripos manual:
Quote
When the system is first booted, Tripos initially assigns C: to the :C directory. This means that if you boot with a disk that you had formatted by issuing the command:

FORMAT DRIVE DF0: NAME "My.Boot.Disk"

SYS: is assigned to 'My.Boot.Disk'. The 'logical device' C: is assigned to the C directory on the same disk (that is, My.Boot.Disk:c). Likewise, the following assignments are made

C: My.Boot.Disk:c
L: My.Boot.Disk:l
S: My.Boot.Disk:s
DEVS: My.Boot.Disk:devs

If a directory is not present, the corresponding logical device is assigned to the root directory.

My emphasis. The same holds for AmigaOS (page 15 of the AmigaDOS manual). I think I've seen a few CD32 games that throw everything (startup-sequence and all) into the root directory.

Both manuals go on to explain how to reassign the system to a hard drive, since bootable Amiga hard drives hadn't yet been invented at the time these were written. I imagine the precise order in which one reassigns the system shouldn't matter as long as it's the very first thing done.
 

Offline Matt_H

Re: AmigaOS filesystem layout
« Reply #2 on: March 26, 2015, 12:54:07 AM »
Quote from: matthey;786725
Assign would have been more powerful if relative assignments could be reassigned when a parent assignment changes. If relative assigned were allowed, then all of these assigns:

Code: [Select]
Assign SYS: HD:
Assign C: SYS:C
Assign S: SYS:S
Assign L: SYS:L
Assign LIBS: SYS:Libs
Assign DEVS: SYS:Devs
Assign FONTS: SYS:Fonts
Assign LOCALE: SYS:Locale
Assign HELP: LOCALE:Help
Assign KEYMAPS: DEVS:Keymaps
Assign PRINTERS: DEVS:Printers
Assing ENVARC: SYS:Prefs/Env-Archive
Assign REXX: SYS:Rexx

could be reassigned to CD0: with:

Code: [Select]
Assign SYS: CD0: PATH

Even more powerful would be:

Code: [Select]
Assign SYS: CD0: PATH ADD

Note that this is not how assign currently works. Also, assign with PATH and ADD options won't work.
Agreed, that would be convenient. For the sake of argument, though, I'm wondering if there is a reason for why it's designed as it currently is, i.e., are there conditions under which one might want to reassign SYS: but keep C:, Libs:, Devs: etc. in their original places. Maybe it was just too complicated to implement at the time, since it would require the Assign command to recognize SYS: as a special entity.

Quote
I recall that the TripOS manual mentions a hard drive and using memory to copy C: commands to. I was surprised considering hard drives would have been rare and expensive and memory of most 68000 computers was probably 64k-128k at that time and also very expensive.
The manual even says "If you are so lucky as to have a hard disk..." :)
But the memory thing surprised me too. I wonder what kind of machines Tripos was meant to run on? Did high-end 68000 workstations exist at universities or similar institutions? What other 68000 machines of that era could Tripos have targeted?