On Tue, 16 Dec 2014 11:41:07 +0000, Chuck wrote: I fired up an image of VAX/VMS 5.5-2 I had hanging around. I didn't get very far with the tape image though. Which kind of SIMH device is it supposed to be attached as and what do you want done with it? Regards, Peter Coghlan.

On 12/16/2014 06:29 AM, Al Kossow wrote: http://simh.trailing-edge.com/docs/simh_magtape.pdf is the document that I'm using for this. I clearly have some extra padding in the records--that's a bug in my own padding routine. The document does say that records will be padded to an even byte boundary--is this incorrect? If I were to append a metadata record at the end of the image, would this hurt anyone? Perhaps preceded by 4 tapemarks? What I'd like to do is standardize the format in which I'm storing images. In particular, metadata as part of the image is important. SIMH doesn't seem to have any way to record corrected errors or even un-corrected errors. Very strange; one wonders why. Yes, it's a FORTRAN 4.5 tape--just one that I have lying around. --Chuck

On 12/16/2014 09:58 AM, Al Kossow wrote: I'd probably add a field to the header for each record for a CRC for the record data. Should a file become corrupted, I'd think that people would want to know. --Chuck

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