Date: Mon, 8 Apr 96 20:34 WET DST From: uhclem@nemesis.lonestar.org (Frank Durda IV) To: freebsd-current@freebsd.org Subject: Re: floppy format detection [was Re: devfs questions] Message-ID: <m0u6SJm-000CB9C@nemesis.lonestar.org>
next in thread | raw e-mail | index | archive | help
[5]I've did format autodetection, though in my CP/M driver. :-) I've [5]seen better autodetection in another CP/M driver, and i've seen many [5]worse examples later. 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 8"/5" 128x26 FM 256x27 MFM (TRSDOS) 77 1032.8K+boot 8"/5" 128x26 FM 512x16 MFM (XENIX/TRSDOS II) 77 1224K+boot 8"/5" 128x26 FM 128x26 FM (3741 format) 77 500.5K 8"/5" 256x26 MFM 256x26 MFM (CP/M?) 77 1001K 8"/5" 512x16 MFM 512x16 MFM (SAVE format) 77 1232K All above formats could be single or double-sided Later versions added: 8"/5" 512x16 MFM 512x16 MFM 80 1280K 8"/5" 512x15 MFM 512x15 MFM (PC 5.25" compat) 80 1200K 3" 512x18 MFM 512x18 MFM (PC 3.50" compat) 80 1440K 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. The detection of the last three formats above was sped-up via the use of "hints", settings the sysadmin configured to let the driver know what hardware was really out there, similar to the CMOS settings of the PC. This yielded a semi-automatic solution. 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. Searching for sector 18 and 16 to decide between 18, 16 and 15 sector MFM formats could be very slow (two seconds spent on track 0 and then again on track 2) if done completely automatically, so we didn't do it this way and relied on hints to make assumptions on possible and impossible media combinations. With the most likely formats tested firsts, nominal open time was 1.5 seconds, not including motor-on time. Without hints, the test for 77 vs 80 track drive test would have exceeded 500msec by itself, and would damage certain drive brands, which is why we didn't make that test automatic. 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 type must be reverified each time the drive is opened, unless you know absolutely that media-change reporting is working correctly on a given drive. Example, Tandon had drives that reported media changes, but only if you removed the media while the drive was selected, ie, the drive select light was on. Media changes that occurred while the light was out were not reported. So, it only reports the change if you do it when you aren't supposed to do it. Great design. IMO, the tradeoff between full automatic format detection, semi-automatic detection (as in the 16/6000) and manual specification, is a question of driver complexity plus how much delay you are willing to experience on each open of the drive, plus whether you can determine certain things without 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. Frank Durda IV <uhclem@nemesis.lonestar.org>|"How do I know? I re-wrote or uhclem%nemesis@rwsystr.nkn.net | that driver once upon a time, | that's how." or ...letni!rwsys!nemesis!uhclem |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0u6SJm-000CB9C>