Extracting files off unknown 8_inch_disks Any thoughts
cisin at xenosoft.com
Mon Apr 17 19:37:22 CDT 2017
On Tue, 18 Apr 2017, Terry Stewart via cctalk wrote:
> I'm puzzled why I couldn't format the disk using the /t:77 and /n:15
> switches. Did MS-DOS just go by what was in the CMOS. If that's the case,
> why have those switches at all? Are they just legacy switches for
> pre-CMOS machines?
The /T: and /N: switches do NOT set the number of tracks and sectors!
They just don't! Instead, their function is to gather answers to those
questions from the user, that the OS then uses to select which one of its
limited number of formats matches what the user is requesting.
It's like retail sales systems that ask my city, ask my ZIPCODE, and then
change my city in my address from Berkeley to Albany for zipcode 94706 and
from El Cerrito to Richmond with Zip 94530.
(Yes, there are MANY ZIPCODES that straddle city boundaries, MANY that
straddle county boundaries (a problem in correct computation of sales
tax (cf. XenoSoft Sales Tax Genie)), and even a few that straddle state
For example, /N: has values of 8, 9, 15
/12 won't be accepted.
/T: has values of 40 and 80.
If you are using a Shugart SA400, it should have also accepted 35.
If you are using an 8" drive, it should also have accepted 77.
For that matter, it should accept anything less than or equal to the
limits of the drive, and use what you ask for, so that you could format 35
tracks, or 77, or 70, or 53, if you want, instead of only using your
request as a selection between it's option.
It has a very finite list of supported formats, and uses your variable
settings only to select which one of THOSE to use!
At one time, MS-DOS had some other drive types!
DRIVPARM (and the related DRIVER.SYS device driver) were first visible in
DOS 3.20 (the first time that all DOS supported 720K, although many OEM
versions of 2.11 were configured with manufacturer specific additional
drive types, such as Gavilan 720K MS-DOS 2.11K)
DRIVER.SYS created a new drive letter (at the end of your drive letter
list) accessing the drive, whereas DRIVPARM did an override of the drive
type that was set in CMOS.
If your BIOS CMOS settings didn't include 720K, you could set the CMOS to
360K, and use DRIVPARM/DRIVER.SYS to switch it to 720K.
With DRIVPARM, it could still be B:, but with DRIVER.SYS, it would have a
letter after your hard disk, etc. (Did you set LASTDRIVE?)
At that time, type 7 (1.4M) and type 9 (2.8M) didn't exist yet, and it
would also balk at drive types that were contrary to what DOS believed
that the BIOS/hardware could support. (Neither the hardware nor INT13h
needed any change to switch from a 160K/180K/320K/360K drive to a 720K)
But, with DOS Version 6.00, type 3 (single-density 8-inch floppy disk
drives) and type 4 (double-density 8-inch floppy disk drives) are no
With your CMOS set to drive type 1 (1.2M), what happens if you try to use
DRIVPARM/DRIVER.SYS in DOS 5.00 to switch to type 4?
Or /F:4 in DRIVER.SYS?
NOTE: Many sources, INCLUDING MICROSOFT "support", have erroneous
information about which versions of MS-DOS and PC-DOS support DRIVPARM.
It's understandable, with MY experience I could easily misinterpret it in
numerous incorrect assumptions.
On a generic 5170, using 720K drive WITH PC-DOS and MS-DOS 3.20, DRIVPARM
worked fine. But, when I replaced its BIOS with a copy of the "real" IBM
BIOS, both operating systems reported "UNRECOGNIZED CONFIG.SYS COMMAND"
for DRIVPARM! So, I had to use DRIVER.SYS. Replicated on an OEM 5170.
Other weirdities surface:
Chuck reported needing to tamper with the CONFIG.SYS line to use it.
(perhaps he could repeat his explanation?)
Grumpy Ol' Fred cisin at xenosoft.com
More information about the cctalk