Those NEC x87 FPUs are CMOS. So they *might* overclock okay.
But, according to CPUShack they are only rated at 8MHz. I'm not sure how that was determined though, since I wasn't able to decipher the production code.
Even if you can only get it up to 10MHz, it still provides one advantage over standard 8087s...387 instruction set.

@Feipoa

About NEC 8087:
my other source = CPUShack 😀

M919 performance issue with over 32Mb system memory:
This motherboard is troubled. Kind of the usual PC-Chips stuff.

LS C/D, UUD, PVI, VLI don't have such issues as long as you stay within the L2 cacheable range.

---

@Anonymous Coward

Will run two tests at least:
1. NEC vs Intel running on the same frequency.
2. Overclock both to their limit but ensure the system is completely stable.
It will be interesting to see who comes on top.

pshipkov wrote on 2022-05-04, 05:04:

LS C/D, UUD, PVI, VLI don't have such issues as long as you stay within the L2 cacheable range.

Interesting. You tried all 5 of these motherboards at 32 MB vs. 64 MB, and the DOS Quake scores were identical? If so, what could the PCChips BIOS be doing? We know they had fake cache originally. I wonder if the BIOS is forcing non-cacheability above 32 MB? I say this because the the performance increase from 32 MB no-cache to 1024K cache is greater (about double) than the increase from 64 MB no-cache to 1024K cache.

The listed boards do not exhibit such problems. You can quote me on that. : )

So far all 486 class mobos from PC-Chips, i had the honor to try, turned out quirky.
M919 is no different - flaky pain in the ass if attempt anything more interesting than staying deep inside the safe zone of its specifications.
I guess this makes it a good retro hobby toy to thinker with.
At the same time if conservative enough in my needs/expectations - it will function as advertised and be basically hustle free.
But this applies for most hardware, so not an achievement extraordinaire really.

It is certainly one of the more unique problems. I think I need to do more testing to ensure that the 1024K module is providing some boost against the 256K module.

I will be checking this soon too.
Waiting for the module to arrive.
Share findings if you get to any of that in the meantime.

I've run a more detailed analysis of the M919 v3.4 with respect to the 32 MB vs. 64 MB slow down. I've run the setup as shown, with the following modules, and collected data.

It would appear as if the hardware or the BIOS has some performance bug around the 64 MB mark, regardless of how much L2 is installed. This performance bug, or hit, doesn't occur at 32 MB, 128 MB, or 256 MB. I suppose it would be interesting to see at exactly what MB boundary the bug starts and at what point it ends. PC Chips boards are just loaded with unwelcome surprises!

The most telling bit of data was with 0K cache. 32 MB = 11.3 fps, 64 MB = 9.6 fps, 128 MB = 11.3 fps. lol. It was interesting to see that even using the quantity of RAM where the bug occurs, 64 MB, that adding L2 cache still helped. 0K = 9.6 fps, 256K = 10.0 fps, 1024K = 10.2 fps. But the percent gain for the bugged 64 MB with increasing L2 cache (4%) was somewhat less than the percent gain for non-bugged 32 MB (5.5%), e.g. 0K = 11.3 fps, 256K = 11.9 fps, 1024K = 12.3 fps.

I suspect this PC Chips bug had something to do with their fake cache deception. Did you test this board with the UUD or HOT433 BIOS and also notice a slow down with 64 MB?

The good news is that these 1024K modules from pakecakepuppy sort of solve the dilema in which this board can really only use 32 MB of RAM. We just need to skip over the 64 MB amount and use 128 MB. Note that the benchmark results with 1024K and 32 MB match the results at 1024K and 256 MB, which was 12.3 fps.

Very interesting find indeed.
Didn't check back then with more than 64Mb because of the 256Kb L2 cache module limit but with 1Mb module you exposed an address-range "performance hole".
What the "OK" rows indicate btw ? No L2 cache ?

So yes, keep RAM to 32Mb or less, assuming 256Kb L2 cache limit or skip to 128Mb or more with 1Mb L2 cache size.

UUD and HOT433 don't have this issue with 64Mb RAM.
UUD is steel solid assembly really. Best integration of the UMC 's 486 chipset in my opinion.

Yes, 0K means no L2 cache, or 0 KB.

Tonight, I'm going to try and narrow down that 64 MB to see where it stops and starts.

Anonymous Coward wrote on 2022-05-04, 04:48:

Those NEC x87 FPUs are CMOS. So they *might* overclock okay.
But, according to CPUShack they are only rated at 8MHz. I'm not sure how that was determined though, since I wasn't able to decipher the production code.
Even if you can only get it up to 10MHz, it still provides one advantage over standard 8087s...387 instruction set.

