3 Aug
2005
3 Aug
'05
3:20 p.m.
From: "Dwight K. Elvey" <dwight.elvey at
amd.com>
Hi
I see from Dave's post that this was one of those redundant
information I was talking about. I wonder if all the
later PC controllers deal with these fields the same?
Dwight
From: "Fred Cisin" <cisin at
xenosoft.com>
On Wed, 3 Aug 2005, Dave Dunfield wrote:
Hi
At least for Dave's setup, he could get by with
a bypass switch on the head selector. It is always
funny what different setups have done. At least there
is a potential bypass for this one.
I'd guess the fellow that wrote the driver for the
Kaypro didn't have a problem so he didn't notice the
missing head information in the sector header. He
may have thought the controller took care of this
somehow. I know when I've fiddled with the disk controller
directly, it isn't always clear when and where
each register takes effect. There are a few places
that it seem that there is redundant information.
Dwight
Tried ImageDisk on some Kaypro disks this
morning...
Buggers recorded side1 as additional sectors of side0.
The different set of sector numbers didn't bother
ImageDisk, but it had a bit of a tantrum with the Head
ids which didn't match the physical head selection.
Quite common :-(
765 insists on accurate sector headers;
WD 179x can ignore the head # field in the sector headers.
The Kaypro won't even mind reading/writing a disk,
if you FORMAT it with a 765 using valid sector headers!
I can imagine that someone somewhere does weird
things
with the Cylinder ids on a track as well ...
Rare. I've only seen it a few times.
3 Aug
3 Aug
5:11 p.m.
On Wed, 3 Aug 2005, Dwight K. Elvey wrote:
I see from Dave's post that this was one of those
redundant
information I was talking about. I wonder if all the
later PC controllers deal with these fields the same?
Pretty much so. (for compatibility reasons)
Int 13h will handle the whole process, and introduce some major
limitations.
VERY oversimplified (apologies to Dave and Allison):
It moves to the track (and head) of the sector that you specified.
It sets up the DMA.
It checks Int 1Eh for some parameters (gaps, bytes per sector, etc).
It looks on the current track for a sector with the CHRN values specified.
Because Int13h is using the cylinder, head, and sector number that you
specified for BOTH seeking to track and selecting head, AND for the CHRN
values looked for in the sector header, therefore, Int13h cannot
handle sectors with "invalid" headers.
That is the "redundancy".
If you go below the BIOS, and talk directly to the hardware,
those limitations disappear, since YOU seek to track, select head,
and then look for any CHRN header you want.
(CHRN == fields in sector header: Cylinder, Head, Record (sector) number,
bytes per sector (128 * 2**N, or 128<<N ). Sector header also has a CRC
that is checked to be sure that data read matches CRC. "VERIFY" does NOT
check whether correct content was written, only whether the data that is
there after writing has a valid CRC)
suggested reading: Int13h source in "Technical Reference Manual",
NEC and WD data sheets, Wiliam Barden's "TRS80 disk controller" paper,
"Beneath Apple DOS" for simple description of GCR, . . .
--
Grumpy Ol' Fred cisin at xenosoft.com
7080
days inactive
7081
days old
1 comments
2 participants
participants (2)
-
cisin＠xenosoft.com -
dwight.elvey＠amd.com