Sphere478 wrote on 2024-03-30, 18:21:

You would need a floating power supply and to tie one of the legs to negative of the chip. Probably the +5 of the new floating p […]
Show full quote

kingcake wrote on 2024-03-30, 15:24:

feipoa wrote on 2024-03-30, 01:21:

As pshipkov mentioned, I need 5.15 V going to the SXL2 for stable operation at 90 MHz. I only need 3.85 V for stable operation at 80 MHz.

That should read 37 C on VRM heatsink, steady-state, with only the linear reg. I've fixed it now.

Wire your regulator to +12V and +5V to get 7V Vin. You'll need an amp of load on your +5V power supply rail to ensure it doesn't try to sink current. A 5R power resistor would work fine hooked up to a molex connector. This will drastically cut your linear regulator's heat load.

You would need a floating power supply and to tie one of the legs to negative of the chip. Probably the +5 of the new floating psu

It can be done. I thought of it earlier but it’s kinda silly when you can just buck down from
+12v into some capacitors

Oh definitely. I was just saying it's a possible hack to avoid interposer redesign for a one off type thing.

kingcake, if I wanted lower VRM or CPU temps, I'd us my $1 in-line buck. Interposer redesign not needed. Without it, 35-37 C on the VRM and 27 C to the CPU is nothing to frown upon. Nonetheless, I took some additional measurements at steady state, 90 MHz.

Linear MIC29302WT only (no in-line buck)
5.15 V to CPU
VRM w/fan = 35.4 C
CPU w/fan = 27 C
VRM w/out fan = 43 C
only CPU fan, CPU = still 27 C
The 30 mm 3.2 cfm fan seems to help the VRM temp quite a bit, but not having it doesn't harm the CPU temp.

Buck at 6.3 V, Linear MIC29302WT at 5.15 V
VRM w/fan = 22.4 C
CPU w/fan = 23 C
VRM w/out fan = 23.5 C
only CPU fan, CPU = 23 C
So, if I use the buck, I don't need the VRM fan and the CPU runs 4 C cooler. Conclusion, the buck would only be needed if the CPU temperature once inside a case becomes a problem for stable operation.

Some other numbers from the benchtop:

DRAM = 50.2 C in the centre of 8 sticks
GD-5434 = 32 C
Northbridge w/heatsink = 26.9 C
SRAM = 29.9 C
FPU while running Quake for 8 minutes = 22.2 C
Buck regulator = 30.5 C

The DRAM seems a bit warm, but I'm using 9-chip modules here. This board did not like my 3-chip pieces at 45 MHz. Should I blow the DRAM with a fan?

By the way, there was another of these SXL2-50 chips with flush dongle from Improve-It that sold for $250. I was surprised to see that it sold for that price. https://www.ebay.com/itm/326071534917

I can tell these are collectors, otherwise the SXL2-66 + adaptor is the cheaper path to a much better place.
Of course, many of these threads are not visible from top level search engines, so good chance many people are just not aware.

Have you been able to stress the CPU @ 90 MHz against a sustained synthetic benchmark to ensure complete stability?

feipoa wrote on 2024-03-30, 23:55:

By the way, there was another of these SXL2-50 chips with flush dongle from Improve-It that sold for $250. I was surprised to see that it sold for that price. https://www.ebay.com/itm/326071534917

That seems like a rather silly amount to pay given how easy it would be to get a regular CPU and make one of those circuits just from visually looking at one of them. It seems like it wouldn't take much to re-create one of those circuits (although I could be wrong).

This is a test-fit of my design.

The double-sided 132-pin socket fits beautifully in the motherboard and PCB, with a ~2mm vertical gap.

The 168-pin press-fit fits the CPU, but PCB needs a redesign. Drills are 0.05mm too small.

I discovered the PCB should also be 2mm thick so the sockets sit flush on both sides. And I'll be adding the new flush circuit to make things easier.

