dpz@athos.rutgers.edu (David P. Zimmerman) (04/12/88)
I was looking through my MS-DOS 3.30 manual and found a nifty feature called "drivparm" that you can stick in your CONFIG.SYS file. Basically it is supposed to let you change the characteristics of a block device to another specification (e.g., make an 80 track drive act like a 40 track). However, try as I might (and try as another DOS wizard here might), all that I can get spit out at boot time is a complaint about "drivparm" being an unrecognized command. Anybody get this to work, or is this truly nifty feature a truly nifty vapor? dpz -- David P. Zimmerman, Rutgers University Center for Computer and Info Services Internet: dpz@rutgers.edu UUCP: rutgers!dpz Bitnet: zimmerman@zodiac
bob@acornrc.UUCP (Bob Weissman) (04/13/88)
In article <Apr.12.12.26.22.1988.14955@athos.rutgers.edu>, dpz@athos.rutgers.edu (David P. Zimmerman) writes: > I was looking through my MS-DOS 3.30 manual and found a nifty feature > called "drivparm" that you can stick in your CONFIG.SYS file. > > However, try as I might (and try as another DOS wizard here might), > all that I can get spit out at boot time is a complaint about > "drivparm" being an unrecognized command. Yes, "drivparm" does not work in DOS 3.3. I corresponded with a MicroSoft rep on CompuServe about this and he said it will probably become available as a free upgrade some time in the future. (In the mean time, they're getting dozens of calls about it!) So you still have to use device=driver.sys ... instead. -- Bob Weissman Internet: bob@acornrc.uucp UUCP: ...!{ ames | decwrl | oliveb | apple }!acornrc!bob Arpanet: bob%acornrc.uucp@ames.arc.nasa.gov
esd@cbterra.ATT.COM (Eric S. Deese) (04/13/88)
In article <Apr.12.12.26.22.1988.14955@athos.rutgers.edu> dpz@athos.rutgers.edu (David P. Zimmerman) writes: >I was looking through my MS-DOS 3.30 manual and found a nifty feature >called "drivparm" that you can stick in your CONFIG.SYS file. >However, try as I might (and try as another DOS wizard here might), >all that I can get spit out at boot time is a complaint about >"drivparm" being an unrecognized command. >Anybody get this to work, or is this truly nifty feature a truly nifty >vapor? > >David P. Zimmerman I have spent several hours with it also, as I thought I might have a use for it. Like yourself, DOS kept telling me that it didn't like the drivparm command. I tend to believe that it is "truly nifty vapor. Eric Deese (cbosgd!esd) -- Eric Deese (cbosgd!esd) AT&T Bell Labs
leefi@microsoft.UUCP (Lee Fisher) (04/14/88)
> esd@cbterra.att.com (Eric S. Deese) writes: > > dpz@athos.rutgers.edu (David P. Zimmerman) writes: > > > > I was looking through my MS-DOS 3.30 manual and found a nifty feature > > called "drivparm" that you can stick in your CONFIG.SYS file. > > However, try as I might (and try as another DOS wizard here might), > > all that I can get spit out at boot time is a complaint about > > "drivparm" being an unrecognized command. Anybody get this to work, > > or is this truly nifty feature a truly nifty vapor? > > I have spent several hours with it also, as I thought I might have a > use for it. Like yourself, DOS kept telling me that it didn't like > the drivparm command. I tend to believe that it is "truly nifty vapor. DRIVPARM does not work in MS-DOS v3.30. There is a new release of the MS-DOS v3.30 "packaged product" called v3.30A which has fixed this. It has been sent to manufacturing and will be available soon. OEMs already have this update. If you have an OEM version of DOS, contact them for availability of a fix. If you have the "packaged product" version, call Microsoft at 206-882-8089 and tell them that you have this problem; they'll take your name/address, and send you this update when it becomes available. -Lee ________ 01001100 Lee Fisher, Microsoft Corp., Redmond, WA. 01000101 {uw-beaver,decvax,decwrl,trsvax,sun,attunix,uunet}!microsof!leefi 01000101 leefi@microsof.uucp 01000110 leefi@microsof.beaver.washington.edu 01001001 disclaimer: My opinions are my own, not those of my employer.
wtm@neoucom.UUCP (Bill Mayhew) (04/14/88)
The DRIVPARM= parameter for CONFIG.SYS is one of the things that has been [quasi?] officially acknowledged as not always working correctly. I have had varying degrees of luck with it on the machines here. It seems to matter what BIOS is in the machines. Machines with dumb BIOS seem to get along better with DRIVPARM= than newer machines. You may want to use the DRIVER.SYS installable device driver instead of DRIVPARM=. DRIVER.SYS takes the same option switches as specifying DRIVPARM=. The advantage is that DRIVER.SYS is self-contained, and would appear from personal experience to have fewer problems with BIOS conflict. The disadvantage with using DRIVER.SYS is that it has to assign a logical drive letter one letter greater than your last physical drive. Thus, on a hard disk system a 1.44 meg 3.5 inch drive is stuck being accessed as drive D when you use the 1.44 meg mode, while it is B: in 720K mode. (The only way I've been able to get 1.44 meg drives work is by using DRIVER.SYS.) One might try supplying the appropriate leading zeros, etc. For instance, you might want to enter the heads switch as /H02. Note that IBM PS/2s have integral support for 1.44 meg, and don't require DRIVER.SYS. I have a PS/2 model 80, and it insists on formatting even 720K disks as 1.44 meg. Maybe it needs a DRIVER.SYS running to go to the low density mode for formatting. The PS/2 seems to correctly sense the density of disks that have already been formatted some place else. By the way, for the record, I don't recommend formatting 720K disks for 1.44 meg. Grrrrr. --Bill
bkliewer@iuvax.cs.indiana.edu (Bradley Dyck Kliewer) (04/16/88)
In article <1104@neoucom.UUCP> wtm@neoucom.UUCP (Bill Mayhew) writes: >Note that IBM PS/2s have integral support for 1.44 meg, and don't >require DRIVER.SYS. I have a PS/2 model 80, and it insists on >formatting even 720K disks as 1.44 meg. Maybe it needs a DRIVER.SYS >running to go to the low density mode for formatting. The PS/2 >seems to correctly sense the density of disks that have already >been formatted some place else. By the way, for the record, I >don't recommend formatting 720K disks for 1.44 meg. > >Grrrrr. > >--Bill You can use options on with FORMAT for 720K diskettes. I don't have a DOS manual right here, but it's something like FORMAT /T:80 /N:9. I have a 1.44 Meg (using a driver from BASTECH since my BIOS is too old for even DRIVER.SYS), which is also set to D:. I use ASSIGN to set it to B which works for everything except FORMAT and CHKDSK (both 1.44 and 720 are addressable by either B: or D:. The only thing I really hate about this setup is that the Bastech driver is copy protected. If anybody out there has seen any non copy protected 3.5" drivers, please tell me by e-mail. It's the only copy protected software on my system and I want it off. Bradley Dyck Kliewer Hacking... bkliewer@iuvax.cs.indiana.edu It's not just an adventure It's my job!
dpz@athos.rutgers.edu (David P. Zimmerman) (04/20/88)
Thanks for all the replies. Looks like I'll be using DRIVER.SYS (barf, gag) until the 3.30a update comes through.... dpz -- David P. Zimmerman, Rutgers University Center for Computer and Info Services Internet: dpz@rutgers.edu UUCP: rutgers!dpz Bitnet: zimmerman@zodiac
frodo@wcom.UUCP (Jim Scardelis) (04/27/88)
In article <1104@neoucom.UUCP>, wtm@neoucom.UUCP (Bill Mayhew) writes: > Note that IBM PS/2s have integral support for 1.44 meg, and don't > require DRIVER.SYS. I have a PS/2 model 80, and it insists on > formatting even 720K disks as 1.44 meg. Maybe it needs a DRIVER.SYS > running to go to the low density mode for formatting. The PS/2 > seems to correctly sense the density of disks that have already > been formatted some place else. By the way, for the record, I > don't recommend formatting 720K disks for 1.44 meg. > The FORMAT command under DOS 3.3 takes a couple useful options: /T:<# of tracks> /N:<# of sectors> For example, on a PS/2 model 50,60,or 80, to format a 720K disk, you do a "FORMAT A:/T:80/N:9". In the "old days" of the AT, you could FORMAT a 360K disk in a 1.2 MB drive with a "FORMAT A: /4"...guess there got to be too many different types of disks for IBM to assign a number to each...
tneff@atpal.UUCP (Tom Neff) (04/29/88)
In article <243@wcom.UUCP> frodo@wcom.UUCP (Jim Scardelis) writes: > ... In the "old days" of the AT, you could FORMAT a 360K disk in a 1.2 MB >drive with a "FORMAT A: /4"...guess there got to be too many different >types of disks for IBM to assign a number to each... I don't have a copy of PC-DOS 3.3 handy, but I can tell you that Compaq DOS 3.31B not only supports the new /T: and /N: switches in FORMAT, but also the original /4 switch. I just formatted a bunch that way today. -- Tom Neff UUCP: ...uunet!pwcmrd!skipnyc!atpal!tneff "None of your toys CIS: 76556,2536 MCI: TNEFF will function..." GEnie: TOMNEFF BIX: are you kidding?
mintz@hpindda.HP.COM (Ken Mintz) (04/30/88)
> In the "old days" of the AT, you could FORMAT a 360K disk in a 1.2 MB > drive with a "FORMAT A: /4".... But is that reliable? I've been told that writing to a 360K disk on a 1.2M drive is not supported. The explanation was as follows: the HD disk has thinner metallic surfaces, so the 1.2M write heads don't put out as strong a signal as do the 360K heads. Of course, because the 360K heads are N times stronger than needed, the 1.2M heads will work X% of the time. (Anyone have some idea what "X" is?) Ken Mintz
stevewa@upvax.UUCP (Steve Ward) (05/02/88)
In article <4330071@hpindda.HP.COM> mintz@hpindda.HP.COM (Ken Mintz) writes: >> In the "old days" of the AT, you could FORMAT a 360K disk in a 1.2 MB >> drive with a "FORMAT A: /4".... > > But is that reliable? I've been told that writing to a 360K disk on a > 1.2M drive is not supported. The explanation was as follows: the HD disk > has thinner metallic surfaces, so the 1.2M write heads don't put out as > strong a signal as do the 360K heads. Of course, because the 360K heads > are N times stronger than needed, the 1.2M heads will work X% of the time. > (Anyone have some idea what "X" is?) > >Ken Mintz I've been using 360K disks in my 1.2M drive for some time now. As long as you're only going to be using them in 1.2M drives, they should work OK. Using these disks in a regular 360K drive can be a problem, though. I've found that the best results are obtained if the disk if formatted in a 360K drive. If that's not possible, you can get almost as good reliability by using only blank disks (either new or erased with an electromagnet). You can then format them in the 1.2M drive with the "/4" option (which IS still supported in MS-DOS 3.3) and use them. The problems seem to occur with disks that have been used previously in 360K drives (ie. had data on them), then are re-formatted or DEL *.*'d and use on the 1.2M drive. The reason for this can be traced to the difference in drive head width. The high density drive has a much thinner head than the 360K, so it writes a 360K disk by laying down one thin track in the middle of the wider 360K track. If the disk is then read by a 360K drive, it will "see" both the new track and the outside "strips" of the original wider track. This of course is interpreted as garbage. This indicates to me that there would be no exact "percentage failure" for 360K disks in 1.2M drives. Steve
len@elxsi.UUCP (Len Mills) (05/03/88)
In article <4330071@hpindda.HP.COM> mintz@hpindda.HP.COM (Ken Mintz) writes: >> In the "old days" of the AT, you could FORMAT a 360K disk in a 1.2 MB >> drive with a "FORMAT A: /4".... > > But is that reliable? I've been told that writing to a 360K disk on a > 1.2M drive is not supported. The explanation was as follows: the HD disk > ... the 1.2M heads will work X% of the time. > (Anyone have some idea what "X" is?) > When the proper procedure is followed "X" is 100. What is this proper procedure, and why does it work? Glad you asked. The data written by a 360k drive is WIDER than than that written by a 1.2m drive. If a disk which was previously written by a 360 is formatted and written by a 1.2, the previous magnetization is not guaranteed to be erased. This remaiming magnetization can cause read errors on either 360s OR 1.2s with slightly different alignment charateristics. The highly reliable procedure is to degauss the 360s before doing the FORMAT A: /4. This can be done in a number of ways, using various equipment. My favorite method is to use a bulk tape eraser built for reel-to-reel tape. Home units can do 10 at a time; computer-room units can do 40 in four stacks of 10 at a time. I position the disks so that the center of rotation is at the center of rotation of the tape reel. This process is reliable and repeatable. >Ken Mintz -- Len Mills ... {uunet,ucbvax!sun,lll-lcc!lll-tis,altos86,bridge2}!elxsi!len