Let's develop an open-source media archive standard

Hi Sellam, I sent off another email with a comment with regards to what I was proposing. There is a misunderstanding with regards to what I was proposing. I was not looking at having two copies of the data. Only one is required and that is what the formatting information references when it needs sector data. I think it would be better at this point for us all to try and understand all the facits of what is being done. My proposal for the data blocks are not a file specification per se. I would gather that a data block would consist of a descriptor that would indicate how many blocks comprise the data, a data type such as "file", internal data (boot sector), block ID for use with the formatting info. The formatting info would tell whether it is sequential, track/sector oriented, etc. There is no need to create a bunch of different types. Even your description created two distinct formats for data. I was being more generic in that a engineering design for a image file could be created that was not difficult and could satisfy both EASY emulator access for non-physical media access and image file description for another tool to actually create the media required. best regards, Steve Thatcher -----Original Message----- From: Vintage Computer Festival <vcf(a)siconic.com> Sent: Aug 11, 2004 9:07 PM To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk(a)classiccmp.org> Subject: RE: Let's develop an open-source media archive standard On Wed, 11 Aug 2004, Steve Thatcher wrote: This can be done anyway. Parsing the tags should not be too difficult. And unless someone can come up with an elegant way of doing it, what you're proposing will require two sets of data in the imagefile: one in the structured format and one in an unstructured format. I suppose tags could be added to specify this is the case so that "lazy" programs don't have to go through all the trouble of parsing the structured data. You're describing an imagefile that contains a filesystem image, rather than, say, a disk image. This can be accomodated in the spec, but it's a different type of image than what we've been discussing. Remember, I envision the spec being able to handle: 1) A filesystem image (as you describe) 2) An image in "logical" format (i.e. blocks structured in tracks and sectors for a floppy, or cards for a punch card deck) 3) An image in "raw" format (a bit stream, or the actual punched holes And there's actually a: 2.5) Magnetic media at a level below the "logical" format (decoded tracks and sectors) but above a bit-stream, which would be the raw sectors on a disk or tape including address headers, data headers, prologue/epilogue bytes, sync bytes, etc. Right. If you choose to store an image in the raw disk format. It's up to emulator writers to read the spec and adapt to it. We'll make the spec as flexible as possible, but first and foremost, the spec is intended to archive images of data media, and not to serve as a universal emulator image format (though it should be able to be used as such). I think I understand what you're saying. Let me know if I still don't get it. -- Sellam Ismail Vintage Computer Festival ------------------------------------------------------------------------------ International Man of Intrigue and Danger http://www.vintage.org [ Old computing resources for business || Buy/Sell/Trade Vintage Computers ] [ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]