On 12/16/14 9:39 AM, Chuck Guzis wrote: No, if that's the format you want to support. I personally think it is incorrect since that wasn't what was written on the tape. He added an end of media tag. I'd put it after that and wrap your record in block marks with an obvious ID string at the front There should also be a magic number and a byte offset and at the very end of that last record so that you can lseek -8*3 bytes from the end, find out the metadata is there and lseek to the start of it. John Bordynuik defined bad block information in the tape images he created. Too bad it was never documented.

On 12/16/2014 10:39 AM, Chuck Guzis wrote: The optional 1-byte padding, as I understand things, is not included in the data record byte count. So it's pretty easy to determine if the record format is padded or not, since you've still got an odd byte count--you need only look at the trailing information--either the trailing byte count field will be offset by one byte or it won't. But, in general, I agree with the padding issue--there isn't any good reason to pad a record, but for being SIMH compatible. I'll flesh out the diagnostic error stuff a bit more. Another thing that doesn't appear to be in the SIMH spec is whether or not the EOT marker occurred during the writing of the last record. That might be useful to some. Indeed, many systems will allow writing of an extra record or two beyond the EOT marker and EOM. Additionally there's no way to indicate the presence of extra BOT markers on a tape. (One technique used in the old manual-load drives was to record a set, then, manually add a BOT strip for another data set. One could space forward to the subsequent BOTs simply by hitting the "LOAD" button on the drive.) Very handy for keeping several deadstart systems on a single tape; but that's probably considered to be an aberration these days. So after the FFFFFFFF EOM record, I propose placing an extra record whose content is entirely ASCII. The first 8 characters will be "TAPEINFO". Lines terminated by an LF. If a line starts with a colon, it signifies a keyword field, which is terminated by a colon, followed by the value of that field, which may extend for as many lines as needed, provided that none begins with with a colon. Some possible keywords might be, but are not restricted to: :IMAGE CREATED BY: :IMAGE DATE: :LABEL DESCRIPTION: :DENSITY: :TRACKS: :READ DEVICE: :SYSTEM: ...and so forth... The record itself will be in SIMH format--i.e, with 32-bit header and trailer record length. That should retain SIMH compatibility. What do ye think? --Chuck

On 12/16/2014 11:13 AM, Rich Alderson wrote: ..and, as a counter-example, there is at least one system/vendor where tapes are usually written in multiples of 3 8-bit bytes (ANSI labels being the exception). CDC 6000, for example--6 bit characters and 12-bit PPU words translate 2 PPU words/4 6-bit characters) to three 9-track frames, so odd-byte length records are not unusual. So perhaps the best way to go is not to pad anything. --Chuck