Wanted: SIMH VAX VMS tape image tester, take 2

On 12/19/2014 08:20 AM, Al Kossow wrote: Basically, what I've got now is code that adds the "TAPEINFO" line and the created-by line--everything else is read from an external file. For all the application cares, that file could be your favorite chocolate-chip recipe. The issue of what to do with the content and how it should be formatted is one that bears a lot of consideration. A human-readable ultra lightweight markup language is my choice. JSON does require a parser of some sort, so perhaps not a good choice. What, in my opinion, is needed is a simple way to describe what you've got, what you think about it (e.g. "Could be a tape from a Super Whiz-bang 88 system, popular in the 1830s" or "Tape was covered in green mold; this is what we did to recover it."), any external label contents, etc. I think a CRC over the data contents might be useful for giving some sort of integrity assurance. So, maybe a few standardized tags, then free form narrative after that I initially proposed the standardized tags be of a simple but unambiguous form; i.e. colon in the first position of a line, immediately followed by a keyword. Pretty much self-descriptive. Plain old 7-bit ASCII is fine and unlikely to change over time. Here are the very basic SIMH-format issues as I see them. 1. There's no way to express "soft errors". Some interfaces allow for flagging individual frames that contain parity errors, for example. Others allow for retrieving the uncorrected data. 2. The SIMH standard says that a hard error is signified by setting bit 7 in the high-order byte of the block length being set *and* a non-zero block length. What if the interface doesn't allow for the return of raw data? What's the block length then? Even so, where does one put the diagnostic information? 3. Some devices either encode a block number or maintain an internal counter for the block number. There's no place for that in the spec. 4. One can't recognize a SIMH tape image by reading the first few bytes of it--there's no header of any sort. 5. Non textual (i.e. photos) metadata has no provision made for it. I do realize that the interests of those who simply want a simulation capability and those who are interested in archiving do not necessarily converge. Can we come up with a format that satisfies both groups? --Chuck