Type-in program

A type-in program, type-in game or just type-in, is a computer program listing of source code printed in a computer magazine or book, meant to be typed in on the computer's keyboard by the reader in order to run the program.

Type-ins were very common in the early home computer era of the late 1970s and early 1980s because of the period's lack of inexpensive portable storage media, the low penetration of modems and bulletin board systems, and the relatively short maximum length for a program's code on a home computer with a main memory of a few tens of kilobytes. Type-ins were often seen as useful for learning programming, allowing users to begin their programming efforts by porting a program written for one system for use on another.

Description

Here is an example of a type-in:

Listing 1.
 
10 PRINT "HELLO, WORLD!"
20 GOTO 10

To use this type-in, a reader would take a printed copy of the program listing, such as from a magazine or book, sit down at a computer, and manually enter the two lines of code ("Listing 1." is a heading and is not part of the code). Computers of this era automatically booted into a programming environment – even the commands to load and run a prepackaged program were really programming commands executed in direct mode. After typing the program in, the user would be able to run it and also to save it to disk or cassette for future use. Users were often cautioned to save the program before running it, as errors could result in a crash requiring a reboot, which would render the program irretrievable unless it had been saved. The simple program displayed above is a trivial example - many type-ins were fully functional games or application software, sometimes rivaling commercial packages.

Type-ins were usually written in BASIC or a combination of a BASIC loader and machine language. In the latter case, the opcodes and operands of the machine language part were often simply given as DATA statements within the BASIC program, and were loaded using a POKE loop, since few users had access to an assembler. In some cases, a special program for entering machine language numerically was provided. Programs with a machine language component sometimes included assembly language listings for users who had assemblers and who were interested in the internal workings of the program.

The downside of type-ins was labor. The work required to enter a medium-sized type-in was on the order of hours. If the resulting program turned out not to be to the user's taste, it was quite possible that the user spent more time keying in the program than using it. Additionally, type-ins were error-prone, both for users and for the magazines. This was especially true of the machine language parts of BASIC programs, which were nothing but line after line of DATA statements. In some cases where the version of ASCII used on the type of computer the program was published for included printable characters for each value from 0–255, the code could have been printed using strings that contained the glyphs that the values mapped to, or a mnemonic such as [SHIFT-R] instructing the user which keys to press. While a BASIC program would often stop with an error at an incorrect statement, the machine language parts of a program could fail in untraceable ways. This made the correct entry of programs difficult.

To counter the difficulty of keying a type-in, the MIKBUG machine code monitor for the Motorola 6800 of the late 1970s incorporated a checksum into its hexadecimal program listings.[1] Later, some magazines developed checksum programs of their own. There were many different styles of checksum program, usually depending on the type of program being entered and on the complexity of the checksummer. Checksummers were proprietary and were generally printed in every issue of the magazine. The most basic distinction was whether the checksummer was run only once, when the program had been completely keyed in, or whether it was used interactively. The former type either read the typed-in computer code off a disk, or read it directly from memory (this type of checksummer was usually manually appended to the end of a BASIC program). The checksum program would print a checksum for each line of code. The magazine would print the correct checksums adjacent to the listing, and the user would compare the two to catch errors. More advanced checksum programs were used interactively. They would take a line of code as it was entered and immediately produce a checksum which could be compared to the printed listing. Users, however, had to enter the checksum programs themselves correctly.

An example of hexadecimal MLX type-in program code as printed in a Compute!'s Gazette magazine.

For example, Compute! and Compute!'s Gazette printed the BASIC listings for "The Automatic Proofreader" (to verify lines of BASIC) and "MLX" (for binary data) in each issue that carried type-in programs in these formats. Once the user had typed in "The Automatic Proofreader" correctly, he had bootstrapped his way to verifying "MLX" and other programs.

Beyond the manual labor of type-ins, it was not uncommon for certain magazines to print poor quality listings, presenting the reader with nearly illegible characters (especially in the case where machine-code data was printed using extended ASCII glyphs instead of DATA statements); this typically happened when transferring the list output from the era's ubiquitous 7–8-pin dot-matrix printers directly to the printing presses – sometimes even without prettyprinting. This was particularly troublesome in listings which contained graphical characters representing control codes, used for e.g. cursor movements; such characters tended to be less legible than alphanumeric ones in the first place. Additional issues arose after the advent of BASICs that did not require line numbers as the magazine broke logical lines across physical lines due to space constraints and without the line numbers the distinction was not always apparent. Compute! even for a time used a handwritten arrow to represent a carriage return in its program listings. Of course, some errors in type-ins were the result of programmer error, and were simply bugs in the program. Magazines often issued "errata" notices to correct bad listings in subsequent issues.

Other solutions existed for the tedium of typing in seemingly-endless lines of code. Freelance authors wrote most magazine type-in programs and, in the accompanying article, often provided readers a mailing address to send a small sum (US$3 was typical) to buy the program on disk or tape. By the mid-1980s, recognising this demand from readers, many US-published magazines offered all of each issue's type-ins on an optional disk, often with a bonus program or two. Some of these disks became electronic publications in their own right, outlasting their parent magazine as happened with Loadstar. Some UK magazines occasionally offered a free Evatone that played on a vinyl record player connected to the microcomputer's cassette input. Other input methods, such as the Cauzin Softstrip, were tried, without much success.

