The "opposition" to ProDOS was more of a reluctance to accept it, and had more to do with the status quo of the Apple II at the time than with specific objections to the OS design. In other words, much of the controversy was due to the fact the ProDOS was not the first Apple II OS.

DOS 3.3 (ProDOS' predecessor) was basically a crude file system written around a 5.25" disk driver, with a command interpreter thrown in so you could access files from BASIC. It felt like something that was just thrown together, but in many ways that was its appeal. It was the sort of glorious mess that you'd build in your workshop. Something like Frankenstein's monster, with multiple code styles, patches here and there, a little duct tape, and wires all over the place. It was fairly short and uncomplicated, so you could easily patch the things you wanted to improve. Even though there was no support whatsoever for adding things like RAM drives or hard drives, it was easy to write your own driver and a patch to go along with it. As you would expect, there were a lot of mutually incompatible patches floating around, but armed with an anything goes attitude, many of us wouldn't have had it any other way. A lot of people tinkered with DOS 3.3, but nobody ever really tinkered with (the internals of) ProDOS.

Things were never the same when ProDOS arrived as a more serious operating system. Instant demerits for stuffiness! It did add many improvements, such as subdirectories, time stamping, interrupt support, a standard way to add device drivers, named disks (in DOS 3.3 you referred to a disk drive even in high-level BASIC by the slot number that the disk controller card was installed in), support for larger storage devices (up to 32MB, versus the 400k limit in DOS 3.3), and a simple but hardly foolproof way of write protecting memory (actually it was more like error checking of buffer addresses). The part that interfaced with BASIC was separated, and provided some simple memory mangement, improved garbage collection for BASIC strings, and a standard way to add commands.

So what are the downsides? For one, with all the new features (including many not listed above), ProDOS used about 26.5k of memory, as compared to the 10.5k used by DOS 3.3. DOS 3.3 worked with both Applesoft and the earlier (and shorter and faster) "Integer" BASIC, and in fact, with one in RAM and the other in ROM, you could switch between the two at any time. Many programs were written in Integer BASIC, but ProDOS provided no support for Integer BASIC. DOS 3.3 was written when an Apple II might have anywhere from 16k to 48k of RAM, so its location was not fixed, and it was easy to move (relocate) it out of the way. ProDOS had a fixed location, which was out of the way of almost everything, but there were a few programs that could only be used with DOS 3.3. ProDOS had a more modular (but slightly slower) boot sequence, and consequently more memory was overwritten at boot. This was not an issue if you were cold starting the system, but if there was a crash that made rebooting necessary, it was nice to preserve the contents of as much RAM as possible.

ProDOS file names were much more restrictive than DOS 3.3. DOS 3.3 file names could be up to 30 characters long, and could contain any character except comma (which was used to specify command parameters) including spaces, although they had to start with a letter (actually any chracter from @ to ~ could be used). In ProDOS, file names were limited to 15 characters, could only contain letters (case insensitively), numbers, and periods (and had to start with a letter). Thus, even as disk capacity was increasing (with 3.5" disks and hard drives), making more files per disk more likely, users had to use less descriptive file names. This certainly seemed like a strange design decision.

One of the more puzzling changes was the removal of the code that formatted 5.25" disks (the most common storage media on the Apple II at the time) from the 5.25" disk driver. With a 140k (per side, but each side was formatted separately) capacity, it was easy to fill a disk, but an application (such as a word processor) had to provide its own code to format a disk (and write the file system and boot code to disk). Users couldn't very well quit the application, then run a utility to format a new disk, if they didn't have a disk to save their work on. Of course, many people were in the habit of keeping formatted disks on hand, but you could really get stuck. This alone probably alienated a LOT of people.

In fact, I myself prefer DOS 3.3 to ProDOS, due to longer, less restrictive file names and the fact that less memory gets overwritten when reboot after a crash (generally of my own doing, I should mention).



I'd like to point out that this capability, while certainly possible, can be inconvenient to use in practice. The main reason is that the address that BRK pushes onto to the stack is the address of the byte AFTER the "operand" byte. To pass a one byte parameter to a BRK handler, it's usually more efficient to pass it in a register and just ignore the "operand" byte.

Also, since BRK and IRQ use the same vector ($FFFE), the performance of each will suffer when the BRK/IRQ handler must distinguish between the two. Thus, its often a good idea to use no more than one of the two.

This would explain why ProDOS was more readily accepted for the Apple IIgs than for its predecessors. Of course, having more RAM capacity via the 65816 also helped.

I believe ProDOS 16 also returned the 30 character filename size, IIRC, though not with the first OS revision. I believe that came about with GS/OS System 5 I think. Being a Commodore fan all my life, I never really followed it that well. I'm just going on what I remember my friends telling me back then plus modern-day Google-style research.



Performance of an IRQ handler will not suffer any more than it currently already does for the 6502-based kernels. Performance will suffer only for BRK handlers, because they have to decode the operand byte.

That being said, I agree, the utility of BRK for 6502 based environments is questionable except to serve as a debugger breakpoint. For the 65816 it makes somewhat more sense, because it is really the only way to make an OS system call in such a manner that an external MMU is aware that this is happening (as fetching the BRK vector pulls the _VP signal low). Additionally, BRK has its own vector.

Hmmm . . . I just realized something. If you're going to write a small CLI-type OS for the 6502, and getting it running first on a VIC-20 or Commodore 64 environment, it would be nice to use the Commodore filesystem for interoperability with other filesystems. But since SEQ and USR file types are treated as if they were cassette streams, you'll need to use B-A, B-R, B-W, and B-F disk commands to manage the disk to emulate random access to files. This might be an advantage though: it would be nice to be able to read/write VLIR files, which you simply MUST use those disk commands for anyway. Obviously, for a custom filesystem, you could do whatever you wanted.

Bigger filenames came with GS/OS in general. GS/OS 6.0 was rather nice. You could even format drives with the macintosh filesystem instead of the ProDOS filesystem and supported a logical superset of all popular filesystems internally.

Actually, file names can be much longer than 30 characters in GS/oS.



I didn't mean to suggest otherwise. The IRQ examples Garth's interrupt primer assume that BRK won't be used at all. I was trying to address the other end of the spectrum, namely when BRK is used, but not IRQ. If an IRQ handler is then added in such a scenario, not only does this add additional overhead to BRK, but IRQ performance is worse than if it were used without BRK. When BRK is used for debugging, it's usually used to stop whatever was happening, so it's probably not a big deal if stopping takes several extra cycles. However, when BRK is used as a OS (or library) call, the additional overhead makes using IRQs less appealing. I don't know what the rationale was for having BRK and IRQ use the same vector, but I guess hindsight is 20/20.

Anyone looked at Acorn MOS? That was a decent modular OS for 8-bit machines (6502 specific). Covers multiple filesystems, multiple interpreters etc and networking!

Is there an online reference on MOS?

Ideally I think the OS should be designed to allow relatively easy upward migration to future processors (e.g., 6502 -> 65816 -> Terbium), so that we don't end up with 3 different APIs for 3 different processor architectures.

Nothing particularly decent but there is some here: http://www.mdfs.net/Docs/Comp/BBC/

Most are in 80's books. It's not upwardly compatible but Acorn ported it to ARM in a week (!)

So, RiscOS is a port of MOS? Or, more accurately, RiscOS is an evolution of MOS, retaining much of its original API and architecture?

Speaking of which, how exactly do MOS's and RiscOS's filenames work? I have never found a complete explanation of their various components. I'm more familiar with how AmigaOS and Unix-style filenames are implemented and used. Can you compare and contrast the RiscOS/MOS approach, and list their relative merits and demerits?

Thanks.

MOS = Machine Operating System

MOS is a single tasking OS for pretty much all Acorn systems with an fairly compatible API between 6502 and ARM systems. RISCOS is basically an evolution of MOS with a GUI on top which handles the multitasking side of things. They wrote it very quickly because they had to get machines out of the door and their big UNIX-style OS wasn't finished. If they had finished it, we might all be using it now as it would have been very good (Acorn have had unarguably the most talented hardware and software engineers ever - and they document stuff properly!).

As for paths:

$ = root
. = path separator
/ = file extension separator
LABEL:: = volume

so:

D:\this\is\a.test

is:

D::$.this.is.a/test

There is a 1:1 mapping but you can't map the filetypes between unix/windows and riscos easly as they are stored in the file's meta-information rather than the path information. Acorn files don't usually have the /test bit on them.

Merits:

- File types are persisted whatever the file name is
- It's consistent back to Acorn System 2 days. You can read a filesystem from 1979 to now on a recentish acorn machine. I had a 5-1/4" floppy disk in my circa 1995 riscpc and i could read 40 track bbc disks without any hassle and run BBC software quite happily.
- It works transparently with multiple filesystems and over the network on different platforms (SJ research made fairly capable Z80 fileservers).

Demerits:

- noone immediately understands it
- older machines were limited to very primitive directory structures (particularly with DFS - the OLD disk filing system).
- Lots of "variants" of their filesystem which are "variably" compatible as they were produced by 3rd parties.

Ah! I see. This is somewhat similar to AmigaOS:

: refers to the root
/ is the directory separator -- there is no official extension mechanism -- extensions are part of the normal filename

That's it.

To re-use your example: D:this/is/a.test

However, disks have volume labels which it uses preferably over specific device names (Workbench2.0: and Extras1.3: versus DF0: and DH1:). Or, if you are referring to the root directory of the current volume, you can just use : as the first character (e.g., :this/is/a.test).

I've seen RiscOS paths similar to this before:

Foo::AnotherName.$.rest.of.path.here

What purpose does "AnotherName" serve in this context? Also, it looks like Foo:: referred to a filesystem driver (usually CDFS:: or ADFS::). Is that another use for the volume label? If so, I would assume that AnotherName in this case refers to the volume name.

Also, what are the semantics of Foo::rest.of.path.here -- that is, if you leave off the $? In that case, does it use the current directory for volume Foo:: as the starting point?

Thanks for the information. This is helping to clear up a number of mysteries.

Sorry - my bad - you are correct:

%filesystem%::%volume%.$.%directory%.%directory%.%file%[/ext]

Got a stinking cold at the moment meaning my brain is lacking somewhat.

Never got the hang of Amigas - I had an A500 strictly for Xenon 2 and Speedball, not workbench

AmigaOS kicked all the other OSes butts as far as I'm concerned. Tiny, simple, elegant API, with preemptive multitasking all made for the revolution that we all know as "multimedia" today. It was an attempt to "fix" what they perceived was broken in Unix -- the lack of automatic disk volume mounting, and the incessant need to use '..' for previous directory instead of using a proper tree-structured filesystem implementation. As a result, to change to three previous directories, you would issue the command cd ///, which is awfully convenient.

I remember AmigaOS blasting away 20fps to 30fps, full-screen video, reading it in from floppy, in near real-time (in particular, I'm referring to Space Ace game, as shipped on floppy). It was obviously compressed on the disk, which made for faster I/O. Still, no other computer at the time could touch this level of performance. Of course, today things are much different.

Of course, I worked for Amiga, Inc. after Commodore disbanded, so I am biased.

That being said, I was doing some research on RiscOS (BTW, no matter what Linux distribution I use, I always make it a point: the #1 thing I compile is ROX-Filer) a while ago, and was quite deeply impressed. The only thing that bummed me out was the decision to use cooperative multitasking instead of preemptive. Other than that, it looked like a really nice environment.

Going back to MOS and related topics, I am curious to learn what would happen if you issued the wrong filesystem. For example, supposing you have a volume ADFS::MyVolume with a file called data/txt in the root directory, what would happen if you issued CDFS::MyVolume.$.data/txt as a filename to work with?

Thanks.

It's going to take me some time to finish it myself, but I'm currently working on an OS for the 65xx series that will (hopefully) satisfy some of what people are looking for in a 65xx OS. The primary requirements for the system are portability to new 65xx systems, minimal size, scalability (can be built to run on VIC-20, Apple IIgs, anything in between), and true pre-emptive multitasking. I tore down my web pages and whatnot because no one seemed to give a flying you-know-what about it, but then again, it still doesn't do nearly as much as, say, LUnix. Of course, one of the biggest goals is to make sure it's NOT trying to be a UNIX clone, or a weak attempt at replacing the GEOS desktop...anyway, suffice it to say that because I'm doing everything alone and from scratch, it's going to be a while. I'm currently working on the self-hosting preprocessor/assembler/linker/dynamic loader code bases, because I'll have to face it sooner or later, and I might as well develop it the way it's going to be rather than re-tool it all later..

No, I don't like o65 format. I know someone will ask, "Why don't you just use o65+luna+lupo+lld for everything?" I am of the opinion that it's an unnecessary burden to use a generic executable format that is designed to accomodate multiple 8-bit processors and operating systems when I can make a better format that will cut down on the size of the dynamic linking loader a lot. Just wanted to cut that one off before it comes up. :P

Thanks for all the discussion about Apple and whatnot. I don't know much about the old Apples, other than every singe public school in my state seemed to have at least 30 of them at one point. It's interesting that Apple had a disk operating system at all, and on top of that there's more than one, but I can't think of a single disk operating system for the 64 off the top of my head, unless GEOS counts.

Excuse my wordiness.

Ten years ago the school where my wife teaches was anxious to get those "old, slow" Apples and Commodores out of there. But when I looked at the "educational" software they had, I could see why they thought the computers were so rinky-dink. It's because the software was! It was all written in interpretted BASIC, apparenly by hobbyists in their garage! And for what little software there was that could have been a lot better, they of course had lost the manuals long ago. (It was written before computers had the memory and storage space to have the manual online. Come to think of it, it was also before the art of good manual-writing was lost.)