Pre-release notes for DRIVPARM.COM
----------------------------------
Copyright 1988  by Daniel Fandrich

DRIVPARM is a utility which allows you to modify your disk parameters in
memory.  It is used as a replacement for the DRIVPARM command in MS-DOS 3.2,
and for PC-DOS 3.3, a replacement for the (allegedly) buggy DRIVPARMS command.
It also allows you to find the drive type and use it in a batch file via the
errorlevel.  It will only work with DOS versions 3.2 and  above, because it
uses IOCTL function call 44H with AL=0DH, CH = 08H, and CL = 40H or 60H which
was only implemented in those versions (I think).

The parameters it modifies are used mainly to set the physical drive type and
set parameters for formatting disks.  I use it  in conjunction with DRIVER.SYS
to create a pseudo disk drive whose parameters I modify to allow formatting of 
42 tracks.  That way my original drive specification (A:) is unchanged, but 
formatting the new one (E: in my case) will give me an extra 18k or so on the 
disk.

What follows is not what I'd call documentation.  I call it, 'Beta Pre-release
Notes' for DRIVPARM.PAS.  I figured that rather than letting DRIVPARM rot on
my hard drive I'd let it loose with some brief notes and let the hackers in 
computer land figure it out for themselves.  As soon as I find a spare month
to write up formal documentation, I'll upload it.  Who knows?  I might even
take off lunch one day and edit it, too.

Please feel free to use DRIVPARM.COM in any which way you see fit.  Just don't
sue me if you do manage to use it to knock off your mother-in-law.  The same
thing goes if DRIVPARM bombs and you end up with a hard disk filled with

DRIVPARM WAS HERE! DRIVPARM WAS HERE! DRIVPARM WAS HERE! DRIVPARM WAS HERE!
DRIVPARM WAS HERE! DRIVPARM WAS HERE! DRIVPARM WAS HERE! DRIVPARM WAS HERE!
DRIVPARM WAS HERE! DRIVPARM WAS HERE! DRIVPARM WAS HERE! DRIVPARM WAS HERE!
DRIVPARM WAS HERE! DRIVPARM WAS HERE! DRIVPARM WAS HERE! DRIVPARM WAS HERE!
DRIVPARM WAS HERE! DRIVPARM WAS HERE! DRIVPARM WAS HERE! DRIVPARM WAS HERE!
DRIVPARM WAS HERE! DRIVPARM WAS HERE! DRIVPARM WAS HERE! DRIVPARM WAS HERE!

or something similar. I will say, though, that I've used the program for
several weeks without mishap.  But if something DOES go wrong...you have been
warned.  Of course if you love the program (what can I say -- _I_ do), feel
free to include me in your will.

Another thing -- don't charge anyone for it.  The amount of money you might 
conceivably get for this program is so small, it's hardly worth it for you.  
And besides, you didn't write it. 

If you do have any suggestions, bug reports, spelling errors, or letter bombs,
please let me know at one of the addresses at the end of this document so I
can keep DRIVPARM.COM one of the fastest, best looking, most grammatically
correct real-time disk parameter block modifying programs around!


------------------------------------------------------------------------------


A while ago I was perusing the INFO IBM-PC newsletter sent out over various
EMAIL networks and noticed this message and an accompanying ASM program:

------------------------------------------------------------------------------
Date:  Wed, 29 Jul 1987 11:47 EDT
From:  Villy G Madsen <VMADSEN%UALTAVM.BITNET@WISCVM.WISC.EDU>
Subject:  Drive Tables IOCTL 44H

A while back, I sent a note discussing the fact that the DRIVPARMS entry in
CONFIG.SYS no longer works.

After some research, I have found that PC/DOS 3.2 and 3.3 support a new
IOCTL (FUNCTION 44H) call. Function 44H with AL=0DH, and CH = 08H provide
a number of subfunctions  viz:  CL = 40H  Set device parameters
                                   = 60H  Get device parameters
                                   and a bunch more.
