Date: Tue, 9 Apr 1996 18:30:11 +1000 From: Bruce Evans <bde@zeta.org.au> To: freebsd-current@FreeBSD.org, uhclem@nemesis.lonestar.org Subject: Re: floppy format detection [was Re: devfs questions] Message-ID: <199604090830.SAA14558@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>The old Tandy 16/6000 XENIX floppy driver did semi-automatic format >detection, and it had to deal with far more complex combinations of formats >than what we are talking about supporting here. It had to do these: >Size Track 0 All other tracks Cylinder count Data Cap. >8"/5" 128x26 FM 256x26 MFM (LS-DOS) 77 994.5K+boot >[...lots more] >Detection of all of these formats was fine and simple as far as the user >was concerned, but there was a significant speed penalty on each device >open, which worked out two or three media revolutions per format tested. >On 5RPS media (3.5"), the above tests could take as long as eight seconds >without "hints" and other tricks to speed the format identification, >regardless of CPU speed. Ouch. What was the type of the floppy controller? >Asking for the disk controller to locate a sector ID that wasn't there >to determine the true sector count cost one second, since the controller >would look for the sector ID for five media revolutions before giving up. It's better not to ask the controller to locate the ID if possible. For nec765 and wd17xx style controllers, the best method is to use the read id command. This gives you the complete format for each track. 4 passes per track might be required to distinguish between FM/MFM and different transfer speeds. I used this in a driver written in 1983-198? for a mb8876a (Fujitsu clone of a wd17xx (?)) on 1-2MHz 6809 systems. It handled FM 128*16 (mainly for track 0), MFM 256*16, MFM 256*26 (high density), detection of most media changes by comparing the directory (a whole track), interleave detection and optimization (always use physical order) and a couple of other oddities. This wasn't automatic. There was a memory-resident utility to tell the driver to determine the format. I forget how long it took - it must have been comparable with the motor startup time. I was pleased to forget about these complications for PC floppies. Originally, PC floppies were all 512*8 interleave 1. I don't like automatic media detection because it slows things down and reduces robustness - if media detection isn't implemented or working, then you have to assume that an error means that the media [density] changed, and flail around attempting to detect the new media. >Don't forget that even with PC-AT compatible systems, there are still >drives out there that have broken media-change reporting (which MS-DOS >conceals by assuming media change is broken on ALL drives), so the media Nope, versions 4.01 and 6.22 screw up my disks by assuming the the change line works on my broken 3.5in drives. >damage to the hardware. I personally prefer having an semi-automatic >dev plus manual devs or an ioctl available for explicit settings. In the >PC/AT world, the CMOS provides the "hints" needed to perform semi-automatic >operations and get the test time down to an acceptable level. I prefer using only standard formats so that format detection is normally unnecessary. Reading foreign formats is probably sufficiently rare that the driver shouldn't have any complications to support it - it should just support it. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604090830.SAA14558>