4 ms·

And remember, boys and girls, that the correct sequence is CR LF, and not LF CR. If I see LF CR in your C code I will slap you with a review comment, just out

And remember, boys and girls, that the correct sequence is CR LF, and not LF CR. If I see LF CR in your C code I will slap you with a review comment, just out of nostalgia, even though modern printers rarely drip oil. CR can take more than a single character time for the carriage to move to the left and settle, so to avoid print corruption, issue CR first, and then LF so that the carriage also has LF time to settle. Back many moons ago I used to operate RTTY on ham radio. On the air, since characters can be easily lost, the standard end-of-line sequence was often CR CR LF LF NUL NUL in case a CR or LF got clobbered by a static crash or such, and the NULs are extra settling time. (Usually we also configured "unshift-on-space" because a lost LTRS in Murray code is annoying. We all assumed the other end was running U.S.O.S. so always assumed SPACE took the receiver out of FIGS mode and therefore sent a redundant FIGS after SPACE.) If you are wondering why UARTs can be configured for 5 data bits and 1.5 stop bits.... Murray code as used in Model 15's is why. Once upon a time I did a Apple II program in 6502 assembly that gave me a "glass TTY", split screen, received text on the top 2/3's of screen, sent on the bottom. Interfaced to a HAL ST-6000 (I loved that box. I still have it collecting dust somewhere). Eventually I ported the glass TTY to a Macintosh I. Now... where did I leave my cane? And get off my lawn.

frutiger 8y ago
I have never seen LFCR in C or any other code (but plenty of LF and CRLF, and since OS X, very rarely just CR). I know your comment is tongue-in-cheek but I am genuinely curious if LFCR is otherwise common in some obscure niche.
- tom_ 8y ago
  The OSs for Acorn computers printed it in that order, as it made the 6502 version of the translating print routine (that would translate CR into LFCR) a few bytes shorter to print them in that that order: (not exactly the code in the ROM, but not meaningfully different) osasci: ; print ASCII char, preserving A, translating CR->LFCR cmp #13 bne oswrch osnewl: ; print newline, overwriting A lda #10 jsr oswrch lda #13 oswrch: ; print ASCII char, preserving A ... rts (According to Wikipedia, this ordering survived into the ARM range! - maybe it helped with the ARM code too? Or perhaps they wanted the output to be identical, or nobody thought it mattered which order you print them in... no idea.) CR on its own was the standard line ending, but if you saved screen output (e.g., a BASIC listing) to a file you'd find LFCRs in the file, and if you played the output back as input you'd see a bunch of blank lines added due to the additional cursor movements. I suppose this must have affected printer output, but I don't remember it causing any issues as the printer interface had some kind of flow control.
- dbcurtis 8y ago
  You know, I can't remember why it vexed me so much. I think there was a time back in the day when serial cards would have to add a CR because the C printf() would terminate in just \n. And a number of them did it in the wrong order, and some printers just did not have enough time to get back to the left edge. Much like the annoyance of trying to find a keypunch in the student keypunch area where the machine didn't have a bunch of broken star wheels for the programming drum. Some burrs under the saddle can be relegated to the dust bin of history.
Animats 8y ago
The real history of CR LF. Western Union's earlier Teletype-based services used tape printers, which printed on narrow paper tape. See this video, "Telegram for America", at 6:31.[1] Note that the operator typing in the message is typing "blind" - she can't see what she's typing and is expected to make no mistakes. At the receiving end, the message is printed on narrow paper tape and glued down by hand on telegram blanks. (We've done this at steampunk conventions. For smaller conventions, I put a little tape printer in a fitted Anvil case, so we have a nice portable setup.) While page printers like the Model 15 were available, WU was mostly tape printer oriented. Compatibility between the systems needed something to convert an unbroken stream of text into lines with CR LF sequences at the end of each line. So they invented the first word wrap device.[1] - a box full of relays which counted the characters and put in a CR LF at a word break when necessary. This was coupled to a Model 15 Teletype with a pin feed platen and some other extra features so standard telegrams could be printed automatically. "Due to the inertia of the carriage, the travel time for a full line is in excess of the time required to send one character (space) and even with a short line, dash-pot operation with attendant carriage bounce produces an irregular left margin". Two character times are sufficient. Hence CR LF, which overlaps the carriage return and the paper advance. I do that today in a Python program. A machine that needs more than two character times for a carriage return is out of adjustment. Perform procedure "Carriage Return Spring Drum Adjustment" from page 32 of the "Model 15 Adjustments" manual.[2] Also see "Printing Bail Adjustment", page 10, if the carriage is sticking on carriage return. Follow the oil-grease-oil lubrication procedure on the printing bail rails - light machine oil, light grease, light machine oil again. Welcome to maintainable technology. [1] http://massis.lcs.mit.edu/archives/technical/western-union-tech-review/10-1/p040.htm http://massis.lcs.mit.edu/archives/technical/western-union-t... [2] http://aetherltd.com/public/model15manuals/138_Model15_Adj_Oct41.pdf http://aetherltd.com/public/model15manuals/138_Model15_Adj_O...

