@Max....even if your KSR33 does not carriage return and line feed, it should be able to read the tape and send the codes out on the RS-232 line to a PC which can then record them. However, depending on the state of your KSR, banging the print carriage against the end of the line might do some damage....I doubt it though, they were pretty rugged beasts.
Alternatively you could get 9 IR leds and 9 IR photodiodes and make your own reader, You will note that the feed holes are smaller than the data holes, this is so the position detecting photodiode will not sense the hole until it the data holes are well and truly aligned...like this
Sorry...tried to post a nice graphic but it would not do it.....
You'd have to get a small MCU to read the 8 data lines when the feed hole is detected, and then send it off in serial form to a PC. You'd also have to make up a guide to keep the paper tape straight as it passed your detector.
I could whip something like this up with a PICAXE but I don't have any paper tape. It also strikes me that you may have to find very small LEDs / diodes or file down some 3mm ones to fit......
BTW if the tape is only a few feet long you could read it manually. I have a graphic with the codes but no doubt that would not post here either....
@David: Actually, this would make a great project for your PICAXE -- you wouldn't need multiple LEDs -- just one light source underneath the tape and then a bunch of photo-diodes on top.
Re having to file down large photodiodes, you could always stagger them like:
Such that diodes 0,2,4,6 were reading one row of holes while diodes 1,3,5,7 were reading the adjacent row -- then when you progress the the next row you can assemble the data from the previous row... if you see what I mean.
You wouldn't need a motor -- you could just pull the tape through by hand.
So, when do you think you will have this built? LOL
A single LED (point light source) will cast an image through the holes that expands the farther you go from the tape. Just move the photodiodes back an inch or so from the tape, to where the projected dot spacing matches the photodiode spacing.
IIRC, the ASR-33 paper tape reader and keyboard are independent from the printer and punch, unless you switch to off-line mode and turn on echo. So just reading the paper tape over the serial line (probably current loop rather than RS-232) should work fine, as long as you can set your serial input to 110 Baud.
Back when I was in high school and undergrad, like proper computer nerds I could read ASCII paper tape pretty well by eye. But that was a long time ago :-) But yes, it's pretty easy, especially with BASIC where each line starts with a line number and you know where the spaces are and you keep seeing the same keywords like GOTO over and over. ASM is even easier, where half the instructions are MOV. The hard part of doing it manually is that it's easy to screw up your program by mistranslating variable I for J and things like that.
[Pedantic note: Max has an ASR-33 (Automatic Send/Receive), which means it has paper tape reader and punch. The KSR-33 (Keyboard Send/Receive) does not have paper tape.]
Thanks for posting the request, Max. The paper tape in question is about 56 cm long, and it seems to be 4 bytes per cm, so 224 characters.
Of course I could simply re-write it, and I don't know where I'd get a BASIC interpreter, but if there is too much human in the loop I'm not sure if it's "authentic". (Ideally I want my printout written with a type ball using a well-used ribbon. :-) ) OCR might feel authentic enough; I suppose I could type in each byte if the tedium doesn't induce errors, and write a quick translator. (Graphics is not my strength, so I can't write the program to read the image.)
@Chester: For what it's worth, here is what the paper tape looks like:
Hi David -- I think you were trying to include a link to the image of your short paper tape program on Flickr, but for some reason it's not appearing -- if you email me the image I will make it available to folks.
Just as an aside, Air Zimbabwe in the old days used to have some paper tape punches connected to their reservation system. Most of the outstations were served by Telex (remember that) and messages were output to these punches by the Res system and the tapes were then sent to the relevant station on Telex using a machine like your KSR (in Zimbabwe we used to use Siemens machines. We only used to use 5-hole tape though - Baudot code, not Ascii.
What am I doing debugging/reverse engineering this? Since N is set to N-1 before the loop, I'm thinking F was initialized to N, not to 1.
I remember being amazed at how quickly the answer came back (relative to 110 baud -- but a state-of-the-art TI-30 of the same vintage has noticable lag coming back with a trig value) so maybe I was trying to be clever and save a multiplication.
@Chesler....you could initialise F by saying F=1 or F=N, but unless the machine defaults to initialising variables to 1 your initial program would not work. But I don't know how that machine behaved....
> "What am I doing debugging/reverse engineering this?"
Well you can see how far you have come since those early days,,,,and a bit of nostalgia is always a good thing I find.
I loved playing with GWBASIC again but I was forever trying to position the cursor with the mouse, or cut and paste....NOT! But as I remarked above, the power of that little program in 60K is awesome compared to todays's bloated code. But then would I want to go back to Wordstar or MS-Word DOS versions without WYSIWYG? I don't think so..... Then again GWBASIC appears on the screen ready to work about 0.4 second after clicking it. You never gain anything without also gaining a disadvantage.....
Wirth's Law: "Software is getting slower faster than hardware is getting faster."
I did take a Tic-Tac-Toe (on a cylinder or something funky) I'd written for Data Structures and it was an amazing example of Moore's Law. In 1982 each move took the computer about three hours. In 2005 the same code was running in interactive time (and I learned it was a very boring game, guaranteed win for the first mover.)
I don't recall pre-initialized variables, certainly not to 1, so I suspect there are lines missing, given there are no lines 50 or 60, and the GOTO 60.
In every Basic I've ever used the interpreter would tell you if you had an uninitialized variable. In fact, one of my favorite computer pranks was when I was at the remote end of a software demo. Two very clever guys from a different high school had created a program in Basic that allowed separate time-shared teletype sessions to chat, using shared files as storage.
OK, so they're in the other room and the program is working fine. We're sending back and forth the usual "HELLO", "HOW ARE YOU?", "FINE THANKS", and other unimaginative messages you can expect from teen-agers who did math instead of literature. I got a diabolical inspiration and sent the message "UNDEFINED VARIABLE IN LINE 1320". They panicked, and started giving commands like "LIST" and "RUN", not realizing that the program was still running perfectly. I dashed into the next room and asked "what happened?" and let them sputter a bit before confessing.
You're right, not that hard to hand translate, with the table on page B-4. Human error in splicing together the photocopies.
So the missing lines are, as we figured:
50 F = N
60 N = N-1
I made little pencil marks on the tape so I can take more photocopies and splice them together and post it to Flicker, but I think this dead horse is sufficiently beaten now (until I get stuck on real work and need to divert for few minutes...)
@Chesler... "Is semicolon a delimeter to PRINT that says don't do a carriage return?" Yes, as I recall
; Semicolon means stop where you are and wait for the next print command
. comma means advance to the next TAB stop (useful for tables)
nothing means do a new line
I've often thought that the inventors of ASCII - who would have been computer nerds - should have thought to put in characters like not equals, equal to or Greater / Less than, etc. But they didn't, so we are stuck with these weird substitutions. I once wrote a terminal emulator in QuickBasic and it needed some weird characters. Fortunately I found a font editing program that let me create them.
I still love Basic and have never learned C (though that is one thing I want to do) and am doing some blogs on the PICAXE MCUs at the moment - great little things if you're a BASIC tragic like me.....
Back to the base topic, did the ASR-33 do lowercase?
The paper tape seems to truly be ASCII (true 7-bit ASCII, not UTF-8 or Code Page 437) but this program was all uppercase, and I think that's all we used, so we couldn't generate codes 0141 to 0172. I guess I'm looking at it backwards, it had a set of characters, and those characters were represented in ASCII; it is not necessary that tape with defined ASCII be read, and it's reasonable and simple for it to interpret 0141 'a' as 0101 'A'.
I remember the Teletypes recognized 0007, ^G, BEL, but we were discouraged from using it, because we had 16 such Teletypes arranged around the room. (Also two CRT terminals, probably earlier than VT-100.)
At that point, high school students had varying typing skills, and even with the program written out in longhand before class, we were limited by how many characters we could type in half of a 40-minute period. (Twice as many students as terminals.)
I think it was a sans serif font. Does anyone know a reasonable facsimile? Or have a sample we could feed into one of those "What font is this?" programs? It had a certain look, and books at the time (I had one which was a scientific approach to Monopoly, where the authors had run a simulation to find the odds of any property being hit) tended to show the results of computations as photographs of the printout, rather than typesetting the table the way the publisher would almost any other piece of manuscript.
The ASR-33 is UPPERCASE ONLY. If you want full ASCII, you need a Model 37 or Model 38. I used a Model 38 quite a bit. It also had a dual-color ribbon, with escape sequences to switch ribbon color. Great fun.
I used the Model 38 to write PDP-11 assembly language with lower-case comments. This was considered heresy at the time and made me a pariah among pariahs -- kind of like an EE student with a circular slide rule.
There's a nice photo of Teletype output on the familar yellow paper at Wikipedia.
I tried to teach my father what I was doing (payback for lots of math he'd taught me and many others). He had tried to learn some programming in the 1960s, but it didn't go anywhere.)
I remember he couldn't get past "N = N - 1". "How can N be equal to N minus 1?" "No Dad, that means 'Set N to be equal to...' "
And because Factorial was the first program I learned (computers were taught out of the math department) every time he asked me or my brother to show him programming, we had to start with that. He could learn videogames and the Web, but through generations of programmable calculators, pocket computers, and PCs that we brought home, he never learned to write a program.
@Chesler....I'm glad Betajet came back to you and advised about the ASRs, as I know next to nothing about them.
As Betajet also remarked, the tape has even parity, ie bit 8 is always such that you have an even number of bits. So only bits 1-7 are used, as you say, true 7-bit ASCII.
When I was playing with GWBasic I noticed that it always displays commands in uppercase. If you look at a program file in (eg) Notepad, it looks like gobbledegook - I suspect they tokenised everything to save memory.
< ...codes 0141 to 0172..." I take it those are Octal? Long time since I have seen that. reminds me of what I think is the first story I ever wrote for EE Times:
Pedantry: Pascal uses "<>" (less than or greater than) for "not equal to". Pascal also uses the Algol ":=" for assignment, so that you can use "=" for equality. This avoids the need for C's "==" equality operator.
I blame the Model 026 keypunch, which influenced Fortran. The creators of Fortran were mathematicians, so I'm sure they would have loved to use the proper mathematical symbols instead of .GE. and .LT. for ">=" and "<". I'm sure glad we've left those silly notations behind! [What? You say they're still around in HTML? 'Strewth!]
Of course, now that we have full graphics displays and the Symbol font, we can fully expect languages to take advantage of these advances and not have syntax designed for a Model 38 teletype, right?
As for proper printing of ">=", "<=", and "!=", you can of course use overstrikes on a teletype or line printer. And if you're really a gutton for mathematical notation, there's always APL :-)
I was in a Pascal class for a day or two before I was pulled out to troubleshoot a hardware problem with the new equipment. I do remember having trouble remembering when a semicolon was required and when it was not. The instructor said there was sometimes a certain feel to when it was needed. Not my kind of language .... Another time he pointed out that you could stomp on the first byte of a string to change it's length, which was quicker than using the built-it function. When I ask why bother to use the function, he said anyone on his staff would be fired for doing that (I guess because it was not as obvious as using the function). Finally, when I asked why the printer diagnostic was so slow printing a sliding alpha test, he said the programmer was recreating the line each time, incrementing the initial character. When I asked why he didn't just create the full set of characters twice and step across it with a substring function, he replied it was written by a trainee. It thought to myself, "Why is Uncle Sucker paying to train your people?"
Pascal was "Wirth" so much he had to write Modula-2. ;- )
betajet: "I blame the Model 026 keypunch, which influenced Fortran. The creators of Fortran were mathematicians, so I'm sure they would have loved to use the proper mathematical symbols instead of .GE. and .LT. for ">=" and "<". I'm sure glad we've left those silly notations behind! [What? You say they're still around in HTML? 'Strewth!]"
There were only so many keys on the keyboard of a teletype or keypunch, and only so many characters in the character set (7 bits plus pairity). Even IBM mainframe printers didn't always have a full character set. Our college used Assembler, RPG, Fortran and PL/1. PL/1 used a semi-colon to end a statement, but our print train didn' t have the character. The IBM PL/1 compiler had an option which we set as default so we could terminate lines with a comma and a period (",."), as if the semicolon fell over on its side.
Knowing how old FORTRAN is, it may be that they didn't have the ">" and "<" symbols available on printers. The IBM 029 Keypunch did have the > and < characters on the keyboard.
By contrast, IBM's EBCDIC code had a cent sign ("¢") which their mainframe terminals had but that teletypes and ASCII-based equipment didn't have (we Americans are so Jingoistic!).
On the PC one can use CHARMAP.EXE to find it or type Alt-0162 (using the numbers on the Numeric Keypad) to enter it (Like this: ¢).
And if you're really a gutton for mathematical notation, there's always APL
I think glutton is too mild of a term. Masochist comes to mind ... but if you want arcane notation, try FORTH (which I did play with on my TI-99).
Thank you for contributing this week's dose of nostalgia.
Dr. Wirth intended Pascal as a language for teaching good programming practices. I still think it's a terrific first programming language. OTOH, Modula-2 was intended as a serious programming language.
Teaching a programming language isn't easy, particularly if you haven't mastered it. Not understanding semicolons in Pascal is pretty lame. A Pascal semicolon is a statement separator. You put it between statements. Thou shalt never place a semicolon in front of "else". In contrast, a C semicolon is a statement terminator. It also converts an expression like "x = 3" into a statement like "x = 3;" Go ahead an put a semicolon in front of "else". Go ahead and write "if (x >= 0) y = x; else y = -x;" So what it it's ever so much uglier than "if x >= 0 then y:= x else y:= -x". OTOH, in C you can write "y = x >= 0? x: -x;" which much nicer than Pascal.
While FORTH is something of a write-only language, it does make a nice intermediate language and is dirt simple. But APL is the epitome of the write-only language.
@betajet: "Thank you for contributing this week's dose of nostalgia."
You're welcome! When I'm not reading SciFi I'm reading history.
@betajet: "A Pascal semicolon is a statement separator. You put it between statements. Thou shalt never place a semicolon in front of "else". In contrast, a C semicolon is a statement terminator."
Coming from a PL/I background I probably thought of it as a terminator, thinking of "else" as a separate statement (line). My brief encounter with Pascal was 30-some-odd years ago.
I try to write code so I can follow it a later time (somewhat self-documenting), using indenting. I would write: if (x >= 0) y = x; else y = -x; in two lines as:
if (x >= 0) y = x; else y = -x;"
I can see how if you read the Pascal statement from left-to-right it's almost a complete sentence, not broken down into separate steps like above:
if x >= 0 then y:= x else y:= -x
but, "OTOH, in C you can write "y = x >= 0? x: -x;" is great for compact syntax and saving space back when disk space was dear. But hey, it was written by system programmers looking for something between assembler and a high level language. I hope to learn it and play with it some day (I like the bit where you can stuff in some assembler or machine code in-line; a hacker's dream (from the original def of hacker).
Thanks David Ashton. I think Y-512 may have been my account on the timeshare. No idea what was supposed to be at lines 40 and 50 (presumably one of them initialized F), or why they didn't save to the tape. Line 85 :-) I guess the day before I'd written my first endless loop!
@Chesler....no problem, I had lots of fun with it. (If MS had not updated everything I'd still be quite happy with DOS and BASIC and Wordstar :-)
In your original program, if Nwas input as 1, it would have got 1 subtracted from it first, and you would have got an endless loop. Mine can cope with 1 but not 0 or negative Ns.
I remember being taught that unconditional jumps like GOTO 60 were a no-no, and to use DO WHILE or FOR N = x TO y instead. Good point.
I did a FORTRAN course once and put and endless loop in a program, I got presented with a 2 inch high stack of paper and a very stern talking-to from the computer centre manager when I went to collect my printout. We all have to start somewhere.....
The name BASIC came from Beginner's All-purpose Symbolic Instruction Code and it was developed at Dartmouth (not Microsoft!). It really was pretty basic at first.
The original BASIC didn't have a DO WHILE construct, only FOR...NEXT loops and GOTO and GOSUB statements. I don't remember if the version I used had the ON...GOTO/GOSUB statement. In the earlier versions every statement had to have a keyword at the beginning, so to assign a value it was LET Y=3 or LET X=X+1. It was great day for typists when BASIC interpreters finally made the LET part of an assignment statement optional!
I seem to recall that Dartmouth BASIC had built-in functions to perform matrix manipulations (MAT INV to invert, something I never understood or used; math was not a strong point). After all, it was invented by two Math professors using student labor. The professors (Kemeny and Kurtz) wrote a book called "BASIC Programming" that gave examples of how to us the language in various academic disciplines.
As for piles of paper ...
The control panel on the IBM 360 Model 25 had half a bazillion lights, but two of them were Wait and Sys. A hard Wait was when something got farbled and the program just sat there; it was called a Hard Wait. When a student's program started looping somewhere in core, the Sys light came on and stayed on, so we nicknamed it a Hard Sys.
A good source of large piles of paper occured when a FORTRAN student tried to print to a channel that wasn't punched on the printer's control tape (IBM 1403 printer). Then it was a contest to see if the operator could stop the printer before it slewed through a whole box of paper before he cancelled the program! At least we could recover the paper in that instance. If their program got into a loop (but not a hard Sys) and printed one character and a page feed continuously, well, there would be a pile of scrap paper.
@stargzer...thanks for all that.. I did know what BASIC stood for but not about its origins. And I didn't use any of the very early ones much, though I do remember working on something that needed LET for assignments. (Maybe that would have made more sense to your dad, @Chesler?)
> The original BASIC didn't have a DO WHILE
Just looked up in GWBASIC's manual and it does not either. I was probably thinking of QBASIC which I used a lot. Never used DO WHILE much, I preferred the other conditionals.
Gotta love the bazillions of lights (and sometimes switches) on the old computers...
I liked FORTRAN at the time, but I'd be hard pressed to remember any of it now :-)
It's nice that GWBASIC is still available, but you ought to check out FreeBASIC. It can be set to accept old-school GWBASIC syntax, but has a lot more modern capabilities, as well -- arrays of up to 2GB or so, high-resolution graphics in true color, user-defined types, and structured programming (functions, subroutines, etc.)
I use FreeBASIC with FBIDE: http://fbide.freebasic.net/
@FlyByPC...I have heard about FreeBASIC and might give it a try sometime. I used GWBasic here as it was from about the right era for the program. FreeBASIC says on its website that it is very compatible with QuickBASIC which I worked with a bit. I'll put FreeBASIC on my ever-growing list of things to do. I need to win the lotto and retire so I can get time for all the interesting stuff... :-)
Flurmy wrote: Think about the C syntax: it's made almost unreadable just to save some bytes IN THE SOURCE CODE!
If did your editing using ed on a 10 char/sec teletype, you'd want concise source code too :-)
Personally, I mostly like C's syntax, especially assignment operators like "+=" and the conditional expression "a? b: c". However, chacun a son goût (YMMV). As Flurmy said, there's always Cobol if you really like to type.
@MAX: "Although the paper tape reader appears to work fine, the carriage-return / line-feed needs some attention."
If it's a problem when the print head returns to the left, there is an adjustment.
Under the lid, on the left side, where the print head returns, is a cylinder call the dash-pot. The print head has a sort of a piston with a rubber ring (or something) that is supposed to go into the cylnder. A lever on the outside head of the cylinder can be moved over a hole in the end of the cylinder to set the amount of air allowed to escape and fine-tune the cushioning effect. As I recall there are a couple of screws on top to loosen and adjust the cylinder. You'll get a nice little "pop" sound when it's adjusted correctly. I had to do that on an ASR-33 when I had a part-time job teaching programming to 4th, 5th, and 6th graders back in 1973-1974.
If it's not returning, I'm not sure what the problem is. Some have an autoreturn set so the print head automatically returns after 72 or 80 characters. Sometimes the autoreturn is not set and it just keeps piling up characters in the last positon.
But, if it's doing a line feed an printing a character in the middle of the line, you need to send two chariage returns and a line feed to the print. This was the standard -- it's a matter of timing. I've also seen specs for other printers that call for varying numbers of carriage returns or nulls, depending on the bit rate and how far over to the right the print head is (it takes longer to return from 132 characters than from 80, and no printer in the old days could print 960 chars/sec (9600 bps - 10 bits/char).
There once was a Star Trek program that would print out S T A R T R K in the middle of the line, space out to 80 characters, and then print a carriage return with no line feed followed by the E, which would print out between the R and the K.
@Stargzer: If it's not returning, I'm not sure what the problem is.
If you type characters you can see them on the paper (very faint because the ribbon is 30 years old -- I iave to pick up a new one when I get round to it) -- but when you hit the return key, the carriage returrns but there's no line feed, which there shoudl be when you are manually typing on the keyboard.
No there should not be a line feed when you manually hit return. The ASR uses 0x13 to move the carriage left, nothing else. It uses 0x0A to roll the paper up, nothing else. I have forgotten if there is a LF key on the keyboard, but if there isn't , CTRL-J does it. Like David I spend a lot of hours on an ASR-33 connected to a HP 2000 E basic interpreter on an HP 2100 A mini.
You are correct. I was thinking decimal 13 and wrote hex 13. 0x0D is indeed CR. The point still is, though that CR on an ASR33 is not supposed to roll the paper, only move the carrier to the left margin
@ Wilton.Helm though that CR on an ASR33 is not supposed to roll the paper, only move the carrier to the left margin
IIRC the Model 19 (5 level Baudot) also had separate charcters for carriage return and paper roll. The carriage was a massive affair with type bars, and the shift between letters/numbers caused the entire carriage to bump up and down. A paper tape with repeating shift/unshift codes was the basis for a rather naughty joke...
Just for curiosity, I googled ASR-33 and pulled up a photo. The line feed key is just left of the Return key. Neither is large or special shaped, like we are used to on keyboards today (or even typewrites of the past). Just one more round key to press. It wasn't easy typing on those things. The touch left a bit to be desired.
Often when connected to a computer, when the computer saw a CR it responded with CR and LF, so pressing LF was not necessary. I did work on one OS (the HP OS that we ran Fortran and Assembly on) that expected just a LF and returned CR and LF.
The ASR-33 (and the original ASCII definition, which it followed) is why we have CR and LF in text files on MS to this day. Contrast that with Linux (and default C behavior) where only the LF mattered, and we've been fighting conflicting standards for many years.
@Wilton.Helm: "... is why we have CR and LF in text files on MS to this day. Contrast that with Linux (and default C behavior) where only the LF mattered, and we've been fighting conflicting standards for many years."
Wikipedia's Newline article has more information, including which systems used CR, LF or CRLF for a new line. IBM mainframe EBCDIC code had a Newline (NL) in addition to CR and LF, but then, that's not ASCII. In addition to Windows, some DEC systems and "... and most other early non-Unix and non-IBM OSes ..." used CRLF.
Also remember that on a TTY, the computer always sent CRCRLF (2CRs) to make sure the type head had enought time to return to the left before starting again. An LF somewhere in the middle of the line would roll the platen up one line without moving the type head and resume printing from that position. I think I mentioned it before, but there was a Star Trek game n BASIC that would go to the end of the line and do a Line Feed and then as it returned it would print a character in the middle of the blank line (I think it was the "A"), then start spacing over and printing the rest of the letters "S T R T R E K", spacing over the "A" that was already on the line. A programmer showing off his knowledge of the hardware!
The CR without a LF was also used during logons, where the computer would do a CR without an LF while printing several lines of garbage, overprinting each other so no one could see what was typed.
"You have to understand how a starship works." Captain Kirk, "Star Trek: The Wrath Of Khan"
Ah I remember Star Trek. We played it back in 1978? Using ASR33's connected to a PDP10 mainframe. It was the main university computer, but if you joined the "computer club" you could buy CPU time by the second, I think a couple of bucks bought you enough to play star trek an hour a day for a month or equivalent "real work".
@stargazer: The asr33 was usually operated half duplex so it was usually one CR typed by you and a CR and LF sent by the computer. I do recall needing to use null padding though, So you would send <CR> <LF> <NUL> from your program to avoid the typing_something_on_return problem.
And you could ring the bell by entering <ctrl G> so you would put these on the paper tape for amusement.
In 1980 I had an ASR33 at home (in the shed) , it was hooked up to a card cage scavenged from a 6502 based space invaders video game, the circuitry for the coin mechanism switch and coil were modified minimally to make a 20mA serial circuit for the ASR33. I copied an EEPROM from an AIM65 development board with minor changes. The video memory and program memory were the same, so you could see your program and data as little dots on the screen. All of the program and data were entered using the ASR33, and programs were "saved" on paper tape. I recall I wrote a version of Conway's Life on it , and you needed to be careful not to overwrite program data. I did some of my preliminary research work for my Masters on it, even with severe restrictions (like all variable were two characters, beginning with a letter) , you could easily do monte-carlo studies on a dozen or so complex equations, you would just start it off, and come back an hour later.
I found the ASR33's were pretty reliable, but needed to be well oiled.
Depending on the system and the software, sometimes you could specify how many NUL characters to send with a CR, to "time-pad" the output and allow the carriage to return fully to the left side. That is why sometimes, in movies or videos and such, or if you remember, the teletype would make a duh-duh-duh-duh type sound when it was "typing" and the carriage was at the left side. This was the "wait timing with NUL characters" that was common. How it actually sounded and looked depended on how far across the carriage it had typed the line it was on, which was directly proportional to the amount of time to return the carriage to the left. Shorter lines made the wait NULs sound and look different.
The CR and LF were simply following the practice of manual typewriters. They usually had a big paddle connected to the carriage. At the end of a line you reached up and yanked the paddle left which by default would both return the carriage and rotate the platten to the next line position.
However, the paddle was actually a two-stage mechanism. If you pulled it gently you released the carriage to slide without advancing the platten and this was something you would do for example when correcting or sometimes filling out a form. There was not always a backspace key, since that was mechanically more complicated than using the paddle to free the carriage.
You could also rotate the platten independently by just gripping a wheel-shaped knob at the end of the carriage and turning it, which was typically set to click in half-line steps (and you could also adjust the return paddle to cause advance by 1, 1.5, or 2 steps).
So, the ASCII system was inspired by a litteral match to the typewriter mechanism which it was originally designed to drive. That is also where the BEL came from: manual typewriters had a bell you could set to warn you when you neared the right margin so you would think about how to choose the last word on the line or whether to break a word. The teletype repurposed this to alert operators to ends of messages.
STAR was dead on with the dashpot... it gets dirty with paper dust, oil from the mechanisms, and oily chad which gets everywhere.
This simplified shock absorber gets out of alignment due to the constant slamming of the printhead back to the left side for every RETURN.
I think 2 screws on top of the cup mounted on the frame get loose and you simply need to align it so the DASH plunger slids in freely... also adjust the sliding handle thats over the vent hole on the right so you hear that nice PHISSHH sound after every RETURN.
I remember a manual paper tape reader that me and Don Harrison hard wired it into an original IMSAI computer as we were tired with the teletype's 110 baud slow rate. We were amazed when we manally loaded the program and then started pulling the tape through the reader and the data appeared on the screen. The data was read by photocells under the tape and since the feedhole was smaller it was used to clock the data into the computer.
And yes, my ASR still works but is in the attic and the EX got it along with the house...
@Mr. Contractor: "I remember a manual paper tape reader that me and Don Harrison hard wired it into an original IMSAI computer as we were tired with the teletype's 110 baud slow rate. We were amazed when we manally loaded the program and then started pulling the tape through the reader and the data appeared on the screen. The data was read by photocells under the tape and since the feedhole was smaller it was used to clock the data into the computer."
An IMSAI! When you say manual, you mean it wasn't from an ASR, right? I remember a BYTE Magazine article about making a tape reader with photocells, includine one to read the feed hole and use it for clocking in the data. Kind of a combined start- and stop-bit!
Speaking of the slow data rate of the TTY, I remember one December when I worked at the Social Security Administration. At that time a lot of our traffice went out over a GSA TTY network that was also shared with other agencies (our online system with cluster controllers was only a year old then). Someone had sent out a "MERRY CHRISTMAS AND HAPPY NEW YEAR!" message via paper tape, complete with ASCII art, that must have taken six or eight feet of paper to print out. They sent it with the All Points Routing Indicator in the header, sending it not just to all SSA stations (of which there were very many), but to ALL stations on the network. It took hours and hours for GSA to chase down and kill the traffic on the various relay points. I don't know what happened to the hapless operator who did that!
Let's do the math! At a conservative exstimate of 75 characters per line (72 characters per line (the usual for most TTYs) + 2 CR + 1 LF) × 6 lines per inch × 12 inches per foot × 6 feet (conservative) = 32,400 characters. At 10 characters per second (110 bps / 11 bits per character) and 60 seconds per minutes, that's 54 minutes! Eight feet would be another 18 minutes. That's one LMF message, to say nothing of the cost to send it!
betajet: in C you can write "y = x >= 0? x: -x;" which much nicer than Pascal.
Yuk! That's exactly what I try to avoid like hell. As you said, chacun a son goût, but I think I'm in good company. MISRA and alike strictly forbid mumbo jumbo like this.
If their program got into a loop (but not a hard Sys) and printed one character and a page feed continuously, well, there would be a pile of scrap paper.
I worked on a CDC6600 via punched cards and batch processing. When, hours later, I went to pick up the result of my program I met a friend who told me: "Ha, ha, ha! Someone printed a pile of paper so high full of numbers! Ha, ha, ha!" Surprise: someone was... me! I mistakenly swapped the job control cards, putting the "load and run" before the "link" one. obviously the "program" crashed violating the memory fence and I got the dump of the whole memory in octal (each location was 60 bits, i.e. 20 octal digits)...
The Betajet wrote: in C you can write "y = x >= 0? x: -x;" which much nicer than Pascal.
Flurmy wrote: Yuk! That's exactly what I try to avoid like hell.As you said, chacun a son goût, but I think I'm in good company. MISRA and alike strictly forbid mumbo jumbo like this.
Well, I learned LISP before I learned C. LISP's fundamental conditional operator is COND, which is an extended version of "a? b: c". LISP is a great language for reasoning about programs, and proving that they work. (For best results, use equivalent mathematical notations rather than lots of parentheses.) "a? b: c" is also a great notation for writing multiplexers in Verilog.
I'm puzzled that some people don't like "a? b: c", but I accept that some people would rather write Basic or Fortran :-)
As a student at Roxbury Latin School, I also stored my first computer programs on paper tapes. They ran on the Harvard University SDS timeshare computer through a dial-up line. It seems that reading old paper tapes would be a great opportunity for a SmartPhone APP. The holes are very large so it ought to be possible to pull the paper tape across a black background and make an iPhone movie of the passing tape. The iPhone could be fixed about three inches above the tape and oriented along the long axis for a high resolution read. The camera has sufficient resolution to read at a much greater distance. Guides could keep the tape aligned in the center of the image. The motion could easily be tracked (no need for accurate speed control, just pull the tape) and each row of dots could be decoded. As I recall, the symbology was simple ASCII so the results could be directly reported in familiar text. After the decode, if the data were garbled, an option could be included to flip the orientation and / or direction of the data since the old tapes might not necessarily get fed rightside up [mirror image read reversing the bit sequence] or in start to end sequence [they might be reading end to start reversing the character sequence].
@mjkirk12: Forget the paper tape reader - who gets a private office with a door these days!
They don't let me out very often :-)
Remember that I'm theoretically working from a home office -- it's my choice to actually rent a real office (it makes what I do seem lime a real job LOL) -- I have one room in a really large (and not hugely populated) building owned by a company I know -- they are kind enough to give me a really good deal (and they threw in the office door)
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.