ked@garnet.berkeley.edu (Earl H. Kinmonth) (07/15/89)
I have an ATT (Olivetti) 6310 AT clone running SCO Xenix/MSDOS 3.3. It has one 1.2 meg drive. I regularly format 5.25 disks to 720 K. These disks work fine under both Xenix and MSDOS on the ATT whether used with tar (linear sector addressing) or MSDOS directories. When I try to transfer these disks to a 286 Zenith (also running MSDOS 3.3), I encounter various problems. With MSDOS directory disks, the dir command (also ls under MKS) will list all the files on the disk but copies and reads fail. With tar disks, sector reads (using int 13) fail after the first track. The absread and biosdisk functions (TURBO C) also fail. Question: Is there any bullet proof way under MSDOS to read/write to a specific head-track-sector UP TO THE PHYSICAL LIMITS OF WHAT THE MEDIA/DRIVE WILL SUPPORT? For extra points: in the absence of something equivalent to the **IX inode, how does one tell under MSDOS whether an output file is also an input file? (I've asked this twice before with ZERO responses. Either it is (a) a very dumb question, not worthy of a response; (b) a real bitch; (c) my posting was ignored. PLEASE REPLY BY POSTING OR MAIL TO THE ADDRESS BELOW: Earl H. Kinmonth History Department University of California, Davis 916-752-1636 (voice, fax [2300-0800 PDT]) 916-752-0776 secretary (bitnet) ehkinmonth@ucdavis.edu (uucp) ucbvax!ucdavis!ucdked!cck (telnet or 916-752-7920) cc-dnet.ucdavis.edu [128.120.2.251] request ucdked, login as guest, no password
uhclem@trsvax.UUCP (07/17/89)
<> B>I have an ATT (Olivetti) 6310 AT clone running SCO Xenix/MSDOS 3.3. It B>has one 1.2 meg drive. I regularly format 5.25 disks to 720 K. These B>disks work fine under both Xenix and MSDOS on the ATT whether used with B>tar (linear sector addressing) or MSDOS directories. B>When I try to transfer these disks to a 286 Zenith (also running MSDOS B>3.3), I encounter various problems. With MSDOS directory disks, the dir B>command (also ls under MKS) will list all the files on the disk but B>copies and reads fail. With tar disks, sector reads (using int 13) fail B>after the first track. The absread and biosdisk functions (TURBO C) B>also fail. Although this does not answer the question you asked, it may eliminate the question. Your Zenith system may be like some other MS-DOS systems whose BIOS can't cope with the idea of 5.25 == 720K. They assume 5.25 == 1.2 or 360K. This is partly because IBM limited what configurations you can have in CMOS, and they never sold a 5.25" 720 drive. The fact that only the directory can be read (cylinder 0) is a clue that the operating system thinks cylinder 1-n are elsewhere. You are probably getting seek errors, although DOS probably won't report it as such. It is extremely unlikely that the media density was ok to handle the format on cylinder 0 but never works on cylinder 1 or higher, although you should be using 80Tk 96TPI media for 720K operation. If you can watch the heads while it operates, stick one of these disks in and seek about two-thirds into the capacity (720K remember) and see if the head pegs out on the inner stop. You may even be able to hear it. Don't worry (TM). The IBM startup test does this every time you boot, which most clones copied even though it is not very good for the drives. If it does peg, then the system is treating the drive as a 1.2 meg reading a 360K and is double stepping the head for each cylinder increment. (Under XENIX, pull out your uPC765 manual and decode the status returned in the read error. If it is a seek error, this is what you have got.) I routinely have to transport data to an older system with 5.25 720K drives and my MS-DOS system steadfastly refuses to cooperate. To get around this, I lie to the CMOS and tell the system that the drive is a 3.5" lowcap, which holds 720K. The BIOS quits double-stepping and I get my files across the abyss. Don't forget to put the CMOS back when you are done. Under XENIX, you should be able to force recognition by using the appropriate dev, that is if the XENIX floppy driver was written properly. I haven't tried this with the "real" SCO XENIX floppy driver. Hope this helps. <This information is provided by an individual and is not nor should be construed as being provided by Radio Shack or Tandy Corp. Radio Shack/Tandy Corp has no obligation to support the information provided in any way.> "Thank you, Uh Clem." Frank Durda IV @ <trsvax!uhclem> ...decvax!microsoft!trsvax!uhclem ...sys1!hal6000!trsvax!uhclem
ked@garnet.berkeley.edu (Earl H. Kinmonth) (07/18/89)
In article <196500030@trsvax> uhclem@trsvax.UUCP writes: [long and complicated discussion of how/why 720/5.25 disks would not work on an AT clone.] >done. Under XENIX, you should be able to force recognition by using the >appropriate dev, that is if the XENIX floppy driver was written properly. >I haven't tried this with the "real" SCO XENIX floppy driver. The real Xenix driver works fine. You make the appropriate /dev entry, and add to the /etc/default/tar and /etc/default/msdos entries and away you go. You do NOT need high denity floppies for 720 operation. Ordinary double density floppies are still within spec for this. The answer for MSDOS is a programme called fdread2.com that is included as part of an EXCELLENT German program called fdformat. This programme kicks MSDOS in its privates and leaves it stunned and happy with almost any disk! Earl H. Kinmonth History Department University of California, Davis 916-752-1636 (voice, fax [2300-0800 PDT]) 916-752-0776 secretary (bitnet) ehkinmonth@ucdavis.edu (uucp) ucbvax!ucdavis!ucdked!cck (telnet or 916-752-7920) cc-dnet.ucdavis.edu [128.120.2.251] request ucdked, login as guest, no password
jhood@biar.UUCP (John Hood) (07/19/89)
(Note the Followup-To:; we're getting rather far from Xenix) In article <196500030@trsvax> uhclem@trsvax.UUCP writes: [stuff about 720k 5.25" disks] >If you can watch the heads while it operates, stick one of these disks in >and seek about two-thirds into the capacity (720K remember) and see if the >head pegs out on the inner stop. You may even be able to hear it. >Don't worry (TM). The IBM startup test does this every time you boot, >which most clones copied even though it is not very good for the drives. >If it does peg, then the system is treating the drive as a 1.2 meg reading >a 360K and is double stepping the head for each cylinder increment. >(Under XENIX, pull out your uPC765 manual and decode the status returned > in the read error. If it is a seek error, this is what you have got.) Argh... I should warn you I had a little war with Bryan Headley [another Tandy person] once over doing this on the 1000TX. I disagree with those who would test drives by running them into stops. The IBM startup test does not bash heads against stops, at least on the AT; it only recalibrates and steps to track 34. The AT clones I've seen (uh, heard) are similar. Bashing head assemblies against their stops is not a Good Thing to do, in my opinion; many 5.25 drives are not built to accommodate it, and even on things like Apples and Commodores where it's a feature of the drive design, it's a major cause of drive problems. > >I routinely have to transport data to an older system with 5.25 720K drives >and my MS-DOS system steadfastly refuses to cooperate. > >To get around this, I lie to the CMOS and tell the system that the drive is >a 3.5" lowcap, which holds 720K. The BIOS quits double-stepping and I get >my files across the abyss. Don't forget to put the CMOS back when you are >done. Under XENIX, you should be able to force recognition by using the >appropriate dev, that is if the XENIX floppy driver was written properly. >I haven't tried this with the "real" SCO XENIX floppy driver. This BIOS trick will only work if the machine uses dual-speed 1.2M drives. The more common case of single-speed drives and floppy controllers with three different clock rates won't work with this trick; the data will get written at the wrong clock rate. There are, I believe, other BIOS tricks which will work with most machines. Just curious; what machine are you doing this on? I don't think I've yet used one that did have double-speed drives. --jh -- John Hood, Biar Games snail: 10 Spruce Lane, Ithaca NY 14850 BBS: 607 257 3423 domain: jhood@biar.uu.net bang: anywhere!uunet!biar!jhood You may redistribute this article only to those who may freely do likewise.
uhclem@trsvax.UUCP (07/21/89)
<> R3>The IBM startup test does not bash heads against stops, at least on R3>the AT; it only recalibrates and steps to track 34. Hmm, well it does it on the true-blue ATs we have here with 40 track drives in them. (Since the high cap drives have more than 40, no problem.) Our friendly IBM rep explained it away as I described. I even recall that someone took a peek at the IBM BIOS listing to confirm that it wasn't just DOS doing this stunt. (We figured we might get Microsoft to change it if it was their doing.) I agree that pegging the drive isn't a good thing to do on a regular basis, but for a single experiment, there should not be any problem, unless you have got Tandon drives or something. Most half height drives made after 1985 "know" where they are and will disregard stepping pulses beyond their capacity. Check up on the guys using Radio Shack Model 4 systems and trying to get 43 tracks out of a 40 track drive and had to use older, dumber drives if you want to hear more about this. By the way, someone stated that you don't need high-cap media for 720K 5.25 operation. That is true. But you should use 96 TPI (80 track) DSDD media. There *really* is such a thing and it is different from high cap/density (96 TPI 80 trk DSHD) and normal 48 TPI 40 trk DSDD. Since 5.25 720K is a less common size, not everyone carries that type of disk. But Rad Shack does. R3>This BIOS trick will only work if the machine uses dual-speed 1.2M R3>drives. The more common case of single-speed drives and floppy R3>controllers with three different clock rates won't work with this R3>trick; the data will get written at the wrong clock rate. In his case, he was able to read cylinder 0 correctly, so the transfer rate was not the issue, and he already stated an AT environment which would have a dual speed adapter. <My opinion, but hey, I've only been doing this for 15 years.> "Thank you, Uh Clem." Frank Durda IV @ <trsvax!uhclem> ...decvax!microsoft!trsvax!uhclem ...sys1!hal6000!trsvax!uhclem
jhood@biar.UUCP (John Hood) (07/24/89)
In article <196500031@trsvax> uhclem@trsvax.UUCP writes: >[In some article about three days ago, I (John Hood) wrote:] >R3>The IBM startup test does not bash heads against stops, at least on >R3>the AT; it only recalibrates and steps to track 34. > >Hmm, well it does it on the true-blue ATs we have here with 40 track drives >in them. (Since the high cap drives have more than 40, no problem.) >Our friendly IBM rep explained it away as I described. I even recall that >someone took a peek at the IBM BIOS listing to confirm that it wasn't just >DOS doing this stunt. Well, I looked at the BIOS listing in the back of the true-blue IBM Tech Ref manual, and it only steps to track 34. However, now that I look at it a bit more closely, you're probably right: it may be double-stepping the drive. I've never seen or used an AT with a 360k drive as drive 0, and it isn't a good idea to have one set up that way when the clock/CMOS battery goes dead. >R3>This BIOS trick will only work if the machine uses dual-speed 1.2M >R3>drives. The more common case of single-speed drives and floppy >R3>controllers with three different clock rates won't work with this >R3>trick; the data will get written at the wrong clock rate. > >In his case, he was able to read cylinder 0 correctly, so the transfer >rate was not the issue, and he already stated an AT environment which >would have a dual speed adapter. The comment wasn't aimed at Earl's machine, or Tandy's, but rather the typical AT clone. Other people reading this might get confused. Earl's AT&T 6300+ is not a typical IBM clone. --jh -- John Hood, Biar Games snail: 10 Spruce Lane, Ithaca NY 14850 BBS: 607 257 3423 domain: jhood@biar.uu.net bang: anywhere!uunet!biar!jhood You may redistribute this article only to those who may freely do likewise.
ked@garnet.berkeley.edu (Earl H. Kinmonth) (07/24/89)
>The comment wasn't aimed at Earl's machine, or Tandy's, but rather the >typical AT clone. Other people reading this might get confused. >Earl's AT&T 6300+ is not a typical IBM clone. Not a flame. Just a minor correction. I do not have a 6300+. I have a 6310. This is supposed to be a real AT clone. It does, however, handle 720K/5.25 disks without problem (so it is not a ~true~ clone). A true blue machine is not so rational. Just to get back to the original issue: moving 720/5.25 tar disks between MSDOS and Xenix. I have a solution, a German program, fdformat that includes a utility that makes AT-clones behave rationally. My version of tar (with source code) remains available. Cost == support == 0.00, but this may double in the future. (For best results use the uucp address; your mileage may vary.) Earl H. Kinmonth History Department University of California, Davis 916-752-1636 (voice, fax [2300-0800 PDT]) 916-752-0776 secretary (bitnet) ehkinmonth@ucdavis.edu (uucp) ucbvax!ucdavis!ucdked!cck (telnet or 916-752-7920) cc-dnet.ucdavis.edu [128.120.2.251] request ucdked, login as guest, no password
bote@csense.UUCP (John Boteler) (07/25/89)
From article <26422@agate.BERKELEY.EDU>, by ked@garnet.berkeley.edu (Earl H. Kinmonth): > In article <196500030@trsvax> uhclem@trsvax.UUCP writes: > > [long and complicated discussion of how/why 720/5.25 disks would not > work on an AT clone.] > >>done. Under XENIX, you should be able to force recognition by using the >>appropriate dev, that is if the XENIX floppy driver was written properly. >>I haven't tried this with the "real" SCO XENIX floppy driver. > > The real Xenix driver works fine. You make the appropriate /dev entry, > and add to the /etc/default/tar and /etc/default/msdos entries and away > you go. Has anybody suggested using the following DOS command: format [d:] /n:9 /t:80 this will format the diskette to 9 sectors * 80 cylinders * 2 heads/cylinder * 512 bytes/sector = 737280 bytes. This assumes your hardware supports it. You only mentioned a Zenith AT clone, but this does not automatically mean that you have a high capacity drive. -- Bote uunet!cyclops!csense!bote {mimsy,sundc}!{prometheus,hqda-ai}!media!cyclops!csense!bote