You have inspired me to do my own video. I have a Remex RRS3300. In read mode it moves the tape at 300cps by a capstan and pinch roller and stops it with a brake; in wind mode it goes around 300ips using reel torque controlled by a complex system of AC motors, triacs, brakes, relays, and microswitches, including one that acts as a differentiator. No sprocket. It reads the sprocket holes optically same as the data holes and outputs them as a ninth channel for sync. Compared to your machine, it absolutely flies, so it should make an exciting video if not as polished as yours. I use it to archive tapes that came with my IBM 1620 Data Processing System in 1978, because the 1620's own reader wears out tapes.
I have one of these... just acquired it... and want to hook it up to my Altair 8800... this video is perfect... just what I needed! I set it up and did it exactly the way you did... awesome!
@Robert Baruch - The reel that contains the tape to be read is called the "supply reel" and the empty reel onto which the tape will be wound is called the "takeup reel". The same terminology is used in reel-to-reel magnetic recorders.
oh, yeah, someone else got the pattern further down the comments. I hadn't read this before I posted my guess at hte same thing. It looks like they "ab-used" the parity bit to indicate any byte that wasn't a digit, so signs, comma, and . The dead giveaway for me was the 0x8D 0x8A, which is just too similar to 0x0D 0x0A, which anyone that's spent any time in a hex editor immediately recognizes. I got a piece of plastic tape with something I bought, and I was curious if anyone had an open source reader design to read the tape (besides decoding it manually) to see what it is. This isn't quite that, but there are some open source designs that use LEDs (both as light source and reverse biased as photo diodes) to make an easy reader.
Friend, there are 2 ways to store content on punched tapes. Tapes with text information and tapes with machine code (binary codes), which is your case. Therefore, your tape used as an example in this video is binary, it can be executable file or data file. Although its tape is called binary, the 8 bits combined, shows codes in base 16, that is, hexadecimal. The hexadecimal code is represented by numbers from 0 to 9 and from A to F, totaling 16. This is why you see AB, C6, 3F, EE, etc. So that your binary tape can be a computer game, or it can be a utility, or it can be data, or both. If you want a tape that contains text, which is easy for you to read, then the tape should be in the standard ASCII format, which has 128 combinations, and therefore uses 7 bits. Therefore, tapes that have ASCII text recording, will have the eighth bit always punched, by the way, since it is not used in reading. This allows you to view the naked eye, any tape, and whether it is text or binary, because of bit 8. So if bit 8 is being used, the tape is in machine code, otherwise if bit 8 does not is used and is punched, in one corner, across the row of the tape, then the tape refers to text characters, such as uncompiled source codes, digital books, personal notes, readable data, and so on. It is important to remember that even ASCII characters have their hexadecimal equivalent. So your program in Raspberry should be able to display text as text, rather than hexadecimal. Otherwise, you will continue to see characters illegible for texts, because as you know, the punched tape always represents information in binary form, whatever the content. Hope this helps. Greetings from Brazil.
The first tape he read is definitely a bunch of data with record separators. It looks like they "ab-used" the parity bit (bit 7) to indicate any character that isn't a digit, so if you strip off the "parity bit", you get AD ==> 2D or "-" (minus), AC==> 2C or "," (comma), AB ==> 2B or "+" (positive), 8A ==> 0A (line feed) and 8D ==> 0D (carriage return). Then when you decode the first 2 lines of data, you get: -000101,+000385,+000385,+000410,+000421,+000453,+000491,+000540 +000562,+000658,+000757,+000895,+001069,+001179,+001460,+001694 Looks like some sequence of increasing numbers. This makes sense with what was written on the tape by hand, indicating it's some data for some test at a particular temperature.
@Robert Baruch - Does this Remex reader have a tape brake? In the early 1970s I worked with computers that used paper tape readers and punches, and high-speed optical readers were capable of reading the tape faster than the rather slow computers were able to accept the data. Since the tape reels couldn't be stopped instantaneously, an electromagnetic brake shoe was built into the reader head that could be actuated in less than a millisecond, halting the tape until the computer was ready for more data. In fact, a "stupid computer trick" of the day was to write a program in assembly language that could actuate the brake at audio frequencies. One would stick a sliver of paper into the reader, load the program into RAM, and the brake shoe would hit the paper, playing buzzy, kazoo-like music.
This is pretty neat.Together with that writer you could build a translator system to read/write paper tapes to/from modern formats such as 5 1/4' floppies, audio cassette, and CF cards. Are you going to upload dumps of the data from the tapes you read?Best of luck with your future project stuff.
Nice video. Have you ever tried to read the tape without stopping the drive? I suspect the electronics to read are fast enough that you dont need to keep stopping the tape to read? thanks
Just curious how the MSB/LSB on the tape is defined. I suppose the bit order on the DE25 is well-defined. Are the tractor/sprocket holes off-center to enforce this physically, so the tape can only lay in the reader with the right side "up"?
lmiddleman "Track 1" has a well defined position, the outermost of the group of 3 holes on the one side of the sprocket holes. This is usually the lsb. It seems that the msb is a parity bit for ASCII data.
