floating point math died

Conor P. Cahill cpcahil at virtech.uucp
Wed Jan 30 02:19:39 AEST 1991


In article <1991Jan29.005023.4628 at gtisqr.uucp> rick at gtisqr.uucp (Hendrik Groeneveld) writes:
>I recently installed a 387 to see if it would improve performance
>with X11. After running a few tests, I removed the 387 (We bought
>it for a dos machine), and now floating point no longer works.
>All jumpers are in the correct position for running without the
>387, and setup shows the 387 not installed. I am running ISC v2.2.

This is a problem know to exist for some hardware/bios combinations.  Attached
is a copy of an old article posted by Rick Richardson which contains a program
that will fix the problem.


> Article 4661 of comp.unix.i386:
> Path: virtech!uunet!pcrat!rick
> From: rick at pcrat.uucp (Rick Richardson)
> Newsgroups: comp.unix.i386
> Subject: Re: awk divides by zero 386/ix 2.0.2
> Keywords: FPU error Phoenix BIOS Micronics motherboard
> Message-ID: <1990May18.123911.1073 at pcrat.uucp>
> Date: 18 May 90 12:39:11 GMT
> References: <1460 at ssbn.WLK.COM>
> Reply-To: rick at pcrat.UUCP (Rick Richardson)
> Organization: PC Research, Inc., Tinton Falls, NJ
> Lines: 249

In article <1460 at ssbn.WLK.COM> bill at ssbn.WLK.COM (Bill Kennedy) writes:

>Yesterday I changed out the old 16MHz for a new 33MHz caching model.
>The old awk divide by zero was back, so I called Micronics.  They
>gave me a short section of code (below) to run in DOS to fix it once
>and for all.

Yecch! Boot DOS?  Not when you can do it from UNIX.  The following
shar will show you how to manipulate CMOS RAM (what a poor name) from
UNIX.  Of course, you'll still need to reboot after you make any changes.


#! /bin/sh
# This is a shell archive.  Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file".  To overwrite existing
# files, type "sh file -c".  You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g..  If this archive is complete, you
# will see the following message at the end:
#		"End of shell archive."
# Contents:  README README.lef makefile cram287fix.c fptype.c
# Wrapped by rick at pcroe on Fri May 18 08:17:15 1990
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f 'README' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'README'\"
else
echo shar: Extracting \"'README'\" \(1294 characters\)
sed "s/^X//" >'README' <<'END_OF_FILE'
X
X	Lawrence Freil sent me the original version of these programs,
X	to diagnose and fix CMOS RAM so that 386/ix will correctly determine
X	the floating point co-processor type when an 80287 is installed.
X
X	His original instructions (in README.lef) indicated that you should
X	let the BIOS SETUP routine recompute the checksum.  I found that
X	my BIOS (AMI) would restore the CMOS location 0x14 value to 0x43
X	(cram287fix tries to set it to 0x41).
X
X	Checking my genuine IBM AT tech. ref, I found that bit 0x02 is the
X	co-processor present bit.  Indeed, I do have a coprocessor present,
X	albeit an 80287.  I guess that doesn't count with 386/ix, because
X	when the bit is turned off, all of my floating point problems go
X	away.  Pic arrowheads now work; the X xclock hands are the correct
X	size, the X basicwin program works, etc. etc. etc.
X
X	Anyhow, since my BIOS SETUP routines wouldn't let me turn off the
X	coprocessor present bit, I hacked Lawrence's program to recompute
X	the checksum.  I also made it just turn off the 0x02 bit, instead
X	of writing the entire location with what might not be entirely
X	correct.  So all you need to do is run "cram287fix" and then
X	reboot.  Then run "fptype" to be sure that the coprocessor type
X	is correct.
X
X	Oh yeah, I added a makefile, too.
X
X	Rick Richardson
X
END_OF_FILE
if test 1294 -ne `wc -c <'README'`; then
    echo shar: \"'README'\" unpacked with wrong size!
fi
# end of 'README'
fi
if test -f 'README.lef' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'README.lef'\"
else
echo shar: Extracting \"'README.lef'\" \(1389 characters\)
sed "s/^X//" >'README.lef' <<'END_OF_FILE'
X
X	Date: Tue, 10 Oct 89 09:52:49 EDT
X	From: uunet!cs.utexas.edu!gatech!dogwood.atl.ga.us!lef (Lawrence Freil)
X	Subject: Problem with Interactive/ix 287 under X-windows.
X
X	I had what sounds like same problem with a couple of our 386 systems
X	(With 287).  We also had several systems from the same vendor all
X	configured alike which worked fine.  I eventually tracked the problem
X	down to a bit in CMOS.  Byte 0x14 of cmos should be a 0x43 for a 80387
X	and a 0x41 for 80287.  Nobody sets these bits so it is just random
X	chance if any 287 will work correctly or not.  The following program
X	will check with the operating system to determine the co-processor
X	type.  If you have this problem then it will say you have a 387
X	instead of a 287.  The reason for the bad clock hands is that a 387
X	has hardware Cosine and Sine and the library routines try to use the
X	instructions if it thinks you have one.  All Sines and Cosines will
X	return the input value without an error if this is your problem.  
X	The second program will attempt to patch the cmos to the correct
X	co-processor type (if you run it as super-user).  You will need to
X	bring you system down and re-run you manufacture setup program to
X	re-calculate the checksum after using the cramfix because I don't feel
X	like looking up the checksum algorithm for a one-time patch.  When you
X	reboot unix everything should work correctly.
X
END_OF_FILE
if test 1389 -ne `wc -c <'README.lef'`; then
    echo shar: \"'README.lef'\" unpacked with wrong size!
