Pertec interface

I can't speak for Jon. But, as someone who's invented a disk-file representation of tapes (for very similar purposes in a rather different context), my primary reason was that I wasn't aware a SimH format existed - though, of course, on reflection, something of the sort must exist. (I'm not sure whether I was aware SimH existed when I invented my format.) Quite aside from that, the SimH format does have a few disadvantages. For one thing, as far as I can tell the only documentation on it, besides source code, is a PDF file; while I do have a program to extract readable text from a PDF, it's relatively recent, and it would not have been worth slogging through a PDF for the purpose. (The PDF also isn't present in the SimH distribution as far as I can see; comparing it with sim_tape.c and sim_tape.h, I find it also is partially incorrect.) Its metadata is binary, meaning that tapes containing pure text are not represented as pure text files. The format's magic numbers are ones that are relatively likely to occur in data, thus making sync loss comparatively serious. It represents a number of things (such as read errors and erase gaps) which make it inappropriately detailed for some purposes. At the very least, readers need to understand them enough to skip them (and the dissonance between the source and the doc is worrisome). It has nothing like a format version number in the files. While not a technical issue, it's another instance of the very problem you are decrying; SimH could perfectly well have adopted the copytape format, with suitable slight variations (such as trailing as well as leading record lengths). As far as I can tell SimH dates back to only the early '90s; copytape goes back to the mid-'80s. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B