In August of 1980, Apple released an upgrade for DOS, to version 3.3. This upgrade was an important one. It consisted of not only a new System Master disk, but a hardware upgrade chip as well. The original disk drive had been designed with the ability to read and write 35 tracks of 13 sectors each on a 5.25 inch disk. At 256 bytes possible per sector, this made the disk capable of holding 113.75K of information. Since it was designed to have DOS present on each disk in the first three tracks, and the catalog took up another entire track, there was actually only 100.75K available for data storage. Steve Wozniak, the author of the original DOS disk driver (RWTS), had found a way to increase the storage capacity of Apple floppy disks. Changing slightly the method used for encoding data on the disk made it possible to have 16 sectors per track, instead of the original 13 sectors per track in DOS 3.1 and 3.2. This resulted in a disk that could now hold a maximum of 140K of data (124K excluding DOS and the catalog track), a 23 percent increase over the 13 sector disks. The remarkable thing about this upgrade was that the disk drives themselves did not need to be changed to make this possible. Only the ROM program on the Disk II controller card needed to be changed to make the move to DOS 3.3. Those users who bought this upgrade to DOS 3.3 had to change the ROM chip on the disk controller (or have their dealer do it for them). An updated and greatly expanded version of the DOS manual was also included in the DOS 3.3 upgrade.
The DOS 3.3 System Master disk included many programs that had previously been present on the DOS 3.2 Master, plus a few others. The “COPY” program (used to copy entire disks) was translated to Applesoft as “COPYA” for those II Plus users who didn’t have access to Integer BASIC.
The newer COPY programs also worked properly on single drive systems (previously, you had to have two disk drives in order to use this program to copy a disk). To allow users to startup their older 13 sector DOS 3.2 disks, a binary program called “BOOT13” was included.
(Also, a separate disk called “BASICS” was included that could be used in the same way as a pre-boot for 13 sector disks).
Because of the changes in the ROM controller, it was not easy to read disks formatted under DOS 3.2 directly from DOS 3.3. It could have been incorporated into DOS 3.3, but would have called for a major effort in rewriting the track and sector access routines, as well as making DOS larger than the earlier versions. Instead, Apple supplied on the System Master disk a conversion program called “MUFFIN” to allow files to be moved from 13 sector to 16 sector disks.
Enterprising hackers in the Apple II world made modifications to MUFFIN and created DE-MUFFIN, a DOS 3.2 utility to convert the files back to the 13 sector format. Rich Williams at Apple wrote the MUFFIN program (which was supposed to stand for Move Utility For Files In NewDOS).
The System Master disk also contained a new utility called “FID” (which started at version “M”; nobody knows why the first public release didn’t start with “A”). FID, written entirely in assembly language, allowed easier copying of files, particularly Text and Binary files that couldn’t simply be LOADed and SAVEd from one disk to another, as could Applesoft and Integer programs.
The name “FID” was odd, however. The Apple manuals said it stood for FIle Developer, but Rich Williams (who also wrote this utility) said that the original name of the program was FISHEAD (which stood for FIle Shower, HElper, And Duplicator). Apple Marketing said he couldn’t name a program FISHEAD, so he changed it to FID, which they said was okay. It really stood for Fishead In Disguise (or Fishead In Drag by some within Apple).,,,
Some Apple II users didn’t like to have to use utility programs to manage their collections of disks in both the 13 and 16 sector formats. One method that was used to overcome this inconvenience was to piggyback the old and the new disk controller ROMs and use a switch to toggle between systems. The most elegant solution I’ve found was a ROM chip that plugged into a special card (the ROMPlus made by Mountain Hardware, or the ROMBoard made by Andromeda). A call to a memory location would switch between DOS 3.2 and 3.3, making file conversions quite easy. Soft Ctrl Systems, the company that sold this Dual DOS ROM also sold ROMs that gave instant access to an Applesoft renumber and merge program, an Applesoft editor, and a specialized disk command menu and disk map.
Another change found on the DOS 3.3 System Master was in the method used to load the alternate BASIC. Since by this time the Language Card was available (this added 16K of bank-switched RAM in parallel with the Apple II ROM), there were two groups of users to service on bootup. For Apple II Plus owners, there was a file named “INTBASIC”, which would load Integer BASIC onto the Language Card. For the older Apple II (non-Plus) users, the file “FPBASIC” would be loaded onto the Language Card when the DOS 3.3 disk was booted, making Applesoft available. The last version of the DOS 3.3 Master disk, released with the Apple IIe, used a new utility to load these files which was significantly faster than the standard DOS BLOAD command.
A rumor expressed in a letter to Call-A.P.P.L.E. magazine in January 1982 suggested that up until Christmas of 1980 there never had been an assembly language source listing of DOS. The writer of the letter stated that changes made to DOS up until that time were done by patching it with the mini-assembler in the Monitor. John Arkley at Apple stated that there always was a source code listing for DOS. (He stated that possibly the writer of the letter may have been referring to the problem with the lost Autostart ROM source code previously mentioned in Chapter 6.) Arkley stated that the earliest versions of DOS were written using a cross-assembler on a Horizon microcomputer., He also said that the only part of DOS 3.3 that was assembled from scratch was the new RWTS. The rest was merely attached to RWTS and “conditionally” assembled (meaning that the code would be assembled one way with certain flags set at the beginning of the file, and another way if they were set differently). They made a few patches to fix bugs in the File Manager and Main DOS routines, but did so only in very specific places, to avoid moving undocumented entry points that programmers had been using up to that point.,,,
There were actually three versions of DOS 3.3 that Apple released without bumping the version number:
With regard to the FPBASIC and INTBASIC files: There were three differences between the 50 sector and the 42 sector versions of the INTBASIC file. Firstly, the $F800-$FFFF section was removed. This area was the code for the Monitor, and with the changes introduced in the Apple IIe, it could cause some things to “break” if the older Monitor code was executed. Secondly, a FOR/NEXT bug in Integer BASIC was fixed. Finally, there was a three-byte bug in the Programmer’s Aid ROM #1 chip. The code for this chip was included in the INTBASIC file, and could therefore be patched.
The major limit of DOS 3.3 was that, like its predecessors, it was designed specifically to support the Disk II drive. Hard disks, RAM disks, and 3.5 disks (like those used in the Macintosh when it was released in 1984) could not be easily used with DOS 3.3 (without doing major patching).
The Pascal system was released in August 1979, prior to the DOS 3.3 upgrade. The Institute for Information Systems at UCSD (University of California, San Diego) had created the Pascal system in 1978 for use on the campus PDP-11 computer, as well as with the various microcomputers that were becoming available at the time. UCSD had even created a 6502 version of Pascal already. Bill Atkinson, newly employed at Apple, did the work adapting the UCSD Pascal interpreter to the Apple II, creating the BIOS (basic input/output system) to let the hardware of the Apple II work with the Pascal system. He had to convince Steve Jobs that this would be useful and important to potential customers of the Apple II. Ultimately, the greater sophistication of Pascal led to the development of the Apple III operating system, and was later on used to create the Lisa operating system.
To make Pascal work on the Apple II, it was necessary to free up the memory space that was being used by Integer BASIC, Applesoft, and the Monitor. For this reason, they created the Language Card to add 16K of bank-switched RAM to make that extra space available. Also, the Language Card package used the same hardware upgrade to the Disk II controller as was included with DOS 3.3.
The method used by the Pascal disk system to store files was quite different from that used by DOS. Instead of the 256-byte “sectors” used with DOS 3.2 (and by 3.3), the Pascal system used 512-byte “blocks”, using two sectors per block. Pascal used the larger 140K disks from the beginning, and its method of file naming was somewhat more limited. Instead of names that could be as long as 30 characters and could contain any ASCII character (as was the case with DOS 3.2 and 3.3), Pascal files could be only 15 characters long, and could contain only letters, numbers, or a period. It was designed with a little more flexibility in the types of files that could be created, however. Instead of DOS 3.2’s limit of eight different file types (“A”, “I”, “B”, “T”, and the other four infrequently used ones), Pascal was designed to allow many more, and used a two-byte code to designate file types. A Pascal file entry also had space for a date to indicate when the file was created or updated. DOS 3.2 or 3.3 could not do this without being modified to use part of the 30 character filename for the date, and even then it required the presence of a third-party clock card in one of the slots.,
Pascal disks differed also in being able to have a unique name to designate each disk. DOS 3.2 and 3.3 could be formatted to use up to 254 different volume “numbers”, but this feature was seldom used and did not allow disks to be very unique. The Pascal disk name could be up to 7 characters in length, and had the same limits of character choice as did file names. Another feature of the Pascal disks that differed from the older DOS disks was how space was allocated on a disk for a particular file. Under DOS 3.2 and 3.3, space was used on the disk to identify the used and free sectors. When a new file was created or an existing file was enlarged, DOS consulted this track/sector list to find where free space could be found, and the list was updated when a new sector was used. The advantage was that all space on the disk could be used as it was needed, but the disadvantage was that a file could be “fragmented”, with the sectors that made up that file scattered throughout the disk.
Pascal disks did not have any map of free blocks. Instead, a Pascal file used only consecutive blocks on a disk, and a new file would be started following the end of the last file on the disk. The advantage of this system was faster access to disk files, since they were all on one continuous piece of the disk. The disadvantage was that if a file was deleted, the newly freed space could not be used unless Pascal’s “Krunch” utility was used to move all files forward over the unused space.
Designed as it was be to platform independent, UCSD Pascal had standard names for each of its “volumes”. These volumes were designated as being any type of input or output device, be it printer, keyboard, or disk storage. Each volume had an ID number and a name. The standard volumes used in Pascal were:
|Unit No.||Volume ID||Description|
|1||CONSOLE:||screen and keyboard with echo|
|2||SYSTERM:||screen and keyboard without echo|
|3||GRAPHIC:||the graphic screen|
|4||<volume name>:||System disk|
|5||<volume name>:||alternate disk|
|7||REMIN:||serial line input|
|8||REMOUT:||serial line output|
|9-12||<volume name>:||additional disk drives|
The Pascal system also included some other built-in disk utilities, an assembler, and a compiler. As part of this system one could also purchase from Apple a compiler for FORTRAN programs and a few other computer languages. Apple released four versions of this Pascal, 1.0, 1.1, 1.2, and 1.3 (the last being released in 1985).
With the release of the Microsoft CP/M Softcard, a disk system was needed to handle this foreign programming environment. (Recall from Chapter 13 that the CP/M system gave Apple II users a Z-80-based computer inside their 6502 computer and, therefore, access to programs and utilities that were previously unavailable). CP/M disks were designed to use four 256-byte sectors as one “block” (twice as large as the Pascal “block”). Like DOS 3.2 and 3.3, the first three tracks on the disk were used for the CP/M operating system that was loaded into memory when booting the disk. Like Pascal, the CP/M directory was found at the start of the disk, instead of in the middle as DOS was designed.
Apple II CP/M disks followed the standard CP/M file naming system. A file name consisted of 8 characters, followed by a period, and then a three-character “extension”. One interesting feature of CP/M files was that if a file was longer than 16 CP/M blocks (64 DOS sectors), a new directory entry would be made with the same file name. This entry had an extra byte set to show that this was a continuation of a previous file, instead of a new, separate file.
The operating system designed for the Apple III computer was called “SOS”. This title arose from the Apple III code name, “Sara”, which itself came from the name of engineer Wendell Sanders’ daughter. Originally, then, SOS stood for “Sara’s Operating System”. The manuals released with the computer, however, used the more professional-sounding name “Sophisticated Operating System.” SOS was the first operating system for a microcomputer to use the concept of “device drivers”, which were programs taken from the startup disk and made part of the operating system. These drivers told the computer how to communicate with the various devices that were attached to it, from a variety of disk drives to the keyboard and monitor. This gave flexibility to the Apple III to use new technology as it became available.
When Apple designed the Apple III, they were under constraints of maintaining some compatibility with the Apple II disk format. They used the same disk controller and the same capacity disks as the Pascal/DOS 3.3 systems: 35 tracks, of 16 sectors each. However, the engineers were free to make any changes they wanted in the way in which files were stored on the disk. They came up with something that was a hybrid between the DOS 3.3 and Pascal methods of file storage. From Pascal they took the concept of using 512-byte blocks as the basic unit of storage, a two-block “system loader” program at the start of the disk (this loader would locate a larger system file elsewhere on the disk to actually start the operating system), and a four-block main catalog (which they called a “directory”). From DOS 3.3 they used the concept of disk maps and block lists for each file, allowing parts of files to be stored anywhere on the disk (and eliminating the need for the Pascal “Krunch” function). The SOS filing system also continued the use of a byte to identify different filetypes, space for a date (and time) of file storage, and the 15 character file names using only letters, numbers, and a period. Because the Apple III was intended to be a business machine and had to be able to access larger disk devices than were standard for the Apple II, they also added the ability to create and use different levels of file directories. A single four-block directory had space only for 51 files; even if it was enlarged to allow more files, on a large disk it would soon be difficult to find a file in a list that got longer than a couple of hundred names. The use of subdirectories made it easier to organize files.
The SOS disk file system also would allow files to be as large as 16 MB, and a single disk volume could be up to 32 MB in size. In 1981, when the 5 MB Profile hard disk was released by Apple for the Apple III, this limit of 32 MB was considered to be more than adequate.
In 1984, when ProDOS was released for the Apple II as a “Professional Disk Operating System”, the same file structure was used. In fact, the disks were so designed that a disk created by the Apple II ProDOS formatter installed an Apple III SOS loader segment in the second block on the disk. This made it possible to boot the same disk on either an Apple II or an Apple III, if the necessary system files unique to each computer were present on the disk. Also, files could be shared easily between the two computers. Even after the Apple III had been out of production for years, disks formatted by Apple II System Utilities still had SOS boot information located on block 1. What was even more amazing was that this disk system for the Apple III, released in 1980 (and probably designed in 1978 or 1979), was still flexible enough to be useful for Apple II computers into the 1990s and beyond.
The original DOS for the Apple II was designed primarily to support BASIC. If a programmer wanted to make use of the disk system for an assembly language program, he had to make use of undocumented, low level calls to the DOS File Manager, or possibly to some of the Main DOS Routines. This method was clumsy, and often made inefficient use of memory, as DOS expected that any calls made to it were done on behalf of BASIC. Moreover, this tied the hands of programmers at Apple in their ability to enhance DOS, since any changes they might make would most likely change internal addresses, and cause older software to malfunction if used with the revised DOS.
Another problem with DOS was speed. Since each byte read from the disk was copied between memory buffers three times, much of the disk access time was spent in moving things around in memory. Consequently, as hackers took DOS apart and found better ways to do things, several variations of DOS speed-up programs appeared by 1983, including Diversi-DOS, ProntoDOS, and David-DOS. Each of these programs were mutually incompatible in terms of the low-level calls they made, and had slightly different ways of speeding up DOS.
DOS was also limited since it was device dependent. It was designed to work quite well with the Disk II drive, but to make use of a hard disk or RAM disk (a pseudo-disk “drive” that was actually RAM memory, had no moving parts, and was therefore quite fast), DOS had to be patched. This usually made it impossible to use different brands of hard disks together, or to use a hard disk and a RAM disk simultaneously. Other problems with DOS included poor support for interrupt signals generated by various hardware devices, obstacles in designating memory areas as protected from being overwritten by DOS, and the difficulty in customizing DOS for special functions.
At Apple Computer, despite the Apple III and the planned Lisa, it was determined even in 1981 that there were still a number of years of life left in the Apple II. Mike Markkula, who had just taken on the role of CEO at Apple, stated at a meeting at this time that it was expected that the Apple II was expected to continue to sell well through at least 1983, and that although by then the sales would flatten, they would continue to sell at the rate of 25,000 systems per month through at least 1987. In a memo that Dick Huston wrote that made mention of Markkula’s remarks, he pointed out that there was at that time an estimated user base of 200,000 Apple II users. This forecast, if accurate, meant that there could potentially be 1.5 million new Apple II systems by 1987. With that in mind, he made his case for the creation of a new operating system that would accomodate the larger storage devices customers would demand for the Apple II.
The memo pointed out problems with several current software programs that made it difficult if not impossible to use disk drives other than the 140K Disk II. The Controller, a small business management and accounting program, EDASM (Apple’s 6502 assembler), Visicalc, and DB Master all had custom ways of loading and saving files that were locked to the Disk II. Even FID, Apple’s file management program, could not be used with a Corvus hard drive because it was tied to using only Slot and Driver parameters in identifying a disk. To work on an Apple II, the Corvus was partitioned into multiple 140K volumes, and under Applesoft or Integer BASIC it depended on the little-used “Volume” parameter. FID, however, had not been written to be able to use that feature and could not manage the patched DOS for the Corvus.
Huston’s memo outlined the argument for a completely new DOS. Simply updating to a DOS 3.4 would not fix these problems without breaking software that was already making use of direct, undocumented calls to DOS routines. Furthermore, DOS was limited to a fixed number of files per disk, and had no ability to organize them into subdirectories. Since a major change would be needed anyway, he proposed that they make a complete break with the structure of DOS 3.3 and the past, and make use of the file system that had been designed for SOS on the Apple III. That disk system allowed for up to 32 megabytes per disk volume, individual files potentially as large as 16 megabytes in size, and a more robust directory arrangement. It would also have the side advantage of making file sharing between the Apple II and Apple III simpler.
Because the changes Huston proposed were going to change many facets of the disk system, from the way in which files were named to ways programs interacted with it, he proposed it be called XDOS instead of DOS 4.0. This different name would make it clear that it was a significant change from the older system, and was not just an update. In planning for the changes, engineers also had to anticipate what changes would be needed to software that Apple sold (Apple Writer, Apple Plot, The Controller, Apple PILOT, and Apple Post, which was a mailing list program) to work with the new system.
Because software piracy was still a significant problem, engineers also looked at ways to help make copying more difficult. The methods used for DOS 3.3 could still work, but were specific to the Disk II drive, and did not allow moving a program onto a larger drive. As far back as 1978, Apple had been working on a higher capacity disk drive to ultimately replace the Disk II drive. The engineers had come up with a different design for disks which they called “Fileware” disks. These disks had two opposing ovals for two read/write heads to access the disk, to allow for greater density storage, and they were ultimately used in the Lisa. Also, the disks had space for 12 extra bytes per block that could be used as a key to authenticate the disk as valid (that is, not an unauthorized copy). Potentially, this same scheme could allow the program to be legally copied to a hard drive. (The disk drives, best known by their code name, “Twiggy”, and in service manuals as Apple 871 drives, were developed far enough to have a product name, Unifile and Duofile, for single and dual drive units that would eventually be sold for the Apple II and III. Due to significant problems with reliability, these were ultimately scrapped in favor of Sony’s 3.5-inch drive. Presumably, the plans for program-specific keys also disappeared with these drives.)
Under this more advanced disk operating system, BASIC was just one of many possible applications to interact with a storage device. The part of DOS that worked with BASIC in ROM was separated out from the rest of the disk routines. Early specifications planned support for both Applesoft and Integer BASIC, as well a standardized way for disk access for non-BASIC applications.
The XDOS project was stopped and restarted several times, due to politics within Apple. [Some years later, at the 1992 A2-Central Developer’s Conference, someone asked event organizer Tom Weishaar why Apple made a certain decision about something unrelated. He responded, “[People] have this vision of Apple as an organism with a brain. And I don’t think that’s a correct metaphor.” He went on to explain that the company was a collection of many different goals and people and egos, and all of those factors led to different outcomes of the many projects going on in the company at any one time. ]. The success of a project usually depended on a champion who pushed hard for a project and worked on it even when it was set aside. For ProDOS, that champion was Dick Huston, who originally anticipated only a few months of work would be needed to bring the XDOS project to completion. During the time that Huston was singlehandedly working on the kernel and the Applesoft interface, then moved to the Disk Division, to coding for the ProFile hard drive (which he named), to the Apple II/III systems group, and then to a sidetrack to work with Steve Jobs on the Macintosh. No matter what else he worked on, Huston eventually kept coming back to XDOS.
Finally in 1983, soon after the release of the Apple IIe, it had been given its final product name “ProDOS” and was in its final stages to prepare for production and distribution, including artwork and design of the manuals. Then, at the last minute, it was again cancelled. There were powerful voices within the company that expressed concern that ProDOS would confuse customers, since it used the same file system as SOS. They argued that since the Apple III was targeted as the direct competitor to the IBM PC, and the Apple II was the company’s home and education computer, this would potentially dilute the impact of the Apple III. Furthermore, the Lisa was a significantly better product than the Apple II, and the Macintosh that was coming soon would also be a big player.
The reality of the situation was that the Apple III was barely turning a profit, the Lisa was not doing well, and the Macintosh was still a year away from release, while the Apple II (and the new IIe) was still selling quite well and actually increasing in sales. Dick Huston took his concerns to Mike Markkula, who allowed him to present it to Apple’s board of directors, asking approval for the release of ProDOS.
One of the rumors circulating at the time was that Rupert Lissner, author of /// Easy Pieces on the Apple III, had been able in just a week’s time to convert it to run under ProDOS in the Apple II. Lissner was prepared to buy ProDOS from Apple if it was killed and distribute himself, in order to sell his conversion! (Had this come to pass, it most likely would not have been called AppleWorks.)
After some deliberation, the board decided that the marketplace should decide how well ProDOS was accepted, and not a committee within the company. They approved the final release of ProDOS, and it was shipped to dealers for sale to customers. Sadly, this victory for the Apple II came at a price. Due to politics, several individuals lost their jobs for having backed Huston’s project despite orders from their supervisors, including Huston’s marketing partner on the project, Natalie Shuttleworth.
With the introduction of ProDOS in October 1983, all of the weaknesses of DOS 3.3 were addressed. ProDOS would run up to eight times faster than DOS in accessing 5.25 disks. It supported a standardized protocol for hardware-based devices, allowing reads, writes, status calls, and formatting (erasing). This allowed a large variety of disk devices to be used on an Apple II. Support was also included for a hardware clock, allowing date- and time-stamping of files. Hardware interrupts were supported, necessary system calls were placed in a standard location in memory (called a “global page”), and memory could be protected from being overwritten by the actions of ProDOS.
Because the functionality of this disk operating system was enhanced so much, its size grew as well. To specifically support Applesoft BASIC, a separate “SYSTEM” program was included that worked nearly the same as the older DOS 3.3 did. In addition, it included some further enhancements that had been requested for years by Applesoft programmers. Also, the earlier plans to support Integer BASIC had been dropped. Trying to make it work with this older BASIC would have complicated the development, since the ProDOS program loaded itself into high memory (bank-switched) where Integer BASIC was designed to run. Since very little development of software had been done in Integer BASIC since the introduction of Applesoft, this was felt to be a reasonable trade-off. And if Integer BASIC was needed, it could still be run under DOS 3.3. Neither Apple nor any other company ever created an “INTBASIC.SYSTEM” file to allow Integer BASIC programs to run under ProDOS, with the exception of an Integer BASIC compiler distributed by The Byte Works in late 1991 for instructional purposes.
When Apple released the IIGS in September 1986, with its considerably greater power compared to the older 8-bit Apple II models, changes were needed in the operating system to better manage that power. This had to be done with another goal, that of maintaining compatibility with older Apple II software. The new operating system was called ProDOS 16, and the operating system intended for use with 8-bit software (both on the IIGS and on older Apple II computers) was renamed ProDOS 8. On the IIGS, this ProDOS 8 could utilize the built-in clock on the IIGS, and could use both /RAM as on an enhanced IIe or IIc, and a /RAM5 card assigned to slot 5, utilizing additional memory on the IIGS (as allocated on the Control Panel). When the Apple IIGS originally shipped with what was called System Software 1.0, ProDOS 16 was only a rudimentary program, and translated the new system calls for 16-bit software into ProDOS 8 calls to actually carry out disk activities. As such, it was slow and cumbersome.
Instead of launching into a specific desktop program, this earliest version of the IIGS operating system opened a launcher. Unlike the quit code in the first versions of ProDOS that required actually typing in the name of the next program to launch, this ProDOS 16 launcher displayed SYS files from the launch disk on the super hi-res screen, using colors and menu elements that continued to be used in later versions of the operating system.
One of the major differences between programs written for a 128K Apple II computer and the Apple IIGS with its possibility of 8 MB of memory was the location of the program in memory. On the older computer, typically a program would be written to work at just one memory location. With such a large memory space to work with on the IIGS, it was not possible to ensure that a program would always run at the same location. To provide portability, part of the information included with each program made to run on the IIGS was code to allow it to be modified to work in any possible location. The Memory Manager Toolbox routine helped to make space available for a particular program, and the relocation code made it possible to run that code in the allocated memory. Part of the job of the operating system that was to be designed for this computer was to ensure that software could be deployed to the appropriate location in memory and that it would run there.
The earliest versions of ProDOS 16 were quite rudimentary in carrying out the promise of a Macintosh-like GUI experience. After the Program Launcher used in System Software 1.0, the next version offered something more. System Software 2.0, released in May 1987, booted into the Apple II Desktop. This was a re-branded version of International Solutions’ MouseDesk program, originally sold for the 128K Apple IIe and IIc and pushed as a launch vehicle for that company’s MouseWrite software. On these early versions of ProDOS 16, the Apple II Desktop was buggy, and actually did not have some of the features found in the latter versions of MouseDesk for the older 8-bit computers. Desk Accessories (small desktop programs like a calculator and a puzzle) were not included, and there were no longer any keyboard shortcuts to help in carrying out certain functions.. The lack of keyboard shortcuts was not necessarily a problem, as the shortcuts that had been created for MouseDesk were too numerous and very difficult to guess. On the IIGS, the Apple II System Utilities program from ProDOS 8 was included, as use of the Apple II Desktop was sometimes just too complicated or didn’t work right for certain activities. The 8-bit System Utilities could be used when it was necessary to really get something done. ,
In September 1987, Apple released System Software 3.1 for the IIGS. This was the first version to include the Apple IIGS Finder, which replaced the Launcher and the Apple II Desktop. This Finder was in color, which was something that even the Macintosh had just recently gotten with the release of the Macintosh II. System 3.1 also included version 3.0 of the ProDOS 8 system utility program, which could copy files between ProDOS, DOS 3.2, DOS 3.3, Apple Pascal, and CP/M disks. For the ProDOS 16 environment, there was a folder for Desk Accessories, but it was empty. Unlike Desk Accessories on the Macintosh, which had to be installed with a special utility, the IIGS system was designed to simply put the appropriate files into the right folders and they would work. That applied also to fonts.
Additionally, System Software 3.1 had a new toolset, the Note Synthesizer, which was originally planned for the release of the Apple IIGS, but had not been ready in time.
System Software 3.2 for the Apple IIGS was released in May 1988. It supposedly offered bug fixes for BASIC.SYSTEM (however on closer examination of the code, it turned out that virtually nothing changed between this and the previous version), improved boot time, and added the MIDI toolset, the Note Sequencer (a companion for the Note Synthesizer), and ACE (audio compression and expansion). Printer drivers were changed; it was now possible to print to an ImageWriter LQ over an AppleTalk network, as well as load the system software over AppleTalk. The driver for the regular ImageWriter and for the LaserWriter was completely rewritten and was faster.,
With the experience of SOS, ProDOS, and the Macintosh Operating System to draw from, the engineers and programmers in the Apple II division devised a yet more powerful and flexible disk operating system for the Apple IIGS. It was called GS/OS, and was released as Apple IIGS System Software 4.0 in September 1988, at AppleFest. Written completely in 16-bit code (which allowed faster performance), GS/OS was more than a disk operating system, but a truly comprehensive operating system that also handled keyboard input, video display (text and graphics), mouse input, printers, modems, and more. In these respects it was just as powerful as the older SOS written for the Apple III back in 1980. But they also added a new concept, something that even the Macintosh did not have.
Although GS/OS would allow an Apple IIGS to communicate with disk devices that had not been used on an Apple II before, there would still be the limits of having to know exactly how files were stored on that disk. ProDOS could only handle files stored in the specifically defined ProDOS/SOS format; DOS 3.3 could only handle files stored in that format; and so on. To make this new system as broad-based as possible, Apple programmers built into it the concept of a File System Translator (FST). With the appropriate FST teamed up with a suitable disk driver, GS/OS could theoretically read any disk created by any computer. The FST simply translated the requests made by GS/OS into the language “spoken” by the disk it was trying to read. No disk operating system up to this time had attempted to achieve that feat. Apple, recognizing that the computers used in the real world would never be 100 percent Apple, made it possible to simplify transfer of data between different computers. The concept was first implemented in a limited fashion on the Macintosh, when the Apple File Exchange program was modified to be able to use MS-DOS disks. On GS/OS, it was no more complicated than to drop an FST into the proper folder on the GS/OS system disk. FST files included with this first version of GS/OS included PRO.FST (for access to ProDOS-formatted disks), CHAR.FST (to handle character-oriented devices, such as the keyboard, screen, printers, and modems), and HS.FST (to handle access to CD-ROM files in the High Sierra format).
GS/OS was also made more flexible by removing the older Apple II method of identifying a disk by the slot where its disk controller was attached, and removing the limitation of only two disk devices per slot. The limits of maximum file and disk size built into ProDOS 8 were expanded. A GS/OS file or disk volume could be as large as 4 GB (gigabytes), specifically 4096 MB. However, when GS/OS dealt with ProDOS disk volumes, it still had to stay within the limits of ProDOS (files no bigger than 16 MB, and disk volumes no bigger than 32 MB).
System Software 4.0 included version 1.2 of the Finder. It also had a new program called Advanced Disk Utility, for formatting and partitioning disks, and an Installer program to make it easier to update System disks. It was delivered on two 3.5 inch disks, /SYSTEM.DISK and /SYSTEM.TOOLS, and was made available free to existing users from Apple dealers, user groups, and online services. It required a minimum of 512K of RAM, and at least version 01 of the IIGS ROM.
Another simplicity introduced with GS/OS was the method of handling drivers for various devices that would be attached to the computer. The driver file had to be put in the DRIVERS directory on the system boot disk, and it would be recognized. System Software 4.0 came with drivers for the ImageWriter, ImageWriter LQ, LaserWriter, and Epson printers. There were also drivers to handle the various IIGS ports, including the printer, modem and AppleTalk ports. Another group were drivers for disk devices, including 5.25 and 3.5 floppy disks and SCSI devices. Finally, there was a driver for the console (keyboard and screen) and for MIDI devices.
In this 4.0 release, ProDOS 8 was at version 1.7. Previous versions of IIGS system software had showed a boot screen that was nearly identical to the ProDOS boot disk for 8-bit Apple II computers, except it read “PRODOS 16”. Starting with GS/OS, it displayed a deep blue startup screen with a loading bar that showed progress of the start process, much like the Macintosh used.
Announced at AppleFest Boston in May 1989, and released in July of that year was Apple’s next enhancement for the Apple IIGS. System Software 5.0 made it possible for all existing Apple IIGS computers to run faster, doing it all without the need to make changes to the IIGS hardware. It added speed, speed, and more speed to many features of the IIGS, accomplishing this through more efficient software coding. There were patches to the IIGS ROM Toolbox to improve throughput in many of the built-in capabilities of the machine. A new feature called “Expressload” was added, making it possible for certain program files to load from disk up to eight times faster (and this change could be applied to existing applications). The package included a new Apple SCSI Manager, which worked specifically with the Apple II SCSI card. It bypassed the ROM code on that card to accomplish its faster throughput, increasing it from 18K per second to as much as 80K per second. A new Apple 3.5 driver used a method called “scatter read”, sometimes pulling a full track from the disk at a time and then picking out the blocks needed. The performance changes were dramatic for some programs; for example AppleWorks GS with the help of ExpressLoad went from taking four minutes to load to as little as one minute. The magic performed by the new Apple 3.5 drivers took this one-minute load time and dropped it further to just 35 seconds.
GS/OS was modified to remain in memory during a switch to ProDOS 8 applications, making the return to GS/OS significantly faster. The text-based control panel was supplemented by a new graphics-based one that was accessible in the same way as other 16-bit desk accessories. An FST for AppleShare was added, allowing a IIGS attached to an AppleTalk network to access the file server as a disk.
ProDOS 8 was bumped to version 1.8, which fixed a bug introduced in version 1.3 involving file deletion under certain circumstances. BASIC.SYSTEM was changed to version 1.3, and fixed a bug involving use of the CHAIN command to link one Applesoft program to another, fixed BSAVE when a shorter file was saved over a longer file, and replaced the old MON command (a remnant from DOS 3.3 days that didn’t really work properly in ProDOS) with a MTR command, which simply entered the Monitor (faster than typing “CALL-151”).
The concept of Desk Accessories had been designed into the Apple IIGS from the beginning, and was built into the ROM. These were text-based, and were known to programmers as Classic Desk Accessories (CDAs). The user could access CDAs at any time, even from graphic-based programs, by pressing Open-Apple-Control-Escape (as long as interrupts were not disabled). Only a small number of CDAs were ever released for the Apple IIGS. The more interesting types of Desk Accessories were known as New Desk Accessories (NDAs). These were accessible from the Apple menu in the Finder. In System 4.0, there was only a single NDA present, “Disk Cache”, which allowed part of memory to be set aside to speed disk access.
Apple IIGS System Software 5.0 began to expand on this concept, with a Macintosh-like Control Panel NDA. It performed most of the functions of the text-based Control Panel, though with some small differences. Programmers could add extra functions to the NDA Control Panel by creating the code and putting it into the CDEV (Control Device) folder within the System folder.
Two new tools, TextEdit and Resource Manager, were released in System 5.0. TextEdit made it easy to handle simple word processing function within programs. Resource Manager added support for resource forks in files, allowing programmers to put non-program resources into a part of the file separate from the program code. This made development faster, and simplified customization of certain features of the program without requiring rewriting of the code. These resource forks, which were similar to file structure designed for Macintosh applications, could not be properly copied with 8-bit file utilities, and IIGS users were warned to use only 16-bit utilities to copy and move them between disks or volumes.
Other features introduced in System 5.0 were support for scrolling and pop-up menus, the addition of keyboard shortcuts for some commands, and better code optimization for Toolbox calls that allowed existing programs to run faster. The Finder was also faster, and could now handle AppleShare servers. There were new printer drivers (except the ImageWriter LQ) which were faster than the older ones.,,
System Software 5.0.2 was released in December 1989. It fixed several bugs in the BASIC.SYSTEM file, required a minimum of 512K memory, but worked best with 768K or more. December 1990 saw an update to 5.0.3, which had a much faster ImageWriter driver and a proper ImageWriter LQ driver. On file dialog screens, a “Volumes” button was added, making it easier to change disk volumes when loading or saving files. The additional features of this update brought the memory requirements for GS/OS up to 1 megabyte.
The last revision of System 5 of GS/OS was 5.0.4, which was released in February 1991. Drivers for printers and modems were enhanced to work at rates up to 19.2 kilobaud. Again, a full megabyte of memory was needed to support this version of the system. Bugs that were not fixed were bugs in the SCSI.Manager, and some problems with handling seedling sparse files (but this was a very uncommon occurrence). Also, it was important if a computer was using a non-Apple SCSI card to be sure that Apple’s SCSI.Manager was not installed, because it would conflict with the proper SCSI driver for that card., An improved “standard file dialog” was included in the system tools for 5.0.3, (making it possible to choose files more easily for loading into an application), as were improved drivers for the ImageWriter II and ImageWriter LQ printers. System 5.0.4 was released six weeks after 5.0.3 to fix some remaining important bugs that were discovered. 
Before System 5.0 was released, plans were already in store for further improvements to the system software. Apple representatives attending the A2-Central Developer’s Conference in July 1991 in Kansas City announced plans for release of a major update, System 6.0, which was expected for release by late in 1991. It would take five 800K disks to hold the files for all of the planned enhancements that would make up the new system. Also announced were plans for an Ethernet card and for a card to handle a SuperDrive. This high-density drive could read 3.5 inch 800K and 400K disks, and could possibly read 720K and 1.44 MB MS-DOS disks, although no mention was made of support for those formats.
Apple IIGS “power” users were calling for the ability to use Macintosh HFS (Hierarchical Filing System) disks, as well as the older Apple II DOS 3.3 and Pascal formats. Although there were some simple third-party translation programs available that allowed transfer of files from Mac disks to ProDOS disks, they did not provide the same ease of use, as did the direct access possible with ProDOS and CD-ROM files. Although it sounded to these users like a relatively straightforward proposition, the increased complexity of the Mac HFS directory structure complicated things. Not only did the Mac disks contain more information about each file than did ProDOS disks, but the names of files on Mac disks (as on DOS 3.3 disks) could contain characters that were not “legal” for ProDOS file names. To help with this problem, the new FSTs were designed to watch for potentially illegal filenames, and to make suggestions for alternate names that were legal. Apple software engineers had always made it clear to programmers clamoring for additional FSTs that such changes were more than just dropping the new FST into the System/FST folder on a boot disk. Modifications were necessary throughout GS/OS to accommodate these new features, and the time needed to make these changes was becoming longer than originally planned. To allow some improvements to be made available without waiting for them all, the system software engineers divided tasks during 1990, putting the features that could be programmed most quickly onto a fast track that would allow them to be released as Version 5.0.3 later that year.
The other half of the team worked on the rest of the planned enhancements for what would become System 6.0. When 5.0.4 was completed, the entire team again came together to continue work on this upgrade. After fourteen months of hard work, they were finally ready to release GS/OS System 6.0 in March 1992. New FSTs were released, full read and write access for Macintosh HFS disks, and read-only access to DOS 3.3 and Apple Pascal disks. Also provided were drivers to allow support of the Apple Scanner, the slot-based Apple II Memory Expansion card (which on the IIGS worked primarily as a RAM disk), and the Apple Tape Drive. The SCSI drivers were enhanced, and the Apple 5.25 disk driver was made faster. A new printer driver was included, to support the Apple StyleWriter inkjet printer, and more large fonts were included to use with that and other printers.
The Finder was re-designed almost from scratch by Andy Nicholas, the author of ShrinkIt and GS-ShrinkIt. It added a Windows menu, to make it easier to switch between windows that might be buried under other windows. It could also arrange the windows into a staggered stack. For those using the IIGS with a hard drive, the new Finder also made it easier to tunnel down through folders and subfolders, closing the higher-level folders to minimize desktop clutter.
There were several applications that Apple included with System 6:
System 6 added enhancements for media controls for devices such as videodisk players and CD drives. It included the Universal Access suite of controls for accommodation of computer users with disabilities. One feature, Sticky Keys, made it possible to do multiple keypresses (such as Open-Apple-P) one at a time. This ability was built into the ROM 03 Apple IIGS computer, but this feature was not available also on a ROM 01; System 6 made it work on either model . It was activated by pressing the Shift key five times quickly. MouseKeys allowed the keypad to move the mouse on the screen; Video Keyboard showed a keyboard on the screen, and keys could be selected by clicking on them with the mouse pointer. CloseView zoomed in on areas of the screen (only on desktop GUI applications, however).
The Control Panel NDA, first introduced with System 5, was redesigned. Each Control Panel file was now its own NDA, and more than one could be open at a time. Additional Control Panels added were Sounds (which allowed different sounds to be assigned to various system events), SetStart (to set the startup disk device), Medial Control, Namer (to assign names to printers on an AppleTalk network), and one that allowed network booting directly into ProDOS 8 (particularly helpful in a school environment with a number of computers all linked together).
ProDOS 8 was updated to v2.0 (followed shortly by v2.0.1), but was assembled using 65c02 opcodes, and so was usable only on the Apple IIGS, IIc and enhanced IIe. One of the changes in this version of ProDOS 8 included allowing 8-bit programs access to as many as fourteen disk devices on a single slot. This made large, partitioned hard disks usable on these older Apple II models. ProDOS 8 v2.0.2 and 2.0.3 were the last revisions to be released by Apple, the latter accompanied by BASIC.SYSTEM 1.5.
At the A2-Central Developer’s Conference (KansasFest) in 1992, Apple engineers had announced that version 6.0.1 of GS/OS would be out later in 1992 or early in 1993. Along with specific support of the hotly anticipated Apple II Ethernet card, this update was expected to include bug fixes found in 6.0, and an MS-DOS FST (at least read-only, with write capability to come later). However, politics at Apple resulted in the cancelation of the ROM 04 “Mark Twain” Apple IIGS at the last minute at the Apple User Group satellite broadcast back in September 1991, the Ethernet card, and finally the removal of the IIGS from Apple price lists in December 1992. It took until March 1993 before this final version of GS/OS finally was released, after code specific to the unreleased Ethernet card was removed.
The start dates for Apple DOS, ProDOS, and GS/OS:
(Many thanks to Peltier Technical Services, Inc. for assistance in creation of this chart.)