Shop OBEX P1 Docs P2 Docs Learn Events
CR vs CRLF Dilema — Parallax Forums

CR vs CRLF Dilema

I use W10 and PST regularly with my P1 & P2.
Here CR only is required as otherwise I get double spaced output.

Peter IIRC uses Linux and a terminal program.
Here CR+LF is required.

So here is the thing. Peter discovered I was only sending CR so he changed it to output CR+LF. Great, so I realised there were a few other instances that needed changing. Well I did that and then tested it. OOPS! Now I get double line spacing.

Hence the dilema...
What to do for the Monitor & TAQOZ?

In my P1 OS I have a setting for LF or NOLF. Not so lucky here ATM and time is short.

What do we do????
«13

Comments

  • I think CR+LF is the standard these days. Most terminal programs let you configure this
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2018-05-15 01:02
    LF by itself is the Linux standard newline.

    -Phil
  • Any standard terminal doesn't add a LF to a CR or a CR to a LF. Some simple terminal programs that don't support ANSI for instance just go to a new line when they receive a CR but I may use CR to return me to the start of the line continually to report a changing value etc otherwise it would fill and scroll the whole screen. Sure, many terminals support auto CRLF if you tick that box but then they also support ANSI which allows you to position the cursor anywhere on the screen.

    TAQOZ uses CRLF a lot and sometimes CR only to avoid screen fills.
  • I suggest sending CR+LF. You can always turn off LF in the Preferences-Function screen in PST. That's what I do when I run Prop code that sends CR+LF.

    If you leave LF on in PST you will get double spacing, which is readable. The alternative is to send only CRs and get zero spacing (all the lines on top of each other) in terminal programs that don't do an auto-linefeed when receiving CRs.
  • Cluso99Cluso99 Posts: 18,069
    edited 2018-05-15 01:17
    Thanks Dave. Just didn't recall PST having that setting. Done & tested :)

    And thanks Peter for the enlightenment :)
  • I'd rather see it end lines with CR+LF. While it is true that text files in Linux typically end in only an LF, when that file is cat'ed to a terminal the LF is added on output so the terminal gets both CR and LF.
  • Cluso99Cluso99 Posts: 18,069
    CR+LF is done and dusted :)
  • msrobotsmsrobots Posts: 3,709
    edited 2018-05-15 09:49
    As Peter mentioned CR and LF have two distinct behaviors. It goes back to those old noisy mechanical printers.

    CR was even on a Teletype a "Carriage Return", so "position the cursor on the beginning of the current line".

    LF was also even since Teletype times a "Line Feed", so advance the line by one and NOT move the horizontal position of the cursor.

    Two distinct behaviors, both very useful.

    Then came that horrible mistake done by "C" and "*nix like systems" to leave out the CR and just use LF as terminator, combining horizontal and vertical movement. bad mistake, because it opened the door for MAC to distinguish itself from Windows and *nix by just using CR as terminator.

    Current MAC versions do not do this anymore, I think, but the damage is done.

    Edit a Textbox in your Browser, if IE or EDGE you will get back CRLF as terminator, do it in CHROME, you'll get LF only, both on Windows.

    It's not a dilemma, it's a mess.

    But the correct way to do it is to use both characters as they are intended to do and even named after.

    my 2 cents

    Mike
  • Heater.Heater. Posts: 21,230
    That's a very logical argument msrobots. It might be more complicated though....

    Good old fashioned typewriters, since early last century, had a carriage return mechanism and an independent line feed mechanism. Perhaps under different names.

    They also had a big leaver you could drag from left to right that would do both carriage return and linefeed in one go. Very convenient. Let's call it "new line".

    Then things got messed up with the arrival of teletypes. Their mechanics were not sophisticated enough, or fast enough, or whatever to do a carriage return and line feed at the same time. So, they had no "new line" as a single character. We had to make do with using both carriage return and line feed. A step backwards.

    The mistake comes with the definition of ASCII that only has carriage return and line feed. No newline.

    This gets compounded by the new line character of C (\n) being mapped onto the ASCII/teletypes line feed (hex 0A). Obviously new line is not the same thing as carriage return!

    And then all hell breaks out as Unix, DOS and Mac all get totally confused as to what to do in the absence of that old typewriter feature, new line.
  • Heater. wrote: »
    They also had a big leaver you could drag from left to right that would do both carriage return and linefeed in one go. Very convenient. Let's call it "new line".
    I remember those levers except downunder ours went right to left. :lol:

  • Heater.Heater. Posts: 21,230
    Oops...

    I have to put these deliberate mistakes in just to see if anyone actually reads my ramblings.

    Or perhaps I was standing on my head typing when I was a kid. Like you guys do :)

    Well, spotted.
  • Heater. wrote: »
    That's a very logical argument msrobots. It might be more complicated though....

    Good old fashioned typewriters, since early last century, had a carriage return mechanism and an independent line feed mechanism. Perhaps under different names.

    They also had a big leaver you could drag from left to right that would do both carriage return and linefeed in one go. Very convenient. Let's call it "new line".

    Then things got messed up with the arrival of teletypes. Their mechanics were not sophisticated enough, or fast enough, or whatever to do a carriage return and line feed at the same time. So, they had no "new line" as a single character. We had to make do with using both carriage return and line feed. A step backwards.

    The mistake comes with the definition of ASCII that only has carriage return and line feed. No newline.

    This gets compounded by the new line character of C (\n) being mapped onto the ASCII/teletypes line feed (hex 0A). Obviously new line is not the same thing as carriage return!

    And then all hell breaks out as Unix, DOS and Mac all get totally confused as to what to do in the absence of that old typewriter feature, new line.

    I think you'll find that the teletypes did not include a "new line" code because they initially used ITA2, ultimately based on Baudot code, which only has 5 bits to represent the entire character set, with two codes reserved to switch between two mappings of the code set.
    Null, CR, LF, and Space are common to both mappings, with the first mapping representing the uppercase alphabet, and the second representing "figures", being the numbers, punctuation, and "WRU?" meaning "Who aRe yoU?", and Delete doubling up on "Switch to Letters".

    There wasn't the luxury of 7 or 8 bits to add things like "new line", or "Start of Transmission", etc. that made it into ASCII.

    ITA2 dates from 1924.

    By the time development of 7-bit ASCII came around in 1963, the use of the CR+LF combination was so common that the addition of "new line" was probably considered unnecessary.

    Baudot code (ITA1) predated the typewriter style keyboard input method for telegraphy by around 30 years, even though typewriters of various forms existed at the time of it's development, as the code was entered using a 5 key method: one for each bit of the code.

    The only "mistake" I can see in the progression of coding styles was the industry choosing ASCII over EBCDIC, as the latter contained Form Feed, Line Feed, New Line and Carriage Return in the host of control codes.
  • Heater.Heater. Posts: 21,230
    edited 2018-05-15 18:38
    AJL,

    You are right. It's very confusing. Wikipedia now tells me that these codes can be traced back to Francis Bacon in the 16th century !

    I'm pretty sure though that the standards we have grew out of what it was possible for the machines to do at the time. A teletype could do a carriage return or line feed in the time it took to transmit a single character. Perhaps not "line feed" which would have required more complex decoding and action in that same character time.

    Later we got "glass teletypes" that could handle cursor positioning. Hence the VT100 escape sequences and such.

    Later we got color!

    Anyway, looking back, if they were short of code space it would have been better to drop the TAB character and have a NEW LINE instead.

    That would have saved a hundred years of confusion, debate and wasted time arguing over what is a line end and what is the size of a TAB.

    That would have saved me having to use the dos2unix and unix2dos commands all the time.
  • potatoheadpotatohead Posts: 10,261
    edited 2018-05-15 19:15
    If it were me, I would just send them both.

    For extra kicks randomize the order. Ducks head! Yes, I am not serious.

  • TorTor Posts: 2,010
    The LF used for line endings in Unix/Linux is only that - an end-of-line character. It has nothing to do with the actual output, if you decide to print the prose. The character didn't have to be LF, it could have been anything. But that one was unlikely to be used in your text files, so it's not a bad choice. Again, it has nothing to do with terminal or printer output.

    The job of the output software (e.g. the printer driver) is to translate the line ending into whatever's necessary for the printer/whatever. So, for your serial terminal, that LF gets translated to CR/LF, because that's what the terminal needs. But it could have been 0x0037 or anything else. But the text file end-of-line indicator would still be LF. Unlike e.g. MS-DOS, Unix didn't hardcode the actual physical output format into their text file format.
  • it is not the time taken for the commands, but different meaning.

    For example printing BOLD was done by "CR" to go to the beginning of the line and printing just the bold stuff a second time, else spaces.

    Same goes for line feed, one could print vertical rows, indented by current position and some backspace to position again.

    There never was a need for CR and NL in one command, it is all the fault of them "C" guys, to lazy to type, in opposite to the COBOL guys...

    And that lever on typewriters usually let you do a CR and when on the left end of the movement some extra pressure was needed to add a LF to it. So you could just do a CR to, say, strike out some stuff you wrote.

    So even there two 'commands'

    Mike
  • cgraceycgracey Posts: 14,134
    I've thought for a while that a sub-$20 trigger character followed by a $20..$7F space count character would be great for consolidating white space and getting around the tab issue. For example, say $1F (trigger) + $7F (count) would mean 96 spaces ($7F - $20 + 1 = 96). This would shorten up source code files nicely and be easy to handle within editors, etc. The ship has sailed, I know, but some convention like that established a while back would have been great. $7F would have made a good trigger character, too, keeping things out of the murky sub-$20 range.
  • Heater.Heater. Posts: 21,230
    edited 2018-05-15 22:48
    msrobots,
    it is not the time taken for the commands, but different meaning.
    Let's just say that I don't believe so.

    Good old electro-mechanical teletypes were marvels of electric motors, relays, cogs and wheels. All synchronized to the incoming "start bit" on the serial input characters.

    As such, I imagine that a carriage return could be done in one character time. A line feed could be done in another.

    Doing both, NEW LINE, in one character time may have not been possible to engineer.

    As you quite rightly point out "...some extra pressure was needed to add a LF..." with the old typewriters.

    In this situation, your abstract meaning are of no consequence. What matters is the signal you have to feed into that mass of motors, relays, cogs, and wheels to get it to do what you want.
  • Heater.Heater. Posts: 21,230
    Chip,
    I've thought for a while that a sub-$20 trigger character followed by ...
    I do believe you have invented the escape sequence.

    Sadly Bob Bemer got their first. In 1960 something.. https://en.wikipedia.org/wiki/Bob_Bemer

  • Heater. wrote: »
    msrobots,
    it is not the time taken for the commands, but different meaning.
    Let's just say that I don't believe so.

    Good old electro-mechanical teletypes were marvels of electric motors, relays, cogs and wheels. All synchronized to the incoming "start bit" on the serial input characters.

    As such, I imagine that a carriage return could be done in one character time. A line feed could be done in another.

    Doing both, NEW LINE, in one character time may have not been possible to engineer.

    As you quite rightly point out "...some extra pressure was needed to add a LF..." with the old typewriters.

    In this situation, your abstract meaning are of no consequence. What matters is the signal you have to feed into that mass of motors, relays, cogs, and wheels to get it to do what you want.

    Given that the carriage return acts on the carriage mechanism, and the line feed acts on the platen, I can't see any mechanical reason for the two actions to require decoupling. As ITA2 did not contain a "new line" code it is impossible to test with teletype hardware without modifying the decoder; Good luck finding someone with hardware who is willing to experiment on your behalf.

    I think conventional inertia lead us to this situation, not mechanical concerns.
  • jmgjmg Posts: 15,171
    edited 2018-05-15 23:14
    cgracey wrote: »
    I've thought for a while that a sub-$20 trigger character followed by a $20..$7F space count character would be great for consolidating white space and getting around the tab issue. For example, say $1F (trigger) + $7F (count) would mean 96 spaces ($7F - $20 + 1 = 96). This would shorten up source code files nicely and be easy to handle within editors, etc. The ship has sailed, I know, but some convention like that established a while back would have been great. $7F would have made a good trigger character, too, keeping things out of the murky sub-$20 range.
    Interesting idea - run length coded text files.
    Way, way back when disk storage mattered, and fixed space fonts were the most common, that certainly could have helped.
    These days, file size in source code is a `who cares` and variable width fonts complicate things...
  • If memory serves, we sent LF CR CR from an SDS920 to a model 35 Teletype. Conventional wisdom held that both CR's were needful.
  • The TRS-80 (Model-1, Level-II-BASIC) had such 1-char-multispaces...
  • Heater.Heater. Posts: 21,230
    AJL,
    Given that the carriage return acts on the carriage mechanism, and the line feed acts on the platen, I can't see any mechanical reason for the two actions to require decoupling.
    Sounds reasonable. We might not know for sure unless we can dig up a teletype designer.
    As ITA2 did not contain a "new line" code it is impossible to test with teletype hardware without modifying the decoder; Good luck finding someone with hardware who is willing to experiment on your behalf.
    Sadly I lost track of my good old friend who had been nursing a good old teletype in his bedroom in 1980 or so.

    Not that he would want us doing experiments on it mind?

  • cgraceycgracey Posts: 14,134
    jmg wrote: »
    cgracey wrote: »
    I've thought for a while that a sub-$20 trigger character followed by a $20..$7F space count character would be great for consolidating white space and getting around the tab issue. For example, say $1F (trigger) + $7F (count) would mean 96 spaces ($7F - $20 + 1 = 96). This would shorten up source code files nicely and be easy to handle within editors, etc. The ship has sailed, I know, but some convention like that established a while back would have been great. $7F would have made a good trigger character, too, keeping things out of the murky sub-$20 range.
    Interesting idea - run length coded text files.
    Way, way back when disk storage mattered, and fixed space fonts were the most common, that certainly could have helped.
    These days, file size in source code is a `who cares` and variable width fonts complicate things...

    But I want to go back to 1980.

    All this talk (in another thread?) about what IDE to use is so BLAH!! We've got a whole computer in the P2 by 1980 standards. A really good one. I like the idea of getting off the reservation and making an IDE that is about 16KB and runs on the P2, itself. Just plug in a monitor, keyboard, and mouse. Instant rock-solid development experience with real-time turn-around like no one's ever seen. It would enable super fast development. People don't know what they are missing with the current paradigm.
  • Heater.Heater. Posts: 21,230
    edited 2018-05-15 23:52
    jmg,
    These days, file size in source code is a `who cares` and variable width fonts complicate things...
    I'm not sure what you mean.

    Source code is still just text. Same as ever.

    A few extra characters because you want spaces rather than tabs is hardly hardly much to ask.

    Perhaps your text is unicode, utf8 or whatever, because you want to support many languages. That is not much to ask either.

    Proportional fonts are neither here nor there. That is all to do with how your source text is displayed. It is not in the source itself.

  • "A good one."

    Yes. Agreed. We got a little taste of that back then when we got to use computers with add on type CPUs.

    BBC micro had provision for a second 6502, Apple 8 bit computers had various add on devices too. Z80 for CP/M, 6809... there were other combinations.

    So, this thread has me thinking. The self hosted tools could incorporate these ideas.

    Just do the RLL text. Why not?

    We will have enough capability to do some very interesting things. Multiple displays? Had that on the Apple. A clever screen font could host a pretty great IDE. An output, or live debug display working in tandem opens up some real potential.

    The thing is, no dependencies.

    It can work as one cohesive, performant thing.

    Filters, translators, whatever can be written to get the good work products out to ordinary tools. Same thing going in.

    Back in the day, I was frequently running some dev environment on an Atari. Would put my code into an interrupt so it would run without really having to disturb that setup.

    Assemble it, drop to BASIC maybe, run it and see it on a screen region. Peek, poke to change run parameters...

    For a lot of things, the P2 could leave a few COGS untouched for a much more robust kind of setup. And Peter has something like it now anyway.

    Since it appears we will have "find and launch file" in the ROM, doing this stuff seems more compelling.

    In any case, I just wanted to riff on what a self hosted environment can mean. It's an opportunity to explore some ideas with very little baggage, and do so on a system that is relevant in its overall scope of capability.





  • jmgjmg Posts: 15,171
    edited 2018-05-16 01:50
    cgracey wrote: »
    But I want to go back to 1980.

    All this talk (in another thread?) about what IDE to use is so BLAH!! We've got a whole computer in the P2 by 1980 standards. A really good one. I like the idea of getting off the reservation and making an IDE that is about 16KB and runs on the P2, itself. Just plug in a monitor, keyboard, and mouse. Instant rock-solid development experience with real-time turn-around like no one's ever seen. It would enable super fast development. People don't know what they are missing with the current paradigm.

    Perhaps, but when I code these days, I have multiple PDF files and many text files open, as well as device simulators, plus google.
    Sometimes also PCB CAD tools....

    That said, I can see good educational material in something like Project Oberon, which should port easily onto a P2-region resource.
    The recent 4Mb 45MHz QuadSPI RAM would expand the available memory nicely too.

    There are some stats here for Embedded Project Oberon (a trimmed down version, minus GUI, display, VGA, mouse, keyboard, compiler, editor etc.)
    The basic core looks to fit under 64k Bytes, so is P2-ballpark.


    Another pathway could be similar to Ultibo, which is looking mature for the RaspPi. The FPC compiler they use has many code generators, so adding a P2 one could be interesting.
    That would allow easier code-split between P2 and Pi working together in a system.
    I doubt FPC could self host on P2, and certainly not Lazarus (> 850MB on disk).
  • cgracey wrote: »

    But I want to go back to 1980.

    All this talk (in another thread?) about what IDE to use is so BLAH!! We've got a whole computer in the P2 by 1980 standards. A really good one. I like the idea of getting off the reservation and making an IDE that is about 16KB and runs on the P2, itself. Just plug in a monitor, keyboard, and mouse. Instant rock-solid development experience with real-time turn-around like no one's ever seen. It would enable super fast development. People don't know what they are missing with the current paradigm.

    I want this too! It'd be like back on my C64, except super turbo multi-core awesome-sauce. We need to make a P2 single board computer. Just plug in a display, keyboard, and mouse, and you boot an SD card into a simple command line OS. Run an editor to write spin2/pasm2 code, then run a compiler on that to produce your binary executable. Then run those... This should all be very doable. For even more retro-like feel, we can make software "chips" for things like sound and graphics displays with sprites, etc.

  • cgracey wrote: »

    But I want to go back to 1980.

    All this talk (in another thread?) about what IDE to use is so BLAH!! We've got a whole computer in the P2 by 1980 standards. A really good one. I like the idea of getting off the reservation and making an IDE that is about 16KB and runs on the P2, itself. Just plug in a monitor, keyboard, and mouse. Instant rock-solid development experience with real-time turn-around like no one's ever seen. It would enable super fast development. People don't know what they are missing with the current paradigm.

    I was thinking about this the other week too, that P2 is so much more than even the first PCs or Macs. We can drive VGA, we can handle SD, networking, but we could use USB HID code at least plus mass storage class. With that we can plug in our usual keyboards and mice or USB wireless dongles as well as Flash memory sticks.

    One of my first pcbs I will be doing will be something like an RPi except with VGA, although there is never any need to have bulky VGA connectors on any board as it is easy enough to have an adapter cable that plugs straight into the monitor and only needs 6 pins on the pcb.
Sign In or Register to comment.