11 Aug
2004
11 Aug
'04
6:29 a.m.
This example represents the block data using metatags...I guess along the
"XML" part of the thread.
I was thinking similarly to you but not using XML metadata:
;Hardware descriptor
MFGR
MACHINE
SUBTYPE
DRIVETYPE (this of course defines what follows)
;for floppy
DRIVESIZE
ENCODING
TRACKS
SECTORS
SECTSIZE
;HexData
; Each record or group of records contains the related media data. The
address record would be used for encoding the metadata
00TTSSHH: (00-track-sector-head)
I looked to Intel Hex (or Motorola) because it had built-in CRC facilities
and it was human-readable ASCII. The drive and machine description could be
encoded in special MOT records probably.
XML is more a more "current" technology but I was trying to keep with the
platform neutrality by sticking to text-only and not assuming the use of any
other technology like XML.
Rich
-----Original Message-----
From: cctalk-bounces(a)classiccmp.org
[mailto:cctalk-bounces@classiccmp.org]On Behalf Of Vintage Computer
Festival
Sent: Wednesday, August 11, 2004 1:56 PM
To: General Discussion: On-Topic and Off-Topic Posts
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
]