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(a)classiccmp.org
>> [mailto:cctalk-bounces@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
>>