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

Mouse writes In the CDC tape community, we have three almost-compatible variants of the SimH format. SimH itself acknowledges two of them. The first, totally naive format came about when someone heard the briefest description of it (32 bits of block length, that many bytes of data, and 32 bits of block length) and ran off to write a reader that produced it. Note that all blocks have that format, even tape marks are 8 bytes long. The second is pretty much as described in the SimH documents, meaning tapemarks are 4 bytes long. Odd-length blocks are not padded. This is E11 format. The third is identical, except that odd-length blocks are padded. This is SimH format. One theory about the padding is that this format congealed at a time when 16-bit I/O on minicomputers was prevalent. I've had to make my readers a bit heuristic to read all three on-the-fly, modulo duplicate tape marks (assuming that the presence of data after 8 bytes of tapemark indicates a single 8-byte tapemark instead of two 4-byte ones (signalling EOI) ignores the possibility (which I've encountered many times) of recovering some data past the shorter thing that overwrote the first part of it). Wiping out bastard formats is a lost cause. Data cannot be destroyed--you'll run across backups of it and not know which format you used that day, so handle all of them. SimH also describes bad blocks, which have the high-bit set in the length but otherwise look normal. Except that most tape drives, without heroics, will not give you any data for an unrecoverable read error (both that and a tapemark read as 0-length blocks; some gymnastics are needed to tell them apart), except that such a block cannot be empty. So what to put in it, if we're noting them at all? I'm playing with ANSI-style labels for this. Some history is at: http://neil.franklin.ch/Usenet/alt.folklore.computers/20001209_New_Tape_Con… , though in there it is asserted that tape blocks cannot be longer than 64K, implying that only two bytes are required for the length. However, I have a tape someone else wrote (HDR2 even says so) with 65536-byte blocks (not every O/S today can handle that--16-bit signed comparisons). To represent that along with 0-byte tapemarks requires 17 bits. Elsewhere someone asserted that a tape block can be as long as the entire tape, which seems unlikely and wouldn't always fit in three bytes. -- Jeff Woolsey {woolsey,jlw}(a){jlw,jxh}.com first.last at gmail.com Spum bad keming. Nature abhors a straight antenna, a clean lens, and unused storage capacity. "Delete! Delete! OK!" -Dr. Bronner on disk space management "Card sorting, Joel." -me, re Solitaire