The JP2 is likely about selecting synchronous vs dedicated NPU clock.
The board is missing NPU clock generator, but both CPU and NPU are rated for 25MHz, so JP2 is soldered to select synchronous mode.
That's about all there is to switch about NPU, so it's quite likely you've damaged it.

vstrakh wrote on 2022-11-11, 11:16:

The JP2 is likely about selecting synchronous vs dedicated NPU clock.
The board is missing NPU clock generator, but both CPU and NPU are rated for 25MHz, so JP2 is soldered to select synchronous mode.
That's about all there is to switch about NPU, so it's quite likely you've damaged it.

🙁

One can forget those old machines are not as "idiot proof" as today's...

I've ordered another one. Thankfully the seller has more of them.

Also I have a question regarding a motherboard with no npu enable jumper. When I start it after installation of the npu. Should it show up in the initial bios screen?

This is how it looks like now.

https://dougx.net/gaming/coproc.html

flynth@gmail.com wrote on 2022-11-11, 11:29:

Also I have a question regarding a motherboard with no npu enable jumper. When I start it after installation of the npu. Should it show up in the initial bios screen?

Yes the second row "Numeric processor" should change to "Present" or something similar

I honestly never understood the point of the 387sx

The 386/387dx both could run in 16 bit mode
The 386Sx had 256 bytes of onchip cache but besides packaging the 387sx had no significant improvements over the dx core.

Also gotta wonder why late 286 machines didn’t just come with a 387sxor dx socket at that point the chipsets were the same and faster 286 chips (25mhz) didn’t have decent floating point options

rmay635703 wrote on 2022-11-11, 15:47:

I honestly never understood the point of the 387sx […]
Show full quote

I honestly never understood the point of the 387sx

The 386/387dx both could run in 16 bit mode
The 386Sx had 256 bytes of onchip cache but besides packaging the 387sx had no significant improvements over the dx core.

Also gotta wonder why late 286 machines didn’t just come with a 387sxor dx socket at that point the chipsets were the same and faster 286 chips (25mhz) didn’t have decent floating point options

Market segmentation is likely the reason .

If a common model of 387 had been usable in both 386SX and 386DX machine, how should it have been priced ?

By the end of their period of relevance, the 387DX and 387SX were site similar in price, AFAICR.

Early on, the price difference was likely significant.

rmay635703 wrote on 2022-11-11, 15:47:

The 386/387dx both could run in 16 bit mode
The 386Sx had 256 bytes of onchip cache but besides packaging the 387sx had no significant improvements over the dx core.

Are you saying 386SX had this 256 bytes of onchip cache and 386dx didn't? I can't find any definitive answers online. Also, when I run cache test on my 386sx it said it didn't find any caches.

From the collecting point of view 386sx is interesting to me as "a last 16 bit x86 cpu". I read somewhere it really is 32bits internally, but with only 16 bits exposed. This makes no sense to me at all. If it really is 32 bits internally than what is the difference between 386sx and 386dx? Just the packaging? If I was to guess the most likely reason for its existence I would say perhaps they used chips that didn't run well at 32 bits due to some manufacturing faults, but were still capable of running 16 bit code. Then they somehow disabled the upper 16 bits and 386sx was born from chips that otherwise would get thrown out. This is just a guess. I have no idea if it really was something like this.

rmay635703 wrote on 2022-11-11, 15:47:

Also gotta wonder why late 286 machines didn’t just come with a 387sxor dx socket at that point the chipsets were the same and faster 286 chips (25mhz) didn’t have decent floating point options

Perhaps they could've come with a 386sx socket. I don't know enough about the difference between 286 and 386sx, but surely not a 386dx socket? That would require a 32 bit wide data bus which 286 couldn't use.

rmay635703 wrote on 2022-11-11, 15:47:

I honestly never understood the point of the 387sx

