VOGONS


First post, by Predator99

User metadata
Rank Oldbie
Rank
Oldbie

Hi,

I like to install a co-processor on my 386 board:

386-702430d.jpg
Filename
386-702430d.jpg
File size
1.74 MiB
Views
935 views
File license
Fair use/fair dealing exception

However, for a 80387 the socket is too big. Can I install it anyway or is such socket only suitable for a Weitek 3167..?

IMG_0278.JPG
Filename
IMG_0278.JPG
File size
1.75 MiB
Views
935 views
File license
Fair use/fair dealing exception

Thanks! 😎

Reply 1 of 18, by jesolo

User metadata
Rank Oldbie
Rank
Oldbie

The socket appears to be a PGA 121 pin socket, which means it's most likely meant for a Weitek FPU. It might not be meant for an 80387DX (or similar) FPU.
Best would be to identify your motherboard here and confirm: https://arvutimuuseum.ee/th99/#1

Last edited by jesolo on 2019-07-14, 20:42. Edited 1 time in total.

Reply 3 of 18, by root42

User metadata
Rank l33t
Rank
l33t

My 386 has a similar socket and sports an Intel 387.

E7B37D0E-7476-4D01-B385-4A01990ECAD9.jpeg
Filename
E7B37D0E-7476-4D01-B385-4A01990ECAD9.jpeg
File size
270.09 KiB
Views
900 views
File license
Fair use/fair dealing exception

YouTube and Bonus
80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, SnarkBarker & GUSar Lite, PC MIDI Card+X2+SC55+MT32, OSSC

Reply 5 of 18, by Predator99

User metadata
Rank Oldbie
Rank
Oldbie

Hmm, does not seem to work.

With the 387 installed all Sysinfo-Programs (Checkit, Drhard, NSSI) crash at startup...without 387 all are running.

I disabled coprocessor emulation in the BIOS. Maybe some DIP needs to be set? But I dont have documentation for the board.

Reply 6 of 18, by derSammler

User metadata
Rank l33t
Rank
l33t
Predator99 wrote:

With the 387 installed all Sysinfo-Programs (Checkit, Drhard, NSSI) crash at startup...without 387 all are running.

Funny, I had exactly the same problem when I installed an i287XL in one of my 286 machines. All benchmark tools crashed after that, but the FPU was indeed working. Well, one benchmark tool was still working, though I can't recall which one.

Afaik, only XT class machines needed a dip switch or jumper for the FPU, but you'll never know... Did you try running some software that would not work without an FPU?

Reply 7 of 18, by elianda

User metadata
Rank l33t
Rank
l33t

Most 386 mainboards have an EMC socket, which is the Extended Math Coprocessor socket also suitable for Weitek FPUs. Weitek FPUs have one more pin row around. The sockets also take regular i387.

Also from my experience most 386 boards need a jumper to be set to enable FPU and sometimes a second to set 387 or Weitek.
e.g. look at this: http://retronn.de/imports/hwgal/hw_mb_chips_386.html The board has right of the FPU socket a jumper with 387 ON/OFF and above the socket 3167 ON/OFF which is for Weitek Abacus 3167.

Additionally the BIOS often have an often with NPU disabled/enabled/auto/weitek which has to be set accordingly.
Some boards have an extra clock quartz for the FPU that needs to be populated.

Retronn.de - Vintage Hardware Gallery, Drivers, Guides, Videos. Now with file search
Youtube Channel
FTP Server - Driver Archive and more
DVI2PCIe alignment and 2D image quality measurement tool

Reply 8 of 18, by Predator99

User metadata
Rank Oldbie
Rank
Oldbie
derSammler wrote:
Predator99 wrote:

With the 387 installed all Sysinfo-Programs (Checkit, Drhard, NSSI) crash at startup...without 387 all are running.

Funny, I had exactly the same problem when I installed an i287XL in one of my 286 machines. All benchmark tools crashed after that, but the FPU was indeed working. Well, one benchmark tool was still working, though I can't recall which one.

Afaik, only XT class machines needed a dip switch or jumper for the FPU, but you'll never know... Did you try running some software that would not work without an FPU?

I had a problem with DOS/4GW games like Warcraft 2 on this specific board. It crashes with "exception 07h (device not available)". Its related to the FPU according to the information I was able to find.
This message disappears with the 387 installed, therefore it seems to work in some way.

The only diagnostic program that starts up is "Norton Sysinfo" which reports something like "unknown FPU".

EDIT: MSD also reporting 80386/80387 ... seem to be working.

Last edited by Predator99 on 2019-07-20, 09:18. Edited 2 times in total.

Reply 9 of 18, by jesolo

User metadata
Rank Oldbie
Rank
Oldbie
Predator99 wrote:

Hmm, does not seem to work.

With the 387 installed all Sysinfo-Programs (Checkit, Drhard, NSSI) crash at startup...without 387 all are running.