frutiger 8y ago

I have never seen LFCR in C or any other code (but plenty of LF and CRLF, and since OS X, very rarely just CR). I know your comment is tongue-in-cheek but I am genuinely curious if LFCR is otherwise common in some obscure niche.

tom_ 8y ago
The OSs for Acorn computers printed it in that order, as it made the 6502 version of the translating print routine (that would translate CR into LFCR) a few bytes shorter to print them in that that order: (not exactly the code in the ROM, but not meaningfully different) osasci: ; print ASCII char, preserving A, translating CR->LFCR cmp #13 bne oswrch osnewl: ; print newline, overwriting A lda #10 jsr oswrch lda #13 oswrch: ; print ASCII char, preserving A ... rts (According to Wikipedia, this ordering survived into the ARM range! - maybe it helped with the ARM code too? Or perhaps they wanted the output to be identical, or nobody thought it mattered which order you print them in... no idea.) CR on its own was the standard line ending, but if you saved screen output (e.g., a BASIC listing) to a file you'd find LFCRs in the file, and if you played the output back as input you'd see a bunch of blank lines added due to the additional cursor movements. I suppose this must have affected printer output, but I don't remember it causing any issues as the printer interface had some kind of flow control.
dbcurtis 8y ago
You know, I can't remember why it vexed me so much. I think there was a time back in the day when serial cards would have to add a CR because the C printf() would terminate in just \n. And a number of them did it in the wrong order, and some printers just did not have enough time to get back to the left edge. Much like the annoyance of trying to find a keypunch in the student keypunch area where the machine didn't have a bunch of broken star wheels for the programming drum. Some burrs under the saddle can be relegated to the dust bin of history.

Animats 8y ago

The real history of CR LF. Western Union's earlier Teletype-based services used tape printers, which printed on narrow paper tape. See this video, "Telegram for America", at 6:31.[1] Note that the operator typing in the message is typing "blind" - she can't see what she's typing and is expected to make no mistakes. At the receiving end, the message is printed on narrow paper tape and glued down by hand on telegram blanks. (We've done this at steampunk conventions. For smaller conventions, I put a little tape printer in a fitted Anvil case, so we have a nice portable setup.) While page printers like the Model 15 were available, WU was mostly tape printer oriented. Compatibility between the systems needed something to convert an unbroken stream of text into lines with CR LF sequences at the end of each line. So they invented the first word wrap device.[1] - a box full of relays which counted the characters and put in a CR LF at a word break when necessary. This was coupled to a Model 15 Teletype with a pin feed platen and some other extra features so standard telegrams could be printed automatically. "Due to the inertia of the carriage, the travel time for a full line is in excess of the time required to send one character (space) and even with a short line, dash-pot operation with attendant carriage bounce produces an irregular left margin". Two character times are sufficient. Hence CR LF, which overlaps the carriage return and the paper advance. I do that today in a Python program. A machine that needs more than two character times for a carriage return is out of adjustment. Perform procedure "Carriage Return Spring Drum Adjustment" from page 32 of the "Model 15 Adjustments" manual.[2] Also see "Printing Bail Adjustment", page 10, if the carriage is sticking on carriage return. Follow the oil-grease-oil lubrication procedure on the printing bail rails - light machine oil, light grease, light machine oil again. Welcome to maintainable technology. [1] http://massis.lcs.mit.edu/archives/technical/western-union-tech-review/10-1/p040.htm http://massis.lcs.mit.edu/archives/technical/western-union-t... [2] http://aetherltd.com/public/model15manuals/138_Model15_Adj_Oct41.pdf http://aetherltd.com/public/model15manuals/138_Model15_Adj_O...