Wanted: SIMH VAX VMS tape image tester, take 2

[Chuck Guzis]

On 12/19/2014 08:20 AM, Al Kossow wrote:
> On 12/19/14 8:18 AM, Al Kossow wrote:
>> On 12/18/14 11:07 PM, Chuck Guzis wrote:
>>> Okay, I think I've gotten the SIMH image thing straightened out--and
>>> I've added a descriptive record after the EOM marker in the image.
>>
>> looks OK, but it may be difficult to parse
>
> you may want to consider JSON
>
> http://www.json.org/xml.html

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