CR vs CRLF Dilema
Cluso99
Posts: 18,069
in Propeller 2
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????
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????
Comments
-Phil
TAQOZ uses CRLF a lot and sometimes CR only to avoid screen fills.
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.
And thanks Peter for the enlightenment
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
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 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.
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.
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.
For extra kicks randomize the order. Ducks head! Yes, I am not serious.
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.
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
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.
Sadly Bob Bemer got their first. In 1960 something.. https://en.wikipedia.org/wiki/Bob_Bemer
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.
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...
Not that he would want us doing experiments on it mind?
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.
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.
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.
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).
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.
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.