AmigaOS filesystem layout

[pVC]

I'm not so convinced of that. Yes you can add paths to the assigns, and even remove and reassign them else where, but if the standard dirs aren't there, you might have trouble booting in the first place, to run the script that does that.

The absense of SYS:S and SYS:C in particular may cause a headache.

Some people have made boot disks etc with reassigned system assigns, and I haven't heard any complaints of them. So I'd guess it should work that you first remove S: assign, and then assign it elsewhere. Although I don't remember trying it myself, but nobody (at least programmers) should never use fixed paths in these situations... probably at least most of the stuff would work happily.

Maybe only the startup-sequence has to be where kickstart looks it at first place, but then you can reassign other dirs first thing in it...

[Matt_H]

Check out page 1-14 of the Tripos manual:

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.

[matthey]

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.

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.

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.

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.

[danbeaver]

Not really, Commodore had hard drives for sale with their PET computers used in lab and office settings.

[chris]

Check out page 1-14 of the Tripos manual:
[...]
DEVS: My.Boot.Disk:devs

I wonder why that's DEVS: and not D:. I thought it had been added post-TripOS but obviously not.

[Oldsmobile_Mike]

Not really, Commodore had hard drives for sale with their PET computers used in lab and office settings.

I had no idea such a thing existed.  :lol:

Google:

[Matt_H]

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.

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?

[danbeaver]

A bunch of the Amiga stuff was emulated on (68000) Macs.  Also the "68000 became the dominant CPU for Unix-based workstations including Sun workstations and Apollo/Domain workstations." -- Wikipedia

[matthey]

I wonder why that's DEVS: and not D:. I thought it had been added post-TripOS but obviously not.

I noticed that too. At least AmigaOS fixed the inconsistency by adding a new style "Libs" to go with the "Devs". Maybe they should have put the Classes in LIBS: though as the gadgets and datatypes are libraries. Then again, devices are libraries also, showing the Amiga was object oriented from very early. Building structures on structures like this is very efficient, Passing the structures as pointers in registers to function calls (without entering supervisor mode either) is still the most efficient way today. Tag lists which were introduced later are not as efficient. C is still the most efficient high level language too.

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.

I believe the current AmigaOS way of doing assign is the fastest and most memory efficient. It would be possible to store the original relative assign along with the optimized version which would be used most of the time for little extra memory cost today. More CPU processing would be required when an assign is changed as well. It may be possible to add relative functionality in a compatible way with a new assign command option.

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?

Yea, that's the quote I remembered but I was too lazy to go back and look it up for you.

The 68000 made a poor mans workstation. It lacked supervisor functionality common in workstations and servers but was otherwise similar to the VAX and PDP-11. The 68000 was more orthogonal with more registers than most cheaper <=16 bit processors, had 32 bit registers and wide operations from the beginning and didn't have to worry about memory banks or anything like that. This made it a better target for C compilers (and thus the AmigaOS) than most cheaper processors. The supervisor functionality was improved with the 68020 and then again with the addition of the MMU in the 68030. The 68020-68040 were popular in low end (affordable) workstations and servers. Then the RISC hype came along with Motorola's anti-68k marketing which killed the market even though the 68060 was a better CPU for the price (including how much memory was needed with it) than its replacements.

[kolla]

Which RISC are you talking about now? m88k?

[matthey]

Which RISC are you talking about now? m88k?

No, PPC. Mororola threw away everything they failed to develop organically and decided what was on the other side of the fence was greener. The only organic ISA I recall them creating since adopting PPC is the MCore disaster of minimal ISA and hardware which was crushed by the much better ARM (ColdFire is a cut down 68k and removing isn't creating). Motorola had a loyal 68k customer base but they threw it away when they told everybody that RISC is the future. Now RISC PPC is practically dead after being destroyed by x86_64 CISC which is inferior to the 68k. Motorola is a Chinese company and Freescale will be Dutch. Game over.

[guest11527]

Assign would have been more powerful if relative assignments could be reassigned when a parent assignment changes.

Not quite sure what you mean. We have "symbolic" assignments that evaluate by "name" and not by "lock". That's precisely the "PATH" option.

[danbeaver]

I don't think developing a CPU able to handle Big and Little Endian is "throwing everything away." The rest of your conclusions are "an" opinion.

[guest11527]

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.

Huh? All that is possible. Actually, that is pretty much the default, namely C: is a regular assign to SYS:C, and if SYS: changes, C: does not. C: is an "assign by lock", not "by path".  The only inconsistency I see here is that the command line path is a data structure, not an assign. With the assigns as we have them today (and as Tripos did not), it would be possible to make C: a multi-assign and get rid of another Shell data structure.

[danbeaver]

No, PPC. Mororola threw away everything they failed to develop organically and decided what was on the other side of the fence was greener. The only organic ISA I recall them creating since adopting PPC is the MCore disaster of minimal ISA and hardware which was crushed by the much better ARM (ColdFire is a cut down 68k and removing isn't creating). Motorola had a loyal 68k customer base but they threw it away when they told everybody that RISC is the future. Now RISC PPC is practically dead after being destroyed by x86_64 CISC which is inferior to the 68k. Motorola is a Chinese company and Freescale will be Dutch. Game over.

I don't think developing a CPU able to handle Big and Little Endian is  "throwing everything away." The rest of your conclusions are "an"  opinion.

[kolla]

I'm not sure I'd call amd64 inferior to m68k, maybe in your nonexistant parallell universe where m68k was picked by IBM to power the first IBM PCs and m68k would enjoy the kind of attention that x86 has had. But in our universe, no.