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