4 ms·

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

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.

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.