johnr's Virtual Paper Tape Reader

Virtual Paper Tape Reader

see copyright notice. Page created 1-Dec-2020. Use the button groups above to navigate quickly around the site.

I'm eternally grateful to Brentwood School, and Mid-Essex Technical College (METC, as was) in Chelmsford, for giving us school-kids access to the latter's NCR-Elliott 4120 computer in the late 1960s and early 70s. For the most part, our input was on 80-column punched cards - we had some hand-operated punches at school, and an obliging student who lived in Chelmsford ferried boxfuls to and from the College, also returning the lineprinter output they generated (mainly listings of program errors, but including the occasional burst of runtime results!).

Paper tape was a much less bulky storage medium, but we were only able to use it occasionally - by visiting a room full of noisy Westrex teletype machines at the College. The computer had its own paper tape punch, with which I created "backup" copies of working punched-card programs. A few of these have survived; in the photo are BRENTRAN (a set of numeric and string I/O procedures written in NEAT assembly language), and PTEDIT (a program to edit paper tapes, written in ALGOL 60). Sitting on top is a calendar generator, which I later wrote (reluctantly) in FORTRAN IV for an IBM computer in Cambridge (it's on ⅞ inch tape, 6 bits + parity, as opposed to the others which are 1 inch, 7 bits + parity).

Note, in passing, my METC user number 3052, which predates username JOHNR by many years! Also, the "slashed" letter Os; that was the convention on their system, although it was generally more usual for the 0 (zero) character to be "slashed".

[Paper tape against dark background]

Having recently "discovered" those tapes in a cupboard, I thought it would be fun to write some software to read them, using a series of photos as input. My prototype Virtual Paper Tape Reader (VPTR) can decode up to about 50 inches of tape per [16 megapixel] image, provided it's laid out fairly straight on a dark background. That's 500 characters! I've had an interesting time reading the first tape (BRENTRAN), including a grim reminder of the chaos that results when the centre of a rolled-up tape drops out. That used to be surpassed, in the computer room, only when a card-reader jam caused a magnificent spectacle known as a "card fountain". Pity the poor operators who had to crawl around the room picking up cards!

[Screenshot of Virtual Paper Tape Reader]

VPTR's control panel is overlaid on a window which displays the text as it's recovered from the image. The "Load" button launches a standard open file dialogue, then the navigation buttons can be used to nudge the tape start into the viewport. The "Engage" button attempts to find and lock onto the nearest sprocket hole; if successful, green cross hairs and a decoded character, in Hexadecimal and Ascii, appear as above. The Right and Left buttons now respectively advance and backspace by one character. "Read" will attempt to read to the end of the tape, displaying the results in the text window and appending them to a buffer which can be written out to a text file with the "Save" button. "Clear" clears the buffer and text window.

The software continually tracks the top and bottom tape edges, adapting to changes in tape dimensions, brightness and contrast. It also monitors the topmost (parity) track, measuring the horizontal offset of every hole from its datum, to calculate a "skew" factor that's used when detecting holes on all tracks. Offsets can be applied manually to the luminance level which distinguishes the paper from the holes in it ("Threshold"), and to the vertical position of the sprocket holes ("Tracking"). If - despite these tweaks - a parity error occurs, then any read in progress stops, the cross hairs turn red, and either the Hex or the Ascii value can be edited. In the case illustrated, a tab character (code 09) has been misread as code 08; these codes are "unprintable" (denoted by the § symbol), so the correction must be made in the Hex box, whereupon the "Read" button becomes available to continue.

Future improvements? One unforeseen problem is that some tapes have things printed on them, e.g. arrows indicating the feed direction. The easiest way round this would be to allow an image of the reverse side to be used! I'm also tempted to extend the skew detection to all tracks, ultimately perhaps making the sprocket holes redundant (being smaller, they've proved to be the biggest problem at low image resolutions). I'll probably add options for different tape formats, such as the IBM one mentioned earlier, too.

For the amusement of fellow geeks, I've put a copy of the recovered BRENTRAN program here. Note that the tab positions were originally based on punched-card fields. Also, the backslash (\) originally rendered as a pound symbol (£), which was used, like the dollar in American software, to prefix system-defined names. In retrospect I should have used the latter in place of the various numeric addresses that appear in BRENTRAN, but, hey, I was only 16! I'll write more about the 4100 architecture, and runtime environment, in due course.