The point of the 387 (whether SX or DX is to provide floating point operation to the system. All it does is floating point; it does not replace the 386 itself. Are you thinking of the 486SX/487SX (in which the 487SX is just a 486DX that takes over the functions of the 486SX while adding an internal FPU)?

The 386Sx had 256 bytes of onchip cache

[citation needed]

but besides packaging the 387sx had no significant improvements over the dx core.

The 387, whether SX or DX, is a floating point unit (FPU). It's not a CPU.

In the case of the 386, the SX and DX do not designate whether or not the CPU has an internal FPU. It describes the width of the external bus-- Single word eXternal (16 bits) vs. Double word eXternal (32 bits).

[Edit: Fixed a typo and made clarifications]

Early 80386 motherboards had an additional 80287 socket.
That's because manufacturing math co-processors was very complicated at the time
and because they weren't available in versions rated for higher speed.

When Intel released the 80386, it had little interest in the 80286 anymore.
Someone could say it wanted to see the 80286 dying.
So was Microsoft, essentially. Their products had no future on the 80286.

It were the other companies that kept the 80286 alive.
And IBM, with its OS/2 project. However, MS, a partner at the time, optimized OS/2 for 80386 wherever possible.
The optimized and optional HPFS driver for OS/2 used 80386 code, for example.

So it makes sense that 80286 systems usually didn't get 80387SX NPUs.
It's creator never bothered to even implement it.

Anyway, I'm not saying it's not possible. The Intel 80287XL uses an 80387 core, after all.
It also runs on 3/2 clock rate, to compensate for the usual 2/3 clock rate of 80286 systems.

However, the market of x87 processors was quickly handed over to 3rd party companies by the late 80s.
Cyrix, ULSI, Weitek etc. They made co-processors still.
Intel was already working on the 80486 and integrated FPUs.
The Intel Rapidcad was essentially an 80486 for 80386 motherboards. A dummy chip was installed in the x87 socket to react to the FPU interrupts etc.
The real 80387 was directly in the Rapidcad chip.

Another thing to consider are x87 emulators on DOS.
On 80286 and higher, an interrupt/exception is produced if an x87 instruction is received, but no x87 is available.
An exception handler then can be used to call an x87 emulator in memory.

There are many x87 emulators, mainly emulating either the 8087 or the 80387.
That's because emulating an FPU was very time consuming, which contradicts the purpose of using a software crated faksimile.
Clever coding and the extra accuracy over integer math were the few arguments for such x87 emulators, though.
A very popular emulator for 80386 PCs in my place was "Franke 387". It used quick 32-Bit code, which at the time somewhat helped in a mostly 16-Bit dominated world.
http://icfs.de/franke387.html

Some old 8087 emulator binaries for testing:
Re: Coprocessors for the AMD 386DX 40MHz CPU

I think you're getting tripped up by a few related facts. Yes, there were some 386 models that only ran 16 bit software and were stamped as such. I seem to recall this being a yield related issue. On the other hand, your garden variety 386SX was more than happy to execute 32 bit code. Yes, the data bus was 16 bit, but this is more a throughput issue than a code compatibility issue. Realistically, outside of performance you'd need a MAJOR corner case to find software compatibility difference between an SX and a DX (off hand memory addressing is the only thing I can come up with,but anything where the 24 bit address space of the SX wasn't enough would be agonizingly slow and a purely academic exercise).

flynth@gmail.com wrote on 2022-11-11, 18:05:

From the collecting point of view 386sx is interesting to me as "a last 16 bit x86 cpu". I read somewhere it really is 32bits internally, but with only 16 bits exposed. This makes no sense to me at all. If it really is 32 bits internally than what is the difference between 386sx and 386dx? Just the packaging? If I was to guess the most likely reason for its existence I would say perhaps they used chips that didn't run well at 32 bits due to some manufacturing faults, but were still capable of running 16 bit code. Then they somehow disabled the upper 16 bits and 386sx was born from chips that otherwise would get thrown out. This is just a guess.

The 386SX not only had a narrower external connection to the motherboard than the original 386 (the DX suffix came later after the introduction of the SX suffix), but only has a 24-bit address bus, like the 286. This meant it could only address 16MiB , unlike the 4GiB (4,294967,296 bytes) of a 386DX (not that 4GB was a practicable amount of RAM, considering the amount of 16MB (16,777,216 bytes) 30-pin SIMMs (256!) it would take to reach that limit.

The 386SX was released as a cost-effective way to get better multitasking than a 286 (which was a terrible multitasker thanks to bad design decisions), and the additional instructions and optimizations of the 386.

AlaricD wrote on 2022-11-11, 18:34:

rmay635703 wrote on 2022-11-11, 15:47:

I honestly never understood the point of the 387sx

The point of the 386SX is to provide floating point operation to the system. All it does is floating point; it does not replace the 386SX.

http://archive.computerhistory.org/resources/ … 9.05.01.acc.pdf

No I am saying that a 386dx/387dx can operate happily on a 16 bit 286 bus just like a 387sx, it’s primarily external packaging that differentiates , it was designed with that in mind. Even when the 387sx was “new” the floating point unit market was a small one and the price difference between a 87dx and 87sx quickly became negligible despite the more expensive packaging on the dx. In terms of volume manufacturing the 87sx never made sense.

In terms of “cache”, the original 386DX was intended to have a very small “linear” cache similar to the 386sx but the designers found that it offered little improvement on the dx and dropped it in favor of using the spare transistors for a more robust hybrid / virtual x86 memory management system.

By the time the sx came about you could fit more onto the die and indeed the 386sx has more than 275,000 transistors, (many internet experts get this very wrong) simply because it needed more to operate.
Intel was loath to talk about why a chip with slightly more transistors was cheaper so the error stuck in the popular consciousness.

The SX actually needed the tiny linear cache that was tossed in the dx,
sometimes referred to as a buffer
Needed it or the sx was significantly slower than even a 286.
Many old CPUs even 8 and 16 bit from other manufacturers included a very small amount of “cache” like 8, 16 or 256 bytes.
Like the 386sx This cache did not require special support , was far from fully associative and was invisible to both the hardware and software focusing on stability and compatibility over performance.

https://www.onhumanenterprise.com/the-art-of- … -the-impossible

Amusing reading… why the 386sx failed?

Thanks for the link, it's essentially saying what I said, also.

Personally, I think, there's something good about the SX - it kept good 80286 motherboards chipset alive/in circulation.
Those NEAT like motherboards with EMS, Shadow RAM and a good Setup Utility in ROM.

The latter was something Compaq's famous 386 PC didn't offer - an utility in ROM.
It used diskettes for configuration still.

And yes, the 80386 can do all the things the 386SX can do.
That miniature "cache" is nothing but a buffer to compensate for the 16/24-Bit bottleneck, I think.

That's why the 386SX is no real innovation, it's just a good version of something that's was an excellent version.

And the 80287 vs 80387 difference is mainly the bus/communications interface.
Most 80287 FPUs sold by third-party companies had a core equivalent to the 80387/287XL or their own 80387 FPUs, respectively.

As far as Real-/Protected-Mode goes, the 80287 and 80387 are similarly compatible.
At least under normal circumstances (DOS, Windows 3.1), an original 80287 works just as fine with an 80386 CPU as an 80387.

Interesting about the 256 byte buffer/cache in 386sx. Despite 386SX being released after 386DX I definitely think of it as a step back in computing development, but still interesting.

It was mentioned that 386sx "would happily run 32 bit code". This to me sounds very weird . Does this mean 386SX actually has 32 bit registers (EAX etc), or are they 16 bit?

This is some heavy stuff 🤣

386sx has full 32-Bit Internal Architecture

More reading here:
https://media.digikey.com/pdf/Data%20Sheets/I … tel386%20SX.pdf

kixs wrote on 2022-11-11, 22:37:

This is some heavy stuff :lol: […]
Show full quote

This is some heavy stuff 🤣

386sx has full 32-Bit Internal Architecture

More reading here:
https://media.digikey.com/pdf/Data%20Sheets/I … tel386%20SX.pdf

Thank you. This answers my questions. However, I'm a bit disappointed it is not really a "last 16 bit x86 CPU" (well internally). I think that title belongs to 286.