Let's develop an open-source media archive standard - test-drb@ccmp.vtda.org

11 Aug 2004

I agree with Sellam on the point about using it both for media re-creation and emulation. 
The trouble with the approach below of just using raw data on a track sector basis is that
now you have created a file that can only be used with an emulator that understands the
physical format and OS access for the computer system you are emulating. My earlier point
of separating the data and the format information allows a single file (that would not be
much bigger that the one described below) to contain multiple platform specific files that
can be "read" by a simple utility that does not require any knowledge of the OS
or the platform.

best regards, Steve Thatcher

-----Original Message-----
From: Vintage Computer Festival &lt;vcf(a)siconic.com&gt;
Sent: Aug 11, 2004 10:56 AM
To: "General Discussion: On-Topic and Off-Topic Posts"
&lt;cctalk(a)classiccmp.org&gt;
Subject: RE: Let's develop an open-source media archive standard

On Wed, 11 Aug 2004, Cini, Richard wrote:

...
  I might have missed what the ultimate use of this
archive would be. Will the
 archive be used to (1) re-generate original media; (2) operate with
 emualtors; (3) both? 
Both.  Emulators will certainly be able to make use of the archive by
having parsers built-in that can translate the archive data into
something the emulator can use.  So instead of point the emulator to a
binary disk image, you would point it to an archive file and it would
translate the file back into tracks/sectors, or punch cards, or whatever.

...
  To ensure integrity of the data I would propose
recording the data in the
 Intel Hex format -- it's text-based and has built-in CRC. Now, we'd have to
 modify the standard format a bit to accommodate a larger address space and
 to add some sort of standardized header (a "Hardware Descriptor"). This data
 would be used by the de-archiver to interpret the stream of data read from
 the data area (the "Hex Block"). 
I think you're thinking of this in terms of a large binary file encoded as
ASCII hex.  If so, this is not what's being proposed.  What is being
discussed is a format which actually describes the physical medium.  For
example, on floppy:

<MEDIA TYPE=FLOPPY SIZE=5.25 SIDES=1 DENSITY=SINGLE FORMAT=GCR TRACKS=35
SECTORS=16 SECTORSIZE=256>

<VOLUME>Apple ][ System Disk</VOLUME>

</MEDIA>

<DATA>
<TRACK 0><SECTOR 0>

HERE WOULD BE THE ASCII HEX DATA FOR TRACK 0, SECTOR 0

</SECTOR></TRACK>

...

<TRACK 34><SECTOR 15>

HERE WOULD BE THE ASCII HEX DATA FOR TRACK 34, SECTOR 15

</SECTOR></TRACK>
</DATA>

...
  I think that we should start compiling a list of the
various media we want
 represented and how that media is organized natively. I don't mean "well, it
 has blocks and sectors" either. We should examine the exact format down to
 the actual numbers (i.e., "2048 blocks of 256-bytes recorded twice"). Seeing
 how the various data stores are organized should bring some clarity to how
 we should represent it. 
I agree.  This would be useful.  Does someone want to volunteer to do
this?

-- 

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  ]