Flush circuit on a 386sx/486SXL(C)2:
After testing a new 486SXL(C)2 386sx system I have questions about the BIOS knowing whether it's a 486SLC/DLC CPU and doing something with the 486 flush instruction "INVD" (https://www.felixcloutier.com/x86/invd). On the 386sx board with the Flush pin not connected to anything, and BARB disabled, Flush enabled... the cache worked. The board has hidden refresh and does not operate HLDA during normal memory refresh. When using another BIOS, the CPU was recognised as "486" not "486SLC" and the cache didn't work.

In any case, if the circuit on the Improve Technologies interposer covers 90% of cases and is better than hooking up MEMW, then I'll redesign it that way, with a solder jumper.

MikeSG wrote on 2024-05-02, 04:43:

On the 386sx board with the Flush pin not connected to anything, and BARB disabled, Flush enabled... the cache worked. The board has hidden refresh and does not operate HLDA during normal memory refresh. When using another BIOS, the CPU was recognised as "486" not "486SLC" and the cache didn't work.

According to my old notes, this was a common occurrence.

For motherboards which did not have the FLUSH# pin connected to anything, all I had to do was ensure that the full range of memory wasn't set to non-cacheable, e.g. using cyrix.exe -i1 -i2, etc. On other boards (still without FLUSH# connected), I may just need to enable the flush pin with cyrix -f, and again, ensure -i1 -i2 set.

The majority of 386 boards I've encountered did not have the double NAND gate flush circuit connected to FLUSH# (although some did) and had FLUSH# not connected, yet worked with L1 cache by setting cyrix -f -i1 -i2. Some of these 386 boards pre-date the release of the DLC by a year or two, and presumably, were not be L1 aware.

For instances in which I had to use the BARB method, it was because of a DMA based SCSI controller, like the AHA-1542C.

Yeah, might be a good idea to have a jumper dis-connectable option for the Improve-It flush schema on your design, while not eliminating the MEMW# option.

Can you describe the BARB method, I may try it on my system with the scsi controller. It’s been sitting on the shelf, need to get it out again.

MikeSG wrote on 2024-05-02, 04:43:

On the 386sx board with the Flush pin not connected to anything, and BARB disabled, Flush enabled... the cache worked.

of course, the problem was never cache not working, the problem was working cache glitching out other parts of the system like ISA DMA. So was floppy working reliably with cache enabled on that system?

One of the tests I like to do is play a (downsampled) mp3 file in Windows, while trying to access the floppy drive. Presumably, this tests floppy DMA, sound DMA, and FPU interaction in one shot.

feipoa wrote on 2024-03-30, 23:55:

By the way, there was another of these SXL2-50 chips with flush dongle from Improve-It that sold for $250. I was surprised to see that it sold for that price. https://www.ebay.com/itm/326071534917

Just out of curiosity: is this dongle already fully analyzed?
I got hold of a board with exactly this cpu/dongle and as it pretty rare to see in the wild I was wondering if is worth to analyze in detail.

feipoa wrote on 2024-05-03, 11:27:

One of the tests I like to do is play a (downsampled) mp3 file in Windows, while trying to access the floppy drive. Presumably, this tests floppy DMA, sound DMA, and FPU interaction in one shot.

.MP3s often use fixed-point arithmetic for compression, and any players (and compressors) from the from that era will almost certainly not use floating-point operations.

rasz_pl wrote on 2024-05-03, 10:37:

[...] was floppy working reliably with cache enabled on that system?

I tested a few file copies from a floppy and it works. I use "Cyrix.exe -cd -b- -f -m". I don't have much set up to test with at the moment..

Have you tried -m instead of -i?

Skorbin wrote on 2024-05-03, 11:40:

Just out of curiosity: is this dongle already fully analyzed?
I got hold of a board with exactly this cpu/dongle and as it pretty rare to see in the wild I was wondering if is worth to analyze in detail.

It's worth it - could you label the connections of the two large ICs? The traces are hard to follow when they go underneath.

AlaricD wrote on 2024-05-03, 14:07:

.MP3s often use fixed-point arithmetic for compression, and any players (and compressors) from the from that era will almost certainly not use floating-point operations.

feipoa wrote on 2024-05-03, 11:27:

I didn't mention an era for the mp3 player I'm using. If I remove the FPU, the player won't play the mp3 file very well. It tries, but there will be 10 second gaps of silence.

