MSxyz wrote on 2024-04-05, 09:59:

The bad news is that the system is a bit underperforming.
[...]
... CacheCHK doesn't seem to recognize the 2KB cache at all (see pic). Before working further on this setup, I need to dig up some old utilities for the Cyrix CPUs. The one I used for the 486DLC doesn't appear to be working with the 486S.

The RAM speed is a little slow.. should be 20-30MB/S.
L2 cache (128KB) is approx the right speed.
L1 cache is not detected...

The Cyrix app may not work on this CPU to turn on the internal cache, and the BIOS may not know how to turn on the internal cache...

If you can find the datasheet for the CPU and find the pin "KEN", then just connect GND to turn it on. If you need to guess, use a 5k resistor to GND.

This is a list of many 486 CPUs and their pins but the Cyrix SX-40 may be different to all of them. http://www.pchardwarelinks.com/486pin2.htm

Honestly it should be connected somewhere to either the interposer or the motherboard.

Anonymous Coward wrote on 2024-04-06, 05:29:

Quite a lot of 486 boards use chipsets that also support the 386. The bigger issue would probably be the pinout, which I believe is slightly non-standard. Then you'll need a BIOS that can correctly identify the CPU and enable the cache at boot. I've never owned a 486S. Feipoa has one, and I think he's tried it on boards that don't officially support it. I forget how that worked out.

But seeing as how you already have the board that probably came with your 486S, you should keep all that stuff together. Having the board, the CPU and interposer makes it somewhat collectable as far as I'm concerned.

I'm not even trying to separate the CPU from the FPU since the latter is mounted onto a pcb, and I don't trust 30 years old polymers -that make up the pcb- not to crack under pressure. Yesterday, it took me nearly 10 minutes of gently prying with a plastic chip removing tool to separate the CPU+FPU from the mainboard.

