Mercurial > hg > Members > kono > nitros9-code
changeset 1708:823c651e7dcd
Updated DNS.STD and DNS.DTD definitions based on Gene Heskett's explanation:
The trigger for the double-stepping then becomes a state of finding
a disk in the drive whose descriptor says its 0x03 in the dns byte
but when LSN0 is read, it finds an 0x01 there. This is how its
worked for many years.
Now, since there is only one tpi for a 3.5" drive, the point is
moot within a given system, but if this user then swaps a disk
with a friend, and the other friend has his system setup the
other way, then things get interesting because the driver may
double-step, rendering any read past track 0 as garbage. This
may crash the system if the track 2 data (track 1 skipped) isn't
a continuation of the expected directory. The error catching
in such a scenario isn't exactly bulletproof, I've managed to
get some real colorfull confetti on my screen occasionally :).
So this has been my message regarding this for quite a while:
All 3.5" drives and 48tpi 5.25" drives are effectively single
track density drives and the drives descriptors 'dns' should
be set to $01.
All 5.25" 96tpi drives should have this 'dns' set to $03 in
their descriptor. Everything else then becomes automatic
other than remembering that you cannot write to a 48 tpi
disk in that 96 tpi drive, ever, you can only read. That's
bit me many times I have to admit. :(
Please note that a quick session with ded on LSN0 can fix
any disks that are "miss-formatted". There are two bytes
that need changed, one at offset $10, and another at offset
$3F IIRC. If miss-formatted on a 3.5", one will contain
$03, and the other $07, and you have to make them into
$01 and $03 respectively. Or vice-versa to fix a 5.25"
96 tpi formatted disk that was formatted a with dns=01
in the descriptor at the time of the formatting.
You won't lose any data from that.
One of the things I was always "going to do" was to make
use of that double-stepping condition to also reset that
disk as read-only, to prevent its being trashed by an ill
thought out write. But I never really got around to dissing
the floppy drivers and doing it. Too many of them basicly.
And I don't recall rbf ever being aware of this issue.
Maybe that can be built into the next release? (hint hint)
author | boisy |
---|---|
date | Thu, 12 Aug 2004 18:43:58 +0000 |
parents | 3911533043d3 |
children | 1e026af2217c |
files | defs/rbfdefs |
diffstat | 1 files changed, 2 insertions(+), 2 deletions(-) [+] |
line wrap: on
line diff
--- a/defs/rbfdefs Thu Aug 12 14:25:17 2004 +0000 +++ b/defs/rbfdefs Thu Aug 12 18:43:58 2004 +0000 @@ -135,8 +135,8 @@ * IT.DNS bit definitions if bit 7 of IT.TYP is clear (floppy disk) DNS.FM equ %00000000 Single-density (FM) DNS.MFM equ %00000001 Double-density (MFM) -DNS.STD equ %00000000 Single track density (48 tpi) -DNS.DTD equ %00000010 Double track density (96/135 tpi) +DNS.STD equ %00000000 Single track distance (48/135 tpi) +DNS.DTD equ %00000010 Double track distance (96 tpi) * Floppy disk step rate definitions STP.30ms equ 0 30ms step rate