As a follow-up to my previous comment, AlaricD, could you let me know which mp3 players do not use the FPU? I would like to try them out on my SXL2 systems.

I was running a few tests on my SXL2-66 system with mp3 files.

Win 3.11
WinPlay3 v2.3beta5 16-bit (1994-1997)
WinPlay 3 will spit out an error if you don't have an FPU installed:
"Sorry, WinPlay3 requires a 486 Processor with a build in FPU"
Yes, it has gramatical errors.

Win NT 3.51
WinPlay3 v2.3beta5 32-bit (1994-1997)
Curious how WinPlay3 will actually attempt to play the mp3 file without an FPU installed, but the gaps between sound samples makes it unplayable. Install an FPU, and it can do 64 kbps, mono, 11 KHz. There was a sound skip at about 38 seconds into playback.

Win NT 3.51
Winamp v1.60RC5 (1997)
This plays a little better than WinPlay3, I think, because you can set the decoding priority to HIGH rather than NORMAL. WinPlay3 didn't have this option. The 38 second skip doesn't exist here, but don't put your song on repeat unless you want to manually reset the system. I did not bother trying to use Winamp without the FPU installed.

feipoa wrote on 2024-05-03, 11:27:

I didn't mention an era for the mp3 player I'm using. If I remove the FPU, the player won't play the mp3 file very well. It tries, but there will be 10 second gaps of silence.

As a follow-up to my previous comment, AlaricD, could you let me know which mp3 players do not use the FPU? I would like to try them out on my SXL2 systems.

There's madplay which uses the libmad library (https://www.underbit.com/products/mad/); strangely, it appears to have been released long after FPUs were standard equipment (2000!).

Audacity is listed as using libmad; perhaps the Win98/WinME-compatible version (Audacity 2.0.0) would be interesting to test with.

AlaricD, unfortunately, I only see Linux files for Madplay. Audacity has Win98 minimum system requirements and looks relatively modern. From your comment of 'players from that era', I was expecting something circa 1994. I normally use Windows 3.11 and NT 3.51 on 486DLC era hardware.

feipoa wrote on 2024-05-07, 20:57:

AlaricD, unfortunately, I only see Linux files for Madplay. Audacity has Win98 minimum system requirements and looks relatively modern. From your comment of 'players from that era', I was expecting something circa 1994. I normally use Windows 3.11 and NT 3.51 on 486DLC era hardware.

feipoa wrote on 2024-05-03, 11:27:

I didn't mention an era for the mp3 player I'm using. If I remove the FPU, the player won't play the mp3 file very well. It tries, but there will be 10 second gaps of silence.

I didn't notice that part before-- clearly, whatever .MP3 player you're using already doesn't require an FPU. If required it, it would just quit/crash/maybe be graceful about it with a clear error message.

I made a PCem VM-- A 386DX-40 clone without an FPU, running Win95 OSR2. Landmark 6.0 says there's no FPU, and Quake complained as well ("Coprocessor not available..."). Madplay.exe v0.15.2b (which doesn't require FPU, but will use it if present) did the "playback" with the expected stuttering and gaps. Also, madplay.exe was billed as a "command-line .MP3 player" but it still said "This program cannot be run in DOS".

With the 387 enabled for the VM, it still was super extremely stuttery. Quake reported 1.9FPS, though (technically, ~1.85FPS as it was 969 frames in 523 seconds).

The mp3 player I'm using does require an FPU and will not operate in Windows 3.1 without one. It was noted above, if you try to run it without an FPU, you get "WinPlay3 requires a 486 Processor with a build in FPU".

It is only the 32-bit version of the same player from within NT 3.51 which tries to play without an FPU, and it does a horrible job at it. Since the "yo bro, no FPU" error does not appear in NT 3.51, it is likely that NT uses an FPU emulation feature which tricks WinPlay3 into thinking there's a real FPU present. Given the massive gaps between music playback, it is evident that WinPlay3 does require an FPU on this class of hardware and emulation alone is grosely insufficient.

