m5@lynx.uucp (Mike McNally) (04/27/89)
I'm in some serious confusion over detection and initialization of a
floating point coprocessor in 386 AT compatibles. So many things
confuse me that this message may prove very difficult to compose.
FIRST QUESTION:
What does your typical BIOS or setup program do when it "configures"
the floating point processor type (i.e., 287 or 387)? Why does it
need to do this at all; the 386 is supposed to be able to figure that out
automatically! Does it ignore the initial value of ET in CR0 and set
it to whatever it's told?
SECOND QUESTION:
What are the ramifications of using the FPP when ET is incorrect? Like,
let's say I want to start from scratch after BIOS has done whatever
damage it thought appropriate. I'd like to do something like this:
Turn ET on, so we make believe we've got a 387
Do an FNINIT
Check the status and control words
If the words are ugly, change ET and try again
OK, fine. Of course, it doesn't work; at some point, after the whole
process completes, the initialization sequence does a WAIT and hangs.
Attempts to clear any errors via the magic OUT to F0 don't seem to
work. In any case, the FNSTSW and FNSTCW seem to work regardless of
the state of ET. The sequence finds nice status and control words on
my 287 and 387 machines with ET=1.
THIRD QUESTION:
What in the heck could a PC do to completely disable a coprocessor? I've
got an NEC PowerMate 386 box with a 387 in it. I can't find a setup
program, so I figure "well, I'll just hit on the FPP anyway." No dice.
It's as if it's not even there. I strongly suspect that AST machines
have a similar deal. (Most of the machines I use are from Mylex.)
Anybody who has any experience with this stuff will receive my gratitude
for any pearls of wisdom.
--
Mike McNally Lynx Real-Time Systems
uucp: {voder,athsys}!lynx!m5 phone: 408 370 2233
Where equal mind and contest equal, go.darryl@ism780c.isc.com (Darryl Richman) (04/27/89)
In article <5504@lynx.UUCP> m5@lynx.UUCP (Mike McNally) writes:
"FIRST QUESTION:
"What does your typical BIOS or setup program do when it "configures"
"the floating point processor type (i.e., 287 or 387)? Why does it
"need to do this at all; the 386 is supposed to be able to figure that out
"automatically! Does it ignore the initial value of ET in CR0 and set
"it to whatever it's told?
You must consider the history of this, since the AT BIOS on your 386 machine
is a direct descendant of an 8086 BIOS. Until the 386, Intel didn't provide
any software detection mechanism. They did suggest that manufacturers wire a
certain pin (sorry, I'm a software guy, I don't know about this hardware stuff
;-) through a resistor to ground, from the *87 socket. Then they provided a
software routine that could "feel" for this grounded pin if no chip was
present. However, no matter how cheap and easy this solution might seem, and
although Intel published it in every description of every *86 chip book I've
seen, many hardware manufacturers didn't do this.
Now, IBM selected a certain bit in a certain byte of the CMOS in your AT
to contain a bit that indicates whether an *87 chip is in the box. The
setup program, which is specific to a manufacturer's machine, and may do
whatever nasty tricks are necessary to discover whether an *87 is
present, is responsible for the setting of this bit.
However, the setup program for Intel's own INBoard seems to set the
present bit, regardless of the actual presence or absence of a chip!
And furthermore, some manufacuterers have added a third option to their
setup--instead of just present/absent, they also allow, nay select by default
when absent, an "emulate" mode--which merely means that they set the present
bit even though they know it is wrong!
Now, on to the ET bit. This is just a continuation of the "ground the pin
through a resistor" gimmick, that fewer people have been following. So the ET
bit only works right if the manufacturer has played ball. Sigh. Intel seems
to have thought it was the software folk who couldn't copy their routine
correctly, so they put that into the hardware.
"SECOND QUESTION:
"What are the ramifications of using the FPP when ET is incorrect? Like,
"let's say I want to start from scratch after BIOS has done whatever
"damage it thought appropriate. I'd like to do something like this:
" [...]
"OK, fine. Of course, it doesn't work; at some point, after the whole
"process completes, the initialization sequence does a WAIT and hangs.
"Attempts to clear any errors via the magic OUT to F0 don't seem to
"work. In any case, the FNSTSW and FNSTCW seem to work regardless of
"the state of ET. The sequence finds nice status and control words on
"my 287 and 387 machines with ET=1.
FNSTSW and FNSTCW are the two exceptions to the inter-processor protocol that
the 386 and 387 follow. Normally the 386 sends the instruction to the 387
*and waits for an acknowledge* back before proceeding *with anything else*.
This means that you hang when you pass the instruction, not when you wait for
the reply. The reason why the FNSTSW and FNSTCW are different is that the
designers recognized that these two instuctions would complete very quickly
(as compared to just about anything else with the 387), and so they pass the
instuction and then immediately read the data lines for the answer. If
there's no chip, you get whatever is floating on the data lines.
"THIRD QUESTION:
""What in the heck could a PC do to completely disable a coprocessor? I've
"got an NEC PowerMate 386 box with a 387 in it. I can't find a setup
"program, so I figure "well, I'll just hit on the FPP anyway." No dice.
"It's as if it's not even there. I strongly suspect that AST machines
"have a similar deal. (Most of the machines I use are from Mylex.)
This is where I get headaches. They have obviously done something else with
the coprocessor, perhaps used a pal or latch to turn the chip off so you won't
hang when you "do something stupid." Since there is no *accepted* way for a
generic program to detect an *87, you have to believe the bit, and know which
machines (and how to detect them!) you can't believe! Isn't this fun?!
--Darryl Richman
--
Copyright (c) 1989 Darryl Richman The views expressed are the author's alone
darryl@ism780c.isc.com INTERACTIVE Systems Corp.-A Kodak Company
"For every problem, there is a solution that is simple, elegant, and wrong."
-- H. L. Menckenjohn@jwt.UUCP (John Temples) (04/29/89)
In article <26762@ism780c.isc.com> darryl@ism780c.UUCP (Darryl Richman) writes: >However, the setup program for Intel's own INBoard seems to set the >present bit, regardless of the actual presence or absence of a chip! VP/ix seems to do the same thing. The equipment byte in the "virtual CMOS" says there's a FPP whether there is or not. (VP/ix 1.1, ISC 1.0.6) I've had an FPP initialization problem crop up recently, too. When upgrading from 1.0.5 to 1.0.6 on a Micronics motherboard with a 287, Unix no longer recognizes the coprocessor. I wrote a little program that uses the sysi86() call to check floating point hardware. Under 1.0.5, it said there was a 287, under 1.0.6, it says no FP hardware. And floating programs are very slow under 1.0.6; it's obviously not using the coprocessor. Has anyone else had this problem? -- John Temples - UUCP: {uiucuxc,hoptoad,petsd}!peora!rtmvax!bilver!jwt!john
darryl@ism780c.isc.com (Darryl Richman) (05/02/89)
In article <271@jwt.UUCP> john@jwt.UUCP (John Temples) writes: "In article <26762@ism780c.isc.com> darryl@ism780c.UUCP (Darryl Richman) writes: ">However, the setup program for Intel's own INBoard seems to set the ">present bit, regardless of the actual presence or absence of a chip! "VP/ix seems to do the same thing. The equipment byte in the "virtual CMOS" "says there's a FPP whether there is or not. (VP/ix 1.1, ISC 1.0.6) That's because VP/ix does "see" an *87 chip--the Unix kernel is running its emulator and that's what VP/ix gets. --Darryl Richman -- Copyright (c) 1989 Darryl Richman The views expressed are the author's alone darryl@ism780c.isc.com INTERACTIVE Systems Corp.-A Kodak Company "For every problem, there is a solution that is simple, elegant, and wrong." -- H. L. Mencken