piner@newton.physics.purdue.edu (Richard Piner) (08/15/90)
For those who don't like puzzles, hit "n" now. I've got a real puzzle for the wizards of the net. I have an old hard disk subsystem that is not working and I'll be damned if I can figure out why. Here are the facts. Miniscribe 2012 (10 meg) hard drive connected to a Xebec S1410 controller connected to a SASI host adapter. The drive will not write, but I can read just fine. The computer to SASI interface seems to be working correctly because I can talk to the controller ok. The controller passes it's internal test and tells the computer everything is fine. Control codes and data passed between computer and controller all make sense. So I assume the interface is working ok. I happending to have a spare miniscribe, so I swapper disk drives. Same results. I then ordered a spare controller board. A side note, I got the Xebec controller from Computer Surplus Store. They are listed in Computer Shopper. Thanks to everyone who responded to my request for help locating this part. Well, the controller board showed up today, and I swapper in the new board. No change. I can still read the disk but not write to it. So, now I've tried two different disk and two differenct controllers and it still does not write. So, I checked all the wires in the connecting cables. Twice. They are fine. I checked the power supply. Within spec, no ripple. I've tried formatting the drive, this is a high level command for the Xebec. It goes off and tries to format the drive, but just goes into a loop. After, resetting the system, I can still read the old data, so format is not writting to the drive. Clearly there is some problem between the controller and drive, but I'm out of ideas. I'm stumped. I can't believe that I have two dead drives with the exact same problem, or two dead controllers with the exact same problem. The host to SASI interface seems to be communicating fine. Such a simple thing either works or it doesn't. The power is ok and so are the cables. I'm down to checking signals on chips, still I can find no problem. Does anyone have a clue? Is there something I'm overlooking. Another chap had a similar problem with a Xebec drive and posted here a couple of weeks ago. Any progress? R. Piner
jws@thumper.mlb.semi.harris.com (James W. Swonger) (08/15/90)
Perhaps the controller power up in a write-protected default mode and you have to explicitly remove write protection.
grege@gold.GVG.TEK.COM (Greg Ebert) (08/15/90)
Check the WRITE_GATE signal, pin 6 on a 34-pin cable (aka ST506). When the WRITE_GATE signal is low, it'll wipe-out anything on the disk, which means that whatever is on the differential WRITE_DATA lines is immaterial. If you can, try grounding WRITE_GATE and see if it obliterates the data. At least you can isolate the problem between the drive and the controller. This sounds like a neat puzzle :-O
hobbit@remus.rutgers.edu (*Hobbit*) (08/16/90)
I installed a switch in my PC to deliberately open the write gate signal, and damned if it doesn't prevent the controller from scribbling on the disk. I never understood why PCs don't normally supply real write-protect switches, but they don't and this is one reason viruses are so rampant... Anyway, the fun thing about this hack is that the controller has no clue whether the write succeeded or not, and due to disk buffering, MSLoss really thinks the new file is there, and you can even type it; but the next time you do a DIR or something the buffers get flushed and the file mysteriously disappears. If you do use one of these, make sure you don't flip it in the middle of some disk operation, or you'll REALLY be up the crick. Oh, yeah, as someone else said it's pin 6 on the larger ST506 connector. At any rate, your stumper's behavior sounds exactly like your write gate isn't going low when the controller wants. _H*
dana@lando.la.locus.com (Dana H. Myers) (08/18/90)
In article <Aug.15.13.24.38.1990.26985@remus.rutgers.edu> hobbit@remus.rutgers.edu (*Hobbit*) writes: >I installed a switch in my PC to deliberately open the write gate signal, >and damned if it doesn't prevent the controller from scribbling on the disk. >Anyway, >the fun thing about this hack is that the controller has no clue whether >the write succeeded or not, and due to disk buffering, MSLoss really thinks >the new file is there, and you can even type it; but the next time you do a >DIR or something the buffers get flushed and the file mysteriously disappears. On MS-DOS, the shell (command.com) normally provides a command to enable or disable verification of disk writes. This is the 'verify' command. At the DOS prompt, issue the command 'verify'. You will be notified of the current state of verification ('on' or 'off'). If it is off, try setting it on; enter the command 'verify on'. When verify is on, DOS informs the device driver that it wishes verfication on write; a device driver, at the whim of the implementor, may not actually verify the data, but generally will. I'd suggest trying this with write gate disabled, to see if your implementation of DOS does perform this checking. ***************************************************************** * Dana H. Myers KK6JQ | Views expressed here are * * (213) 337-5136 (ex WA6ZGB) | mine and do not necessarily * * dana@locus.com | reflect those of my employer * *****************************************************************
scjones@thor.UUCP (Larry Jones) (08/20/90)
In article <15649@.la.locus.com>, dana@lando.la.locus.com (Dana H. Myers) writes: > In article <Aug.15.13.24.38.1990.26985@remus.rutgers.edu> hobbit@remus.rutgers.edu (*Hobbit*) writes: > >I installed a switch in my PC to deliberately open the write gate signal, > >and damned if it doesn't prevent the controller from scribbling on the disk. > > >Anyway, > >the fun thing about this hack is that the controller has no clue whether > >the write succeeded or not, and due to disk buffering, MSLoss really thinks > >the new file is there, and you can even type it; but the next time you do a > >DIR or something the buffers get flushed and the file mysteriously disappears. > > On MS-DOS, the shell (command.com) normally provides a command to > enable or disable verification of disk writes. This is the 'verify' > command. At the DOS prompt, issue the command 'verify'. You will be > notified of the current state of verification ('on' or 'off'). If it is > off, try setting it on; enter the command 'verify on'. This is a common misconception. When you enable VERIFY in MS-DOS it only verifies that what is on the disk is readable. It most definitely does NOT compare what it reads to what what written. The confusion is understandable given the terrible description given in most DOS references. For example, the MS-DOS Encyclopedia description of VERIFY refers to COPY/V which says (notes in [] are my comments): The /V switch causes a read-after-write verification of each block of the destination file [blatently misleading]. Its effect is equivalent to that of the VERIFY ON command [don't you just love circular definitions?]. No comparison is made between the source and destination files [finaly, the key phrase!] -- the /V switch simply causes MS-DOS to verify that the destination file has been written correctly [again somewhat misleading]. All that VERIFY does is call INT 13, Function 4, Verify Disk Sectors, which just verifies that the sector is readable, not that it contains any particular data. ---- Larry Jones UUCP: uunet!sdrc!thor!scjones SDRC scjones@thor.UUCP 2000 Eastman Dr. BIX: ltl Milford, OH 45150-2789 AT&T: (513) 576-2070 It doesn't have a moral, does it? I hate being told how to live my life. -- Calvin