Compiled and written by Steven Weyhrich
(C) Copyright 1991, Zonker Software
 

Csa2 FAQs resource file: R019V4HIST.HTML

The comp.sys.apple2 Usenet newsgroup Apple II FAQs
originate from the II Computing Apple II site. 1997 ...

Note: To facilitate easier reading, the extensive footnote
references have been removed from this document.
 
 
 
 

DOS 3.3

     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.
 

DOS 3.3 - FEATURES

     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"; just like DOS "3", 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 had some sort of mnemonic meaning that he could no longer recall).  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 (which, as you should recall, was simply 16K more RAM to add in parallel to 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.
 

DOS 3.3 - MISCELLANEOUS

     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.  However, during a phone interview in September 1991 with John Arkley at Apple, he said there ALWAYS was a source code listing for DOS, as far back as DOS 3.  He believes the writer of the letter may have been referring to the problem with the lost Autostart ROM source code (see Part 6 of this History).  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 (a programmer's term; sorry).  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.
 

DOS 3.3 - LIMITATIONS

     The major limit of DOS 3.3 was that it, like its predecessors, 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 directly used with DOS 3.3.
 

PASCAL SYSTEM

     The Pascal system was released in 1979, prior to the DOS 3.3 upgrade. It 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, however.  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 little 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 when the file was created or updated.  DOS 3.2 or 3.3 could not easily do this, even if a clock card was installed.

     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 which sectors were used and which were free.  When a new file was created or an existing file was enlarged, this track/sector list was consulted by DOS 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.

     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.
 

CP/M

     With the release of the Microsoft CP/M Softcard, a disk system was needed to handle this foreign programming environment.  (Recall from Part 12 of the History 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 which 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.
 

SOS/PRODOS

     The operating system designed for the Apple III computer was called "SOS". This title arose from the Apple III's code name, "Sara", which itself came from the name of engineer Disk Huston's 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 allowed 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 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 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 as late as 1992, when the Apple III has been out of production for eight years, disk formatted by Apple II System Utilities still have SOS boot information located on block 1. What may be even more amazing is that this disk system for the Apple III, released in 1980 (and probably designed in 1978 or 1979), is still flexible enough to be useful for Apple II's in 1992.
 

PRODOS

     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.

     With the introduction of ProDOS, all of these weaknesses 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.  The only disadvantage of the new ProDOS was that it did NOT support Apple's original Integer BASIC, since the ProDOS program loaded itself into high memory where Integer BASIC was loaded in an Apple II Plus.  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.  At the time of this writing, there has been no release of a ProDOS system program that would support Integer BASIC (with the exception of an Integer BASIC compiler distributed by ByteWorks in late 1991 for instructional purposes).
 

PRODOS 16

     When Apple released the IIGS, with its considerably greater power compared to the older 8-bit Apple II's, 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 the older Apple II's) was renamed ProDOS 8.  But ProDOS 16 version 1.0 was somewhat of a temporary fix to the problem of disk access for 16-bit software.  It was not written in 16-bit code, and it simply translated the new system calls defined for ProDOS 16 into ProDOS 8 calls to actually carry out disk activities.  As such, it was slow and cumbersome.
 

GS/OS

     With the experience of SOS, ProDOS, and the Macintosh Operating System to draw from, Apple engineers and programmers devised a yet more powerful and flexible disk operating system for the Apple IIGS.  Written completely in 16-bit code, GS/OS was released in September 1988.  It was more than a DISK operating system, but a truly comprehensive operating system that also handled keyboard input, monitor output (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.

     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 be able to 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.  This task had never before been attempted by a computer company in designing a disk operating system. 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.  The Mac system is now also able to add its equivalent of an FST for the ProDOS and MS-DOS disk systems, but not as easily as has been implemented in GS/OS.

     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 can be as large as 4 GB (gigabytes), or 4096 MB to be more specific. However, when GS/OS is dealing with ProDOS disk volumes, it still has to stay within the limits of ProDOS (files no bigger than 16 MB, and disk volumes no bigger than 32 MB).

     System Software 5.0 for the IIGS was introduced in May 1989.  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.  GS/OS was modified to be capable of staying 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.  Access to 3.5 disks was accelerated by implementing a feature called "scatter read", which could take an entire track (rather than just a single block) of data from the disk at a time. An FST for AppleShare was added, allowing a IIGS attached to an AppleTalk network to access the file server as a disk.  It also included an FST to allow access to CD-ROM drives, new utilities for disk partitioning, and it had an intelligent "Installer" program to make it easier to install system or application files.

     Because of further improvements in features, System Software 5.0.2 (an upgrade to 5.0) required a minimum of 512K memory, and worked best with 768K or more.  Versions 5.0.3 and 5.0.4 needed a full megabyte of memory.  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 discovered too late.
 

GS/OS SYSTEM 6

     Before System 5.0 was released, plans were already in store for further improvements to the system software.  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. In addition to FSTs for the Mac HFS disks, DOS 3.3, and Apple Pascal, device drivers were created to allow support of the Apple Scanner, the slot-based Apple II Memory Expansion card (which on the IIGS works 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.  Archiver (a disk backup utility) and Teach (a GS/OS-based text-editing program) were also included. Finally, ProDOS 8 v2.0.1 was released, allowing 8-bit programs access to as many as fourteen disk devices on a single slot.  This made large, partitioned hard disks usable even to Apple IIc and enhanced IIe users (this version of ProDOS 8 required the opcodes of the 65c02 chip, although ProDOS 8 v1.9 was still available to run on the Apple II Plus or unenhanced IIe).

     At the 1992 KansasFest, Apple engineers announced that v6.0.1 of GS/OS would be out later in 1992 or early in 1993.  Along with specific support of the Apple II Ethernet card, this version is expected to include bug fixes found in 6.0, and an MS-DOS FST (at least read-only, with write capability to come later).
 

++++++++++++++++++++++++++++
 

PROGRAMS "R" US

     Nearly everyone reading this is already a programmer, on one level or another.  Even if you don't know a "GOTO" from a "STA $C030", you already know how to program something.  For the act of "programming" is nothing more than giving instructions to a non-human device to have it carry out what you want it to do.  The device that most of you already know how to program is your automobile.  The act of giving those instructions may not seem like programming to you; nevertheless in its strictest sense, programming it is.  You want the car to go forward?  Set the transmission to "D".  Go in reverse?  Use "R".  Of course, the programming needed to operate an automobile is quite simple, and cannot be done in more than one step at a time.  An example of a device that is more complicated to program but does let you store up several instructions in advance is a VCR.  On the VCR you instruct it to record a television broadcast that starts at 7:00 pm and ends at 8:30 pm, on channel 6.  The more sophisticated VCR's can have several programs set up in advance.  If you can operate a VCR in this fashion (which is, admittedly, not always as easy as I have described), you are a programmer.

     When it comes to the microcomputer, the process of programming (giving it instructions on how to carry out a task) is somewhat more complicated.  This is primarily because the computer is far more flexible in its ability to accept instructions and carry them out than is an automobile or VCR.  Devices attached to a computer can be manipulated by a program to do something useful (print a letter several times, or perhaps read the outside temperature and sound an alarm if it drops too low).  This flexibility, plus the speed at which a computer can execute its instructions, makes it a powerful tool for doing things that have previously taken much more effort and time.  And as a project becomes more sophisticated, so also must the programming acquire a similar level of sophistication.  The rate at which computers, including the AppleII, have increased in capacity during the past fifteen years has made it possible to design programs that can do things that were not even dreamed possible back in the days of the 4K Integer BASIC machine.

     An example of programming evolution on the AppleII was given during Kansasfest in July of 1991.  To fully appreciate this narrative, you need to know a little about an old Integer BASIC program, APPLEVISION.  This was found on the DOS 3.2.1 System Master disk, and was a fun little display that showed off the use of hi-res graphics.  It began by creating a simple line drawing of a room, with a picture on the wall ("HOME SWEET HOME") and a television set.  On the screen of the TV appeared a man who danced to the tune of "Turkey In The Straw", which sounded on the built-in speaker.  It ran repeatedly, until the user interrupted the program.  It was fascinating at the time, since there was nothing in the program text that showed off exactly how the hi-res effects were accomplished.  But things have gotten a bit more complex as time has gone by:
 

"Roger Wagner's keynote address featured a history of hypermedia which Roger set into action and left to run as he wandered offstage.  The history began with Bob Bishop's classic AppleVision, done in black and white on the original AppleII. Progressive screens enhanced the AppleVision image using subsequent incarnations of AppleII graphics (single hi-resolution, double hi-resolution, and the IIGS's Super Hi-Resolution modes).  Finally, thanks to a laserdisc player under HyperStudio's control and a video overlay card, Roger's image appeared within the television's screen and spoke to the audience, completing the introduction before turning the presentation back to Roger (returning from offstage)."
 

     To follow the programming progress that has made such magic possible, we will begin with the first two built-in high-level languages for the AppleII, Integer BASIC and Applesoft, and move on to a briefer discussion of some of the other languages that have been available over the years.  Next will be a summary of various 6502 and 68816 assemblers that Apple programmers have used over the years.  Finally, I will present an introduction to "hyper-programming".
 

FUNDAMENTALS OF PROGRAMMING

     A programming language has the standards to translate "what I want" into commands that the computer understands.  To do so, it must take some human language and convert it into the binary dialect of the computer on which it is executed.

     Computer languages usually come in one of two different types: "interpreted" and "compiled".  A language that functions as an interpreter takes the text of the program and translates it at the time of execution into commands the computer can understand.  A compiled program, on the other hand, has already had the program text translated into executable code before it is run, usually including some extra code needed to carry out necessary functions of input, output, and calculations.  As such, an interpreted program usually runs more slowly, but has the advantage of being easier to modify and re-run without the delay of first re-compiling.  A compiled program will ordinarily run faster, but may use more memory than an equivalent interpreted program.

     Languages are also given the designation of being "high-level" or "low-level", depending on how close they are to the base language of the computer on which they run.  The lowest level of computer programming is at the level of the bytes understood as commands by the microprocessor.  This "machine language" is typically not very understandable to humans.  A low-level language more often used by programmers is "assembly language".  This uses commands somewhat more understandable ("LDA $24" means "load the accumulator with the contents of memory location $24") and are then assembled (actually compiled) it into machine-readable code.  Assembly language is very powerful, since it works on the byte level of the computer.  However, as a low-level language it can be very complicated and requires an intimate understanding of the function of the computer.

     As a language becomes more "high-level", it is easier for humans to read, but requires more effort from its interpreter or compiler to translate it into the native language of the computer.
 

INTEGER BASIC

     This was the first language available for general use on the AppleII (aside from assembly, which will be dealt with later).  Most of the details concerning its development have already been covered in Part 3 of this History.  It was a quick, compact language, and its creation was an example of programming directly in machine language (since Steve Wozniak, the author, had no assembler available to use).  Its disadvantage was the lack of easy access to floating point operations, and it lacked some string handling functions.  AppleII users, especially those who wanted to produce programs that could be used in business applications, wanted something more powerful to use.

     Despite its limitations, Integer BASIC was a language that had a fanatically loyal following.  For those thousands who purchased AppleII's from June 1977 to June 1979, this was the only programming language available, and it took on a status similar to that of a beloved first-born child.  Games, utilities, and even some simple business-use programs were written using Wozniak's hand-assembled masterpiece, and those who followed the pages of Call-A.P.P.L.E. magazine learned much about the internals of the language.  With the disassembler built into the Monitor, people tore Integer BASIC apart to learn how it worked, and to make it work better.  Val Golding, the editor of Call-A.P.P.L.E., even wrote a series of columns in 1979 entitled "So Who Needs Applesoft?"  These articles showed how to simulate some of the more advanced features of Applesoft in this older BASIC.  A.P.P.L.E. even sold (under license agreement with Apple Computer) "Integer BASIC +", a relocatable RAM version of the original ROM BASIC.  It had all the features of the original language, plus a "USER" command, the ability to easily do four direction scrolling on the text and lo-res screens, easy printing of ASCII characters, and improved error handling.

     Apple never released a comprehensive reference manual for Integer BASIC. The only manual available for it was primarily a tutorial (and a general introduction to using a computer).  The "AppleII BASIC Programming Manual" didn't even call it "Integer BASIC", but referred to the language as "Apple BASIC".  It gave most of its programming examples in the form of segments of a graphics and sound demo that created a lo-res ball bouncing off the sides of the screen.

     With the many programs available that were written in Integer BASIC, it was almost a necessity for Apple to offer a means for AppleII Plus users to be able to run the older software.  The Integer Firmware card made this "backward compatibility" possible.  This was especially important in the early days of the II Plus, when there was little new software available to use with Applesoft.
 

APPLESOFT I

     Although Wozniak had written some floating point routines into the Integer Basic ROM, AppleII users needed a version of Basic that would make floating point math easier to do, particularly for business use (where the number to the right of the decimal point is as important as the one to left).  Apple decided to license a 6502 version of a floating point BASIC from Microsoft Corporation. Back in 1977, Microsoft was producing BASIC interpreters for nearly every microcomputer that was produced.  The version Apple purchased was almost identical to the MITS extended BASIC that Microsoft had previously written for the Altair 8800.

     This BASIC was named "Applesoft", and was released in November of 1977 on cassette.  It was loaded as a 10K program that looked to the computer just like an Integer BASIC program, though only a small part of it really was.  To make it easy to load and start from cassette, the Applesoft interpreter was attached to the end of a short Integer BASIC program.  When the Integer program was run, it poked some values into memory and jumped to the start of the machine language section, which relocated the Applesoft interpreter to the lower part of memory (at $800), just after the memory that held the screen display.

     Using this version of Applesoft (which later became known as ApplesoftI) could be frustrating.  It took several minutes to load from the cassette tape, and it was not dependable.  If the wrong key was pressed while entering or running an Applesoft program, the program that was being run could be wiped out, and the Applesoft interpreter itself would have to be reloaded from cassette. However, few users knew how to make use of the floating point routines that Wozniak had written into the Integer ROM, so this unreliable Applesoft BASIC became the only practical means of doing floating point math on the AppleII.

     Aside from the reliability issue, another difficulty with Applesoft involved hi-resolution graphics.  Although the AppleII was capable of displaying it, the Applesoft interpreter extended up into the memory used by the hi-res screen, and so prevented its use.  Furthermore, this early version had no built-in commands to manage hi-res graphics.

     ApplesoftI came with a manual that was 8 1/2 inches by 11 inches in size, and sported a blue cover with square glued binding.  This came to be known as the "blue book" (recall that the reference book for the computer itself was affectionately known as the "red book").  When starting the interpreter after loading it from the cassette, a screen was display announcing that Applesoft was copyright 1977 by Apple and Microsoft.  It then asked the user for the memory size of his computer, and gave options of allowing either LET and REM statements or the use of lo-res graphics.  The names of the lo-res graphics commands were very different from those that existed in Integer BASIC (and in the later versions of Applesoft).  The commands were:

PLTG           = Go to lo-res graphics mode
TEX            = Go to text mode
PLTC N         = Set color to N (0-15)
PLTP X,Y       = Plot square at X,Y
PLTH X1,X2,Y   = Plot horizontal line from X1 to X2 at Y
PLTV Y1,Y2,X   = Plot vertical line from Y1 to Y2 at X

     There was a note about these commands in the reference card included with ApplesoftI that warned about using graphics coordinates only between 0 and 39, or a program could "self-destruct".   Apparently it lacked the error checking that could prevent the plotting of lines from spilling over into the text of the Applesoft program itself.

     The A.P.P.L.E. user group published a patch in 1978 that allowed programmers to avoid the question about using LET and REM statements versus lo-res graphics, and use the graphics only.  The author of the patch pointed out that the LET statements were not necessary ("A = 3" worked just as well as "LET A = 3").  The REMark statements could be simulated by putting them at the end of a GOTO line (where they were ignored by the interpreter), and the GOTO could just jump to the following line:

   530 GOTO 540: REM LINE 540 SETS VARIABLE N.
   540 N = 2

     Additional patches were made available for some of the other bugs found in ApplesoftI.
 

APPLESOFT II

     In spring 1978, Randy Wigginton and some others at Apple made some needed revisions to Applesoft.  Using a cross-assembler running on a North Star Horizon (Z-80) microcomputer, they fixed the known bugs and added other commands to control features unique to the AppleII.  These commands included the ones needed to draw and manipulate hi-res graphics.  Also, the lo-res graphics commands were renamed to be more consistent with the equivalent commands in Integer BASIC (GR, HLIN, VLIN, etc.)  This version was called "ApplesoftII", and eventually it was available in five forms:  Cassette RAM and Diskette RAM (which loaded to the same memory locations that interfered with hi-res graphics as did ApplesoftI), Firmware card ROM, Language card RAM, and finally main board ROM (in the AppleII Plus).

     When ApplesoftII was started up from cassette or diskette versions, the display screen now showed a copyright date of 1978 by Apple Computer, Inc., and 1976 by Microsoft (which may be either their copyright date for the original Microsoft BASIC, or possibly for Microsoft's first 6502 version).

     This RAM version of ApplesoftII used memory from $800-$2FFF, and the Applesoft BASIC program itself was loaded beginning at $3000.  When the versions that came on ROM and for the Language Card RAM were released, the BASIC program could load at $800, and much more memory was available for it.  Some of this extra space (in high memory) was reclaimed by DOS when the Disk II was released, however.

     Applesoft in the original IIe was unchanged from the II Plus version.  When the IIc was introduced in 1984, however, Apple programmers had cautiously made a few useful changes to the language:
 

     o Input processing was changed to allow lowercase entry of Applesoft commands (they were translated into uppercase)

     o Screen output commands (PRINT, TAB, HTAB, etc.) were modified to more properly handle the 80-column screen

     o Program lines (when LISTed) were changed to begin in column 2, making screen editing easier

     o All of the cassette tape routines (LOAD, SAVE, SHLOAD, STORE, and RECALL) were removed, since the hardware did not support cassette I/O.  The keywords were still in the token table, but now pointed to the same memory vector as the ampersand ("&") command.

     o Patches were made to the lo-res graphics commands (GR, HLIN, VLIN, PLOT, and SCRN) to work with double lo-res graphics.  However, a bug was introduced that allowed PLOTting vertically to areas outside of the double lo-res graphics screen, which would land right in the beginning of the $800 space where the Applesoft program text was located (similar to the "plot" bug in ApplesoftI).

     When the AppleIIe Enhanced ROMs were made available, Applesoft in those ROMs had undergone some similar modifications.  All the above IIc changes were added, with the exception that double lo-res graphics capability was not added (lack of ROM space), and the cassette I/O commands were not removed (since the cassette input and output port was still present).

     The version of Applesoft on the AppleIIGS closely resembled the AppleIIc variant, the only exception being a fix of the double lo-res PLOTting bug. However, a bug in the SCRN function that applied to double lo-res mode was not fixed.  No changes to Applesoft from the IIc version appeared in the AppleIIc Plus.

     The manuals written for ApplesoftII were far more comprehensive than either the older "Blue book" or the Integer BASIC manual.  It gave not only programming examples for each of the commands, but included much more information about the various ways in which each Applesoft statement could be used.  It also mentioned some of the differences between Applesoft and Integer (for those who wanted to convert their older programs), and gave a little information about the internals of Applesoft to aid in creating machine language additions to the language. Curiously, the manuals that have been reprinted even as late as 1990 by Addison-Wesley have included an odd cautionary note to programmers.  In a section in the index about "reserved words" (words reserved as Applesoft commands), it advises against using "XPLOT" as a variable name, stating that "it is a reserved word that does not correspond to a current Applesoft statement." What is apparently meant by this comment is that at one time Apple intended to extend the language and add another command "XPLOT" to it, probably working with HPLOT in the same way that XDRAW complements DRAW in doing hi-res graphics. Examination of the command table within the Applesoft interpreter shows thereis no entry labeled "XPLOT", and a disassembly of the interpreter shows no preliminary code to support the command.  Somehow this precaution persisted to the present day and has never been removed, even though it is extremely unlikely that Applesoft will ever be upgraded.

     Particularly helpful for programmers was the foresight to include a simple extension called the "ampersand hook".  If Applesoft came across the "&" symbol while interpreting a line, it jumped to a known location in memory and left it to the programmer to insert the correct code to add a machine language extension to the language.  With the publication of important information about the internals of Applesoft in 1980, assembly language programmers could now add statements to do things that could not be done with the language as it was originally created.  Music, extended graphics, IF-THEN-ELSE logic, and even the missing "XPLOT" command could be added to the language.  The only limits were the author's imagination (and available memory).

     The importance of Applesoft as an influence to productivity on the AppleII cannot be overstated.  Since the release of the AppleII Plus in 1979, every variety of AppleII has contained Applesoft in virtually an unchanged form.  This has made it possible for anybody to write programs that all other AppleII users will be able to use, since the language does not have to be purchased or added. If there were thousands of Integer BASIC programs from the two years when Integer AppleII's were produced exclusively, there are hundreds of thousands of Applesoft programs that appeared over that subsequent thirteen years.  Even today, it is not uncommon for an applications program to include a configuration module written in Applesoft using the disk commands available with BASIC.SYSTEM in ProDOS.  It is often faster to write such a program in BASIC, and the author knows without a doubt that his customer will be able to run it.
 

APPLESOFT 3 (?)

     In 1979 there were rumors at the West Coast Computer Faire about an enhancement to ApplesoftII that was in the works at Apple.  It would possibly be called Applesoft3, and would be as much of an enhancement over ApplesoftII as that version was to ApplesoftI.  Supposedly it was intended to merge DOS and BASIC, and would include such powerful functions as IF-THEN-ELSE, PRINT USING, WINDOW, and VIEW PORT.  It was predicted to be a RAM version only, and would be about 24K in size.  Knowing the events that actually followed, this rumored BASIC was probably the "Business Basic" released with the AppleIII, rather than an enhancement for the AppleII.
 
 

+++++++++++++++++++++++++++++++++++
 
 

APPLE PASCAL

     Applesoft was easy to use because it was interactive.  You entered a command, and could immediately try it out.  The disadvantage was a lack of more powerful commands, and it could be difficult to create large and complex programs.  Efforts were begun within Apple to develop a more comprehensive language for the II, one that could be updated and modified if necessary.  Since Applesoft was in ROM, it was more expensive and difficult for the end-user to install any upgrades to that language.

     In 1979 Apple Pascal and the Language System was released.  It sold for the steep price of $495, and came on four 5.25 floppy disks (all in the format of the Pascal disk system, of course).  It also included the ROMs to change 13 sector disk controllers into 16 sector controllers, and the Language Card to plug into slot 0.  As discussed in previous segments of this History, the Language Card was a 16K RAM card that made an AppleII into a full 64K RAM computer.  Because of the extra available RAM, the Pascal system could load into memory without having to avoid the space used by the Applesoft (or Integer BASIC) interpreter.  And with some complicated bank switching, even routines in the Monitor could be used if needed.

     Apple chose to use the Pascal standard defined by the University of California at San Diego (UCSD).  To make portability between various different computers possible, UCSD Pascal programs were compiled into a specialized code called "P-code".  This "P-code" program could then be executed on any computer that had a proper interpreter.  An Apple Pascal program could, then, run a little faster than an Applesoft program (since it was compiled), but not as fast as assembly language.  The extra power it provided made it an attractive choice for some programmers.

     The earliest version of Apple Pascal got complaints from users because it would not support lowercase (for those who had modified their Apple to display lowercase), and it was so large that it was quite awkward to use by those who owned only one disk drive.

     Since the original UCSD Pascal language was designed to work with a full 80 columns of text, this was somewhat of a problem for the 40-column AppleII.  For those AppleII's that did not have an 80-column card, Apple Pascal would display half of the screen at a time.  In the Pascal Editor, entry of a line longer than 40 columns would cause the screen to scroll to the left.  Using the arrow keys to move back to the left would scroll the screen back the other way.  If needed, you could jump directly to the other half of the screen by pressing Ctrl-A.

     The limitation of Apple Pascal came from the need for a user to own the Language Card (or one of the later equivalent 16K RAM cards), and the fact that it was incompatible with the large library of DOS 3.2 programs and files that were already available.  Eventually, with the proliferation of the 64K AppleIIe and 128K AppleIIc, a platform for Pascal applications was available.  However, by that time the primary disk system being promoted by Apple for the II was ProDOS, and Apple never officially released a version of their original UCSD Pascal that would run under that operating system.

     The Apple Pascal system has evolved up to version 1.3, which will support the more advanced features of the AppleIIe and IIc, but does not work as well with the IIGS as some would like.  Instead, IIGS programmers now have versions of Pascal distributed by third party companies (like ORCA/Pascal from ByteWorks) created to take full advantage of that machine in 16-bit mode.
 

INSTANT PASCAL

     This version of Pascal was written by Think Technologies, and Apple later bought the rights to sell it as a program for teaching Pascal.  It would run only on the AppleIIc or on a 128K IIe because it used the double hi-res graphics mode, functioning much like a Macintosh "desktop" with multiple resizable windows.  It had a mouse-based editor that checked program syntax as each line was entered (as did the older Integer BASIC) and automatically indented lines and boldfaced Pascal reserved words.  Since it was intended for teaching, it also had a single-step trace function and the ability to modify the contents of variables while a program was running.  Though good for learning the language, it was quite slow because of the overhead needed to display everything in graphics, and because it was an interpreted version of Pascal (instead of a compiled version).

     Fans of the original Apple Pascal complained loudly after Apple introduced Instant Pascal.  After this new Pascal came out, Apple didn't seem motivated to make any further upgrades to the older Pascal, which still used the original Pascal disk system format (Instant Pascal was made to run directly under ProDOS).
 

FORTRAN

     Released by Apple in 1980, Apple FORTRAN ran under the Pascal operating system.  It cost $200 (over and above the $495 needed to get the Language System).  Programs written in FORTRAN for other computers could run with little modification under Apple FORTRAN (if a user needed that ability).  As a compiled language, it ran faster than Applesoft, and probably also faster than Pascal, since FORTRAN wasn't translated into an intermediate "P-code".  Apple's FORTRAN had many bugs in it, though, and since its introduction in 1980 it was never upgraded.  By September 1986 it had disappeared from their product catalogs.

     Another way for an AppleII user to get FORTRAN was to buy the Microsoft Z-80 Softcard for $345 and Microsoft FORTRAN for $200.  This version of FORTRAN was more full-featured than Apple's, and offered some advantages in usability. It did not require changing to the 16 sector disk controller ROMs (if you didn't want to).  Also, standard Microsoft BASIC (which was more advanced than Applesoft) was included in the Softcard package.

     In June of 1987 Pecan Software released FORTRAN for the IIGS.  It ran under ProDOS 16 (GS/OS), but still used the UCSD format for its FORTRAN by creating a ProDOS file that acted as a UCSD volume.
 

OTHER LANGUAGES

     PILOT:  Designed primarily for creating tutorial modules, this language allowed educators to design interactive programs to instruct students and test them on their responses during the process.  One early version was written in Applesoft and was text-based.  Apple later released their own version that ran under the Pascal system for $125.

     FORTH:  This was a interesting language described as "extensible".  It had a number of built-in commands, and new ones could be added as easily as typing its definition.  These added commands could then be used in larger programs. Two versions sold in the late 1970's were "Apple Forth 1.6" (Cap'n Software) and "6502 Forth 1.2" (Programma International).  Apple Forth 1.6 was a good package, but it used a unique disk system that was not compatible with DOS 3.2. Programma's Forth was more extensive, but also more complicated.

     LOGO:  Developed from LISP (LISt Processing) language to be an aid for learning, Logo has been popular over the years in the school environment. Apple's first version of Logo (which operated under the Pascal system) could run on any 64K AppleII, while Apple Logo II (released in July 1984 for $100) ran under ProDOS on AppleII's with 128K memory.

     COBOL:  This language has had limited availability for the AppleII.  The only version I am aware of was from Microsoft.  It sold for $599 and ran under the CP/M system with the Microsoft Z-80 Softcard.

     C:  A language that is currently popular among "power" programmers.  It has some of the structure of Pascal, but also some of the low-level power of assembly language.
 

ASSEMBLERS

     A large variety of AppleII assemblers have been available over the years. The earliest one, of course, was the mini-assembler that came with every Integer BASIC AppleII.  The one was only good for immediate entry of assembly code; if changes were needed, much of the code would likely have to be re-entered from the beginning.  Some other assemblers available in the early days include:

     TED/ASM:  Developed at Apple and smuggled out the doors around May 1978, this assembler had memory conflicts with DOS, so they couldn't be used together. The text editor module was written by Randy Wigginton, and the assembler was written by Gary Shannon.  In the early days, it was the only assembler they had available that would run on an AppleII.

     RANDY'S WEEKEND ASSEMBLER:  Also written by Randy Wigginton, this one slipped out of Apple in September 1978.  The text editor was written mostly in SWEET-16 (Wozniak's 16-bit emulator in the Integer BASIC ROM), and was therefore slow.  Unfortunately, it had its own set of bugs.

     MICROPRODUCTS ASSEMBLER:  The first commercially available assembler for the AppleII, this was a "four character assembler", meaning that labels (a designation identifying a line or variable) could only be four characters long. Later it was expanded to work with six character labels.  Despite some annoying bugs, it was inexpensive at only $39.95.

     SC-ASSEMBLER II:  Probably the second AppleII assembler that was commercially distributed.  Externally it was similar to the Microproducts assembler, but was better supported and regularly upgraded.  It was very compact, and achieved that goal by making heavy use of SWEET-16 code. Consequently, it was slow when assembling.  The author, Bob Sander-Cederlof, later started a popular newsletter called "Apple Assembly Lines" to both support his product and to be an information center for 6502 assembly language tips and techniques.

     BIG MAC/MERLIN:  Sold originally by A.P.P.L.E. as "Big Mac", and later under the name "Merlin" by Southwestern Data Systems (later known as Roger Wagner Publishing).  This assembler has been well supported over the years and has been extensively upgraded.  It is one of the few remaining assemblers that have moved on to the 65816 GS/OS world, while retaining full compatibility with the previous 8-bit 6502 versions.  Currently it is sold as Merlin 816 (including an 8-bit version) and Merlin 16+.  The author, Glen Bredon, has also done many other programs and utilities for the AppleII.

     ORCA/M:  Sold by the ByteWorks, the current version was chosen by Apple Computer as the official assembler of the APW (Apple Programmer's Workshop) programming environment on the IIGS.  ByteWorks has since expanded its product line to include versions of Pascal, C, BASIC, and other IIGS languages.

     APPLE EDASM:  This was Apple's original "official" assembler for the IIPlus and later 8-bit AppleII's.  Though no longer actively supported (ORCA/M having supplanted it in the APW environment), the early versions for DOS 3.3 were included on the Apple Toolkit disk, which also had a hi-res character generator that could be interfaced into Applesoft programs.  The early ProDOS versions of EDASM were sold with a 65c02 debugger called BUGBYTER.

     UCSD PASCAL ASSEMBLER:  Part of the Apple Pascal package, it was popular because it had macro capability, could do conditional assembly and create relocatable code, and had a good text editor.  However, programs created with it could not be run on a standard (non-Language card) Apple, because there was no utility available early on to transfer the files to DOS 3.2.  (Later, A.P.P.L.E. published transfer utilities called "HUFFIN" and "PUFFIN" for movement to and from DOS 3.3, named affectionately after Apple's "MUFFIN" utility for DOS3.2 to 3.3 file transfers).

     MISCELLANEOUS OTHER ASSEMBLERS: ASM/65, sold by Programma; "EAT" (Edit and Assemble Text) sold by Software Concepts, and written in Integer BASIC; and L.I.S.A., sold by Laser Systems.
 
 

MACROS VS. SCRIPTS

     With the increase in complexity of applications programs has also come a secondary level of programming.  This extension has been called a "macro", meaning that a single step would accomplish several separate ones that would ordinarily take more effort.  Early examples of this were available in some DOS3.3 utilities, where pressing Ctrl-C from the keyboard (for example) might cause the word "CATALOG" to appear on the command line.  In this example, a macro was used to save keystrokes and speed up repetitive activities.  Similar macros were available for BASIC programmers, making a control key sequence print many of the common BASIC keywords, speeding program entry.  (This type of macro was different from macros used in some assemblers, such as Big Mac/Merlin and the Pascal assembler.  Here a "macro" was a new command that was defined to represent several standard assembly operation codes.  This did not shorten the final resulting program, but made it possible to more easily enter repeated sequences of assembly codes).

     Application programs began to take this concept and include a macro capability (either offered with the program or as a third-party add-on product). With time, some of these macro features have become so complex that they have become programming languages in their own right.  In fact, many of them are being referred to as "scripting" languages, since they "direct" the function of a program, as a director uses a script to film a movie.  This has been most popular with telecommunications programs, where the process of logging on to a remote computer, downloading new messages, and uploading replies is automated with a script that analyzes the responses from the other computer and takes the appropriate action.  It has also been popular in programs like Applewriter (WPL, Word Processing Language) and AppleWorks (UltraMacros), where each has had its own method of automating repetitive tasks.
 

A LEAP IN COMPLEXITY

     The environment for writing, compiling, and debugging programs has evolved along with the applications created by those programs.  Originally, the AppleII and other computers of the day were used in a "command-line interface" environment.  This means that each command was typed one at a time, and sometimes "batched" together to simplify a repetitive process (as with EXEC files under Apple DOS).  An example of this command-line interface can be found by starting up Applesoft (or by using MS-DOS on an IBM).  Anything that is to be done with this language has to be started by typing the proper command from the keyboard.  Misspell the word "LOAD", and an error message is printed and it will stubbornly refuse to do what you wanted.  The same command line is used for entering the lines of a BASIC program, or RUNning the program.  This method was used because it was what programmers of the day were accustomed to.  Nearly every computer prior to the microcomputer revolution worked in the same way, even if it was done using punched cards instead of being typed at a keyboard.

     Minor differences were used from time to time in different computer languages, but none really took effect and changed the way in which people used computers until the release of the Macintosh in 1984.  Macintosh used a radically different method of operating a computer.  Instead of typing each command, the user would point to something on the screen and "click" on it using the mouse pointing device.  And Macintosh programmers extended this concept to every application released with it.  This different environment has been called a "graphic user interface" (GUI), and uses the concept of objects rather than typed commands.  To delete a file, you don't type "DELETE PROGRAM", but point to the picture (icon) representing the file and drag it onto a picture of a trash can.  This "desktop" includes more complex commands chosen from menus that appear in boxes called "windows" that pull down like a window shade from command category names on a "menu bar".

     As the command line disappeared, so did traditional methods of handling program data.  Words were still typed into a document on a word processing program, but many of the features that set up margins, tabs, and page breaks were translated into graphic icons selected with the mouse.  Eventually this progressed into the world of the programmer.  The text of computer program was entered much like any word processor text, and the command to compile it into an executable program was now selected from the menu bar at the top of the screen.

     A step further along this path is the concept of "object-oriented programming" (OOP).  In this method, the details of windows, menu bars, buttons, and other GUI standards are used to create other programs that use a consistent interface.  Instead of having to laboriously define at the byte level how to create a window box, the computer already knows how to do this; the programmer just has to tell the computer how big it should be and where to place it on the screen.  OOP programming allows smaller modules (called "objects") to be used to build a more complex final product.  A language that works in an OOP environment is finally available on an AppleII, but before we get to it, a little more introduction is necessary.
 

HYPERTEXT

     "Hypertext" is a term created by Computer Lib author Ted Nelson that refers to a method of allowing a user to move from one concept to another in a text by linking the two concepts together.

     The first type of program that used "hypertext" was a simple text based one.  Certain words in the text of a document being viewed were marked to indicate that other information about that word was available elsewhere.  Moving a cursor to that word and pressing a key would jump to the additional facts. For example, in an article about the history of music, the word "sonata" might be highlighted.  Selecting this word could jump to another article that discusses sonatas in greater detail.  When finished, the user could jump back over this link to the place where he left off in the original article.

     "Tutor-Tech" was the first comprehensive hypertext system available for the AppleII series.  It worked on 8-bit AppleII's, and was designed primarily for use in a classroom setting.  Entirely graphics-based, it defined certain parts of the screen as "buttons", and moving the pointer to that area could allow the program to move to a different screen or cause something else to happen.  As with any graphic interface, icons that represented certain functions were used to designate commands (i.e., to exit the program, you point to a picture of door labelled "EXIT").

     In 1986 a remarkable program became available on the Macintosh that was, for a time, included with each Mac sold.  "HyperCard" was a comprehensive system that used the idea of hypertext, plus added a programming language that consisted of words and phrases as close to English as anything else previously available on a microcomputer.  The HyperCard system took care of the details of how to draw boxes and buttons, and left it to the user to define where to put them and how to label them.  And because of the language (which Apple called "HyperTalk"), user actions could do more than just move to a different picture (called a "card" by the program).  It was possible to design simple databases, games, and much more using this system.  Because it called a single part of an application a "card", a collection of cards comprising an entire HyperCard application was called a "stack".

     With the release of the IIGS, the power was finally available in the AppleII world to create a similar product.  But it didn't come first from Apple Computer; instead, Roger Wagner Publishing introduced a product called "HyperStudio" in May of 1989.  This program used the super hi-res graphics modes accessible on the IIGS to create its own type of stacks.  Like HyperCard on the Macintosh, HyperStudio used buttons and objects on the screen to direct movement through a stack application.  It also included a hardware card that made it possible to easily digitize sounds to use in stacks.  Though more extensive than Tutor-Tech, it was not quite as flexible as HyperCard, since it lacked a true programming language.

     In January 1991, Apple released HyperCard IIGS, a conversion of the Macintosh product.  This finally made a fully programmable hypermedia environment possible on the IIGS.  Later in the year Roger Wagner Publishing responded with an updated version of HyperStudio that also included a programming language similar to HyperText that afforded more control over that stacks that were created.  Although neither of these products gives the user power over details of the computer system itself (as does "C" or assembly), it does make it possible for a beginner to create programs that have outstanding graphics and sound without having to know exactly how the hardware produces these effects.  This, along with the flexibility possible with these products, has led Dennis Doms in an A2-Central feature article to suggest that HyperCard IIGS (and now also possibly HyperStudio) will become the "Applesoft" of the 1990's; that is, an AppleIIGS user with HyperCard IIGS can create programs as easily as the Applesoft programmer of 1980 could do, but with far more attractive results.
 

+++++++++++++++++++++++++++
 

"WILL SOMEONE PLEASE TELL ME WHAT AN APPLE CAN DO?"

     One of the most important features to a customer considering any computer is, "What can I do with it?"  It might be an attractive-looking box, with incredible features and potential, but if all it can do is run demonstration programs, it won't be very useful.  In the early years of the microcomputer era, most users had to either write their own software or use programs written by some other amateur.  "Commercial" software written by "professionals" was unavailable, except possibly from the company that produced the computer.  And unless the user knew assembly language and the internals of the computer intimately (which depended on the willingness of the manufacturer to divulge those secrets), the only application software available was likely to be written in BASIC.  Anyone who has used the versions of BASIC available at that time are well aware of the quirks and limits placed on the programmer by that language and by the small memory sizes available (see discussion in Parts 16 and 17).

     As we have already seen, the AppleII came with few intentional secrets; the primary limitation on information distributed with it was the time required for Apple to produce a printed manual.  When the first manual finally did arrive, it included a commented source code listing for the entire Monitor and all its supporting routines.  This openness had a lot to do with the early success of the AppleII.  Other manufacturers, such as Atari (with their models 400 and 800, based on the same 6502 as the AppleII) and Texas Instruments (who made a 16-bit machine called the TI 99/4), kept everything very secret and thus tried to maintain some control over distribution of software.  This may have been done to ensure that only high quality programs were released, but more likely they were concerned about controlling who received royalties on sales of the software. Unfortunately for them, it choked the development of amateur software authors (who may have later become professional authors).

     As an example of this corporate secrecy, one early programmer named John Harris wanted to write games for the Atari, but could not get the company to release any information on how certain effects were achieved in their commercially released games.  He was bright enough to eventually figure out the secrets himself, and became one of the wealthy software "stars" of the late 1970's and early 1980's.

     Computer producers of the time did not yet grasp the principal of the software/hardware loop:  Available software stimulates sales of hardware (computers and peripherals), which further enlarges the software market, which sells more computers, and so on.  The industry was too new to know how to do much more than make and sell new computers.
 

SOFTWARE ON THE APPLE II

     In the AppleII part of the computer world, the first distribution of software came from home authors.  These people were usually first-time computer buyers who were captivated by the excitement of owning their own computer, and then had to sit down to actually find something useful or fun to do with it. They often brought their first programming efforts to show off at the computer store where they had bought their machine.  Since the store owners had very little software to offer to their potential customers, some of these authors ended up with the opportunity of having their programs duplicated and made available for sale.  Ken and Roberta Williams started their company "On-Line Systems" (later Sierra On-Line) this way with a game called Mystery House, one of the first adventure games featuring hi-res graphics pictures.

     Other early software came from the first user groups.  These usually developed out of the gatherings that inevitably took place at the computer stores, as mentioned above.  Since the people who actually used these computers day in and day out at home had a better grasp of how they worked and what could be done to work around problems, the store owners often ended up referring their new customers to these groups for the detailed help they needed.  Not only were there the older groups (like the Homebrew Computer Club), but many newer, more machine-specific groups developed.  Names like A.P.P.L.E. (Apple PugetSound Program Library Exchange) and International Apple Core became known well beyond their local beginnings as they began to distribute their newsletters and magazines to a national audience.  Later, they became major sources of informational articles, utilities, and application programs that were as yet unavailable anywhere else.

     Many of the programs sold by A.P.P.L.E. were popular with AppleII owners. A.P.P.L.E. was designed as a club with dues to pay for the collection of programs, all considered to be public domain, but sold to members at a nominal price to cover the costs of duplication.  A.P.P.L.E.'s programs were written by amateur home users who had a unique idea, were able to make it work, and found that they had a product that was useful to others as well.  Originally collected on cassettes, and later on disks, some of the programs were eventually made available as commercial products by authors that knew they had something unique that would be in demand by Apple owners hungry for something to use on their computer.  A.P.P.L.E. sold many of these as GamePaks, which contained several games on the same tape.

     Understanding that a large variety of available programs would help encourage more sales for the AppleII, Apple took some steps to help software authors get their programs on the market.  In 1980 Apple employee Mike Kane suggested that Apple help distribute programs that were good, but whose authors couldn't get a publisher to distribute them or didn't have access to computer stores that were willing to sell it for them.  Kane formed a division within Apple, called it "Special Delivery Software", and promoted both third-party and Apple-sponsored programs under that label.  Between 1979 and 1981 a number of different programs were sold through Special Delivery Software, sporting the Apple logo and displaying a standardized appearance (packages, manuals, etc.), all listed in a catalog that could be used by dealers for orders.  Apple Writer was originally distributed in this fashion, as were other less well-known programs such as Tax Planner, Plan 80, Script II (for Pascal), and MBA (a spreadsheet).  Apple also established the Apple Software Bank and used it for special programs through 1980.  It was more clearly a set of Apple-sponsored programs than were those sold through Special Delivery Software, and some of them programs, such as Quick File and Apple Plot, achieved strong popularity and were moved more into the mainstream of sales for Apple.
 

SOFTWARE EVOLUTION: THE COMMAND LINE INTERFACE

     Some of the earliest programs available for the AppleII had a user interface that was quite similar to the ones available for use with time-sharing terminals on mainframe computers:  A command was typed on a line, and the computer would execute that command and return with a prompt for the next command.  This method was the necessary way of doing things, because video displays were expensive and not in common use.  This was particularly true for those who used remote terminals, which usually consisted of a paper-based glorified typewriter connected by a phone line to a mainframe.  This device was physically limited to allowing commands to be entered one line at a time.  The concept of displaying things on the screen in any order desired, not necessarily going from top to bottom (as would be necessary if it was being typed on a piece of paper in an teletype) was difficult for many programmers of the time to grasp.  Moreover, for design purposes, the software code built-in to a computer (like the AppleII) that handled a command line style of interface was much simpler (and shorter) than what would be needed for a more complex interface. With memory at a premium price, simple would have to do.  Thus, the AppleII used the command line interface in both the Monitor and in Integer BASIC.  These could be used as building blocks to create more complicated software, once people figured out how to do it.

     The command line interface, though simple to implement in a program, had the disadvantage of requiring the user to know (and correctly type) the names of the commands.  For example, a word processing program might use the command "LOAD" to get a text file into memory, the command "EDIT" to begin to make changes to that file, and then the command "SAVE" to put a copy of the completed work back onto tape or disk.  "SORT", with various pieces of modifying information called "parameters", might be the necessary command to arrange the information in a database file into the desired order.  Other commands might be needed to search for a specific word, replace a word, and move lines around.  In fact, early word processors were often quite similar to writing a program in BASIC:  Each line had its own line number, and inserting new lines often meant having to renumber the lines to make a new line available between two existing ones.  If extra text had to be added to a line in the process of editing, making it too long, the end of that line might have to be re-typed into the following line and deleted from the current one.

     More sophisticated text editing programs eventually began to appear that took advantage of the fact that the user was not working with a typewriter and paper, but with a video screen.  These "full-screen editors" would allow use of the arrow keys (or the IJKM "diamond" on the keyboard) to move the cursor around on the entire screen, and it made text entry and later editing easier.  As they were further refined, these newer word processors even allowed what had previously been impossible:  Text could be typed in the middle of a line, and the text to the right of the cursor would be magically pushed to the right (even "wrapping around" to the next line if needed) as things were typed.  Deletions were just as easy.  What was still cumbersome was the need to have specialized commands, often entered as combinations of the Control key and another letter, to carry out some of the functions of search and replace, copy, and so on. Moreover, these command keys were often different from one program to another, with Ctrl-F in one program being used to begin a "find" process, and in another program as a command to jump to the "first" line of the file.  As the full-screen method of text editing became more standard, the command-line type of interface became less commonly used.
 

SOFTWARE EVOLUTION: MENUS

     As mentioned above, one of the problems with the command-line method was the requirement for the user to have a good memory for the names of the various commands necessary for the program to function.  If the command name was typed incorrectly, or if a specific parameter was omitted or given in the wrong order, an error message would appear, causing great anxiety and hand-wringing to those who were still trying to overcome their fear of using a computer.  As an alternative for certain functions in a program, the concept of "menus" became more popular (and was actually used as early as the Apple Color Demo program that came on cassette with the first AppleII's).  A menu was simply a list of possible functions a program could carry out.  It still often used a command style prompt ("Type choice") to allow entry of the desired item on the menu, but gave a little more ease-of-use since a specific command name did not have to be memorized.  A further enhancement of this style of program construction was called a "magic menu", after a sample program written in BASIC and distributed by Apple.  In this type of menu, the user had the option of typing the number of the desired menu entry at the prompt, or he could use the arrow keys to move a large inverse bar up and down the menu to that item.  After selecting the item with the arrow key, it was executed by pressing the RETURN key.  This came to be known as the "point and shoot" method of command selection.

     AppleWorks (which will be discussed in detail later) took the "magic menu" interface to its highest form, adding the metaphor of "file cards".  One menu appeared on the screen enclosed in a box, with a "tab" on the top left of that box.  This box resembled a 3x5 file card.  When a selection was made from the menu, another file card would appear on top of the previous one, slightly down and to the right, leaving the tab on the lower box still visible.  This allowed stacking of menus, with a clear path identifying which menu led to the current menu.  The ESC (escape) key was used to "back up" one level, erasing the menu card on top and re-drawing the menu card underneath it.  Also, prompts were displayed on the top line of the screen that told where ESC would take you, and what function was currently being executed.  Part of the success of AppleWorks stemmed from its ease of use in this respect.  Not only were there no cryptic commands that had to be remembered and typed, but the use of special command keys was reserved for advanced use of the program.  And when such special keys were needed, a standard "help" screen was available for quick reference.  It was possible to do quite a bit in AppleWorks without the need of even opening the instruction manual.
 

SOFTWARE EVOLUTION: GRAPHIC USER INTERFACES

     One thing necessary to make computers easier for people to use was to overcome both the fear problem and the frustration problem.  Those who were inexperienced in the use of computers were often afraid that they would press a button that would cause something terrible to happen.  If they overcame the fear problem, they still had to face the frustration of trying to decipher cryptic error messages ("*** TOO MANY PARENS" or "$27 Error"), or lack of success in getting the computer program to do what they wanted it to do.

     Adding familiar things to the screen, like the file card menus in AppleWorks, made the fear factor diminish.  Making the keys that controlled certain features of that program work consistently from the word processor to the database to the spreadsheet decreased the frustration factor even further. But there were still barriers to overcome in making computers easier to use.

     When Lisa appeared on the scene in 1983, and Macintosh in 1984, computer users were exposed to a radically new concept in computer software.  These computers lacked the previous standard of typed command input to control programs.  Instead, they used a bit-mapped graphics screen to represent a desktop, with pictures (called "icons") that represented a program to run or a file to load.  It took the "point and shoot" interface to the limit; you used the mouse to move a pointer on the screen onto an icon representing that program, and then "click" on it to start the program!  For more complex control, the Mac used a variation on the "magic menu" system:  A "menu bar" at the top of the screen gave a list of command words, arranged horizontally on the same line. Pointing to one of the words and holding down the mouse button would cause a menu to "pull down" like a window shade, displaying several further options available.  The desired choice on the menu could be highlighted by moving the mouse to that item (such as "Delete") and the command would be executed.  This approach made use of the Lisa and Macintosh considerably easier for the novice computer user, although some commands were also given keyboard equivalents similar to the old "Ctrl" key commands, so a more experienced user could execute some of them without having to take his hands off the keyboard.  If AppleWorks could be considered easy enough to use without opening the reference book, this graphic user interface (GUI) was even more so.  It also provided a standard environment that all programs written for the Mac could use, making it easier to learn how to use a new program.

     Although the 6502 processor did not have the horsepower of the 68000 in the Mac, some programs began to appear for the AppleII that tried to make use of the same concept of overlapping windows, pull-down menus, and a mouse (or joystick) driven pointer.  Quark released a program selector called Catalyst that used a similar graphics-based desktop, icons for files, and the point-and-click method of file execution.  It was included with some of the early UniDisk 3.5 drives, and on Quark's hard drives.  Another company, VersionSoft (from France) had a program called MouseDesk, which was distributed in America by International Solutions.  MouseDesk worked just a bit better than Catalyst, but did not do very well as a standalone product, especially with Catalyst being given away free with the new UniDisk.  Eventually, International Solutions made MouseDesk available for only ten dollars via mail-order, hoping to get it into general enough use that their other graphic- and mouse-based products would sell better. Although that did not happen, International Solutions did eventually sell the rights to distribution of MouseDesk over to Apple Computer.  Apple then modified the program and included it with as a rudimentary desktop (modeled after the Macintosh Finder) for their first versions of ProDOS 16 System software for the AppleIIGS.

     With the release of the IIGS, it became possible for better GUI software to be produced for the AppleII.  The 65816 processor had a bit more power, and the IIGS provided a better quality graphics environment (via its super hi-res mode) and more available memory than was possible on the older 8-bit AppleII's.
 

SOFTWARE: APPLE'S GREATEST HITS

     It is beyond the scope of this writing to go into much detail about the many programs released over the years, as the sheer volume of them since 1977 is enormous.  Even a brief mention of them all could become a book in its own right, but Appendix A contains a listing (in moderate detail) of popular software released over the years.  In this segment here I will address in a little more detail three programs that have been particularly influential in the AppleII world:  VisiCalc, Apple Writer, and AppleWorks.

     By 1980, the AppleII software market had fairly well established itself. This allowed users of the computer to no longer have to write their own programs, but instead move on to simply being able to use them.  Softalk magazine, which began in that year, had started nearly from the beginning with an analysis of top selling software of the day.  In their second issue (October 1980) their bestseller list first appeared, with the top thirty software programs ranked based on actual sales information obtained by polling retailers across the country.  In that first list the top selling program was VisiCalc.
 

SOFTWARE: VISICALC

     A major part of the answer to the question, "What can I do with this computer?" lies in whether or not the software program in question is so important or useful that it literally sells the computer.  Robert X. Cringely, in his book "Accidental Empires", put it this way: "VisiCalc was a compelling application-- an application so important that it, alone justified the computer purchase.  Such an application was the last element required to turn the microcomputer from a hobbyist's toy into a business machine.  No matter how powerful and brilliantly designed, no computer can be successful without a compelling application.  To the people who bought them, mainframes were really inventory machines or accounting machines, and minicomputers were office automation machines.  The AppleII was a VisiCalc machine."

     Visicalc was a way of using a computer that no one had ever thought of before, especially at the time when most computers were mainframes with limited access to the "average" user.  VisiCalc was written by Dan Bricklin, a programmer that had decided to enter Harvard Business School in the fall of 1977 and learn a second profession.  Because of his programming background, he saw ways in which some of his class work could be simplified through the use of computers.  He wrote programs in BASIC on the college time-sharing system to do his financial calculations, but found it tedious to have to re-write the program to deal with each new type of problem.

     In a class that dealt with business production, Bricklin learned that some companies used long blackboards (sometimes stretching across several rooms) that were divided into a matrix of rows and columns.  Each row and column had a specific definition, and calculations were made based on the contents of each cell (the intersection of a row and a column).  If the value of one cell changed, the values of any cell that made use of the first cell's value also had to be changed.  Because this was all written on a blackboard, the results had to be checked and re-checked to make sure that something hadn't been missed when changes were made during a planning session.  Bricklin conceived of a computerized approach to this production and planning matrix.  Even though the computer could not display the entire matrix at once, the video screen could be used as a window on a part of the matrix, and this window could be moved at will to view any part of it.  Best of all, the computer could keep track of all the calculations between the various cells, making sure that a change made in one place would be properly reflected in the result of a calculation in another place.

     Over a single weekend he wrote a program in BASIC that demonstrated this concept.  This demo program was rather slow and could only display a single screen of cells, but it was enough to illustrate the concept.  Bricklin teamed up with a friend from MIT, Bob Frankston, and together they looked for a publisher for the program.  They found Dan Fylstra, who had graduated from Harvard Business School a couple of years earlier and had started a small software company called Personal Software, which he ran out of his apartment. Fylstra's primary product at the time was a chess program for the AppleII, and he was preparing to release the first commercial version of the adventure game Zork.  After he heard what Bricklin and Frankston had in mind, he agreed to help them out.  Fylstra loaned an AppleII to them as a platform on which to develop a more full-featured (and faster) machine language version of Bricklin's program. During 1978 and 1979 they worked together, as time permitted, with Bricklin doing the program design and Frankston writing the code.  (One design contribution made by Frankston was the idea of using "lookup" tables, which he wanted so he could use the program to calculate his taxes).  They did most of their development work on an AppleII emulator running on a minicomputer (much as Apple itself had used a local time-sharing computer for development of the original AppleII Monitor program).  They named their program "VisiCalc", and by October 1979 it was ready for release.

     At first, VisiCalc was not a big hit.  When most customers at computer stores were shown what the program could do, they didn't really grasp the concept behind it well enough to appreciate its possibilities.  When business customers who had some computer knowledge came in and saw the program, however, they immediately saw that it could simplify much of what they did.  VisiCalc actually sold AppleII's to many customers, and these businessmen managed to sneak the new computers onto their desks (despite company policies that discouraged use of anything but the company's mainframe).  The combination of the AppleII's ability to expand its memory up to 48K, and the new DiskII drive to use for quick and easy data storage and retrieval, made VisiCalc an ideal program to sell potential users on this new computer.

     Although executives at Apple Computer had been shown a pre-release version of VisiCalc, they also did not really understand the potential of the program. Trip Hawkins, an Apple employee responsible for developing plans to help sell computers to small businesses, could see that this could become a major selling point for getting AppleII's into those businesses.  He negotiated with Dan Fylstra about the possibility of Apple purchasing from Personal Software all rights to VisiCalc (thus locking up the market in Apple's favor).  However, Apple's president, Mike Markkula, felt that the $1 million in Apple stock offered by Hawkins was too expensive and cancelled the deal.  If his decision had been otherwise, the future of the microcomputer industry might have been quite different; however, Apple was headlong in their push to create their next product, the AppleIII, and a million dollar investment in an untried program for this "aging" AppleII was not in their agenda at the time.

     Bricklin and Frankston had themselves formed a company called Software Arts, and it was this company that had contracted with Fylstra's Personal Software.  As part of their arrangement, they were obligated to create versions of VisiCalc for many other microcomputers, from the TRS-80 to the Commodore PET and eventually to the IBM PC.  As sales of VisiCalc grew by leaps and bounds, Personal Software (and Software Arts) became quite wealthy.  To more closely identify his company with his flagship product, Fylstra changed its name form Personal Software to VisiCorp.  He also hired other programmers to write companion software to extend the usefulness of VisiCalc.  These included VisiFile (a database system), VisiSchedule (capable of creating critical path PERT schedules), VisiCalc Business Forecasting Model (a set of business templates for VisiCalc), and VisiTrend/VisiPlot (graphs, trend forecasting, and descriptive statistics).

     But despite these additional products, VisiCalc continued to be VisiCorp's cash cow.  This, ironically, led to the company's biggest problem, centering around a disagreement about money.  VisiCorp's contract with Software Arts guaranteed Bricklin and Frankston a hefty 37.5 percent royalty on each copy of the program that VisiCorp sold.  VisiCorp was responsible for marketing and distribution of the program, but it was Software Arts who owned the rights to it, and they had no motivation to change their contract to decrease the royalty percent to a number that was more typical for programmers.

     The problem escalated when VisiCorp filed a lawsuit seeking damages because Software Arts was supposedly late in providing them upgrades to VisiCalc. Software Arts countersued, and demanded back the rights to distribute the product themselves.  Further complicating matters was the fact that the name "VisiCalc" was a copyright of Software Arts, but a trademark of VisiCorp.

     By early 1985, things had worn on to the point where Bricklin decided to end the battle by selling the rights to VisiCalc-- but not to VisiCorp. Instead, Mitch Kapor, who ran the Lotus Development Corporation, purchased the program. Kapor had previously worked for VisiCorp, and had helped write VisiTrend/VisiPlot.  After he sold the rights for those programs to VisiCorp, he began design on a spreadsheet program that would run specifically on the IBM PC, with the additional features of limited word processing and the ability to create graphs.  His program, Lotus 1-2-3, worked as well on the IBM PC as the original VisiCalc had on the AppleII (the ports of VisiCalc to other machines had never been quite as good as the original), and Lotus eventually captured the spreadsheet market on the IBM.  In fact, it became the "compelling application" that helped push that computer platform into prominence.  It had, however, made a significant contribution to decreased sales of VisiCalc, and after Lotus succeeded in purchasing it from Software Arts, VisiCalc quietly disappeared from software store shelves.
 

SOFTWARE: APPLE WRITER

     This was certainly not the first word processor for the AppleII, but it was one of the most popular.  During the four years that Softalk magazine was in print, Apple Writer rarely (if ever) disappeared from their best selling software list.  Even if it was not in the Top Thirty, it usually held some spot on their list of top Word Processors.

     The original version was released in 1979.  Apple Writer 1.0 had to deal with the limitations of the AppleII in the form of its uppercase-only keyboard and 40-column display.  Clearly, a document produced on a computer could be uppercase only, but it was more valuable if it could look more like that produced on a typewriter.  To achieve entry of upper and lowercase characters, Apple Writer used inverse text to display uppercase, and normal text to display lowercase.  When entering text, an uppercase letter was entered by pressing the ESC key once.  This changed the usual cursor box to an inverse caret (^), and the next letter entered would be uppercase (displayed in inverse).  If the ESC key were pressed twice in a row, the cursor changed into an inverse plus sign (+), and was now an editing cursor that could be moved through the text.

     The IJKM diamond on the keyboard was used to move the cursor, just as it was used for moving the cursor for editing lines of BASIC programs.  Although the box cursor used in Apple Writer looked just like the flashing box also used in Apple BASIC, this cursor "floated" through the text instead of sitting on top of a character.  If you moved it through the word "AND", it would look like this as it went from left to right: *AND  A*ND  AN*D  AND*.

     This original version of Apple Writer actually consisted of two separate binary programs: TEDITOR and PRINTER.  The first program was used to actually edit the text, and the second one would print the files created by the TEDITOR. In its first release, Apple Writer had two problems that bothered some early users of the program.  One was that the files created by the program were Binary files (instead of Text files), apparently as a means to speed saving and loading files under Apple DOS.  Although it worked fine for Apple Writer, the files could not be used by any other program.  The other problem had to do with the way in which it used (or misused) the ASCII character set.  The AppleII, you may recall, used the upper half ($80-$FF) of the ASCII set for its screen display of "normal" characters (much of the rest of the microcomputer world tended to use the lower half), and used the lower half ($00-$7F) for flashing and inverse characters.  In the upper half, the characters from $80-$9F were designated as control characters (generated by pressing the "Ctrl" key with a letter key), $A0-$BF were special characters and numbers, $C0-$DF contained the uppercase alphabet and a few more special characters, and $E0-$FF repeated the characters from $A0-$BF (this is where the lowercase letters should have been, according to the ASCII standards).  Since the lowercase ASCII characters were unavailable, the AppleII video routines translated any characters in the $E0-$FF range into characters in the $C0-$DF range, making them displayable on the uppercase-only screen.  Apple Writer, for some reason, used the $C0-$DF range internally for display of uppercase letters (which was standard) and the $E0-$FF range for special characters and numbers (instead of using the $A0-$BF range).  When some users began plugging different ROM characters chips (like the Paymar chip) into their AppleII Plus computer, they found that Apple Writer wouldn't display text properly.  The number "3" appeared as a lowercase "s", and "%" as an "e".  A special patch was soon developed to intercept Apple Writer's text output to the screen and make the correct translation to display lowercase as lowercase, and numbers and special characters where they were supposed to be.

     Apple Writer 1.0 ran from 13-sector DOS 3.2 disks, and the binary files it produced had names that began with the prefix "TEXT." (a file named "LETTER" would appear on disk as "TEXT.LETTER").  Apple Writer 1.1 was released in 1980 when DOS 3.3 became available.  It ran under the newer 16 sector format, and contained some minor bug fixes.  This version also had available a companion spell checker called Goodspell.

     The next version released was called Apple Writer ][.  This one came out in 1981, was copy-protected, and still ran on an AppleII Plus under DOS 3.3, but now produced standard Text files instead of the older Binary files, and could properly display 40-column lowercase characters when the character generator ROM was replaced.  It also supported 80-column text if a Sup-R-Term card was plugged into slot 3.  In 40-column mode, words would now "wrap" to the next line if they were too long to display on the current line (the older versions of Apple Writer appeared to split the word and continue it on the next line).  The ESC key was still used as a pseudo shift key (one press) and to enter editing mode (two presses, displayed as an inverse "@" instead of the "+" in previous versions), but the keyboard SHIFT key could be used to enter uppercase characters if the "shift key mod" was performed (recall that this connected the shift key to the input for button 3 on the game paddles).  Other new features included a glossary and the Word Processing Language (WPL).  In modern terminology, WPL was a macro or scripting language, making it possible to automate nearly everything the program was capable of.  A WPL program could create templates like form letters, or could be used for entry of repetitious text (such as your return name and address for correspondence).

     Apple Writer //e, also copy-protected, came next in 1983 with the Apple IIe.  This took advantage of the features of the new IIe (such as the built-in 80 column display and full keyboard).  It also included improvements in tabbing (since a TAB key was now available on the keyboard), could create larger text files (these could be larger than the size of memory, by loading just a segment of the file into memory at one time), could "print" text files to the disk, could directly connect the keyboard to the printer (to use like a typewriter), and had improvements in the WPL language.  When the AppleIIc came out, users of this version of Apple Writer had some problems, as the inverse status line at the top of the screen displayed uppercase characters as MouseText; however, patches quickly appeared to remedy this situation.

     The first version to run under the ProDOS operating system was called Apple Writer 2.0.  It came out in September 1984, was not copy-protected, and it fixed the MouseText problem.  It also allowed the user to set right and left screen margins, giving a closer approximation of the final appearance of the printed text.  This version also had the capability of connecting the keyboard directly to the printer or to a modem, allowing it to be used as a rudimentary terminal program.  This version had some problems with properly printing to certain third-party parallel printer cards (such as the Grappler).

     One annoying "feature" that was added to this version (and was also present in a couple of other Apple-distributed programs, AppleWorks 1.3 and Instant Pascal) was that it did not follow Apple's published protocols in properly handling slot 3 RAMdisks (or other disks).  Since some programs used all 128K memory that could be present in a IIe or IIc, Apple had given guidelines in one of their Technotes on how to properly "disconnect" the 64K RAMdisk (which was designated as slot 3, drive 2) so all 128K would be available to the program. Apple Writer and the other two programs mentioned above had been written so that they disconnected any slot 3 disk device, whether a RAMdisk, hard disk, or a genuine Apple disk.  It is not clear as to why this had been done, although it was suspected in publications at the time that someone at Apple had done this so memory cards not made by Apple would fail to work.  Some of these memory cards had been made to also work in slot 3 but to not interfere with the official 128K of program memory.  Their manufacturers had worked to follow Apple's published standards, and then had been bypassed by what appeared to be programming arrogance.  Patches to make these programs work properly appeared when the problem was identified.

     Apple Writer 2.1 appeared in late 1985.  It contained some minor bug fixes, including the above-mentioned problem with some parallel printer cards.  The 2.0 version had printed characters as low-ASCII (values $00-$7F), which caused a problem with some kinds of interface cards and printers.  Version 2.1 changed this so characters were printed as high-ASCII ($80-$FF), although files printed to a disk file were saved in the original low-ASCII format.  This version also was not copy-protected, making it possible to easily install on a 3.5 disk or hard disk.

     When AppleWorks appeared on the scene, Apple Writer began to decrease in popularity; however, old time users did not like AppleWorks as well as Apple Writer, primarily because it put a layer of "protection" between the user and the program.  This made it easier for the computer novice to immediately put the program to use, and less likely to do something that would "mess up" his printer or interface card internal settings.  That same protection also made it harder to do specialized jobs.  For example, where Apple Writer would allow entry of control characters (which allowed very specific control of printers and their interface cards), AppleWorks was much more restrictive in this sense, handling more of the details of printer control internally.  Apple Writer's power made it possible to even create documents on Postscript laser printers (as demonstrated by Don Lancaster in his Computer Shopper column, "Ask The Guru"), something that all the computer experts claimed was not possible on an AppleII.  Where Apple Writer allowed an experienced user to use all features on a printer and interface card to the maximum, AppleWorks was more dependent on the printer and card already knowing how to be cooperative with it.  The same thing that gave Apple Writer its power also made it harder to user for less skilled users, who probably found intimidating its nearly-blank screen with no prompts or instructions visible.

     For several years, from around 1988 through 1992, Apple Writer was not very available except as a used program.  The exact reason for this is not clear. One reason probably had to do with the better-selling AppleWorks, which had the additional features of a spreadsheet and database.  But with its Word Processing Language, Apple Writer was still more suitable for certain jobs than was AppleWorks; and yet, Apple simply stopped upgrading, distributing, and supporting it.  But in the summer of 1992, one of the Sysops on GEnie's Apple (A2) Roundtable, Tim Tobin, was successful in contacting Paul Lutus.  Tobin was coordinating a project that A2 had started to try to locate and revive the availability of "Lost Classics", programs that had ceased publication (often because their distributor had gone out of business), and recovering Apple Writer was high on his list.  Lutus agreed to make his program available on a "freeware" basis:  It could be copied freely and given away, but could not be sold for a profit.  (This arrangement was quite similar to an earlier program Lutus had written, FreeWriter.  He had released this program as freeware in 1984.  FreeWriter was very much like Apple Writer, except it did not have a built-in ability to print the documents it created, and it did not have WPL). This new, free distribution was possible because although Apple Computer held the copyright on the Apple Writer documentation, Lutus had retained the copyright on the program itself (Apple had held the copyright on versions 1.0 and 1.1 of the program).  Although the program is based on older technology, and does not take advantage of the larger memory sizes frequently available in the AppleII's of today, it still is powerful and is a welcome addition to any software library.
 

+++++++++++++++++++++++++++++
 

APPLEWORKS

     There is one program in the Apple II world that has not only showed amazing staying power in a world where this year's software hit is next year's yawn, but has also gone on to spawn a number of software companies and magazines that do nothing else but sell products for it.  That program is AppleWorks.  Originally released in 1984 by Apple Computer, it has gone on to become one of the best selling computer programs of all time, on any computer.  Although few seem to mention the influence it has had, it is evident in the number of computer programs that have come out for the IBM and Macintosh that have the "Works" name on them (Microsoft Works, ClarisWorks, Beagle Works, and others).  AppleWorks was one of the first "integrated" software packages, preceded on the Apple II only by The Incredible Jack (published by Business Solutions, 1983; see Appendix A).  It put modules that performed word processing, database management, and spreadsheet calculations into a single environment, using similar commands in each module.  Previous software programs specialized for each of those jobs had their own unique keyboard commands that were often very different from each other.  If you went from Apple Writer to VisiCalc, or from VisiCalc to DB Master, you had to learn a completely different method of controlling the program.  Furthermore, the data files created by those programs were usually not compatible with each other, making it difficult and awkward to move information directly from one program to another.  AppleWorks not only created a continuity between these modules, but went a step beyond in allowing them to share data with each other via a space of memory called a "clipboard".  This clipboard was part of a larger memory area called a "desktop", which could hold data for up to twelve different files at the same time, which made data sharing even more convenient.

     AppleWorks was written by Rupert Lissner (who later changed his name to "Robert".)  Its earliest incarnation was in another product sold by Apple, called QuickFile.  QuickFile was an Apple III database program written in Pascal.  It was flexible and easy to use, and Apple agreed to market it for Lissner in 1980.  It was later translated into a version for the Apple IIe (also in Pascal) called QuickFile IIe.  As a database program it was flexible and powerful, but somewhat slow due to the inherent limitations of the UCSD Pascal system that Apple favored at the time.

     After seeing the Office System on the Lisa computer, Lissner conceived the idea of a single program that would put word processing, database, and spreadsheet capabilities together, and run on an Apple II.  It was originally called "Apple Pie", and he began work on it in 1982.  Lissner took two years to complete his program, and did it entirely in assembly language to achieve better speed.  He wrote versions of the program to work on both the Apple II and Apple III computers, making use of the same filetypes and data structures.  Apple Pie files created on an Apple II could be used on an Apple III, and vice-versa.

     Apple decided to market the Apple II version themselves, and called it "AppleWorks".  Lissner was left with the rights to the Apple III version.  He sold those rights to Haba Systems, who brought it out under the name, "/// E-Z Pieces".  That program continued to be compatible with the Apple II version up until Claris (the software company formed by Apple in 1987) upgraded AppleWorks to version 3.0 in 1989.
 

A STAR IS BORN

     When it was finally released, AppleWorks was one of the most comprehensive programs ever written for the Apple II.  Although neither of the three modules were significantly more powerful than other standalone programs, they had enough power for the average computer user to do what was needed.  The memory management system was the extremely flexible, eventually being able to handle not only the basic 128K on a IIe or IIc, but also several different types of memory cards used on those computers and on the IIGS.  Far larger than the memory of the 64K Apple IIe on which it would run (as a minimum memory configuration), the program was smart enough to swap in or out from disk the parts it needed to carry out its various functions.  Considering that it would run on a computer whose microprocessor could address only 64K of memory at one time, the power achieved by this program is remarkable.  There are few other software packages ever released that have as smoothly and seamlessly made up to two megabytes of memory on an 8-bit computer appear to be one contiguous space.

     AppleWorks' user interface was designed with menu bars, rather than the older command line interface (such as the one used in Applesoft, Integer BASIC, and the Monitor).  Apple's own researchers had put human subjects in front of a computer keyboard to learn what was easiest to use.  They designed an interface that was based on using arrow keys to move a cursor (or "bar") to different choices in a list, and then using the return key to make the selection.  They also came up with the concept of the "desktop" (represented in text rather than in graphics as on the Lisa and Macintosh), and a "clipboard" for transferring data between files.  Apple shared this information with Lissner, and he went on to use it in his program design.
 

APPLE'S "PROMOTION" OF APPLEWORKS

     The marketing decisions made concerning AppleWorks have not been very clear to the outside observer over the years.  At the time that AppleWorks was ready for release there was a considerable amount of company money and time being spent in trying to make the Macintosh sell in the computer marketplace.  Those who had the most influence at Apple were not very interested in a "simple" text-based program, when the Mac and its graphic interface was the "cutting edge" in technology.  Those people believed that the Mac represented the future of Apple, and were not interested in wasting time with old Apple II technology in any form.

     Another problem was Apple's past record in selling software.  Tom Weishaar made these comments in the November 1987 issue of Open-Apple:
 

"...Apple was trying very hard to get the big MS-DOS developers to work with the Macintosh.  One of the reasons these developers gave for their reluctance to work on the Mac was their fear that Apple itself would compete with them-- Apple, obviously, had tremendous advantages in terms of distribution and access to inside information.  Apple had a reputation for developing applications software for its machines that would kill the market for similar software-- Apple Writer (which was at the top of the Apple II software charts at the time) and a complete set of applications software for the Lisa being major examples. Powerful voices inside Apple wanted the company to get out of the applications software business."
 

     However, despite the concern about Apple selling AppleWorks, the decision was eventually made.
 

"Apple's punishment for its indiscretion was immediate-- within six weeks its illegitimate child sat at the top of the Apple II best-seller list.  AppleWorks achieved this without the benefits of a mother's love-- it succeeded in spite of, not because of, Apple's meager marketing efforts in its behalf.  Since AppleWorks was released, for example, Apple has run 26 pages of ads in A+ magazine.  The word "AppleWorks" appears in those ads exactly zero times.  Four of the ads show screen shots of AppleWorks... the Apple IIGS ad in the September 1987 A+ [shows a screen shot of] AppleWorks... in the gutter between the pages and is the only one of the 23 programs shown that isn't mentioned by name.  This is typical of the treatment Apple's bastard child gets from its mother.  [Del] Yocam, [Apple's Executive Vice-President in 1987], didn't mention it or Lissner in his birthday speech [at the 1987 AppleFest, celebrating the tenth anniversary of the Apple II], and John Sculley, Apple's president, doesn't mention it or Lissner in his... book, Odyssey."
 

     When it first appeared on the market, AppleWorks started at number 2 on Softalk's top thirty list.  It moved to the number one spot in Apple sales by the following month, and stayed there for a long time.  By the end of 1984, AppleWorks had moved into the number one spot in monthly retail software sales for all computers, overtaking the MS-DOS best-seller Lotus1-2-3 (a spreadsheet program with graphics and rudimentary word processing capabilities).  But since it was not their beloved Macintosh that put an Apple program into first place, corporate Apple ignored the milestone.  Since that time, though no longer in first place, AppleWorks has continued to do very well, despite an absence of advertising on the part of Apple, and despite later minimal advertising on the part of Claris.
 

APPLEWORKS REVISIONS

     The first change to AppleWorks came with the released of version 1.1 in 1985, which was a modification to help overcome problems with non-Apple printers and interface cards.  Later that year version 1.2 came out with the ability to use more easily even more of this non-Apple hardware.  Both of these relatively minor updates were made available free of charge to existing owners of the program.

     Version 1.3 of AppleWorks came out in early 1986 for a $20 update fee.  It provided a bit more functionality for those users who had larger capacity disk drives.  Specifically, it better supported the new UniDisk 3.5 for file storage and made it possible to format disks on that device.  Previous versions could load files from 3.5 disks only by specifying the ProDOS pathname; version 1.3 could access these disks with the more familiar slot and drive numbers.  Also, since Apple now sold a large memory card which would plug into any free slot on the Apple IIe, this new version of AppleWorks could expand the size of the desktop to as much as 1,012K.  By this time, Applied Engineering and other companies had already been doing quite well selling RAM cards for the auxiliary slot on the IIe, and had also included special software that patched previous AppleWorks versions to allow a larger desktop.  They went further than Apple, however, in also allowing larger word processing and database files to be created.

     Up through the release of AppleWorks 1.3, the only changes that had been made were bug fixes and enhancements to work better with new hardware.  In September 1986, along with announcements about the new Apple IIGS, Apple released version 2.0 of AppleWorks.  It now required a minimum of 128K (previous versions would work with 64K, but allowed only a 10K desktop).  In exchange for the greater memory requirements, it gave users a built-in ability to do mail merge, added more functions to the spreadsheet, and supported Apple memory cards even better than v1.3.  Furthermore, word processing, database, and spreadsheet files could be larger than in previous versions.  Existing users were able to upgrade to v2.0 for $50, which included a completely new manual, a very reasonable price considering the extra abilities of this new version.

     July 1987 saw one change that had an impact on future distribution of AppleWorks.  Apple decided to create a separate company, called "Claris", to handle some of the popular software that they had released for their Apple II and Macintosh computers over the years.  As mentioned above, products released by Apple had a tendency to be the "kiss of death" for third-companies trying to market similar programs.  For example, after the outstanding success of AppleWorks, virtually no text-based work processors released for the Apple II made much of an impact on the market.  Claris had the responsibility of handling AppleWorks, Apple Writer, and the various Macintosh programs that had been available from Apple for that computer.

     Claris has publicized AppleWorks via only three major ads since they took the product over from Apple (of course, previously AppleWorks had received no advertising space).  Their first promotion, run in 1987, stated that AppleWorks2.0 had received a very unique upgrade--its own company.  This was primarily a plug for Claris, of course.  The second ad was rather clever.  This one had a white background with a red sports car up on blocks with its wheels missing.  The caption read, "There are still some Apple II users who don't have AppleWorks", suggesting that working without that program was like owning a sports car without wheels.  Beagle Bros did an even more clever followup to that ad, by using another double-page spread with a white background, and four tires in the same location as the blocks in Claris' ad.  Their ad read, "There are still some AppleWorks users who don't have TimeOut", suggesting that the sports car in the Claris ad was AppleWorks, and TimeOut was the wheels for that car. The third promotion run by Claris for the program was to announce the v3.0 upgrade in 1989.  This one showed an old worn tennis shoe (representing the old version) and a new running show (representing the new version).

     A free update of AppleWorks to version 2.1 was released by Claris in September 1988.  It provided IIGS users some bug fixes that made it work better on that computer, plus it was supposed to support a desktop as big as eight megabytes, if that much memory was installed.  However, because of the way in which desktop memory in AppleWorks was handled, this turned out instead to be a maximum of two megabytes.  No further functionality was added to AppleWorks at that time.
 

APPLEWORKS 3.0

     In 1988, while Claris was issuing its minor update to AppleWorks, they were making plans to do some major improvements to the program.  Since they primarily had Macintosh programmers working for them, they first asked Robert Lissner, the original author.  He wasn't much interested, since he had already made good money off the program and didn't really have the motivation for such a proposal. Claris then decided to turn to a third-party company to do the work.  There were planning to hire a company called Pinpoint Publishing to do the work.  Pinpoint was selling an enhancement package for AppleWorks that gave users some features that MS-DOS users had available on their computers, and seemed to be making a major effort to promote their product and stimulate more sales of AppleWorks. By this time, however, Pinpoint was financially getting into trouble, with sales of their products (AppleWorks-related and otherwise) below what was needed to support the large user support network they had set up.  Consequently, they were eager for the chance to contract out to Claris for the AppleWorks upgrade. However, they planned to make very minimal changes to it, staying exclusively within Claris' specifications.

     During this time, Claris kept hearing from AppleWorks users who were much more loyal to Beagle Bros, who had a series of products called TimeOut.  These products worked in a fashion similar to those from Pinpoint.  After some complicated negotiations that nearly fell through several times, Beagle finally took on the job to do the AppleWorks project for Claris.  Beagle programmers Alan Bird, Randy Brandt and Rob Renstrom worked on it for almost a year, in between a few other projects that were going on at the same time.  They did their work on MacintoshII computers running the MPW (Macintosh Programmer's Workshop) cross-assembler, primarily for the sake of speed.

     As enthusiastic AppleII programmers who also knew AppleWorks inside and out, Beagle's team added a lot of power Claris had not planned on in their original specifications.  Occasionally they called on Lissner for help in understanding why certain parts of the code were written as they were, but all of the work came from these "Beagle Boys".  Viewing it almost as a labor of love, they went beyond what they were asked to do, and enjoyed making AppleWorks into a program that they would want to use.  Randy Brandt stated, "I think it's safe to say the AppleWorks3.0 project yielded the worst hourly rate I've ever made in AppleWorks-related programming, but it did give me a lot of insight which came in handy on future projects."

     Additionally, they fix over one known hundred bugs in AppleWorks2.1.  In June 1989, Claris announced the AppleWorks3.0 upgrade at the National Educational Computing Conference in Boston.  The features that were added or improved are too numerous to describe here; in brief, it added nearly all the things users had wanted the program to do.  It was easier to use, it took better advantage of extra memory (going beyond the two meg limit on the IIGS), and it was easier to customize special printers to work with it.  And it included a new feature that was becoming standard in many commercial word processors:  A built-in spelling checker.  Because of these extra features, the maximum desktop size on a standard 128K Apple II was now reduced to about 40K (down from the original 55K).  Also, the program now loaded from two double-sided 5.25 disks (or a single 3.5 disk), instead of the previous one double-sided 5.25 disk.

     Apple had for years included registration cards with their products, both hardware and software, that was to identify the user in Apple's files as an owner of that product.  Unfortunately, although they had done a good job at including those cards with everything they shipped out, they had done a somewhat less satisfactory job of actually compiling the data from those cards. Consequently, Claris really had no available information about who was and who was not a "registered" owner of AppleWorks.  They decided that they would make an initial upgrade offer of $79 for customers that owned any previous version of AppleWorks (from v1.0 to v2.1), and through A2-Central magazine they even made available a special $99 offer:  An A2-Central subscriber could get the program from Claris for that price, even if he could not prove previous ownership of AppleWorks.  Later, owners of previous versions could still upgrade for $99 if they wanted.

     Unhappily, Claris has since concentrated almost exclusively on Macintosh products and apparently has no plans for further updates or upgrades to AppleWorks.  This is unfortunate, since there are several known bugs in the program, and Beagle Bros programmer Mark Munz eventually decided to release his own AppleWorks bug-patcher program into the public domain to correct these known problems.  Rather than take the hint and make a v3.1 release to officially acknowledge and correct these problems, Claris simply waits until a customer complains about them and then directs them to Mark's Patcher program.
 

ENHANCEMENTS: PINPOINT

     AppleWorks has been such a major influence in the Apple II world that the program has itself spawned a number of related products that act to enhance or expand its usability for different purposes.  This is a reflection on the widespread penetration of the program, as well as the desire of Apple II users for more and better features.

     One of the first customization features that appeared for AppleWorks was from a company that called itself Pinpoint Publishing.  They had originally been called Virtual Combinatics, and had sold a program for the Apple II called Micro Cookbook.  Suddenly in 1985 they burst upon the market with a new name and a significant new product.  Their Pinpoint Desk Accessories was primarily an enhancement for AppleWorks, though it was also possible to install its features for use under Applesoft, and eventually Apple Writer and Word Perfect.  Taking after the popularity of "pop-up desktop" programs for the IBM PC like Sidekick, Pinpoint added some similar features to AppleWorks.  These features were available at any time, simply by pressing solid-apple and P (option-P on the IIGS).  At this point a little "Accessories" menu would pop-up onto the screen, drawn using MouseText characters, and the desired feature was selected by moving the cursor bar up and down the list, pressing RETURN for the one you wanted (working just like AppleWorks).  The accessories included Appointment Calendar; Calculator; Communications (a small terminal program for use with a modem, which could send AppleWorks word processing files or save incoming text as a WP file); Dialer (just highlight on the screen the number you wanted to call, and it would be dialed for you via the modem); GraphMerge (which allowed you to print a word processing document with all or part of a double hi-res picture included with the text); Notepad (a miniature word processor, holding up to 32 lines of text and saving notes in AppleWorks WP format); QuickLabel (take an address off the screen and place it on an envelope template for printing); and Typewriter (type and print lines one at a time).  This was all very exciting at the time, multiplying the abilities of AppleWorks beyond what it was built to do.  Because of disk-space requirements this was more convenient to use from a 3.5 disk or hard disk, but actually could be used from 5.25 disks without too much trouble. Eventually a spelling checker was also made available to use with Pinpoint.
 

ENHANCEMENTS: BEAGLE BROS AND COMPANY

     The next significant AppleWorks add-on appeared in June 1986.  It was a product sold by Beagle Bros and called MacroWorks. Written by Randy Brandt, this program patched itself into the keyboard-reading routine of AppleWorks and allowed the user to automate certain functions and assign them to a specific key on the keyboard.  Previously, many of AppleWorks features were accessed by pressing either the open-apple or solid-apple (option) key together with another key (recall that the apple keys were nothing more than access to the pushbutton inputs on the joystick).  For instance, open-apple and "C" (oa-C) together were used to start a "copy" function.  Before MacroWorks was patched into the program, either oa-C or sa-C had the same effect.  After adding this enhancement, the solid-apple keys were given their own, separate identity, offering more than double the number of functions that could be executed from the keyboard.  (Pinpoint had done something similar, by taking sa-P for its own purposes).

     A macro was actually a series of keystrokes that could be entered from the keyboard (similar to WPL programs for Apple Writer), but was automated so that a single keypress would activate it.  For example, typing a return address could be assigned to the sequence solid-apple-A (sa-A).  Or sa-S could be defined to save all the files on the desktop and quit the program.  Anything that could be done manually with AppleWorks could be automated with MacroWorks, and it could even do some things that could not be easily done manually.

     The idea of automating keystrokes in AppleWorks was not unique to MacroWorks; soon after, AutoWorks was released by Alan Bird of Software Touch, and Pinpoint Publishing got into the act with their product, Keyplayer.  Brandt upped the ante later in 1986 with an upgrade called Super MacroWorks, which added a few new features and was made to work specifically with the new version 2.0 of AppleWorks.

     It didn't take long for the other companies to come out with enhanced versions of their programs to work with the newer version of AppleWorks.  But the most significant enhancement yet came during 1987.  Beagle Bros had just undergone a change in management, as its founder Bert Kersey retired and merged his company with Software Touch.  Mark Simonsen and Alan Bird, owners of Software Touch, had previously worked at Beagle before leaving to start their own company.  Aside from AutoWorks, they had released enhancements such as SideSpread (which would allow a spreadsheet to be printed sideways on a dot matrix printer) and FontWorks (which allowed word processor files to be printed using different font styles and sizes, using codes embedded in the WP text).  As they merged back into the Beagle fold, they brought with them plans for a series of AppleWorks add-ons and enhancement.  These would be accomplished via a new core program (or "engine", as they called it) called TimeOut.

     Written by Alan Bird, TimeOut installed itself into AppleWorks and interfaced directly with Lissner's remarkable built-in memory manager.  The neat thing about TimeOut was that after the engine itself was installed, adding other modules was no more complicated than copying them over to the disk from which AppleWorks started.  This addressed one of the problems with all of the other enhancement programs available; if they were not installed in the correct order, the patches would begin to step on each other, and crashes were much more likely.  TimeOut provided a clearly-defined protocol for adding new features to AppleWorks without this patching hassle.

     The first TimeOut modules released included DeskTools, FileMaster (which allowed file copying and more), Graph (spreadsheet graphing), QuickSpell, SideSpread (update of the older Software Touch program), SuperFonts (update of FontWorks), and UltraMacros (a more powerful version of Randy Brandt's Super MacroWorks, using ideas from AutoWorks).  More followed in subsequent years, including a thesaurus module and a full-featured telecommunications module that worked within AppleWorks.
 

ENHANCEMENTS: JEM SOFTWARE

     Over the years, Beagle Bros has been a major contributor to the longevity of AppleWorks through its many TimeOut enhancements.  And they did many users a favor by making upgrades available virtually free, through a program they called "Beagle Buddies".  Just contact your Buddy, give evidence that you really owned the program, and he would update UltraMacros from version 3.0 to 3.1, without charge.  The down side of this service, however, was that there was no income received by Beagle for updates, making it financially difficult to pay the authors of those updates for their work.  For this reason, authors like Randy Brandt (one of the AppleWorks3.0 revision authors) have decided to start their own private company for release of other products for AppleWorks.  Through his company, JEM Software, he released PathFinder, which made setting the pathname for the AW "Add Files" menu easier and faster to change.  Although that feature was built in to AW 3.0, Brandt did not stop there.  With the help of Dan Verkade, he created TotalControl, which adds features to the database module that make specific qualifications for the type of entries that can be made in new or existing records.  DoubleData changes the database module so AW can handle twice as many categories per record as it was designed to do.  Mr. Invoice gives the capability of producing invoice-type documents with AppleWorks, and DB Pix adds graphic capability to the database, displaying single and double hi-res and Print Shop/ Print Shop GS graphics.  Brandt also wrote an update to UltraMacros3.1, called Ultra4.0, which added considerable power to the macro language.  All of these add-on programs extend the usefulness of AppleWorks for very specific applications, significantly extending the lifespan of the program.

     Brandt also came up with the concept of "inits" for AppleWorks.  These programs are installed to AW via a small patch that allows it to look for them. Adding an init is simple; it is just copied into a subdirectory called AW.INITS, and any binary program found there with a name that starts with "I." is automatically loaded and patched in at startup time.  These inits range from one that improves the handling of the screen print function built-in to AW, to other much larger applications (TotalControl is added via an init, for instance).  The difference between these inits and TimeOut applications is that inits are always working, whereas TimeOut programs have to be specifically activated to work. Brandt used the same concept of simple extensions when he designed Ultra4.0; more commands (called "dot commands") can be added to the macro language in the same way as other inits.
 

ENHANCEMENTS: PATCHES

     As with other popular programs, there have been many patches that have appeared over the years to customize AppleWorks to do things more to a particular user's likings.  These first appeared as one to several byte patches that would be applied using Applesoft, poking the bytes to memory and then using the BASIC.SYSTEM command "BSAVE" to put them into the right place in the program.  Patches were published in various places to do things like changing the pitch and duration of AW's awful error tone, make it possible for AW to access a disk device in slot 1 or 2 (which it refused to do ordinarily), or make more than one custom printer (not easily done in versions prior to 3.0).  Other patches were published to fix various bugs that were uncovered over time. Eventually, these patches were collected into several different programs whose purpose was to streamline the process.  Randy Brandt, through JEM Software, released Late Nite Patches for AppleWorks2.0.  John Link created a program called SuperPatch that he provided via online services initially, later changed it to shareware as it got more and more massive, and eventually arranged for it to be sold via Quality Computers.  Written in Applesoft, John's program made it possible to not only apply the various patches, but to also remove them neatly.

     Beagle Bros came out with AW 3.0 Companion (later updated to Companion Plus) which allowed not only a large number of useful changes to be made to AppleWorks, but also included a version of Mark Munz' Patcher program to correct some bugs that had made it into the program (and which Claris refused to fix via an upgrade).  The Beagle program followed
John Link's lead by making it possible to remove most patches as easily as they were applied.
 

BEYOND APPLEWORKS

     AppleWorks is probably the most powerful integrated program ever written, in terms of speed (being text-based) and overall useability for a wide range of purposes.  Although Claris did release a IIGS version called AppleWorks GS (which was actually a re-write of an older program, GS Works, which they purchased from Styleware and remodelled slightly), that program is significantly different from AppleWorks and cannot be considered an upgrade.  Claris as a company has shown absolutely no interest in releasing a v3.1 upgrade, even just to fix the known bugs in the program.  Other features that could be added, such as the ones provided via TotalControl or DoubleData or even UltraMacros, could be made a part of AppleWorks out of the box, but Claris' attention is on the Macintosh.  It is highly unlikely that any enhancements beyond those that appeared in version 3.0 will ever appear from Claris; but with prolific authors like Brandt, Munz, and others, additional features that some users want will continue to be available.
 
 
 

Formatting by Ground Apple II FAQs site, 1999