PTR circuit board

The PTR is a hand-fed paper tape reader. I built it because Al Kossow wanted copies of a lot of precious PDP-8 paper tapes (TSS/8, disk monitor) that I've been saving (ever since I got my first PDP-8 system in 1983), but I was too paranoid to be willing to ship them to him. So I built this board in the hope of reading the tapes myself (my PC04 has been flakey for years and I don't have any 100% working ASR33s). I never got it working, but hope to finish it Some Day. Meanwhile, in May 2002 Al was on a nationwide road trip and stopped by my house in person with a working paper tape reader, and read off the tapes. What a good sport! But that means this project was all for nothing.

I built the PTR in September, 2000. There's nothing to the circuit, it's just an i8051 style CPU (I used a Dallas DS5000T because it's downloadable), with a MAX232 for RS232 level conversion, status LEDs and a button, and a bunch of QT Optoelectronics L14LOB "Sidelooker Optilogic" IR photodetectors, as well as some physically similar IR LEDs. What was fun was the mechanics. I couldn't find photodetectors small enough to fit on the 0.100" centers used by paper tape holes, that would work. Texas Instruments made/makes some little "bullet" detectors which mount directly into a 1/16" hole in the PCB, but the cathode and anode are the two separate pads on opposite sides of the same hole (so they couldn't be plated-through holes, the plating would have to be drilled out by hand which would probably mess up the positioning). And, they don't mount quite flush, so the paper tape would snag on the detectors and tear, unless I did some really careful work with lucite or transparent epoxy or something.

So I figured, the next best thing would be to find detectors which can mount on 0.200" centers, and use two rows of them, each of which reads only half the bits. Then deal with matching up the two data streams in the firmware. So I bought the Sidelooker things from Digikey, and bent the leads so that they could be surface mounted flush against the bottom of the board. Then I laid out a PCB which had pads for them, and holes drilled in the exact positions where the detectors should look, so the detectors can face up through those holes. Then the tape slides along the top surface of the PC board, which has no parts in the tape path, and no traces in that area. There are holes along the edges of the tape path which are positioned so that a loop of thick resistor leads will have just the right spacing on the inside for the tape to pass through.

Then the whole mess can be put on a desk, with a desk lamp over it, and the user hauls the tape through by hand. The sprocket hole has a photodetector on it and is used as a clock signal (the sensor for this hole is slightly offset from the others so that the data bits will all be valid already when the clock has a leading edge), instead of simply being driven by a sprocket with a stepper motor. So the tape can go at pretty much any speed, and the reader will read whatever goes by the detectors. This is not my idea, it was done in CP/M days with readers like the Oliver Audio Engineering OP-80A. But good luck finding one of those now...

I didn't want to be totally dependent on a desk lamp (my desk is a mess), so I also made a daughterboard (which is part of the main PCB until I cut it off with a hacksaw) with a bunch of IR LEDs, bent to be surface mountable and shining down through holes in the PCB the same way the photodetectors are looking up. This can be (and is, in the photo above) soldered on, hovering a small distance over the photodetectors on wire posts which act as the guides for the paper tape (and also supply power to the LEDs).

Firmware is in assembly language, assembled under RT-11 using the nice i8051 assembler from Alan Baldwin's PDP-11 web site. I wrote a little downloader which runs under RT-11 and sends the .HEX file to the DS5000T, then switches to being a dumb terminal program so I can see debugging messages from the firmware.

The bad news of course, is that I never got the stupid thing working. The optodetectors seem to give somewhat random values most of the time. For one thing I probably should have tried harder to find detectors which work with visible light instead of IR, since they seem to be able to see through the board and the tape some of the time. Also I should fine-tune the amount of light shining down on the tape. It was hard to tell what I was doing with the IR LEDs because they give off no visible light, I can only tell what's going on with them by looking at them through a cheap b&w CCD video camera (which is overly sensitive to IR). Finally, I definitely should have poured a ground plane (well, it doesn't have to be grounded, but a plane anyway) around the whole area where the photodetectors are, so that the only light coming at the photodetectors is what's shining through the drilled holes in the PCB (and through the holes in the tape).

I was hoping to be cute about buffering. A problem with a hand-fed reader like this, is that if the user pulls the tape through faster than the host computer accepts data over the serial port, data are lost and the user has to start over. So I put two detectors on the sprocket hole, offset by half a hole (which in retrospect I did wrong, but anyway...), with the idea that they'd give a quadrature encoded signal of the tape position. And there are three LED outputs -- red, yellow, and green, arranged like a traffic light. So, for starters we give the user the green light. Then, if they pull the tape fast enough that the PTR's internal buffer fills past some threshhold, we switch to the yellow light, to warn them to slow down, until the buffer empties out. If they still pull too much tape through, we turn on the red light, because we've lost data. But the beauty is, we know by how many bytes we overran the buffer, so the user can pull the tape backwards (while we count bytes) until they get to the first byte we missed (or whatever, we can keep track if they overshoot in this direction too). Then when they start pulling again, we pick up at the first missed byte.

Return to projects page

Return to John Wilson's home page