On Tue, 30 May 2000, Tony Duell wrote:
> > 1. Host computer type (2 bytes allowing up to 65536 models to be
> > specified)
>
> 1a. Host computer format, to allow for machines that support several native
> formats (e.g. PERQ POS floppy/PERQ PNX floppy/PERQ interchange floppy)
In what ways do the formats differ? Are you talking logical format or
physical format? If it is physical then I would agree. If it's logical
then that's more detail than we want to get into. We only need concern
ourselves to the level of organized blocks of data on the diskette (i.e.
sectors & tracks).
> > 2. Track format (host computer specific)
> I assume things like the interleave order go in here.
Yes, see followup posting after Jim's input.
> It's probably best to regard the sector as a stream of bits, suitably
> packed into the bytes on whatever machine is doing the imaging
But only if necessary. I think it would be far more useful to simply
store the bytes of each sector on the original disk. I would only want to
archive the bit stream of a track if the format was unusual.
> > 5. Bytes per sector
> > 6. Bits per byte
>
> Isn't that rather defined by 1 and 2 above?
Not necessarily. It's entirely possible to write 20-bit bytes on the
Apple Disk ][ hardware if one wanted for instance. Not that I know of
anyone who's ever done that. I included the bits-per-byte field at the
behest of someone (sorry, forgot who) who suggested that a disk "byte" is
not always "eight bits".
> Wouldn't it be possible to store the data from a particular track in
> several formats? As logical sectors, or as a stream of bytes _in the same
> image file_. Using a pseudo-notation :
That is what I am advocating the standard should be able to support,
although I hadn't thought about being able to support the same image in
two separate formats (logical sectors vs. physical bytes) in the same
archive.
> Machine : Apple ][
> Machine-specifc format : DOS 3.3 16 sector disk, standard format
> Track layout : 35 tracks, 1 head
> Track 0 Hd 0: Logical data. Sectors are 1 (GCR), 3 (GCR),
> 5(GCR),...2(GCR),4(GCR),6(GCR)... (or whatever the
> interleave order is)
> Track 0, Hd 0, Sector 0 : <Stream of bytes from that sector>
> Track 0, Hd 0, Sector 1 : <Stream of bytes from that sector>
> etc
> Track 0 Hd 0 Physical data : <Stream of raw bytes representing the pulses
> on the disk. This would include GCR sync
> bytes, FM/MFM clock and data pulses, etc.
> Basically saying: Pulse, gap of 250uS, pulse,
> gap of 500us, etc>
>
> Repeat for track 1, etc....
I would be more inclined to create two separate images for each format.
But that's just my preferred method of organization.
As far as encoding the level of detail that Tony suggests above, I don't
know that you'd want to have a header for each sector in the archive
image.
Unless there was a header for each sector that perhaps contained the
following:
Track/Head/Sector/Density/#Bytes/<sector data> (...etc...)
In this way you could specify a change in the format of each sector and it
would be very flexible. There would be an 8-12 byte header for each
sector. It would then render some of the fields stored in the overall
header worthless then.
Another way to do this is to have a chain of Description Headers that are
stored at the beginning of each "chunk" of similar disk data. So for a
standard diskette, you'd need only one header that describes the format
for the entire disk (35 tracks, 16 sectors per track, 256 bytes per
sector, etc). If the disk format varies on the disk, say track 0 is 16
sectors and tracks 1-34 are 18 sectors, you would have the header for the
first track including an offset to the beginning of the next Description
Header, then the first track's worth of data, then the next Description
Header and the offset link to the next one, followed by the chunk of
sectors defined by this header, etc.
Know what I mean?
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 Tue May 30 2000 - 15:56:09 BST