It would be interesting to determine at what point this FPU emulation is sufficient to actually play a 128 kbps, 44khz, stereo mp3 file (not downsampled). My guess would be a P200 at around 100% CPU usage. Has anyone actually run this experiment, that is, assuming you could disable the onboard FPU? Other than being able to disable the onboard FPU, I suppose a NexGen would be the fastest, or most advanced, FPU-less CPU.

Most people with a DLC-class CPU aren't running w95 or NT, they are running Windows 3.1, which required an FPU to play mp3 files. If you are aware of an mp3 player for Windows 3.1 or DOS 6.22 which can play mp3s without an FPU installed on 486DLC-class hardware, I would be interested in trying it out.

The original objective of my comment was to relay a simple test I use to check cache coherency. I use mp3 playback (FPU utilisation + sound DMA) in conjunction with floppy read/write access (more DMA) in Windows Explorer to/from the HDD as an initial Windows test for cache coherency or other stability problems. If you also have a DMA SCSI or DMA IDE controller, there's one more DMA in the test. The largest problem with adding DLC/SXL/DRx/BL3 chips onto 386 motherboards is with issues related to L1 cache coherency and DMA. Cyrix also provided some DOS cache coherency check tools, which I found did not catch deeper issues in Windows.

feipoa wrote on 2024-05-10, 00:58:

The mp3 player I'm using does require and FPU and it will not operate in Windows 3.1 without one. It was noted above, if you try […]
Show full quote

The mp3 player I'm using does require and FPU and it will not operate in Windows 3.1 without one. It was noted above, if you try to run it without an FPU, you get "WinPlay3 requires a 486 Processor with a build in FPU".

It is only the 32-bit version of the same player from within NT 3.51 which tries to play without an FPU, and it does a horrible job at it. Since the "yo bro, no FPU" error does not appear in NT 3.51, it is likely that NT uses an FPU emulation feature which tricks WinPlay3 into thinking there's a real FPU present. Given the massive gaps between music playback, it is evident that WinPlay3 does require an FPU on this class of hardware and emulation alone is grosely insufficient.

It would be interesting to determine at what point this FPU emulation is sufficient to actually play a 128 kbps, 44khz, stereo mp3 file (not downsampled). My guess would be a P200 at around 100% CPU usage. Has anyone actually run this experiment, that is, assuming you could disable the onboard FPU? Other than being able to disable the onboard FPU, I suppose a NexGen would be the fastest, or most advanced, FPU-less CPU.

Most people with a DLC-class CPU aren't running w95 or NT, they are running Windows 3.1, which required an FPU to play mp3 files. If you are aware of an mp3 player for Windows 3.1 or DOS 6.22 which can play mp3s without an FPU installed on 486DLC-class hardware, I would be interested in trying it out.

The original objective of my comment was to relay a simple test I use to check cache coherency. I use mp3 playback (FPU utilisation + sound DMA) in conjunction with floppy read/write access (more DMA) in Windows Explorer to/from the HDD as an initial Windows test for cache coherency or other stability problems. If you also have a DMA SCSI or DMA IDE controller, there's one more DMA in the test. The largest problem with adding DLC/SXL/DRx/BL3 chips onto 386 motherboards is with issues related to L1 cache coherency and DMA. Cyrix also provided some DOS cache coherency check tools, which I found did not catch deeper issues in Windows.

I wasn't aware that the Cyrix tools were not 100% reliable. Do you find your test to be more reliable?

Paralel wrote on 2024-05-10, 20:47:

I wasn't aware that the Cyrix tools were not 100% reliable. Do you find your test to be more reliable?

Don't take my word for it; test things yourself and draw your own conclusions. I am relaying my own anecdotes. There were so many 386 motherboard vendors and chipsets that each system behaves as its own beast. I've seen systems pass the Cyrix cache coherency test yet fail to load Windows 3.1. Playing around with the cyrix.exe options which adjust various aspects of cache coherency usually resolve these issues. Sometimes you can get into Windows 3.1 and still have issues within Windows, which require other changes.

Everyone has their own criteria for what they consider stable. Some don't care about loading Windows 3.1, others want to ensure the system can do several hours of code compilation, others insist the system must load the google homepage on IE5, etc. If all you care about is passing the Cyrix cache coherency DOS programme, then it will be quick to get your system "up and running".