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

11 Aug 2004

actually both Intel and Motorola use a checksum which is just the negative value of the
summation of all bytes. A CRC check actually was used in zmodem for example and it is a
mathematical value derived from a polynomial function (do a search for CRC onm the web).
There are CRC code snippets for creation of this type of data.

I know a three section approach that I was proposing is more complicated, but from a code
standpoint allows total freedom of data access without having to create a target media let
alone have the computer system to then read the media just to get at the data that was on
a floppy disk. The beauty is that if you need to create a Northstar system diskette then
you can, but if all you need is a copy of the dump.asm program then you can get that also
without having to go any further than the file you started with.

best regards, Steve Thatcher

-----Original Message-----
From: "Cini, Richard" &lt;RCini(a)congressfinancial.com&gt;
Sent: Aug 11, 2004 7:37 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

Dave:

	I tend to forget about the Motorola format (call me an Intel snob).
The 16mb would be enough for many systems, and I would hope that 4gb would
be enough, at least for now, to represent the largest of the media types we
want to represent. 

Rich

-----Original Message-----
From: cctalk-bounces(a)classiccmp.org
[mailto:cctalk-bounces@classiccmp.org]On Behalf Of David V. Corbin
Sent: Wednesday, August 11, 2004 10:34 AM
To: 'General Discussion: On-Topic and Off-Topic Posts'
Subject: RE: Let's develop an open-source media archive standard

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
>>  