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_at_siconic.com>
Sent: Aug 11, 2004 9:07 PM
To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk_at_classiccmp.org>
Subject: RE: Let's develop an open-source media archive standard
On Wed, 11 Aug 2004, Steve Thatcher wrote:
> I realize that the idea is to create a format to make re-creation of
> media possible for a variety of platforms. We can certainly do that and
> have its only function be to maintain a physical data format. My added
> idea is that the data and the formatting be separated so that a simple
> utility on a non-target platform could extract data from the image file.
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.
> If we create a physical description only and do not abstract the data
> then any emulator must understand the OS file structure in order to
> retrieve any internal file representation. My idea would make the file
> re-creation simple in that the xml image file would be parsed for the
> actual file data that an emulator would need. This makes the emulator
> easier.
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
from a punch card deck)
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.
> To retrieve a file from the physical layout that it at the end of this
> message, the emulator must know the actual disk format that is used on
> the target system (the one the image file was made for). I have seen
Right. If you choose to store an image in the raw disk format.
> cp/m systems where the actual physical sectors were sequential on disk
> and the OS file sector was actually virtual to increase speed. Not my
> idea of the way to do it. It is much easier to make the physical sectors
> slewed so that a physical sector is a file sector. These are the types
> of issues you will have to overcome if an emulator must totally
> understand each and every file system for a cp/m version for example.
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).
> Sellam, let me know if you would like to discuss this via telephone so I
> can convery the idea that I am proposing.
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 ]
Received on Wed Aug 11 2004 - 20:41:58 BST