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 <vcf_at_siconic.com>
Sent: Aug 11, 2004 10:56 AM
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, 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 ]
Received on Wed Aug 11 2004 - 13:10:41 BST