I'm going to use a later version of the same Soyo SY-025, with the SiS 471 chipset instead of the 461. This also has the added advantage of having a ZIF sockeet. Support for 486S is explicitly mentioned in the manual and there are jumper config for all different types of Cyrix 486s up to late 1994 (I assume that's when the board was manufactured). I also have a couple of spare Cx486S (no Cx487 though... that's the first I see outside of pictures) that I can use to test the board before using my newfound rarity 😀

MikeSG wrote on 2024-04-06, 06:48:

The RAM speed is a little slow.. should be 20-30MB/S. L2 cache (128KB) is approx the right speed. L1 cache is not detected... […]
Show full quote

MSxyz wrote on 2024-04-05, 09:59:

The bad news is that the system is a bit underperforming.
[...]
... CacheCHK doesn't seem to recognize the 2KB cache at all (see pic). Before working further on this setup, I need to dig up some old utilities for the Cyrix CPUs. The one I used for the 486DLC doesn't appear to be working with the 486S.

The RAM speed is a little slow.. should be 20-30MB/S.
L2 cache (128KB) is approx the right speed.
L1 cache is not detected...

The Cyrix app may not work on this CPU to turn on the internal cache, and the BIOS may not know how to turn on the internal cache...

If you can find the datasheet for the CPU and find the pin "KEN", then just connect GND to turn it on. If you need to guess, use a 5k resistor to GND.

This is a list of many 486 CPUs and their pins but the Cyrix SX-40 may be different to all of them. http://www.pchardwarelinks.com/486pin2.htm

Honestly it should be connected somewhere to either the interposer or the motherboard.

This board doesn't have a lot of options in the BIOS. I already tried lowering all the timings to the minimum.

The CPU cache is enabled, though. There is a setting in the BIOS to turn in/off both L1 and L2. The speed difference is noticeable. Yesterday, after having written the post you quoted, I found a small app that lets you switch the internal cache of Cyrix CPUs between WT and WB. There's a small boost to be gained by switching the cache to WB mode. However, since the L2 cache is already WB and it works at the same speed, then the gains are small. WB caches on CPUs in which the core runs at the same speed as the IO bus are really useful only if there's no L2 cache, or if it's much slower than the internal cache.

MSxyz wrote on 2024-04-06, 08:43:

The CPU cache is enabled, though.

is it tho?
Cyrix 486S 'FasCache' = 2 KB
it would show up in cachechk, but there is no speed bump at 1 and 2KB compared to 4KB

so in my opinion it is not

MSxyz wrote on 2024-04-06, 08:43:

There is a setting in the BIOS to turn in/off both L1 and L2.

hmm L1 only for CPUs bios knows about, so depending on board age might be even only Intel for really early ones? Is turning on L1 standardized in 486 and all brands work the same way?

It is, because both in synthetic benchmarks and in applications scores were different with and without cache enabled. I also noticed a small improvement when enabling the Write Back feature, so caches must be working.

What I noticed is that CACHECHK also does not detect the 1KB cache of 486DLC (besides reporting a wrong CPU speed; if I have to take a guess, the speed is inferred from executing some simple ALU instructions which are slightly faster on Cyrix CPUs)

Maybe Cyrix L1 is only an instruction cache? That would cause faster code execution but zero data access difference.

The answer to that should be available in the databook.

*edit*

I looked in the 486SLC databook. The first page says this: "On-chip instruction and data cache"
It's unlikely that changed with the 486S.

The reason why the cache is not recognized is possibly explained here: https://github.com/karcherm/cx486wb

The 486DLC/S updates the cache in 2 clock cycles in 'write through' mode. If the external cache is of the 'write back' type, and a write cycle also takes 2 cycles, then CACHECHK cannot recognize the presence of the L1 cache because it measures the latency of memory writes. I cannot verify it now, but it should be possible to identify the caches if the external bus is forced to run slower (i.e. inserting extra wait states).

MSxyz wrote on 2024-04-06, 15:54:

The reason why the cache is not recognized is possibly explained here: https://github.com/karcherm/cx486wb

The 486DLC/S updates the cache in 2 clock cycles in 'write through' mode. If the external cache is of the 'write back' type, and a write cycle also takes 2 cycles, then CACHECHK cannot recognize the presence of the L1 cache because it measures the latency of memory writes. I cannot verify it now, but it should be possible to identify the caches if the external bus is forced to run slower (i.e. inserting extra wait states).

That's my GitHub repo, and it correctly claims that a "write through" cylce (can be either because L1 is in WT mode or due to a write miss) takes (at least) two clocks. This is an intrinsic property of the 486 bus protocol, unrelated to any Cyrix implementation limitations. You are completely correct that a write hit to the L2 cache is supposed to be performed in 2 clocks on any decent 486 motherboard in write-back mode. That's the point of using L2 write-back.

On the other hand, I don't suppose CACHECHK is trying to measure the latency of memory writes, and this is for two reasons. First, measuring the latency is way more complicated than measuring the throughput, because measuring the latency would mean you know when the write to the L1/L2/main memory has completed. I suppose this is just imprecise wording and you actually just meant the reciprocal of the throughput and you called it latency. Furthermore, I don't think CACHECHK is measuring the throughput of writes, but it is measuring the throughput of reads. If you measure write throughput, you can only detect write-back caches. Write-through caches are "invisible" to writes. Unless the cache strategy includes "write allocation", even write-back caches are "invisible" to writes as long as the writes miss the cache. (by the way: That's the reason for the flat line in the "writing" performance is SpeedSys. The write test in SpeedSys is written in a way that it measures cache misses instead of cache hits, so all classic caches don't influence the measured write throughput. My experience is that CACHECHK is perfectly able to detect write-through caches, so it obviously has to measure read throughput instead of write throughput. And that's likely the real issue: If a Cx486S / Cx486DLC can not perform a REP LODSD faster than 2 clocks per iteration, an L1 hit will not be faster than an L2 hit. Looking at the performance figure of 33µs/KB, which converts to 30MB/s, it seems the processor requires 4 clocks for one iteration. So to detect the L1 cache, you need a different access pattern than REP LODSD that generates a read demand exceeding 32 bits per 4 clocks, or you need to slow down L2 hits.

The latter is easy to do: If you disable L2 cache, you should observe "cache-like performance" for block sizes up to 2KB instead of 128KB as you currently do.

mkarcher wrote on 2024-04-06, 16:39:

That's my GitHub repo, and it correctly claims that a "write through" cylce (can be either because L1 is in WT mode or due to a write miss) takes (at least) two clocks. This is an intrinsic property of the 486 bus protocol, unrelated to any Cyrix implementation limitations. You are completely correct that a write hit to the L2 cache is supposed to be performed in 2 clocks on any decent 486 motherboard in write-back mode. That's the point of using L2 write-back.

First, I want to thank you for your useful apps that allowed me to better understand Cyrix processors. Thanks also for the in-depth explanation.

In a couple of weeks, I'll pick up the testing where I left and I hope I'll be able to answer some of the questions raised in this thread.

Finally I managed to dedicate myself to this Cyrix 486 + 487 sandwich 😀

My new board is a later revision of the same Soyo 025 they originally came with. The board is actually quite different (different chipset, a SiS 85C471, different layout different number of VESA slots...), so I don't know why the folks at Soyo kept calling it 025. At any rate, support of the Cx486S was explicitly mentioned in the manual, so I went with it.

The motherboard itself turned to be a nice surprise. With 60ns DIMMs and 15ns SRAM chips, it's rock solid at 40 MHz using the fastest timings available in the BIOS. It's one of the best performing 486 VL motherboards I've tested. With only the video card using the VL bus I had no difficulties running it at zero WS.

I was quite curious to see what the Cyrix 486S would be capable of and it turned out... it's a bit of a lemon. 😀

Aside from the bigger cache, it behaves exactly like a 486SLC; it doesn't seem to take advantage of the faster burst modes available on the 486 bus either. The 487S also seems a rembranded Cyrix 3D87+ adapted to work on the 486 bus, because performance is almost the same both in synthetic benchmarks and real life applications. This, however, was less unexpected, since it's more a problem of the way the x86 architecture interfaces with an external FPU.

I'm uploading a few screenshots of some of the benchmarks I've run...

Ah, now I understand.
SpeedSys' chart does NOT show cache charts below 4 kB because its scale starts at 4 kB.
So you cannot see the L1 cache there.

For me it seems this CPU / FPU combination is like a Cyrix 386 (486DLC) + 387 (3D87) adapted for the 486 bus, with some cache but lack of burst mode. Since the FPU is not integrated in the CPU it won't take advantage of the L1 cache.

Disruptor wrote on 2024-04-23, 07:46:

For me it seems this CPU / FPU combination is like a Cyrix 386 (486DLC) + 387 (3D87) adapted for the 486 bus, with some cache but lack of burst mode. Since the FPU is not integrated in the CPU it won't take advantage of the L1 cache.

This is also my impression. I plugged in an Am486DX2 80MHz in the same motherboard (a better comparison would have been a Cyrix or AMD 486DX at 40MHz but I don't have one at hand) and the L2/memory throughput figures improved dramatically; for me, this is a telltale sign that the 486S doesn't really make use of the burst mode.