Extracting files off unknown 8_inch_disks Any thoughts

[Fred Cisin]

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 
boundaries.)


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 
longer supported.

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?)

and 
http://www.uncreativelabs.net/textfiles/dos/BDRIVE.TXT


--
Grumpy Ol' Fred     		cisin at xenosoft.com