Not all type-ins were long. Run magazine's popular "Magic" column specialized in one-liner programs for the Commodore 64.[2] These programs were often graphic demos or meant to illustrate a technical quirk of the computer's architecture; the text accompanying the graphics demo programs would avoid explicitly describing the resultant image, enticing the reader to type it in.[3]

History

Type-in programs preceded the dawn of the home computer era. As David H. Ahl wrote in 1983:

In 1971, while education product line manager at Digital Equipment Corp., I put out a call for games to educational institutions throughout North America. I was overwhelmed with the response. I selected the best games and put them together in a book, 101 Basic Computer Games. After putting the book together on my own time, I convinced reluctant managers at DEC to publish it. They were convinced it wouldn't sell. It, plus its sequel, More Basic Computer Games have sold over half a million copies proving that people are intrigued by computer games.

Most early computer magazines published type-in programs. The professional and business-oriented journals such as Byte and Popular Computing printed them less frequently, often as a test program to illustrate a technical topic covered in the magazine rather than an application for general use.[4] Consumer-oriented publications such as Compute! and Family Computing ran several each issue. The programs were sometimes specific to a given home computer and sometimes compatible with several computers. Entirely platform-specific magazines such as Compute!'s Gazette (Commodore) and Antic (Atari), since they only had to print one version of each program, were able to print more, longer listings.

As many type in programs were public domain software, like the many games in BASIC Computer Games, authors often encouraged users to modify them, adding capabilities or otherwise changing them to suit their needs. Many authors used the article accompanying the type-ins to suggest modifications for the reader and programmer to perform. Users would sometimes send their changes back into the magazine for later publication.[5] This could be considered a predecessor to open source software, but today most open source licenses specify that code be available in a machine readable format.

Antic stated in 1985 that its staff "spends a good portion of our time diligently combing the incoming submissions for practical application programs. We receive a lot of disk directory programs, recipe file storers, mini word processors, and other rehashed versions of old ideas".[6] While most type-ins were simple games or utilities and likely only to hold a user's interest for a short time, some were very ambitious, rivaling commercial software. Perhaps the most famous example is the type-in word processor SpeedScript, published by Compute!'s Gazette and Compute! for several 8-bit computers starting in 1984. Compute! also published SpeedScript, along with some accessory programs, in book form. It retained a following into the next decade as users refined and added capabilities to it.

Compute! discontinued type-in programs in May 1988, stating "As computers and software have grown more powerful, we've realized it's not possible to offer top quality type-in programs for all machines. And we also realize that you're less inclined to type in those programs".[7] As the cost of cassette tapes and floppy disks declined, and as the sophistication of commercial programs and the technical capabilities of the computers they ran on steadily increased, the importance of the type-in declined. In Europe, magazine cover tapes/disks became common, and type-ins became virtually non-existent. In North America, type-ins remained popular for 8-bit computers well into the 1990s, although type-ins for 16/32-bit computers quickly faded. Some programming or technical magazines continued to print short code snippets for instruction purposes from time to time, but these 10–20-line segments would not be considered type-in programs in the proper sense.

Although type-in programs have disappeared today, the tradition of distributing software with magazines lived on, especially in Europe, with 3½" floppy disks included with magazines throughout most of the 1990s, eventually followed by CD-ROMs and DVDs.

See also

Notes

  1. ^ Listings for the BBC Micro and Acorn Electron, whose BASIC ROM included an assembler, were generally presented as assembly code, providing a somewhat better chance of catching errors and making it easier for knowledgeable users to modify the program. Ahoy! magazine was also notable for printing assembly code listings, even though it covered the Commodore 64 platform, which did not include an assembler.
  2. ^ An example of the sometimes excessively long type-ins to be encountered was a BASIC extension for the Commodore 64 published in the Finnish magazine MikroBitti; the program's machine code portion made up 20 pages full of numbers for the reader to enter flawlessly into the computer.
  3. ^ Ahl, David H. "Editorial." Creative Computing Video & Arcade Games, Spring 1983.

References

  1. Stanfield, David E (June 1979). "My Computer Runs Mazes". Byte. p. 86. Retrieved 18 October 2013.
  2. "Run Magazine Special Issue 1986".
  3. "RUN magazine issue 35".
  4. "High Speed Pascal Text File I/O, Byte Jan 1983".
  5. "RUN magazine issue 39 March 1987 Page 78".
  6. Ferguson, Dr. John C. (May 1985). "Beer Party Atari". Antic198505. p. 43. Retrieved 7 January 2015.
  7. Keizer, Gregg (May 1988). "Editorial License". Compute!. p. 4. Retrieved 10 November 2013.

External links

This article is issued from Wikipedia - version of the Wednesday, February 03, 2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.