Let's develop an open-source media archive standard

comments below... best regards, Steve Thatcher -----Original Message----- From: "Dwight K. Elvey" <dwight.elvey(a)amd.com> Sent: Aug 12, 2004 3:09 PM To: cctalk(a)classiccmp.org Subject: RE: Let's develop an open-source media archive standard ---snip--- No, that is not true. The description of the physical data in the archive should be sufficient to recover the system side data. I can state this because the system side data is just a subset of the physical data. *** if all you are describing is tracks, sectors and heads then you have not included ANY information as to how to get at a specific piece of data in the image file. You can certainly get a sector piece but you will have no clue how to connect individual pieces together to make a block of data. Only platform specific information will get you to that point and that means text has to be included to tell someone how to write software that accesses a particular file structure on a particular OS. If you have that file information when the image file is created, it would be easy to save the info and then be able to get at any file inside of the image file without ANY knowledge of the physical file structure or OS. I recommend that the archive should include enough information to translate from the physical to the system but for archiving purposes, that is not absolutely necessary. *** this information is not trivial, but if we make the data separate then it is if we save the file information too. It is not that hard to describe as part of the header what FM looks like. Still, if we restrict all archived information to include this, some unknown formats may not be archived because the person with the data doesn't know that format. It is better to capture the data first. It may also be that the only way that person has to capture the data is the output of a controller chip. The archiving should allow this as well ( more in the format the Steve would like it all to be in ). *** not sure why this relates to the format I was proposing. What I was desdcribing was a way to do both low level bytes as well as blocks of data This file could later be combined with the more physical information when that was available, just as a archive file that originally had only physical information could be appended with the data as seen by the system. What this means is that some of the archived files may not be directly useable by Steve and his tools without some more in depth knowledge about the encoding use. It doesn't make it impossible to use, just difficult. *** is is not a encoding issue with regards to the hardware level. There are three standards just for 8" disks - FM, MFM, and M2M. ISIS DD uses M2M and I for one want to be able to use my ISIS software independent of the media it is on. I also don't want to have to write a major utility (in other words a small OS) just to read the image file. Dwight