Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!rpi!batcomputer!cornell!uw-beaver!ubc-cs!alberta!dvinci!weyr!p5.f6.n342.z1.FIDONET.ORG!Gerry.Rozema From: Gerry.Rozema@p5.f6.n342.z1.FIDONET.ORG (Gerry Rozema) Newsgroups: comp.os.os2 Subject: Re: OS/2 and Hard Drives Message-ID: <498.25CC2027@weyr.FIDONET.ORG> Date: 2 Feb 90 17:42:17 GMT Sender: ufgate@weyr.FIDONET.ORG (newsout1.26) Organization: FidoNet node 1:342/6.5 - Arctic Front HST, Edmonton Alta Lines: 33 VP> > If os/2 didn't use the BIOS, than how can you explain my 150mb VP> drive VP> > working when it is defined as type 1 in my CMOS (type 1 == 10mb I VP> > think)? My WD1007's BIOS knows the real size of my disk. VP> VP> Actually it's below the BIOS. I have a 1007 as well. It's apparently VP> down in the hardware itself. Love it. VP> VP> Sometime I'd really like to get the entire spiel on what these ESDI VP> controllers are doing, though. If you manage to corner someone who can VP> explain, I'd love to hear the story. I am answering Vince because he is the last on this topic. This is actually for everybody following the thread. There seems to be some confusion in the role of the bios under os/2 regarding disk access. I hope this will clear it up. OS/2 uses the bios during the real mode portion of the boot process. The bios is used to first read the drive parameters, and then load device drivers. Once the device drivers are loaded and initialized they are used. Disk01.sys DOES NOT use the bios to do disk access. It reads and writes directly to the disk. If your disk contoller does not need an on board bios, you _should_ be safe. If it does use it's own bios, you _might_ be safe. In the case of the wd1007, it only really needs the bios to initialize the disk. That is because the controller provides a lot of functionality for the low-level format process with regards to modes of format and operation. Once the drive is formatted, the wd1007 appears at the hardware level to be just another mfm controller, except it has '63 sectors per track, 15 he ads, and however many tracks your disk needs to use it all'. In the case of a MiniScribe 9380e that works out to 600+ cylinders. Typically problems with os/2 not completeing the boot can be isolated to disk/video/keyboard problems. People tend to blame the bios, but should really blame the hardware. Usually the problem is that the bios has some 'fixes' in there that make hardware problems transparent to dos. Because os/2 does not use the bios, the problems come back. In the case of the wd1007, the hardware does the job very well, so it can run clean without the bios involved. You can read and write just as if it were an other mfm drive. If your system suffers from a hung boot, suspect hardware. If the disk is 'non-standard', ie SCSI, that is the problem. If the disk is fairly standard, suspect video next. If the system gets as far as showing PM, then suspect the keyboard and the motherboard in that order. Try a keyboard that is known to work on another os/2 system. If it still fails, get a new motherboard. My system is probably more suspect for hardware problems than most. I have a 'no-name' tiawanese 286 motherboard, Miniscribe 9380 ESDI drive with wd1007 controller, prototype vga card and the rest is 'no-name' clone equipment. The only brand name stuff I have is a USR modem. The system is used for device driver development under os/2. Heck, if it runs stable here, it should run stable on just about any 'good' clone. I dont think it is as hardware sensative as most people seem to believe. The only part of the whole system that gets real iffy is the vga. ALL vga chipsets have bugs. The IBM code does not account for any bugs but its own. The MicroSoft drivers account for known bugs in a few more chipsets. It's best to buy a vga card that comes with a device driver. Then you know that bugs in your card are hidden by your device driver. The problems with 'stripies' when switching from full screen to text are a good example. I have never seen them back since I found the cause, and fixed it in my device driver. In fact, that is a 'feature' of the Tseng chip, and the fix code causes LOTS of other chips to appear 'broken'. I fixed the driver by removing the Tseng fixes. Gerry -- Gerry Rozema - via FidoNet node 1:140/22 UUCP: alberta!dvinci!weyr!342!6.5!Gerry.Rozema Internet: Gerry.Rozema@p5.f6.n342.z1.FIDONET.ORG Standard Disclaimers Apply...