Xref: utzoo comp.windows.x:14121 comp.unix.i386:735 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!wugate!uunet!pcrat!rick From: rick@pcrat.uucp (Rick Richardson) Newsgroups: comp.windows.x,comp.unix.i386 Subject: 80287 coproc and Re: basicwin and 386/ix X-windows Summary: 80287 detection was the problem Keywords: 80287, floating point Message-ID: <1989Oct10.195059.7598@pcrat.uucp> Date: 10 Oct 89 19:50:59 GMT References: <1989Oct4.132359.14514@pcrat.uucp> Reply-To: rick@pcrat.UUCP (Rick Richardson) Distribution: usa Organization: PC Research, Inc., Tinton Falls, NJ Lines: 251 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 '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 X#include X#include X#include 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 X#include X#include X#include 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