[sebhc] h17 and h8d disk images

[Barry Watzman]

Of course the headers always have to match what is requested.  But that's
the whole point.  A copy protection scheme can request sector 218, which
won't exist on any normal disk (or be capable of being created with any
normal format program).  Similarly, if it requests sector 1 and then sector
2, it doesn't matter that sector 2 doesn't immediately follow sector 1.

Personally, if I was writing an image program, I'd record each track's
sectors in the order in which they physically occurred on the track AND I'd
also record, in each sector's data contents, the track and sector number
recorded in that sector's header.

Only by recording BOTH of these -- they physical layout AND the logical
layout (the numbers in the header) would it be possible to physically
reproduce a physically correct image of the diskette.

[by the way, this applies to tracks also.  You could have a track number in
a header that was different from the physical track number.  For example,
all (or just some or just one) of the sectors on the 20th track could have a
header that said it was track 169.]


-----Original Message-----
From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of Dwight K. Elvey
Sent: Wednesday, September 01, 2004 8:07 PM
To: sebhc at sebhc.org
Subject: RE: [sebhc] h17 and h8d disk images

>From: "Barry Watzman" <Watzman at neo.rr.com>
>
>
>There are two ways to interleave.
>
>In the 1st method, used by CP/M, you have an interleave table in the
>operating system itself.  The sectors are in physical order on the
diskette,
>but are not used in physical sequence.  That is, CP/M (on an 8" disk) uses
>sector 1 then 7 then 13, then 19, etc.
>
>The other way is to have the OS use the sectors sequentially (1,2,3 etc.)
>but to do the interleaving when the disk is formatted.  So the OS will ask
>for sector 1, 2, 3 ...., but on the disk the sector after sector 1 is not 2
>but rather something else.  There is no requirement that the sectors on the
>disk be in sequential order.  In fact, there is no requirement that they be
>contiguous, or that they be "positive" numbers (if one wants to interpret
>them as signed numbers).  They are more like labels than actual numbers,
>they can be in any sequence, and there can be gaps (a fact on which may
copy
>protection schemes rely).

Hi Barry
 On the HDOS hard sectored disk, the headers do have to have sector
numbers that need to match those that are requested. The order on
the disk doesn't matter for the H17 ROM. They can even be random order.
 How we got here was that I was concerned that if Dan's code read
the physical sectors and placed them sequentially in the image file,
any interleaving might cause loss of order of the sectors because
the headers are not saved. He assures me that his code looks both
at the sector order and the sector header for a match. As long as
he is not reading interleaved disk, there is no issue.
 He states that he'd never seen this on HDOS. I believe him. I state
that I'd seen it before I'd ever done it myself ( I believe myself ).
Dwight


--
Delivered by the SEBHC Mailing List


--
Delivered by the SEBHC Mailing List