AmigaOS filesystem layout

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

[chris]

Maybe they should have put the Classes in LIBS: though as the gadgets and datatypes are libraries.

Well, SYS:Classes is multi-assigned to LIBS: so it is really.

[paul1981]

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.

LoadWB NEWPATH

[psxphill]

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

The manual is from May 1986, which is after Metacomco had ported TripOS for use on the Amiga. I'm pretty sure there was cross pollination.

Their assembler interface to dos in TripOS looks an awful lot like exec libraries too. It wouldn't surprise me if they didn't even have an assembler interface before commodore came along.

Essentially TripOS was a university project started in 1978, with the 68000 port started in 1981. A researcher from the university joined Metacomco in 1984 and brought the unfinished TripOS with him, this was around the time commodore got involved. He might have even based his decision on commodore becoming involved. It sounds a bit like Tim Paterson selling QDOS to Microsoft who had done a deal with IBM to supply the OS, hoping that they would be able to buy QDOS.

There is nothing to show what state TripOS was in at this point, because it was only used in a university lab and didn't get released commercially until after the Amiga was released. Some of the device features discussed before the Amiga was launched were dropped, so it's possible they took the exec concept of devices into TripOS as well. It would make sense to make the two systems as compatible as possible.

[matthey]

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

I did some more tests with the PATH option of assign and you are correct. My AmigaDOS manual describes PATH as being useful for removable data (which it is) but fails to explain adequately what it is doing and what else it can be used for. The PATH option of assign keeps the relative path instead of converting it to an absolute path. If the original assigns for Libs:, Devs:, L: etc. were assigned with the PATH option and the S:Startup-Sequence changed to add PATH to the assigns:

Code: [Select]

Assign PRINTERS: DEVS:Printers PATH
Assign KEYAPS: DEVS:Keymaps PATH
Assign LOCALE: SYS:Locale PATH
Assign LIBS: SYS:Classes PATH ADD
Assign HELP: LOCALE:Help PATH
Assign REXX: SYS:Rexx PATH

then we could do:

Code: [Select]

Assign SYS: CD0:

One minor flaw of the assign PATH option is that it does not work well with ADD. For example:

Code: [Select]

Assign SYS: CD0: ADD

My tests would not locate data in the new PATHs (like "Assign LIBS: SYS:Libs PATH" which should look in CD0:Libs now also). Is this a bug or a limitation?

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.

Bi-endian CPUs are not a good idea, IMO. Instructions which handle endian conversion are a useful part of modern CPU support though. Any choice of CPU endianess is a minor issue and has little to do with anything I talked about. Some of my comments are opinionated. It's clear that Motorola made the wrong decisions but it is not clear what the right choices were. However, if Motorola could have seen the future of processors, they would have kept the 68k and devoted more resources and "positive" marketing to it. That's not to say that PPC was a bad choice at the time but they shouldn't have bet the farm on it. I went to an Amiga show in St. Louis during the '90s where they had a developer conference with several Motorola employes. They told us PPC was the future and hyped up how great it was. The 68k was already talked about as an old dead legacy processor but the 68060 was faster per clock, used 50% less memory and ran cooler than the "more advanced" PPC replacements. The 68060 was still for sale but Motorola was anti-marketing it. Some of my "opinions" are observations as I recall them from the time.

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.

How many processors or byte code ISAs since the x86 are based on an 8 bit variable length encoding? Java has an 8 bit byte code (it's so effiicent that most JAVA compilers don't even use it) and Java processors were created which have largely failed due to inefficiency. How many processors and byte code ISAs are based on a 16 bit variable length encoding like the 68k? ARM CPUs with Thumb 2 so the majority of processors produced. Dalvik byte code as used by Andoid is based on a 16 bit encoding. It is less known but used more than Java byte code. The 68k has a more efficient encoding, more powerful addressing modes, better code density and it's easier to read and program than x86 or x86_64. The 68k has not been developed in decades but this is actually easier (and with less baggage) to do now. The x86/x86_64 has excellent proven and well known CPU designs produced from huge amounts of cash flow while the 68k has not been developed and has no funding. The potential of the 68k is as good if not better though.

Well, SYS:Classes is multi-assigned to LIBS: so it is really.

True, It may be more efficient and user friendly to have shallow directory trees also. The datatypes drivers being in DEVS: might be more suspect of a decision as there are no devices related to datatypes.

[danbeaver]

A new day, a new addition.

[JimDrew]

Motorola did have a great CPU project in the works.  I helped work on it in Phoenix during my EMPLANT/FUSION haydays.  The CPU was basically a Xilinix on steroids.  We could load a CPU core into the chip.  There were 68000 and 80586 cores working, but not optimized.   It had the ability to byte/word/longword swap on the fly.  The project was scrapped, and the IBM partnership went forward making the PPC chips.

[psxphill]

Java processors were created which have largely failed due to inefficiency.

They failed mostly due to lack of demand. Java just wasn't good enough for people to pay for a dedicated CPU.
 
 ARM becoming successful is purely down to their licensing terms and being in the right place at the right time.

[matthey]

Motorola did have a great CPU project in the works.  I helped work on it in Phoenix during my EMPLANT/FUSION haydays.  The CPU was basically a Xilinix on steroids.  We could load a CPU core into the chip.  There were 68000 and 80586 cores working, but not optimized.   It had the ability to byte/word/longword swap on the fly.  The project was scrapped, and the IBM partnership went forward making the PPC chips.

I'm not aware of what a Xilinix CPU is (surely not Xilinx FPGA technology). Do you have a reference or development project name to this Motorola CPU (or Xilinix CPU)? This project sounds like another EPIC (Explicit Parallel Instruction Computer) VLIW failure like the Itanium and Transmeta processors. VLIW is low power and can execute a lot of instructions in parallel when the code is predictable (some media data and DSP processing) but general purpose code is not and compilers can't solve this problem. It's very likely that billions of investment dollars have been wasted trying to make it work time and time again. Even if it's not VLIW, such CPU emulation with reduced hardware would need compiler and/or JIT support which can never be as efficient for general purpose code. Adding SIMD to a versatile integer CPU with efficient branch prediction is what has been successful.

They failed mostly due to lack of demand. Java just wasn't good enough for people to pay for a dedicated CPU.

The Java processors weren't used because they were slow so, yes, they failed because of lack of demand. There are some ARM processors which have hardware support (acceleration) for Java byte code which is much better than a Java byte code only CPU. There are applications for byte code like Java byte code but it will always be less efficient as it needs more processing than ready to run executables. Java byte code is not efficient or particularly well designed.

ARM becoming successful is purely down to their licensing terms and being in the right place at the right time.

The early ARM designs were transistor misers and became known for their power efficiency. ARM ISA designs have been innovative and well liked by developers. Yes, the licensing terms have been friendly also. ARM built a reputation by doing several things right. Does ARM have a big advantage in power efficiency of mid-performance processors compared to Atom (or a 68k could be)? I don't think so as ARM processors need transistor and energy expensive longer pipelines and OoO to compete in performance. There existing customers worried about power efficiency are still going to come back to them though. When performance is more important than power efficiency, they go to Intel. I don't think it would be difficult to produce a competive mid-range CPU but I expect it would be difficult to differentiate a new CPU and gain market share against this installed competition.