Peter.Fitzsimmons@p1.f628.n250.z1.FIDONET.ORG (Peter Fitzsimmons) (01/30/90)
> OS/2 does not use ROM to access the hard drives. But it does play by > the same table that is in IBM ROM. I think you're wrong on this point, at least for non-ps/2 computers. If Gerry Rozema is listening in, maybe he'll tell us the real scoop. If os/2 didn't use the BIOS, than how can you explain my 150mb drive working when it is defined as type 1 in my CMOS (type 1 == 10mb I think)? My WD1007's BIOS knows the real size of my disk. -- Peter Fitzsimmons - via FidoNet node 1:140/22 UUCP: alberta!dvinci!weyr!250!628.1!Peter.Fitzsimmons Internet: Peter.Fitzsimmons@p1.f628.n250.z1.FIDONET.ORG Standard Disclaimers Apply...
Joe.Salemi@p1.f136.n109.z1.FIDONET.ORG (Joe Salemi) (02/02/90)
In a message to Kenneth Neal <29 Jan 90 21:17:04> Peter Fitzsimmons wrote: PF> If os/2 didn't use the BIOS, than how can you explain my 150mb drive PF> working when it is defined as type 1 in my CMOS (type 1 == 10mb I PF> think)? My WD1007's BIOS knows the real size of my disk. It only uses the BIOS at boot-time, to install the drivers and tables to the devices. Once OS/2 is running, it generally doesn't touch the BIOS at all. -- Joe Salemi - via FidoNet node 1:140/22 UUCP: alberta!dvinci!weyr!109!136.1!Joe.Salemi Internet: Joe.Salemi@p1.f136.n109.z1.FIDONET.ORG Standard Disclaimers Apply...
Peter.Fitzsimmons@p1.f628.n250.z1.FIDONET.ORG (Peter Fitzsimmons) (02/02/90)
> >If os/2 didn't use the BIOS, than how can you explain my 150mb drive > >working when it is defined as type 1 in my CMOS (type 1 == 10mb I > >think)? My WD1007's BIOS knows the real size of my disk. > > Because by the time POST completes and the operating system bootstrap is > loaded, the INT 41H drive parameter vector is pointing at a "drive type" > that the WD1007 has constructed during POST. Thanks, that makes sense. But if the drive params are 'constructed', as you say, where IS the vector pointing to? Surely it can't be in RAM? Hmmm, sudden realization: The PS/2's with large ESDI disks have slightly less than 640K free in lower memory. If I remember correctly, this is where is stores the drive parameter table. After reading your note, it all clicked in. The ps/2 POST is building the table there and then only reporting 639K free. Do you know how the WD1007 does it? -- Peter Fitzsimmons - via FidoNet node 1:140/22 UUCP: alberta!dvinci!weyr!250!628.1!Peter.Fitzsimmons Internet: Peter.Fitzsimmons@p1.f628.n250.z1.FIDONET.ORG Standard Disclaimers Apply...
Gerry.Rozema@p5.f6.n342.z1.FIDONET.ORG (Gerry Rozema) (02/03/90)
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...Jim.King@p3.f1.n396.z1.FIDONET.ORG (Jim King) (02/03/90)
>> Because by the time POST completes and the operating system bootstrap >is >> loaded, the INT 41H drive parameter vector is pointing at a "drive >type" >> that the WD1007 has constructed during POST. > >But if the drive params are 'constructed', as you say, where IS the >vector pointing to? Surely it can't be in RAM? > >Hmmm, sudden realization: The PS/2's with large ESDI disks have >slightly less than 640K free in lower memory. If I remember >correctly, this is where is stores the drive parameter table. >After reading your note, it all clicked in. The ps/2 POST is >building the table there and then only reporting 639K free. > >Do you know how the WD1007 does it? Yup, on the PS/2's the drive parameter table is in the Extended BIOS Data Area (which resides at the top 1K of the lower 640K). The WD1007 has some very clever hardware to handle this. It builds the parameter table in some RAM on the WD1007, then maps that RAM into the address space where the WD1007 BIOS resides. For example (exiting to the DOS box briefly...) on my machine INT 41H is pointing at C800:1F50. Many drive controllers and system BIOS's that allow custom drive types put the parameter table in the interrupt vector space. For example, the Adaptec 2372 BIOS puts the parameters for drive 0 in the space normally used for interrupt vectors 60H through 63H.. -- Jim King - via FidoNet node 1:140/22 UUCP: alberta!dvinci!weyr!396!1.3!Jim.King Internet: Jim.King@p3.f1.n396.z1.FIDONET.ORG Standard Disclaimers Apply...