"Duane Maxwell" dmaxwell@san.rr.com wrote: In the case of CP/M, I believe the problem was that terminals of the era interpreted CR as "move cursor to column 1" and LF as "move cursor down one line, scroll if necessary". That, in turn, is because that's the way ASR-33 teletypes did it - CR meant "return the carriage to column 1" and LF meant "feed one line of paper". The operating system did no translation of the output stream - the data went out raw to the serial port. Virtually all early CP/M-based computers used terminals because memory mapped video was very rare. What terminals do and what operating systems do are only very loosely coupled. When I used Burroughs' CANDE environment on a Model 33 Teletype, the Teletype wanted CR (+nuls) + LF (+nuls) to do the right things with the paper and the print head, *but* what I actually typed to get this effect was Ctrl-C (End of TeXt, right? the obvious thing!), and what the operating system stored was nothing at all (fixed length records).

Note that although many many terminals required padding characters (NUL or DEL) to be sent, the ASCII specification actually forbids those codes appearing in text files (there is some excuse for the C convention after all!), so the decoupling between stored-data and characters-sent-to-the-terminal has been obvious since the early 60s at least.

I wrote a terminal driver for a minicomputer (ok ok, by today's standards a microcomputer) once. Handling line editing and delay padding was hard enough that the extra cost of mapping CR to CR+LF was hardly noticeable.

I note that EBCDIC has CR, LF, *and* a NL code. So of course does "ASCII" these days, NEL (NEw Line) is '\205'.