“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 owners had to write their own software to do anything with their shiny new toy. “Commercial” software written by “professionals” was unavailable, except possibly from the company that produced the computer. Ultimately, some of those amateur programmers did a good enough job on their programs that others wanted to buy and use their software, especially if they were good at deciphering the secrets on how the computer worked. Unless they taught themselves assembly language and could figure out the internals of that computer (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 Chapters 16 and 17).
The Apple II 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 Apple II. Other manufacturers, such as Atari (with their models 400 and 800, based on the same 6502 as the Apple II) 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 effectiveness of those budding software authors (who may have later become professional authors).
One example of this corporate secrecy involves the Atari home computer. 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 smart enough to eventually figure out the secrets himself, and became one of the wealthy software “stars” of the late 1970s and early 1980s. Many computer makers 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.
A couple of years after the Apple II was released, the company sent a poster to computer dealers to post, with the title “Will someone please tell me what an Apple can do?”. Underneath that title was a large list of the many games, utilities, and productivity programs that were currently available to use on an Apple II or II Plus. The point being made was that if a potential customer was not sure just how they could use one of these new home computers, that extensive list of software should have made it clear.
SOFTWARE ON THE APPLE II
In the Apple II 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 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.
Call-A.P.P.L.E. logo - Photo credit: Bill Martens
Many of the programs sold by A.P.P.L.E. were popular with Apple II 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. Members of A.P.P.L.E. who had a unique idea wrote programs that others found useful, and contributed them to the club. 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 Apple II, 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.,
Apple Software Bank, Volumes 1&2 and 3&4 - Photo credit: personal
THE COMMAND LINE INTERFACE
Some of the earliest programs available for the Apple II 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 into a computer (like the Apple II) 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 Apple II 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.
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 Apple II computers). 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 1.3 screen shot - Photo credit: personal
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 3×5 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.
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 that fear, they still had to face the frustration of trying to decipher cryptic error messages (“*** TOO MANY PARENS” or “$27 Error”), or some other 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 Apple II 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 Apple IIGS.
With the release of the IIGS, it became possible for better GUI software to be produced for the Apple II. 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 older 8-bit Apple II models.
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. This segment will address in a little more detail three programs that have been particularly influential in the Apple II world: VisiCalc, Apple Writer, and AppleWorks.
By 1980, the Apple II 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.
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 Apple II 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. He was 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 Apple II, 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 Apple II 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 Apple II emulator running on a minicomputer (much as Apple itself had used a local time-sharing computer for development of the original Apple II 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 the Apple II 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 ability of Apple II memory to be expanded up to 48K, and the new Disk II drive to use for quick and easy data storage and retrieval, made VisiCalc an ideal program to sell potential users on this new computer. It also made the Apple II the computer on which to run VisiCalc, as few other personal computers in 1980 had the combination of adequate RAM and a disk drive for storage.
This is an example of a first-version VisiCalc spreadsheet as it would have appeared on a 40-column Apple II. The “cursor” is sitting on cell C11 (which contains the text, “TOTAL”).
Visicalc screen shot - Photo credit: personal
Here are some features unique to this first spreadsheet:
Line 1: Notice the characters “C-” at the end of this line. This was an indication of the current direction of cursor movement. The original Apple II was designed for only one-dimensional cursor movement, left and right, just as the older teletype keyboards that were popularly used at tht time. Since standard Apple II software still used the command line interface, the inclusion of up and down arrow keys to move the cursor in those directions was likely not considered necessary. But in a document like a spreadsheed you have to be able to move up and down as well as left and right. So Frankston and Bricklin made the space bar into a direction-changing key. When you wanted to move the cursor bar up and down, pressing the space bar changed the “C-” to a “C!”, indicating that movement was now vertical. Pressing it again changed the cursor back to “C-” for horizontal movement.
Line 2: When first starting, this line would read
After starting to work, this would disappear and the line would be blank. This line was a command work and display space. When commands were to be entered to modify a cell, pressing the “/” key would cause other information to appear here. However, because it was only a very small space on the screen, and because the memory available was quite tight, the information displayed here was usually only a list of letters and/or characters. These represented the key to press for something to be done to the cell (or at times to the entire spreadsheet). For example, pressing “/” and then “F” would display
which were commands to affect the format of that cell. Knowing what each letter represented would require either having the manual, or experimenting to see what the result was. Some other commands would require more information to be entered; this would be entered on the next line.
The non-inverse text “33” at the end of this line refers to the amount of remaining memory (33K) left for this spreadsheet. When a new spreadsheet was opened, this would read “34”. It would require a full 48K for this to be the case.
Line 3: This line, blank in this example, is the place where information entered for a cell (or as completion of a command) would appear. Typing a label (such as “ITEM”) would display here, and the only editing that could be done was to backspace (using the ESC key, not the left arrow). To enter information that was a label and not a number required pressing the quote key first.
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, had seen that this could have become a major selling point for getting the Apple II 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 Apple III, and a million dollar investment in an untried program for this “aging” Apple II 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 from 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 Apple II (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.
This was certainly not the first word processor for the Apple II, 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 Apple II 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.
This is some sample text, as Apple Writer would display it on the screen:
(Notice in the above box the inverse “^” cursor, ready to start the next sentence as an uppercase letter. Also notice the lack of word-wrap, the word “expanded” is split between the first and second lines.)
Apple Writer would produce the following when the above was printed on paper:
The Apple II computer’s memory can be expanded to as much as 48K of RAM.
The I J K M 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 the editing cursor was moved through the word “AND”, it would look like this as it went from left to right (the cursor being represented by the inverse “+” box):
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, other programs could not use the files. The other problem had to do with the way in which it used (or misused) the ASCII character set. The Apple II, 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 Apple II 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 Apple II 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 Apple II 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 IIe, 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 Apple IIc 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.
Apple Writer 2.0 splash screen - Photo credit: personal
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 computer “experts” claimed was not possible on an Apple II. 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 internal settings for a particular printer and card already to function 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.
FreeWriter splash screen - Photo credit: personal
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 was based on older technology, and did not take advantage of the larger memory sizes frequently available in the later models of the Apple II, it was still powerful and was a welcome addition to any software library.