PC/XT class machines and all of the 8088 and 8086 ilk have weird timing, it's not quite 50:50, it's all on the rise time of the clock pulse. So if you've got a board that does no special massaging of the clock, you might need a 10Mhz CPU/FPU to run at 8Mhz... if it does produce a "special snowflake clock pulse shape and timing" then the 10Mhz part can actually run at 10Mhz... I guess the question is, do NEC parts run on a "normal" clock or not for their rated speed.

I was able to narrow down the range for the m919's performance bug. I tested above 64 MB at 68, 72, and 80 MB's and the performance hit does not occur. I tested below 64 MB at 48 MB and the performance bug does not occur. I tried to test with 48+4 MB and 48+8 MB, but the POST count indicated the incorrect memory amount (~36 MB). Since the count was off, I didn't test for 48+4 and 48+8. I am pleasantly surprised at how narrow the range is for the performance penalty.

@BitWrangler
Can you clarify your message further.
What is a snowflake pulse shape/timing ?
Also, how this will reduce clock speed by 20% ?

@Feipoa
Ok, so the L2 cache hole is between the 48th and 64th megabyte it seems.
Wonder if this is really remedied by installing more RAM, or it just masks the problem.
For example if i run a memory expensive software that frequently hits this address range - will that cause slow-down or not.
This is a bit tricky to verify but is possible. I think i have an idea how to do that.

I've done a little more digging and am beginning to wonder if this 64MB slow down issue is more of a Quake-PCCHIPS bug. I compared 32 MB with 64 MB using 1024K in DOOM and PCPBENCH, and they score the same. I then ran CPUMark99 in Win95, which is rather sensitive to minor memory speed discrepancies and the slow down wasn't substantial, that is,
32M-1024K-WT = 4.61
64M-1024K-WT = 4.56
128M-1024K-WT = 4.65

What other slow downs were you noticing with >32M when you did your M919 testing?

feipoa wrote on 2022-05-05, 08:14:

What other slow downs were you noticing with >32M when you did your M919 testing?

It was not just Quake 1 issue.
Complex compute like 3D rendering and C++ compilation with Visual Studio are affected as well.

---

NEC D9008D FPU arrived today.

Unfortunately it does not get recognized by the beast XT machine.
Can be a BIOS problem. Can be something on signal level.
Regardless - that's the end of the Intel vs NEC 8087 story ... for now at least.
At some point later will try the chip in another XT but appetite is already low because i intention was to further boost that particular rig.

Damn, that's unfortunate.

yeah, disappointing.

---

In another news finally found the time to move the 180MHz LuckyStar rev:D rig to 200MHz.
Details at the bottom of the original post.
Very stable.
Some highlights:
Quake 1 - 22.7 fps
GL Quake - 35.1 fps
Video showing the rig in action.

EDIT:
Forgot to add something. Better later than never.

Pushed things around a bit - the new highest Quake 1 score on 486 class CPU so far:

A video proof.

pshipkov wrote on 2022-05-06, 05:06:

NEC D9008D FPU arrived today. […]
Show full quote

NEC D9008D FPU arrived today.

Unfortunately it does not get recognized by the beast XT machine.
Can be a BIOS problem. Can be something on signal level.
Regardless - that's the end of the Intel vs NEC 8087 story ... for now at least.
At some point later will try the chip in another XT but appetite is already low because i intention was to further boost that particular rig.

Which CPU was installed when you tested? Was it a V20 or V30?
Did you try power cycling after first booting up?

I don't have V20.
Only Intel 8086 and NEC V30 HL.
Tried hard to make it work - stripped the rig down to the bone with no extension cards, minimum RAM, etc.
When D9008D is in the socket - no lights, only the Tandy mobo produces this specific buzzing sound when something is off with the system.

Did you ever manage to run D9008D FPU ?

No. I have one at AVICC. I normally go visit my parents every 2 years (and pick up my packages), but it's already been almost 4.5 years since my last visit due to the pandemic.
I gave up on international shipping to China, because it's a pain in the arse to receive packages. I have to spend an entire day travelling to the provincial capital to pay the tax. Sometimes my packages disappear for many months, and sometimes they just get returned to sender.

maxtherabbit wrote on 2021-06-19, 15:51:

what's even more vexing to me is that I was unable to get any variant of the Adaptec 2940 to work in my LS-486E
tried a plain 2940, 2940U, and 2940UW - all cards known working in other machines - and all of them would just hang in a death spiral of rescanning the SCSI bus

My ls-486e has built in NCR 3.06 and AHA7850 (=2940UW) module
After removing the latter, I got 2940UW!
Here https://www.phantom.sannata.org/viewtopic.php … =657953#p657953 I wrote about it. There are also firmware with a remote module.

ps: And here https://www.phantom.sannata.org/viewtopic.php … =658884#p658884 there is a description of the same problem for the DC390W/U/F + medicine of those years.