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

On 12/19/14 8:51 PM, Rich Alderson wrote: When the AI lab archived their tapes, John used .tap, so not even MIT AI ended up using it (which was what TCFS was intended for). Extending .tap, for all its warts, seems more likely to gain traction.

On 2014-12-20 10:10, Jochen Kunz wrote: JSON is not really that human readable, and even less human editable. That said - what are people trying to achieve. If someone can explain that a bit, maybe I can also join the fun of this argument... :-) Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

On 12/20/2014 8:19 AM, Al Kossow wrote: Might I ask what the end of the image is? Some tapes have and require more than two EOT markers for a logical end of tape. Maybe the TAPEINFO and some magic tag should be the very last bytes of a tape image which has meta data, and an index in how much crap is at the end of the tape for metadata also is included in that appended bit. Then you just seek to end of file, look for the marker, then back up by the length of the meta data to establish the end of the dataset. I may have just stated the obvious though. Jim

On 12/20/2014 02:43 AM, Johnny Billquist wrote: Fair enough, Johnny. Let me present you with a not-atypical job I've gotten. A dilligent archivist goes through the long-mothballed closet or storage space of a university department. He comes up with a bunch of media that appears to be associated with long-gone faculty of some stature. The various bits of media (ranging from 8" floppy disks, open-reel magnetic tapes, cartridges, maybe a few flopticals tossed in) have either very sparse or even no labeling (outside of a sticker with a number on it). The archivist's job is to preserve and document what's on these creatures. Well, you can make image files from the media content, but with an image file, such as the .TAP file format used by SIMH, you have no way to include a description of even what system the media belonged to, much less its recording characteristics, operating system or type of file, character set, etc. You don't even have a way to include the content of the paper label on the tape, much less its recording mode and density. Given that this stuff was accumulated over a period of a decade or two, you have absolutely no reason to assume that the media have any relationship to a system that was installed at the university, much less how to interpret the information. A real example: 10 tapes. 2 IBM S/360, 4 PRIMOS, 2 CDC NOS (different versions, one using a proprietary archive format), 2 unknown system--raw ASCII with no tape label, just files separated by filemarks. In no case, was the system identified on a paper label. For the next poor sod who is told that there are image files, but no metadata in those files, is there any hope? --Chuck

There is always an off chance that some of the software that uses those files may expect a fixed length, and will freak out if the length isn't what it had expected. Other software may read and process records until it reaches what it thinks of as EOF. If it looks at physical EOF, it will end up reading an extraneous record, that may be of wrong size, but certainly wrong format. Remember what scanf() does when if encounters data that it doesn't understand. Not all software will exit gracefully when it encounters unexpected extraneous content after the last of the expected data. Therefore, there is some risk involved in appending anything to the file(s). Could you create a separate file that is associated with each file? filename.DAT and filename.INF That way, the .DAT file can be an "UNCORRUPTED" exact image of the original data. filename.INF could be a simple text description, maybe even in complete sentences, containing whatever is known about the file, such as record structure(s), etc. (and editable if/when more is learned!) If there is an expectation of an extreme quantity of data files, then the .INF file should have a fixed machine parseable format, followed by a freeform text component at its end. Maybe even create additional files, such as filename.JPG containing an image of the label. The big problem with that is the requirement that the .INF file stay in proximity to the file containing the image of the data. Maybe STAPLE them together?

From: Fred Cisin Sent: Saturday, December 20, 2014 1:34 PM ...and you've just recreated the essence of the Time Capsule File System. Rich Rich Alderson Vintage Computing Sr. Systems Engineer Living Computer Museum 2245 1st Avenue S Seattle, WA 98134 mailto:RichA at LivingComputerMuseum.org http://www.LivingComputerMuseum.org/