neese@adaptex.UUCP (08/17/89)
>I am having major problems putting an Everex STEP 386/20 >system together using a Imprimis/CDC SCSI interface hard drive >and an Adaptec SCSI controller. The drive is a Wren V half-height, >Model 94221-190 (s/n 3007861) which is spec'ed to be 190 Mbytes >formatted (209 Mbytes unformatted). I am using an Adaptec 1542A >(date code ? 8923 ) controller. The bios chip on the Adaptec is >labeled 420-403-00A and the firmware encoder chip is 420-504-00C >E7BC. The problems occur during formatting, if the hard disk >is formatted in the Everex machine everything seems to proceed >OK, except that it formats out to about 177 Mbytes instead of 190. The rest of the capacity is loet due to sector sparing. I have had this discussion with many people. That is why Tandy sales the same drive but only advertised as a 170MB drive. This is the real capacity that a user can get to. You can reprogram the drvie to raise the user capacity but then you loose sector spares. As far as I can tell, someone misrepresented information about the drive to you or whoever sold it to you doesn't know a thing about SCSI. >If the drive and the controller are put in a 286 AT clone the drive >can be formatted correctly but only to 177 Mbytes again. It works OK >in the 286 and can be moved to the Everex 386 where it will boot the >system and seems to function normally. Attempting to re-format in the >Everex produces the same result as described above. I assume you are talking about the MS-DOS formatter versus the low-level SCSI formatter. As the low-level formatter does not have a thing to do with the host adapter. The drive is responsible for doing the low-level format. The host adapter issues a 6 byte command to the drive to do the low-level format and the host adapter hangs around waiting for the drive to finish. To reduce the finger pointing, you might try asking Everex if they have ever tested the 1540 in their system. As it is one of 2 host adapters that uses bus master, if they have not tested it, then they cannot say it is the host adapter. As the host adapter is a bus master, the only way they can know if they did thier bus design right is to test it with the host adapter. I know of some motherboards that do not have the bus master circuit designed properly on their bus and the 1540 will not work in them. I have personally used the 1540 in Compaq, Tandy, AST, and IBM systems, with no problem. >Another curious thing about the drive is that CoreTest indicates that >the average access time is about 22 mS and the track-to-track is about >8 mS. The 94221 is supposed to be 18 mS and 4 mS. This is the second >CDC drive in this fiasco, the first one would spin up but wouldn't >respond at all. Is this a problem with CoreTest and a SCSI drive or >is it the real performance ? The problem is, Coretest (like many other benchmarks), think all drives use a physical interface, that is, when the program asks DOS for the drive parameters, they take those parameters to be the real parameters. SCSI does not have a physical interface and the on-board SCSI BIOS fakes one so that DOS will be happy. SCSI is logically block oriented and not head, cylinder, sector oriented. Therefore, when Core attempts to do the track to track seek times, it ends up seeking more than one track, unless the drive has 64 heads (none spring to mind). So heres what the drive does. If the drive has 8 data heads, Core ends up telling the drive to actually seek 8 cylinders instead of one. This is why the seek times for a SCSI device are difficult to test. In order to do it right you would have to take the physical paramters of the drive and calculate what Core would need to make the drive do a one cylinder seek. The average seek times for a SCSI drive are also misleading. The manufacturer publishes the mechanical seek times for thier products. This is correct, due to the many ways SCSI can be implemented for the host computer seek times can vary tremendously. When you tell a SCSI drive to seek, the drive disconnects from the bus until it finds the block you told it to seek to and then it reconnects to the bus. This arbitration which is transparent to the user, gets calculated in with how Core does its seek test (which is usually about 2ms for dis/reconnect). How fast this occurs is directly controlled by the drive and not the host adapter, if the host adapter has hardware handshaking. Also, you must remember that CDC, by default, disables thier read ahead on the drive. This is also software controllable. I hope to be posting a program real soon that would allow you guys to take control of these things. The program will tell you real quick if your system is properly designed to use a bus master. The best advice I can give anyone thinking of purchasing a computer, and will want to use the 1540 is to contact the manufacturer and ask if they have qualified the host adapter in thier system. If they haven't then I would shop elsewhere just to save you personal grief. Roy Neese Adaptec Central Field Applications Engineer UUCP @ {merch,texbell,killer}!cpe!adaptex!neese