fi
# end of 'README.lef'
fi
if test -f 'makefile' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'makefile'\"
else
echo shar: Extracting \"'makefile'\" \(173 characters\)
sed "s/^X//" >'makefile' <<'END_OF_FILE'
XPROGS=	fptype cram287fix
X
Xall:	$(PROGS)
X
Xinstall: all
X	cp $(PROGS) /etc
X
Xclean:
X	-rm -f *.o
X
Xclobber: clean
X	-rm -f $(PROGS)
X
Xshar:
X	shar README* makefile *.c > 287fix.shar
END_OF_FILE
if test 173 -ne `wc -c <'makefile'`; then
    echo shar: \"'makefile'\" unpacked with wrong size!
fi
# end of 'makefile'
fi
if test -f 'cram287fix.c' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'cram287fix.c'\"
else
echo shar: Extracting \"'cram287fix.c'\" \(1483 characters\)
sed "s/^X//" >'cram287fix.c' <<'END_OF_FILE'
X/*
X * cram287fix.c
X *		: patch cmos memory on a 386/AT clone under Interactive 386/ix
X *		: This program patches byte 0x14 to 0x41 to indicate that
X *		: the math co-processor is an 80287.  
X *		: For an 80387 the value should be 0x43.
X */
X
X#include <stdio.h>
X#include <sys/cram.h>
X#include <fcntl.h>
X#include <errno.h>
X
Xmain()
X{
X	struct {
X		unsigned char adrs;
X		unsigned char value;
X	}
X			cram_arg;
X	register int	cmosfile;
X	unsigned short	cksum;
X	unsigned char	loc14;
X	int		i;
X
X	cmosfile = open("/dev/cram", O_RDWR);
X	if (cmosfile < 0) {
X		fprintf(stderr, "Can't open /dev/cram driver, errno = %d\n",
X			errno);
X		exit(1);
X	}
X	cram_arg.adrs = 0x14;
X	ioctl(cmosfile, CMOSREAD, &cram_arg);
X	loc14 = cram_arg.value;
X	if ( (loc14 & 2) == 0)
X	{
X		printf("Co-processor bit already is off\n");
X		printf("386/ix should already think an 80287 is present\n");
X		exit(0);
X	}
X	else
X	{
X		printf("Co-processor bit is on!\n");
X		printf("386/ix thinks there is an 80387 is present.\n");
X		printf("I'll now turn the bit off for 80287.\n");
X	}
X
X	cram_arg.adrs = 0x14;
X	cram_arg.value = loc14 & ~2;
X	ioctl(cmosfile, CMOSWRITE, &cram_arg);
X
X	/*
X	 *	Recompute checksum
X	 */
X	for (cksum = 0, i = 0x10; i <= 0x20; ++i)
X	{
X		cram_arg.adrs = i;
X		ioctl(cmosfile, CMOSREAD, &cram_arg);
X		cksum += cram_arg.value;
X	}
X	cram_arg.adrs = 0x2e;
X	cram_arg.value = cksum>>8;
X	ioctl(cmosfile, CMOSWRITE, &cram_arg);
X	cram_arg.adrs = 0x2f;
X	cram_arg.value = cksum;
X	ioctl(cmosfile, CMOSWRITE, &cram_arg);
X	exit(0);
X}
END_OF_FILE
if test 1483 -ne `wc -c <'cram287fix.c'`; then
    echo shar: \"'cram287fix.c'\" unpacked with wrong size!
fi
# end of 'cram287fix.c'
fi
if test -f 'fptype.c' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'fptype.c'\"
else
echo shar: Extracting \"'fptype.c'\" \(514 characters\)
sed "s/^X//" >'fptype.c' <<'END_OF_FILE'
X#include <stdio.h>
X#include <sys/types.h>
X#include <sys/sysi86.h>
X#include <sys/fp.h>
X
Xmain()
X{
X	int i;
X
X	sysi86(SI86FPHW, &i);
X	
X	switch (i) {
X	case FP_NO:
X		printf("No floating point supported at all\n");
X		break;
X	case FP_SW:
X		printf("Floating point emulation in software\n");
X		break;
X	case FP_287:
X		printf("Floating point done by 80287\n");
X		break;
X	case FP_387:
X		printf("Floating point done by 80387\n");
X		break;
X	default:
X		printf("ERROR!  Floating point value none of thoses listed\n");
X		break;
X	}
X}
END_OF_FILE
if test 514 -ne `wc -c <'fptype.c'`; then
    echo shar: \"'fptype.c'\" unpacked with wrong size!
fi
# end of 'fptype.c'
fi
echo shar: End of shell archive.
exit 0
-- 
Rick Richardson | Looking for FAX software for UNIX/386 ??? Ask About: |Mention
PC Research,Inc.| FaxiX - UNIX Facsimile System (tm)                   |FAX# for
uunet!pcrat!rick| FaxJet - HP LJ PCL to FAX (Send WP,Word,Pagemaker...)|Sample
(201) 389-8963  | JetRoff - troff postprocessor for HP LaserJet and FAX|Output


-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170 



More information about the Comp.unix.sysv386 mailing list