On Thu, 1 Jun 2000, John Wilson wrote:
> Hard or soft head number? I feel sure I ran into a format (Commodore?) where
> the sector headers had the opposite head numbers to the side on which they
> were actually recorded.
I know that's true on the Apple ][. Side "1" is actually the backside of
the diskette and vice versa.
> Also, re having a field that denotes the source machine, this seems
> dangerous. What if the disk has dual directories and is supposed to
> work on more than one dir structure? What if it's a generic format
> that works on lots of different machines (like FAT or RT-11, these
> disks have become de facto interchange standards and often exist w/o
> ever touching the machines for whom that's a native format)? Also,
Then the machine descriptor would reflect the actual machine that the
software was designed to run on. Providing I understand what you are
saying, I don't see a problem here.
> even if there is a source architecture specifier, I'd rather see this
> as a short ASCII string rather than a magic number, so that we won't
> need a central authority to assign the numbers, in most cases it's
I don't like that because it allows for too much variation in the naming
convention.
I suppose we can include a database of pre-defined Computer Type strings
in the archive creation software but still allow the archiver to type in
his/her own to allow for new computers. The Computer Typer strings can be
contained in a textfile that can be updated regularly and downloaded from
the homepage for the project.
> obvious what short string uniquely identifies the architecture (like
> with SCSI vendor and device IDs).
That works because each SCSI vendor creates one string that they use. If
we have multiple people creating their own strings for computer names then
it gets messy.
Something to ponder though...
> In any case, this is more information than *real* floppies have! All you
> (i.e. the computer) need to know in any given instance, is whether this disk
> is in *your* format, and you'll find that out when you try to read it. Just
> like a real floppy.
This is not just for the computer's sake but for the humans who are
archiving it as well. We need to know what this disk is (hmmm, need to
add a Title string) rather than have to make silly guesses. Besides,
diskettes DO have this information, generally on the label :)
> The complexity seems to be rapidly getting out of hand, and I wonder
> whether this is solving problems that don't really come up that often?
I don't think it's getting out of hand at all. I see a clear end to the
current design process. I'd hate to make a "standard" that doesn't
address all the various needs of every different floppy format and then
end up having to extend the standard later or not have it adopted due to
it's limited usefulness. We have the ability right now to think, argue,
recommend, specify and commit and so we might as well try to do it as
rightly as possible.
> Having something which treats floppies as a black box, like Teledisk, is
> handy in some circumstances, but I already dislike Teledisk because it gets
> you in the silly situation of being unable to reproduce the disk even on
> the machine for which it is intended. In this regard, an open standard is
Well, we are trying to create an archive standard that does allow a
physical disk to be re-created from an archive.
> a big step up from Teledisk, but now that means that in order to reproduce
> a floppy on its native machine, you have to grab the spec and write a big
> disk copier utility for that machine, which knows how to parse text tags
> (please tell me I misunderstood that part) and double-check header formats
> to make sure they're really vanilla. All instead of simply writing the
> contiguous binary data out in the native format.
What I envision is that the software component on the target machine will
only require the following abilities:
a) read floppy in logical or raw format
b) write floppy in logical or raw format
c) send/receive archive data over a serial or parallel port
I envision all the post- and pre-processing will be done on a more modern
host, such as a standard PC running Linux or whatnot. I would never want
the processing done on the target machine, especially if this standard
turns into a big messy markup language.
Once this standard is close to complete I intend to develop either a Linux
or DOS-based demo archival application as well as the utility software for
the Apple ][ to evaluate the workability of the standard before it is
committed to.
> I think a nice compromise might be to represent each floppy disk with
> two files, one of which contains all the data as a straight binary
> image in whatever's the most sensible order for that machine, which
> would be convenient for use on the original machine (not to mention
> emulators), and the other one contains all the fancy headers and
> sector descriptors, with pointers into the binary image. That would
This is a circular specification. What you need in order to create a
"no-nonsense" archive IS the standard we are attempting to define, because
every machine will invariably have some wacky formats that won't allow a
sensible, straight-forward archive to be made. This needs to be taken
into account.
Sellam International Man of Intrigue and Danger
-------------------------------------------------------------------------------
Looking for a six in a pile of nines...
Coming soon: VCF 4.0!
VCF East: Planning in Progress
See
http://www.vintage.org for details!
Received on Thu Jun 01 2000 - 15:08:47 BST