From: "Steve Thatcher"
<melamy(a)earthlink.net>
From: "Dwight K. Elvey"
<dwight.elvey(a)amd.com
---snip---
It may also be that the only way that person has to
capture the
data is the output of a controller chip. The archiving should allow
this as well ( more in the format the Steve would like it all to
be in ).
*** not sure why this relates to the format I was proposing. What I was
desdcribing
was a way to do both low level bytes as well as blocks of data
Hi Steve
Again, you've missed the point here. The information may not
have anything other than the bit stream and the track. The
person extracting the data may have no knowledge of the
format ( FM, MFM, M2FM, RLL or whatever ). They are just
archiving the data of the disk. I agree that if there is
sufficient information available to include such things
as sector boundaries, that should be encoded in some method.
This may not be in the actual data but as part of the format
description ( requires some work to extract from the data ).
At the lowest level, the archive may only contain a bit stream
that correlates to the signal coming from the drive. Without
information as to the encoding method, this may be useless
to you. As Sellam has stated, your application is secondary
to actually capturing a reproduceable medium.
Obviously, most people will not be able to create such information
( I believe I will ). Most will be creating such things as the
output data from some standard disk reading chip. These will
surely have some form of partioning, either in the header or
embedded in the data.
This could still be a valid archive input for standard formats.
Note the word 'could' and not must.
Dwight
