Let's develop an open-source media archive standard

From: Dwight K. Elvey <dwight.elvey_at_amd.com>
Date: Wed Aug 11 13:44:28 2004

>From: "Vintage Computer Festival" <vcf_at_siconic.com>
>
>On Tue, 10 Aug 2004, John Foust wrote:
>
>> Astounding! Will that computer never die? And I say that
>> as someone who Believed, '85-92.
>
>The Amiga is still going strong in some circles. More power to them.
>
>> I'm tempted to say that we should leave copy protection
>> hacks out of the spec for now, but if it was extensible,
>> that would be great.
>
>Yes, copy protection will defintely be able to be described naturally in
>the specification I have in mind. The spec should be able to define
>several layers of bit storage: logical (files, directories, etc.), byte
>(e.g. tracks, sectors), and raw (bit streams). In this way, copy
>protection schemes can be preserved by storing the image in the raw
>format.
>
>This will of course have to be thought out, and it may not even be
>included in the first revision of the spec, but as I declared originally,
>the spec will be extensible.
>
>--
>
>Sellam Ismail Vintage Computer Festival

Hi Sellam
 I can understand the need for both raw bit stream and extracted
data. I propose that it should always include both types of information.
The raw bits are needed to actually rebuild a particular format
but often the information in the data is all that one needs to extract.
In the case of the H8/89, we have working machines to read and write
the format. We just need the data that fills the sectors. In the case
of the H8/89, I've written a bootstrap that can be entered through
the monitor commands. In some cases, the machine has no monitor or
bootstrapping method. In these cases, it would be necessary to create
the disk on another machine. Having the raw bits of clock and data
would then be valuable.
 I'm currently looking at using a DSP chip to extract raw data from
disk. The biggest problem so far is that one needs to do one of two
things. One either needs to extract clocking operations with something
like a PLL or simply oversample the bit stream from the drive.
To do the PLL method, one needs to understand the disk format used
and have hardware to handle that particular format. The oversampling
has the advantage that one can capture all that is needed and post
process it to normalize the data. The disadvantage here is that it
takes a lot of data space. The DSP chip I'm looking at doesn't have
enough RAM space to capture an entire track. Capturing track fragments
has the issue that one needs realign things later. Knowing when
the two fragments are properly connected is not easy. It looks like
the newer DSP chips do have enough speed to capture raw data with
little or no external hardware. This means that one can get one
of the manufacture's development boards ( usually in the $50-$150
range ) and wire it up to the disk drive by connector.
 The disadvantage here is that as newer chips come out, the older
development boards are obsoleted. Still, having the raw data means
that one can recreate the disk in the future, with some effort.
Dwight
Received on Wed Aug 11 2004 - 13:44:28 BST