kc5tja wrote:
I think Apple's ProDOS comes the closest, but I understand that there was (until the Apple IIgs at least) a lot of opposition around it.
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).
kc5tja wrote:
The 6502 has a BRK instruction which can, under software control, take a one-byte operand, thus offering up to 256 software-dispatched vectors.
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.