1 Jun
2000
1 Jun
'00
8:08 a.m.
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!