LAST ARCHIVE

ARCHIVES INDEX

NEXT ARCHIVE

MANY HAPPY... RETURNS?
(or, Is This The End Of The Line?)

Jim Butterfield

(This article was first published in the ICPUG Journal May/June 1993 issue.
Permission from Jim Butterfield to republish on the Internet has been received.)

Some recent comments by Joe Griffin call to mind a number of tricky things that early personal computers had to address. A major one was: how do you signal the end of a line of text?

Early computers, many of which were home brew, might be attached to Teleprinters if the computer owner was rich enough to have one of these. When you got to the end of a line on a teleprinter, you needed to send three characters:

RETURN (character 13)
LINEFEED (character 10)
NULL (character 0)

The RETURN started the "carriage" on its way back to the left hand side.

The LINEFEED moved the paper up.

The NULL killed time to make sure that carriage had made it all the way back.

Computer printers continued this tradition for a while, although faster carriages (no, please don't say "horseless") made the NULL unnecessary. You still needed to give the RETURN first, to give the carriage time to do its movement, and you had to say LINEFEED or the paper wouldn't move up and you'd end up printing everything on one line. Soon, RETURN did the whole job and any timing problems were solved by the use of a buffer within the printer which could store a whole line of text before printing it. Enter Commodore.

When Commodore arrived upon this early scene with the PET 2001, they decided that end-of-line should be the two characters, RETURN and LINEFEED. However, when you were entering text, you would press RETURN only to signal that your input was complete.

When printing to the screen, or to anywhere else, CR (carriage return) and LF (linefeed) were both sent at the end of a line. The screen, of course, cheerfully ignored the LF.

A curious thing started to happen as users started to take advantage of data files. These files had been previously written by the computer, of course, and so each line ended with CR, LF. But when reading from these files, input stopped when CR was seen. As a result, all lines other than the first would have an invisible LF stuck onto the front; as we said, the screen ignores this character. This resulted in a baffling phenomenon. As your Basic program copied files over and over again, they would mysteriously get bigger and bigger. Nothing would be visible if you listed the files in the usual way. Sooner or later, your data program would be doomed to crash on a LINE TOO LONG error.

It took a while for anyone, (including Commodore), to figure out what the trouble was. When the penny finally dropped, Basic was modified so that output USUALLY sent CR only ... no more LFs.

A note in passing: most MSDOS programs still send both CR and LF, which can cause a little extra work for in depth programs.
(Editor: Windows Notepad and Windows Write also send CR and LF. Windows Wordpad, which uses Word 6 format, and Word 97 use CR only)

I'm really not sure where the Amiga standard of using the LF character, (renamed NewLine), for end-of-line came from. It's used in UNIX and Amiga leans a lot on UNIX concepts. I have heard it said that it's part of a CCITT standard. In any case, character 10 is what terminates Amiga text lines. This gives us a not too serious file conversion problem to solve any time we pass a file from one system to the other. A parallel problem exists for transfer of files to or from MSDOS. Gosh, at one time we seemed to have a standard; now we have three; and a few others. . . but let's leave that for now. CR/LF Lives!

Commodore didn't abolish the two character CR and LF combination with their early system modification. In fact, they made it an option. The key to the option lies in your choice of a logical file number. If you open a file with:

OPEN 1,8,2,"0:MYFILE,S,W"

... Basic will terminate text lines with CR only. But if you open a file with:

OPEN 129,8,2,"0:MYFILE,S,W"

... Basic will terminate text lines with both CR and LF. (Few people do this). The trick is the logical file number, which may range from 1 to 255. Below 128, it's CR only; 128 and above, it sends CR and LF.

Joe's article about writing data files on 8-bit Commodore computers suggested you write a data file in a certain way. For example, to write a string X$ to logical file 1, (previously opened, of course), he suggested:

PRINT#1,X$;CHR$(13);

... note the semicolon at the end. What this code says is: forget about any "canned" line ending, just tack on a RETURN character. That's defensive coding. We did this when we feared accidentally running across one of the old machines that still send both CR and LF. The code shown overrides the system end of line and substitutes our own. This kind of thing would still work on newer systems such as Amiga or MSDOS. You may not need it much, but it's nice to know that you do have control

There are a zillion programs around for converting from ASCII to PETASCII to whatever. Some of them look after the end-of-line configurations, some don't. In my computer room, the Amiga seems to be a central clearing house for data from various configurations of machines. I had trouble keeping track of which Amiga program performed what modifications on what kind of files. So I wrote a few of my own. In particular, program TrimText looks at a file, reports what's in there (in terms of end of line data), and offers to let you change it.

This article was reprocessed from the ICPUG Journal by Ken Ross.

TOP