My two cents, in decreasing order of sanity.
Maybe it's a little far from the original goal*, but for the cost of a
few extra bytes in track/sector numbers, the same format might handle
the contents of hard disks. And there's probably a lot fewer "whacko"
formatting concerns with those than with floppies - 99.44% of the time,
just getting a big pile of sectors might be as much as you'd need.
AFAIK, nobody wrote quarter-tracks on hard disks, or tried to copy-
protect software by making bad sectors, or any similarly-goofy stuff.
And machines that used hard disks didn't generally fixate on the number
of tracks or sectors.
(How much of that is true? Discussion?)
My reaction to XML et al is generally negative too, and also not for
any good reason that I could put my finger on. Maybe it seems like
it would be work to parse, and I like to imagine my poor old 8-bitters
being able to make use of the images themselves, not just the recipients
of an end-product that was produced by a modern machine that digested
the image. As I said, it's not entirely a rational concern; those old
8-bitters could do it just as well as any modern machine, given enough
time and storage and programming... Maybe that's it, coding up an XML
parser for a CoCo seems like it would be much more work than having
some byte-by-byte record definition. So maybe you XML supporters need
to hit that point a little harder.
Speaking of which, maybe some compressed representation of repeated
identical sectors could be good. If a floppy was 10% full, and the
remaining sectors were full of some "empty" byte pattern, It would be
nice if those "empty" sectors didn't take up space in the image. Of
course, the image could just omit sectors, but then you'd need
intelligence to decide which sectors to omit; almost as bad as needing
to know which files to keep. The only way to be safe is to get it all,
and maybe take advantage of patterns in the data to compress it a bit.
Then again, if I care about image size, I suppose I could always use
any standard compression utility on the image. And then I'd want to
get decompression going on the TRS-80...
Okay, I think it's time to stop babbling.
Bill.
* I'm _not_ going to make any bad puns about being on the wrong track. :-)
On Thu, 1 Jun 2000 13:34:55, Sellam Ismail <foo_at_siconic.com> wrote:
] Current iteration:
]
] Desk Descriptor Header
]
] 1. Host computer type (2 bytes allowing up to 65536 models to be specified)
] 2. Hard/soft sector flag (1 byte)
] 3. Number of tracks (1 byte)
] 4. Disk drive RPM (2 bytes: 1 for whole number, 1 for fraction) [1]
]
] Optional:
]
] 5. Archiver Name (24 bytes)
] 6. Archiver E-mail Address (48 bytes)
] 7. Disk Title (64 bytes)
] 8. Publisher (if applicable) (24 bytes)
] 9. Year of Publication (2 bytes)
] A. Archive Description (256-512 bytes)
] B. Archive Date (4 bytes: 2 bytes = year, 1 byte = month, 1 byte = day)
] C. Archive Time (3 bytes: hour, minute, second)
]
] ***Does it make sense to have separate fields as specified #7-9 or should
] we rely upon the archivist to include that data in the description? I
] think so since this is important information that should be forced to be
] included with the archive.
]
] Maximum size: 685 bytes
]
] [1] If applicable
]
] Note: Encoding type moved to Track Descriptor Header
]
]
] A Track Descriptor Header will precede each track and give an overall
] description of the track:
]
] Track Descriptor Header
]
] 1. Track number (2 bytes: 1 for whole number, 1 for fraction) [1]
] 2. Disk Side (1 byte)
] 3. Track format (logical or raw; host computer specific) (1 byte) [2]
] 4. Track size in bytes (2 bytes) [3]
] 5. Sector format (single-density, double-density, etc) (1 byte)
] 6. Encoding type (1 byte)
] 7. Sectors in this track (1 byte)
] 8. Interleave (1 byte)
] 9. Bytes per sector (2 bytes)
] A. Bits per byte (1 byte)
] B. Offset to next Track Descriptor Header (2 bytes)
]
] Size: 15 bytes
]
] [1] Fraction allows for specifying half- or quarter-track.
] [2] If the track is in "raw" format then fields 3-9 are ignored.
] [3] The total size in bytes of the raw track image.
]
]
] I can start to see where the flexibility afforded by a markup language
] makes sense. I just can't figure out why I am still resisting it though.
]
] So, are we on the right track? The wrong track?
]
] 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 - 18:52:18 BST