Pertec interface tape drive

On Wed, Mar 21, 2012 at 1:11 PM, Gene Buckle <geneb at deltasoft.com> wrote: Yeah it would! Given the limited amount of RAM on an Arduino-class processor (even a MEGA), it would likely have to have some type of SPI-interfaced buffer, and unless that was in the multi-megabyte range, it would be hard to keep the drive streaming. ISTR a 1600 bpi full-sized reel holds around 45MB? Back in the day, I remember having to put a little work into the problem of keeping our TU78 streaming on our 11/750. The TU-80 was a little easier to keep moving. One could put on a 2MB-8MB buffer, read as many blocks as fit, then disgorge to the host, then repeat. Because the usual interface is just an async serial port, it will take some time between "runs", but it would be less stress on the media and the drive to be able to handle many blocks vs start-stop operation. What's the write speed for an Arduino with an SD interface? It might be more practical to build a "dumping appliance" that just spools the tape onto an SD card that is read later. If the tape is blocked in a known or reasonably simple format, it's feasible for the Arduino to emit individual files. Where it gets tricky is with "odd" tape formats, like bootable OS install tapes that may have a handful of different-sized files at the front to bring up a virgin system far enough to restore the big file or files at the end of the tape (common for PDP-11 and VAX UNIX install tapes, for example). Dumping wads of text files (ASCII or EBCDIC) or VMS BACKUP savesets is quite straightforward by comparison. A compromise could be a file-at-a-time tape reader where the host side tells the Arduino what the block size is and instructs the Arduino to read blocks to EOF or EOT. That shifts the analysis and other burdens off the microcontroller. It just tries to do what its told, and that might not succeed if its told to do something impossible, or if the media is too odd. -ethan