BL is set to the device number, where 1=A:, 2=B:, etc. and DS:DX is set to
the device parameter block to be set/read.
It is explained as well as can be expected in the applicable Technical
References. I have included a short MASM program that can be used to set the
characteristics of the B floppy so that it can be formatted with only 10
cylinders. The following program segment sets the default parameters
which are really only used by FORMAT. If you read a disk, then the actual
BPB is read from the boot block and used for all I/O operations to that
disk (other than a FORMAT).
------------------------------------------------------------------------------

I had just upgraded to DOS 3.3 at the time and was disturbed to find that it
was missing the DRIVPARM function, so I thought that now was as good a time as
any to create a solution to the problem.

(Note: since I wrote this program, I found that DOS 3.3 does have a replacement
for DRIVPARM, called DRIVPARMS.   But apparently it has some bugs, so writing
DRIVPARM wasn't a total waste of time after all!)

DRIVPARM.COM is not a TSR so it doesn't use up valuable memory.  Rather, it
changes parameters already in memory.  It doesn't read or write to your disks,
either (although, see BUGS, just in case).  DRIVPARM was written in Turbo 
Pascal 3.

If DRIVPARM is run without command line parameters, the following description 
is displayed:


DRIVPARM.COM  ver 1.0 (beta)  02-26-88   by Daniel Fandrich

DRIVPARM.COM is a replacement for the DRIVPARM command available in the
CONFIG.SYS files under MS-DOS 3.2.  It allows the alteration of the
disk definitions stored in memory, and may be used instead of DRIVER.SYS
when a new logical drive letter is not needed.  DRIVPARM.COM works with
DOS versions 3.2 and above.

DRIVPARM.COM generally uses the same switch format as for DRIVER.SYS
or DRIVPARM= in your CONFIG.SYS file.  This is a brief summary:

(The default base for 'n' is decimal.  To enter a hexadecimal value for
'n', precede the number with $.)

   x:	 Select the drive to modify or view parameters for.  If the drive is
	 selected in this manner, the D parameter is ignored.
  /D:n	 Select the drive to modify or view parameters for. 'n' differs from
	 the 'n' in DRIVER.SYS or DRIVPARM=, in that it follows the logical
	 rather than physical drive assignments  (e.g. 0 is A:, 1 is B:, 2 is
	 C:, etc.).
  /F:n	 Form factor.  Unlike DRIVER.SYS, /F does not default to /F:2 (720k
	 drive) and must be given implicitly.
  /T:n	 Number of cylinders (tracks per side) on a disk.
  /S:n	 Number of sectors per track (not really implemented).
  /H:n	 Number of heads on the drive.
  /C	 Drive supports diskette changeline.
  /N	 Media is nonremovable.
  /A:n	 Number of FATs.
  /R:n	 Number of root directory entries.
  /M:n	 Media descriptor (see documentation).
  /L:n	 Sectors per cluster.
  /G	 Get the media descriptor and exit with that errorlevel.

Entering DRIVPARM x:  or DRIVPARM /D:n  will make no changes, but display the 
current settings to the screen.

If you want help on most of these switches, look them up in your DOS manual
in the DRIVER.SYS or DRIVPARM sections.  As for the others, if you don't know
by looking at them what they mean, DON'T play with them.  I'll try to
explain them better when I write the 'real' documentation. One change worth 
mentioning is that hexidecimal numbers are supported.  Simply prefix them 
with a $ in any switch that requires a number.

If you make a change to a switch, that change is incorporated into the entire
set of parameters and may have an effect on others.  For example, increasing
the Number of Cylinders on a disk will also increase the Total Sectors.

The values accepted for the form factor are the same as for the DRIVPARM
command and DRIVER.SYS device in MS-DOS 3.21, namely:

dev. #  drive type
-------------------------
0       320/360K bytes
1       1.2M bytes
2       720K bytes or other
3       8" single density
4       8" double density
5       Hard disk
6       Tape drive
7       1.44M bytes

I've never used types 3, 4, and 6, so I can't say what will happen with them.
Play around and see.

Be careful when using type 5 (hard disk).  I really don't know what would
happen if you start muddling around with them, but with mega-megabytes at
risk, don't be foolish.  DRIVPARM doesn't touch the hard disk parameter block
which really is where you should make hard disk changes. (Let me know if you
want a copy of my HDENTRY.ASM which allows you to make such changes. But
remember -- you don't get ANY documentation with that one!)

If you make a change to the disk block, all other parameters stay the same,
except in the case of form factor.  If /F:n is used, a set of default values
stored in the program is used, and any other switches change that new default 
set. 

The output of the command DRIVPARM A: where drive A: is a 5.25" 360k floppy 
is:

DRIVPARM.COM  ver 1.0 (beta)  02-26-88   by Daniel Fandrich

Device parameters for A:
--------------------------------
       DRIVE DESCRIPTION:
       Special Functions:   $00
        Device Type (/F):   $00   5.25" 360k floppy drive
       Device Attributes: $0000
Number Of Cylinders (/T):    40
              Media Type:   $00

       MEDIA DESCRIPTION:
        Bytes Per Sector:   512
Sectors Per Cluster (/L):     2
        Reserved Sectors:     1
     Number Of FATs (/A):     2
   Root Dir Entries (/R):   112
           Total Sectors:   720
   Media Descriptor (/M):   $FD   double sided 9 sector disk
         Sectors Per FAT:     2
  Sectors Per Track (/S):     9
              Heads (/H):     2
        Hidden Sectors_L: $0000
        Hidden Sectors_H: $0000

     Total Disk Capacity:  360k

The values in the DRIVE DESCRIPTION section never change (except for Special 
Functions and Media Type, both of which I have no idea what they do). Those
values under MEDIA DESCRIPTION are either set up as the defaults in memory or
read in from the current disk (see BUGS).  They are only used while 
formatting a disk.  When reading or writing to a disk, the values in the 
disk's boot block are used, and the values shows in MEDIA DESCRIPTION are 
ignored.


BUGS:
=====
When invoking DRIVPARM using the drive letter convention (not /D:n), there 
must be a space before the first switch.

Sometimes executing DRIVPARM won't tell you the values currently in memory,
but will read new ones from the current disk (just those parameters listed
under MEDIA DESCRIPTION are read in -- the others always seem to work). This
seems to happen almost randomly, and so far I haven't figured it out.  (Maybe
I'm not setting a register properly before executing the IOCTL function call
or something silly like that.  Can someone help on this?)

It doesn't seem to work any more on my VDISK 3.3 RAM drive, although it did
originally.  It's probably caused by some conflict with resident programs. Now
it give me an illegal function call error.

I have done minimal error checking (basically range checking), so be careful
how you set your parameters up.

There is really no way for me to know how changing some of the parameters will
make your computer behave.  I've been using this program for several weeks,
and haven't lost any data yet, but I obviously haven't tried every combination 
of commands.  If you do find something wrong, please let _me_ know -- not my 
lawyer.


One final note:  I'd like to hear what you have to say about the way I've 
handled distributing this program.  I hate to spend time writing a program 
only to use it occasionally (even if on those occasions I can't make do 
without it).  I know there must be many others who could benefit by my work, 
but, as a student, I can't find the time to write complete and comprehensible 
documentation.  At least this way there is a probability that someone will 
descipher my notes and find a use for the program.

If this kind of format doesn't bother you, I have a few more programs that I, 
personally, can't live without that I'd be happy to share.


Dan Fandrich

CompuServe:   72365,306
BitNet:       userxagu@sfu.BITNET
         or:  shad04@uofmcc.BITNET
CNCP Dialcom: svp529
Mail (Canada):
 Ste. 471
 Box 8000
 Abbotsford, B.C.
Mail (U.S):
 Ste. 471
 Box 8000
 Sumas, WA   98295-8000
