Let's develop an open-source media archive standard

[David V. Corbin]

You might want to consider Motorola rather than Intel. 
The only reason I suggest this is the motorola format alread has a (semi)
extensible record type description [the second char of each line]. 

S2 and S3 are already defined for 16MB and 4GB memory spaces...

A (non-standard) record type "could" be used for media format, etc...

Just my 16.3875 milli-EUR comment...

>>> -----Original Message-----
>>> From: cctalk-bounces at classiccmp.org 
>>> [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Cini, Richard
>>> Sent: Wednesday, August 11, 2004 10:02 AM
>>> To: 'General Discussion: On-Topic and Off-Topic Posts'
>>> Subject: RE: Let's develop an open-source media archive standard
>>> 
>>> I haven't read the entire thread on this but I did read 
>>> Steve Thatcher's idea and it describes about where I was 
>>> coming out on this myself. 
>>> 
>>> 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?
>>> 
>>> 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 agree that a multi-layer approach offers the best 
>>> combination of platform neutrality and portability. I don't 
>>> really know if we need two or three layers as Steve 
>>> described to describe the file in a standard fashion. Using 
>>> an Intel Hex-like format would increase the "de-archiving" 
>>> time, but in my view it's a fair trade-off. De-archiving 
>>> software could translate the platform-neutral file into 
>>> another format better suited for use in emulators.
>>> 
>>> 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.
>>> 
>>> Just my $0.02.
>>> 
>>> Rich
>>>