On 09/25/2017 08:27 AM, Anders Nelson via cctalk wrote: > Cool! Aaa, good to know one of them can't be used individually. > > What might be involved in using one with a PDP-8/e emulated on SimH? I can > build/program any sort of custom USB device to interface this big stuff, > which I'll open-source of course. But does it need special power/startup > stuff beyond a control interface to get it working?
I can speak only for my experience with the 7970B, which is an 800 NRZI model and has no "slave' mode. The distinguishing characteristic on the 7970E between master and slave is that the slave does not contain the 1600 PE read or write circuitry. If you're accustomed to a Pertec interface, then the 800 interface isn't terribly different, just dumber. You still have a connector for the basic motion and status commands (i.e. forward, reverse, rewind, high-speed and online, loadpoint, ready, protect) and you have two 8-bit+parity clocked data channels for read and write respectively, each with their own connector. However, there is no formatter, as on Pertec interface drives. You get the raw, framed and deskewed data on read and pretty much anything you want to put in on write. No "handshaking" as the interfaces are not buffered. Thanks to Al, I've just adapted a 7970B to used a combination head stack for 7 and 9 track tapes. Some 7970Es already come so equipped, but they're not common. I fabricated a small PCB with 5 miniature DPDT relays to do the switching and it fits right under the head assembly, with the B's 9-track read amplifier plugging in as usual. The lack of a formatter means that you'll have to do the work of gap detection, parity checking/generation and CRC/LRCC interpretation and generation yourself, as well as manage the control lines. I used a small STM32F407 MCU board (about $10) which has lots of 5V tolerant I/O, so receiving data and status is no problem. For driving control lines, simply set the GPIO pins for open-drain operation. There's something like 24ma of sinking capacity on those, so again, no need for intermediate logic. Since I'm interested in reading tapes, but not writing them, I can't address the issue of what to do about that end. My setup uses a serial port for interaction and a USB port that makes the onboard SDHC look like a generic storage device. So, read a tape, dump the data into the SDHC (Chan's FATFS software is useful); suck it out via the USB port to a PeeSee. To handle 1600 PE data would require yet another layer of software. I realize that not many are interested in my peculiar needs, but perhaps this will go to answer a question or two. --Chuck