I disabled coprocessor emulation in the BIOS. Maybe some DIP needs to be set? But I dont have documentation for the board.

Most 386 motherboards I've owned has a jumper to enable and disable the FPU.
There is then also sometimes a jumper to change the clock of the FPU (asynchronous or synchronous to that of the CPU clock speed).
Considering the number of switches on that motherboard, you probably need to figure out what each one does by trying to see if you can find another motherboard on Total Hardware 99 with similar switch blocks.

Reply 10 of 18, by georgel

User metadata
Rank Member
Rank
Member

Most motherboards don't have jumper to select the presence of a coprocessor. It is detected by means of software. A few motherboards have jumpers to select coprocessor type (i.e. weitek, 387, 287). Some motherboards have in their CMOS RAM setup option to detect or not to detect the x87 coprocessor during POST. When one is detected a bit flag is set to 1 in the ROM BIOS data area (at 413h if I remember correctly). Most software that uses coprocessor usually detect its presence by using own routines and do not rely on BIOS flag. The Trap 7 fault your dos extender outputs means that EM bit in CR0 register of the CPU is set by some software and no trap 7 handler is currently installed. EM bit is set usually to emulate a numeric coprocessor in software. Some coprocessor emulators do not properly handle warm restarts and leave this flag set. That usually leads to BIOS hangs during warm restarts (depending on BIOS implementation/version and CMOS setup user settings for detection of x87 (if any). If you are considering the usage of a coprocessor emulator I do recommend you Q87/Q387. It handles protected mode software and its performance is comparable to a physical 287.

Reply 11 of 18, by Caluser2000

User metadata
Rank l33t
Rank
l33t

All the 386DXs mobos I've have had an option in the bios to detect NPUs. Big thing is make sure that they are correctly orientated. The OPs socket looks like it's full of crap.

There's a glitch in the matrix.
A founding member of the 286 appreciation society.
Apparently 32-bit is dead and nobody likes P4s.
Of course, as always, I'm open to correction...😉

Reply 12 of 18, by georgel

User metadata
Rank Member
Rank
Member

This option appeared in the latest 386 BIOSes like the "color" AMI BIOS. It is there on 386SX motherboards as well with the same BIOS. This option has no effect on most software that uses a x87 coprocessor. If the detection is enabled and if a real coprocessor is indeed present it only updates the ROM BIOS coprocessor flag and depending on BIOS shows the coprocessor presence in the pre-boot text table printed on the screen. The setup option you are talking about is analogue to the 8087 DIP switch on PC/XT motherboards. The OP's motherboard almost certainly does not have such late BIOS. It is absolutely no big deal and it is a must to orient every IC correctly in its socket!

Reply 13 of 18, by Predator99

User metadata
Rank Oldbie
Rank
Oldbie

Believe me, I inserted the 387 in correct orientation - notch on upper right :-p

Contacts in the socket doesnt look that bad. In overall the board is very clean.

The BIOS only has an option to enable or disable Coprocessor emulation, which had no effect.

Reply 15 of 18, by Predator99

User metadata
Rank Oldbie
Rank
Oldbie

This here:

search.php?keywords=386-702430d.rar

Dont have the board installed and cannot enter setup in PCem, but you can see the Menu inside the dump:

Hard disk C: type :
Hard disk D: type :
Primary display :
Keyboard :
Co-proc. Emulation :
Scratch RAM option :

Enabled : Emulate coprocessor
Disabled : Do not emulate coprocessor

...but as written, the setting doesnt change the DOS4GW error message.

Reply 16 of 18, by georgel

User metadata
Rank Member
Rank
Member

Early 1990 AMI BIOS...Will analyze it after 10 days. Anyway your dumps are double the size that 27256 EPROMs can hold and that are shown in the picture of your motherboard. Meanwhile if you use Q87 you will solve your trap7 problem for sure and you will have a decent 387 emulation. Probably your BIOS itself provides some crippled 387 emulation, never seen that before.

Reply 18 of 18, by georgel

User metadata
Rank Member
Rank
Member

Hi. I tried your BIOS. I couldn't guess the hotkey to enter setup though and I had to corrupt the CMOS RAM contents every time when I wanted to enter its setup. The coprocessor emulation option in setup should never be enabled because the emulation is absolute fake (you can look at the trap 7 handler that BIOS installs). Once this option is activated all coprocessor instructions generate trap 7 because your BIOS in this case sets EM bit in CR0/MSW. This BIOS handler generally handles basic coprocessor detection instructions by skipping them but cannot even skip more complicated instructions which leads to halting your system. This setup option when enabled is the reason for DOS4GW DOS extender to encounter a unexpected trap 7. A similar if not the same trap 7 handler is installed in later AMI BIOSes but it is never called since EM bit is not set by BIOS.