Wanted: SIMH VAX VMS tape image tester, take 2
cclist at sydex.com
Fri Dec 19 13:37:13 CST 2014
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
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
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
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?
More information about the cctalk