rick@pcrat.uucp (Rick Richardson) (10/11/89)
In article <1989Oct4.132359.14514@pcrat.uucp> I had complained about
a few problems I had with 386/ix's X windows and the O'Reilly "basicwin"
program.
It turns out that 386/ix believed that I had an 80387 co-processor
installed, though really I had only an 80287 installed. Thanks go to
Lawrence Freil for heading me in a direction that ISC and myself had
missed for one and a half years.
Anyway, here's Larry's program (slightly hacked) which will fiddle
the bits in CMOS to fix things up.
-Rick Richardson
#! /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@pcroe on Tue Oct 10 15:45:48 1989
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 ?????? mention
PC Research,Inc.| WE'RE SHIPPING your
uunet!pcrat!rick| Ask about FaxiX - UNIX Facsimile System (tm) FAX #
(201) 389-8963 | Or JetRoff - troff postprocessor for the HP {Laser,Desk}Jet