Amiga.org
Amiga computer related discussion => General chat about Amiga topics => Topic started by: AmigaFreak on March 24, 2015, 08:02:07 AM
-
Hey everyone,
I'm looking for information on the filesystem layout on AmigaOS. What is where, why a particular file is in that place, Just general directory layout... Is there a book like that, or something on-line I can read?
I'm just kinda curious about the FS layout of the Amiga... I've used UNIX systems quite a bit and I'm used to the filesystem layout.. /bin , /usr etc... but even though I have used my fair share of Amigas, I never really opened up CLI to dig around in the actual filesystem beyond Workbench's windows.
-
For which OS (1.3, 3.1/3.9, or 4.1)?
Define "Layout."
"Thomas Rapp" on the forums is an expert, see: "http://thomas-rapp.homepage.t-online.de/index.html"
Also search Google: http://en.wikipedia.org/wiki/Amiga_Fast_File_System
-
Double post - ignore.
-
Is there a book like that, or something on-line I can read?
There is the Bantam Books "Amiga Dos Manual" which contains this information, and there is the "Guru Book" by Ralph Babel. Of the two books, the latter is more recommended, though the former is the original reference.
-
Hey everyone,
I'm looking for information on the filesystem layout on AmigaOS. What is where, why a particular file is in that place, Just general directory layout... Is there a book like that, or something on-line I can read?
I'm just kinda curious about the FS layout of the Amiga... I've used UNIX systems quite a bit and I'm used to the filesystem layout.. /bin , /usr etc... but even though I have used my fair share of Amigas, I never really opened up CLI to dig around in the actual filesystem beyond Workbench's windows.
Briefly, the system partition is something like this (from memory - so may well have missed something):
C - Commands - executable commands.
Classes - BOOPSI Classes - gadget classes, datatypes, etc
Devs - Devices - Device drivers. Also sub-divided into Printers (printer drivers), DataTypes (datatypes descriptors, not sure why these are in Devs though), and some other things I forget.
Fonts - Fonts - Fonts!
L - Filesystem Handlers (named Libraries due to TripOS legacy). OS4 also has some charset information here for some reason (which ought to be in LOCALE: )
Locale - Localisation stuff - translations, country data, help files, etc
Libs - Libraries - Shared libraries
Prefs - Preferences - WB prefs programs. Also contains Env-Archive, which is where permanent prefs and environmental variables are stored.
S - Startup - startup scripts
SObjs - Shared Objects - OS4 only, Linux-style shared libraries (.so)
System - System programs - Commands like Format which are required by WB
Utilities - Utilities - Dumping ground for software which comes with the OS
Tools - Tools - Dumping ground for software which traditionally comes on the Extras disk
The actual directory names don't really matter that much - AmigaOS references them all by assigns - DEVS:, C:, LIBS: etc. I haven't tried renaming and manually setting the assigns to the new locations, but in theory that should work!
-
S - Startup - startup scripts
I read that it's originally from "Sequence" word, and you'll put all kinds of scripts there, not just startup scripts.
The actual directory names don't really matter that much - AmigaOS references them all by assigns - DEVS:, C:, LIBS: etc. I haven't tried renaming and manually setting the assigns to the new locations, but in theory that should work!
Yes and you can also add locations to the assigns. For example if you want to keep your SYS:Libs/ directory clean only containing the libraries which come with the OS, and you want to have 3rd party libraries in some other dir.. for example in SYS:UserLibs. You can add it with "Assign Libs: SYS:UserLibs ADD" command. Then the library to be opened from the Libs: will be looked from the both SYS:Libs/ and SYS:UserLibs/ paths.
-
This what MorphOS does in a very neat way. All the typical directories are pretty much empty, for example SYS:Libs, but LIBS: is assigned to SYS:Libs MOSSYS:Libs, and the lattet comtains all of MorphOS native libraries. Any libraries installed by programs or user, goes to SYS:Libs (since it is first in path of the Libs: assign), and libs in SYS:Libs will also be loaded before equally named libs in MOSSYS:Libs.
And all these directories came from TRIPOS btw.
-
Yes and you can also add locations to the assigns. For example if you want to keep your SYS:Libs/ directory clean only containing the libraries which come with the OS, and you want to have 3rd party libraries in some other dir.. for example in SYS:UserLibs. You can add it with "Assign Libs: SYS:UserLibs ADD" command. Then the library to be opened from the Libs: will be looked from the both SYS:Libs/ and SYS:UserLibs/ paths.
And this is why AmigaOS is so great, even 30 years later. :)
-
And this is why AmigaOS is so great, even 30 years later. :)
Agreed! Actually 1 of many reasons.
You didn't mention which Amiga or version of the OS you have. If you still have the books that came with an OS1.3 Amiga, the small book "Enhancer Software" has a complete list of all the traditional directories and all the files they contain on the standard disks (starting at B-1). As already said, most of the AmigaDos manuals explain this well, too.
One of my favorite references is Rob Peck's "The Amiga Companion". It is clearly written and available online as a PDF.
@ Chris
"..L - Filesystem Handlers (named Libraries due to TripOS legacy).." I used to wonder about how L got its name.
-
The actual directory names don't really matter that much - AmigaOS references them all by assigns - DEVS:, C:, LIBS: etc. I haven't tried renaming and manually setting the assigns to the new locations, but in theory that should work!
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.
-
I read that it's originally from "Sequence" word, and you'll put all kinds of scripts there, not just startup scripts.
Yes, I think you're right.
And all these directories came from TRIPOS btw.
Only the single-letter ones AFAIK.
"..L - Filesystem Handlers (named Libraries due to TripOS legacy).." I used to wonder about how L got its name.
I only found out fairly recently, when somebody posted a link to the TripOS manual.
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.
Yes, fair point. It was more a thought exercise than something I'd expect anybody to try!
-
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.
If SYS:C is missing would AmigaOS look Startup-Sequence from the root?
-
And all these directories came from TRIPOS btw.
Actually, no. Only the one-letter directories are tripos. L: for "Libraries", this is were Tripos keeps its "Library stuff", we call it "Handlers" today. "S:" for scripts, "C:" for commands. DEVS: and LIBS: are exec/Sassenrath names that came in through ramlib. T: is also a Tripos name. FONTS: came a lot later.
-
For reference, here (http://www.pagetable.com/?p=193) 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!
-
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...
-
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.
-
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:
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:
Assign SYS: CD0: PATH
Even more powerful would be:
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.
-
Not really, Commodore had hard drives for sale with their PET computers used in lab and office settings.
-
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.
-
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:
(http://www.mos6502.com/wp-content/uploads/2012/02/cbm9060.jpg)
-
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:
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:
Assign SYS: CD0: PATH
Even more powerful would be:
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?
-
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 (http://en.wikipedia.org/wiki/Sun_workstation) and Apollo/Domain (http://en.wikipedia.org/wiki/Apollo/Domain) workstations." -- Wikipedia
-
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.
-
Which RISC are you talking about now? m88k?
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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:
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:
Assign SYS: CD0: PATH
Even more powerful would be:
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
-
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.
-
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:
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:
Assign SYS: CD0:
One minor flaw of the assign PATH option is that it does not work well with ADD. For example:
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.
-
A new day, a new addition.
-
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.
-
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.
-
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.