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.)
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.]
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.
@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
@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....
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.