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 previously, the Language Card was a 16K RAM card that made an Apple II into a full 64K RAM computer. Because of the extra available RAM, the Pascal System could load into the space where Applesoft (or Integer BASIC) was located. Since it was a compiled language, an Apple Pascal program could conceivably run a little faster than an Applesoft program, but not as fast as assembly language. The extra power it offered made it an attractive choice for some programmers.
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.
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 the files required to support it took up so much space on a disk that it was difficult to use by those who owned only one disk drive.
Since the original UCSD Pascal language was designed to work with a full 80-column text screen, this was somewhat of a problem for the 40-column Apple II. For those Apple II computers 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, it was possible to jump directly to the other half of the screen by pressing Ctrl-A.
For developers, one significant 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 or 3.3 programs and files that were already available. This limited the potential market for software written in Pascal to those who already owned Pascal (and its $495 entry fee). However, it was possible to create a Pascal application that would function on a standard 48K Apple II or II Plus. This run-time version only supported execution of the Pascal application; there was no included assembler, compiler, editor, filer, or linker. The program would have to handle everything, including file or disk copying, and would have to assume that the user didn’t know anything about how to use Pascal. Due its memory limitations, a 48K run-time Pascal application could only work with storage on a Disk II, and that only in slot 6. , 
When Apple Pascal 1.0 was released in 1979, a significant limitation was that it was designed to support only the four peripheral cards that Apple at that time sold (the Disk II controller card, the Apple II Communications Card, the Apple II Parallel Printer interface card, and the Apple II Serial Interface card). As more and more cards became available from Apple and from third-party sources, it was necessary to update the language and system to support those cards. Apple Pascal 1.1, released in 1980, was designed with a new “firmware card protocol”, which required defined entry points on a card that would make it easier for Pascal to use the card without additional special drivers. Each card that fit with the new protocol had to have specific signature bytes in a specific location. For a card in slot “n”, the address $Cn05 had to have the value $38, and $Cn07 had to be $18. $Cn0B and $Cn0C further identified to Pascal what type of card it was, and the version 1.1 BIOS could then determine how to make the card available to the system. Under the firmware card protocol, definitions were made to support printers, serial or parallel cards, joysticks, modems, speech or sound devices, clock cards, mass storage devices, 80-column cards, or network cards. Furthermore, the new 1.1 system made it easier to create custom drivers to add to the Pascal System for devices that needed extra control beyond the generic drivers in the BIOS.
Aside from bug fixes and small language enhancements, Apple Pascal 1.1 also supported the ability to handle upper and lowercase display on a standard 40-column Apple II, using the same method as did the original version of Apple Writer (lowercase was normal video, uppercase was inverse video).
The release of Apple Pascal 1.2 in 1983 provided a fix some bugs remaining in the earlier versions, and made changes to better utilize features available on the Apple IIe. This included support for the cursor keys (the Apple IIe had up and down arrows lacking on the older Apple II models), proper support for upper- and lowercase input from the IIe keyboard, and the ability to use the open-apple and closed-apple keys. On a 128K Apple IIe, Apple Pascal 1.2 could make use of this extra memory; it was done by replacing the SYSTEM.APPLE and SYSTEM.PASCAL files on the startup disk with files on the APPLE3 volume. This larger version of Pascal used the main board RAM for assembly code and data, and the auxiliary RAM for compiled P-code and for the Pascal operating system. Also, this 1.2 version allowed the Pascal compiler to stay entirely in memory during compilation of a Pascal program, which eliminated some disk swapping that was otherwise necessary.
With the proliferation of the 64K Apple IIe and 128K Apple IIc, an adequate platform for Pascal applications was eventually available. However, by that time that occurred, the primary disk system being promoted for the Apple II was ProDOS, and Apple never released a version of their original UCSD Pascal that would run under that operating system. (Possibly, since by definition “UCSD” Pascal was the language and the operating system, it would be unnecessarily complex to modify that version of Pascal to run under ProDOS.)
In 1985, Apple Pascal was upgraded to version 1.3, which supported the more advanced features of the Apple IIe and IIc. It could handle access to larger storage devices attached to the Smartport on a IIc, and the run-time environment was enhanced to work with 64K and 128K systems. Later, when the Apple IIGS was released, one limitation of Apple Pascal 1.3 was that it did not work on that computer as well as some programmers wanted. When third-party Pascal solutions became available (such as ORCA/Pascal from The Byte Works), IIGS programmers turned to those languages, since they were designed take full advantage of that machine in 16-bit mode.
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 Apple IIc 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).
Instant Pascal 1.5 screenshot – Photo credit: personal
Fans of the original Apple Pascal complained loudly after Apple introduced Instant Pascal, as the company no longer appeared motivated to make any further upgrades to the older Pascal. Instant Pascal worked under ProDOS, but the older Pascal still required the incompatible Pascal disk system.
TML PASCAL / COMPLETE PASCAL: TML Systems first released its native code Pascal compiler for the Apple IIGS in 1987. Not only did it take advantage of the power of the Apple IIGS desktop, it was also possible to use it as a learning environment to enter and run textbook Pascal programs. It later became TML Pascal II in 1989 to run under GS/OS, with full access to the IIGS Toolbox. Complete Technology, Inc., purchased TML Pascal and in 1990 released Complete Pascal 1.0 (which was TML Pascal II 1.1 with some minor changes). They advanced it to Complete Pascal 2.0 in 1991; however, soon after this happened, the offices of Complete Technology in Denver were destroyed by fire, and the company did not recover from this loss.
In 2009, the copyright holder and author for Complete Pascal, Vince Cooper, released the product for free distribution.
ORCA/PASCAL: Written to work with the Apple IIGS in The Byte Works ORCA environment. When that company was given the contract to use ORCA/M to create what became the Apple Programmer’s Workshop for the new Apple IIGS in 1986, the money earned by this deal made it possible for The Byte Works to work on other languages, including ORCA/Pascal. Apple tried to get some other programmers to create a version of Pascal to run under APW, but this never worked out, leaving ORCA/Pascal as a version that was compatible with APW, and able to share libraries with other languages under than programming shell.
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). It compiled to a similar code as did Pascal programs, so was not any faster than Pascal. Apple’s version of FORTRAN had many bugs in it, though, and after its introduction in 1980 it was never upgraded. By September 1986 it had disappeared from their product catalogs.
Another way for an Apple II 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 Pascal disk format for its FORTRAN by creating a ProDOS file that then acted as a UCSD Volume.
PILOT: Dr. John Starkweather at the University of California in the 1960s designed PILOT as a special-purpose language for educational programming. The name was an acronym for Programmed Inquiry, Learning Or Teaching. It was designed primarily for educators to create tutorial modules for computer-aided instruction. The language was quite simple, and allowed design of interactive programs to instruct students and test them on their responses during the process. One early version for the Apple II was written in Applesoft and was entirely text-based.
Apple PILOT program screen – Photo credit: personal
Apple released its own version, Apple PILOT, in 1980. Selling for $125, it ran under the version 1.0 of the Pascal System.  The PILOT required two disk drives system to operate in Author mode, and one disk drive to run a Lesson disk. When an Author disk was used to initialize a Lesson disk, it formatted the disk under the Pascal System, and then included the necessary files to allow the disk to boot (much like DOS 3.2 and 3.3 could create bootable disks). After those files were put on the disk, 144 blocks (just over half of the disk space) was available for lesson, graphics, and sound files.
To create lessons, Apple PILOT used the hi-res screen to display upper and lowercase characters (not possible without extra hardware on an Apple II or II Plus). The sound effects, graphics, and character set editors worked on the hi-res screen, using either the keyboard or the paddles to do the drawing. To create lesson files (using the PILOT programming language), the standard 40-column text screen was used. In this mode, again the Apple Writer method was used, with lowercase as standard video, and uppercase as inverse video.
The Lesson disks contained enough of the Pascal System files to allow it to boot (still in a 48K environment), and execute the PILOT system file, which then looked for a file HELLO.TEXT. If this was a PILOT lesson file, it would execute and run that file. The default HELLO.TEXT file was a sample that asked the user to enter the name of a lesson file to load (not unlike the requirement in DOS 3.3 to type “RUN PROGRAM”).
Apple SuperPILOT was released in 1982. It ran under Pascal System 1.1 and had increased memory requirements that made it necessary to have a full 64K Apple II. The various editors were improved and made faster, and the lesson editor was changed to use the hi-res screen just like the other modules (allowing direct display of upper and lowercase characters). The graphics drivers were enhanced, allowing new graphics effects. The language itself was enhanced, offering commands to control external devices (videodisc and videotape players).
At some point after Pascal System 1.3 came out in 1985, APDA (the Apple Programmers and Developers Association) sold a product called SuperPILOT Special Edition. Because of the enhanced Pascal environment, it was possible to access 3.5-inch disks and hard drives.
Programma FORTH splash screen – Photo credit: personal
This was an 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 1970s were Apple Forth 1.6, by Cap’n Software, the first version available for the Apple II. It initially was available only on cassette, and when it did come out on disk, it was a system that was not compatible with DOS 3.2. Another version was AppleFORTH 1.2, sold by Programma International in 1979. Programma’s Forth was more extensive, but also more complicated.,
GraFORTH splash screen – Photo credit: personal
GraFORTH, written by Paul Lutus and published by Insoft in 1982, was a very fast compiled implementation of Forth, which ran under DOS 3.3. It was unique to other versions available on the Apple II in that it included the ability to draw on the hi-res screen using Turtle graphics, much in the same way as Logo. It used integer math only, and could draw fast enough for a program to display animation. The graphics could even be drawn as “3D”, although this type of three dimensional drawing was the same as what can be drawn on a piece of paper with a pencil; it was not 3D in the sense of anaglyph images which give a sense of depth and require special glasses to view. Additionally, GraFORTH could create simple sound effects and music, much as could be done with the sound routines in the Integer BASIC ROM.
Lutus also wrote a more robust version of this language, called TransFORTH II. Released the same year as GraFORTH, Lutus in the accompanying manual stated that he had designed it to be “a general purpose scientific and business language” for the Apple II. It had the advantages of being a structured language, it could be run in both interpreted and compiled forms (the compiled programs could be executed from DOS 3.3 via the BRUN command), it was compact, it included the ability to create lo-res and hi-res graphics, and could make full use of the RAM in a 128K Apple IIe. The second version, TransFORTH IIB, could load itself into the Language Card RAM, leaving more memory available for programs. Lutus intended that TransFORTH be more focused on scientific and business programming, while GraFORTH was to be more for games and educational software, and had a richer set of graphics features. Insoft sold TransFORTH for $125, and GraFORTH for $75.
LOGO: Developed from the LISP (LISt Processing) at the Massachusetts Institute of Technology (MIT) language to be an aid for learning, Logo was popular over the years in the school environment. A National Science Foundation grant at MIT helped the team there, under the direction of Dr. Seymour Papert, to develop the Logo language. Dr. Papert later worked directly with Apple Computer to create the version sold as Apple Logo. MIT also authorized two other versions of the language, Krell Logo and Terrapin Logo. Terrapin Software sold Terrapin Logo; an example of the appearance and use of this language can be found at SydLexia.com. What was about this version was that it was sold with an actual mechanical turtle that would move on the floor in response to commands on the computer. Krell Logo had some minor changes from the original Logo.
Apple Logo II splash screen – Photo credit: personal
Apple’s first version of Logo (which operated under the Pascal system) could run on any 64K Apple II. Beyond the other two versions available, Apple Logo came with two large reference manuals with tutorials. Apple Logo II (released in July 1984 for $100) ran under ProDOS on the Apple IIc or the Apple IIe with 128K memory. Terrapin Logo had less comprehensive manuals, and dealt more with operation of the Terrapin Turtle robot. Krell Logo offered two technical manuals and an education manual, and a primer called “Alice In Logoland”.
3D Logo manual cover – Photo credit: Tony Diaz
HyperLogo manual cover – Photo credit: Tony Diaz
The Byte Works also provided two versions of the Logo language for the Apple IIGS. One was 3D Logo, and the other was HyperLogo, a $60 scripting language for Roger Wagner Publishing’s HyperStudio. HyperLogo worked as a replacement for SimpleScript, which was HyperStudio‘s built-in scripting language. Both 3D Logo and HyperLogo were full implementations of Logo, with the ability to create three-dimensional displays The 3D turtle could draw in either true 3D (which required special glasses to view) or in perspective mode (as one could draw on a piece of paper). It also had support for Talking Tools, which allowed creation of programs that talked to the user. 3D Logo included some additional commands to allow creation of desktop programs that could be launched from the Finder. Stacks created with HyperLogo could be distributed to a HyperStudio user who didn’t own that add-on language, as The Byte Works provided a run-time module to distribute with the stack.
COBOL: This language had limited availability for the Apple II. Microsoft sold it for $599, as a language to run under the CP/M system with the Microsoft Z-80 Softcard.
C: A language that became popular among “power” programmers. It had some of the structure of Pascal, but also some of the low-level power of assembly language.
Apple released a version of C for the Apple IIGS, APW/C to run in the Apple Programmer’s Workshop environment (see below for more details on the history of that product). However, ORCA/C from The Byte Works that was released later was more favored by programmers, as it was a more modern version of C, was fully ANSI-C compliant, had better product support than Apple offered for APW/C, and generated smaller object code files.
A large variety of Apple II assemblers were available over the years. The earliest one, of course, was the mini-assembler that came with every Integer BASIC Apple II. 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 Apple II.
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 Apple II, 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 Apple II assembler that was commercially distributed, released in mid-1979. 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, continued to improve his assembler, and later versions were more speedy. He also 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: Glen Bredon bought his first Apple II in 1979, and didn’t find much software to run on it. He began to create his own programs, first in Integer BASIC and then in Applesoft after he bought the Applesoft firmware card. He began to delve into assembly language, using the built-in Apple II disassembler to examine what software he could find and then using the mini-assembler to try making changes to them. He got the public domain assembler, TED/ASM, and due to dissatisfaction in how it worked Bredon disassembled it, and found ways to improve it. He added the ability to create macros, shortcuts for coding, and improved the editor. He offered it to A.P.P.L.E., and the club sold it as Big Mac (because of its macro capabilities). Val Golding of A.P.P.L.E. later connected Bredon with Roger Wagner of Southwestern Data Systems, and that company later sold the assembler under then name Merlin.
Bredon continued to update the abilities of Merlin; it was one of the few assemblers that moved on to the 65816 GS/OS world, while retaining full compatibility with the previous 8-bit 6502 versions. In its latter days it was sold as Merlin 816 (including an 8-bit version) and Merlin 16+. Merlin was very popular with game programmers, and was often used for smaller projects or casual programmers.
ORCA/M: This was one of the early commercial assemblers for the Apple II series. Mike Westerfield created it in 1979, after he’d purchased an Apple II Plus. He wanted to code a very large project (a chess game in 6502 assembly code), and none of the assemblers then available could handle a project of that size. Also, he was more comfortable with the style of the assembler on the IBM 360 mainframe on which he had been trained on his first assignment out of the Air Force Academy. To that point, no Apple II assembler had been written to work like an IBM 360 assembler. Westerfield ultimately had to write his own assembler on one of the less capable ones he could get his hands on. He created three pieces, two of them at memory locations that assembler could handle, and the third piece hand assembled by entering the bytes into the appropriate memory location using the Monitor.
After putting these three parts together manually, he then used this new assembler to make modifications to itself, ultimately creating an assembler, linker, libraries, and the ability to create macros (shortcuts for longer bits of code). He sought out a publisher, and settled on Hayden Software. Hayden product manager David Eyes suggested the name ORCA/M, an acronym for Object Relocatable Code Assembler for Microcomputers; however, it was also MACRO spelled backwards. Westerfield eventually hired Phil Montoya to help with improvements in the product.
ORCA/M played an important part in the development of application software for the Apple IIGS. When Apple and Western Design Center (WDC) began to collaborate on a 16-bit version of the 6502, David Eyes from Hayden brought Westerfield together with Bill Mensch of WDC. Westerfield ultimately designed the opcode syntax for the 65816 and 65802 processors, and was able to use this knowledge to get ORCA/M updated to work with them before anyone else.
Before the middle of the 1980s, Hayden decided to get out of the software business. Westerfield was able to take back control of his assembler, and decided to start his own company, The Byte Works, to continue to sell and upgrade ORCA/M. Apple took notice of the capabilities of this assembler, and elected to contract with The Byte Works to make ORCA/M the official development environment for the Apple IIGS, which was code-named “Cortland” in its early days. The Cortland Programmer’s Workshop gave tools to the developers who wanted to create software for the new computer, to be ready when it was released in September 1986. The name of the product Apple released was changed to Apple Programmer’s Workshop, abbreviated APW. Apple allowed The Byte Works to continue to sell ORCA/M, which Westerfield continued to enhance and under which he later released other languages, all of which could be used together in large projects.
APPLE EDASM: This was Apple’s original “official” assembler for the II Plus and later 8-bit Apple II computers. It was not actively supported after ORCA/M and the APW environment was released for the IIGS. The early versions of EDASM 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 DOS 3.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 also came 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 DOS 3.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 became so complex that they were actually programming languages in their own right. In fact, many of them were referred to as “scripting” languages, since they “directed” the function of a program, as a director uses a script to film a movie. This was most popular with telecommunications programs, where the process of logging on to a remote computer, downloading new messages, and uploading replies was automated with a script that analyzed the responses from the other computer and took appropriate action. It was popular in programs like Apple Writer (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 Apple II 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 pointer (mouse). And Macintosh programmers extended this concept to every application released with it. This different environment was called a “graphic user interface” (GUI), and used the concept of objects rather than typed commands. To delete a file, it was not necessary to type “DELETE PROGRAM”, but rather the user would point to the picture (icon) representing the file and drag it onto a picture of a trashcan. This “desktop” offered 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 was the concept of “object-oriented programming” (OOP). In this method, the details of windows, menu bars, buttons, and other GUI standards were used to create other programs that displayed a consistent interface. Instead of having to laboriously define at the byte level how to create a window box, the computer operating system already knew how to do this; the programmer just had 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 worked in an OOP environment eventually became available on an Apple II, but first an introduction to the concept of “hypertext”.
The term “hypertext” was created by Computer Lib author Ted Nelson, and referred 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.
TutorTech screenshot – Photo credit: personal
Tutor-Tech was the first comprehensive hypertext system available for the Apple II series, released in 1988. It worked on 8-bit Apple II models, 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 labeled “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”.
HyperStudio screen shot – Photo credit: personal
With the release of the IIGS, the power was finally available in the Apple II 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 this first release lacked a true programming language.
HyperCard IIGS screen shot – Photo credit: personal
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 gave the user power over details of the computer system itself (as did “C” or assembly), it did make it possible for a beginner to create programs that had outstanding graphics and sound without having to know exactly how the hardware produces these effects. This, along with the flexibility possible with these products, led editor Dennis Doms in an A2-Central feature article to suggest that HyperCard IIGS (and now also possibly HyperStudio) would become the “Applesoft” of the 1990’s; that is, an Apple IIGS user with HyperCard IIGS could create programs as easily as the Applesoft programmer of 1980 could do, but with far more attractive results. And had the Apple IIGS been allowed to survive and upgrade, that might have indeed been the end result.
One of the most important applications of hypertext that eventually came into use by people around the world was the work that Tim Berners-Lee did between 1980 and 1991. He started with a simple hypertext database that connected people and software models. Each entry in this database was designed to link with another entry. In 1984, Berners-Lee took this a step further. He was working at CERN (the European Organization for Nuclear Research) in Switzerland, and was trying to solve the problem of scientists from around the world needing to share data. They were hampered by the many different computer platforms in use, and a lack of a common software program for presenting the data.
Berners-Lee designed his system on a NExT workstation, and by late 1990 he had begun to implement the earliest version of his HyperText Markup Language (HTML). To access his computer from the Internet, he designed the HyperText Transfer Protocol (HTTP). (This was just one of many types in use, including File Transfer Protocol, FTP, Network News Protocol, NNTP, and others.) Using a rudimentary editor and viewer for pages served by this protocol, he came up with the name “World Wide Web” for this type of hyperlinked connection. On August 6, 1991, Berners-Lee shared his vision for this method of information exchange on the alt.hypertext newsgroup. Other programmers around the world began to create pages that could be linked using this method, both graphical and text-only, and over the next ten years it grew so much in popularity that it became one of the major reasons for even non-computer-literate people to have and use a computer.
The foundation for the modern World Wide Web was laid with the first hypertext programs on individual computers, and programs that ran on the Apple II made their own contribution to the hypertext knowledge base.