Let's develop an open-source media archive standard

From: Vintage Computer Festival <vcf_at_siconic.com>
Date: Wed Aug 11 20:07:01 2004

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:07:01 BST

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:36:34 BST