In theory it’s swappable without much issue as long as you are not planning on enabling the on chip cache. Once you try using the Cyrix utility to enable the cache things get more complicated along these lines:

486DLC cache coherency blues and headaches

although it sounds cool and great on paper the speed boost you gain from 386sx->486slc is only a benchmark one (because of the 1kb L1 cache) and in real-life apps/games the speed boost won't really make any noteworthy difference.
take a look here: Re: Amstrad Mega PC , I did the upgrade to a 386sx25 mobo that had a 486slc version from factory by Amstrad - alongside a proper bios upgrade... in the end you can see the results from 386sx->486slc:

386sx -> 486slc
Sysinfo: 18.1 -> 33.8
Landmark: 34.15 -> 92.76
Wolf3d: 14.1 -> 14.4 fps
3Dbench: 7.8 -> 8.4

notice the ram banks stuff on the top of the post - might also be an issue on a laptop

keropi wrote on 2024-12-14, 20:16:

although it sounds cool and great on paper the speed boost you gain from 386sx->486slc is only a benchmark one (because of the 1kb L1 cache) and in real-life apps/games the speed boost won't really make any noteworthy difference.

And that's why you want an IBM 486SLC (the original IBM design, not a Cyrix 486SLC-family chip produced by IBM), as those chips have 16KB of L1 cache. I have no idea though whether you can get those processors without a PS/2 computer attached.

This guy has been doing some messing around with the various SLC and DLCs https://www.youtube.com/@DKJones96/videos

I believe you can stick a TI486SLC on a 386SX footprint, and then figure out what to do with the FLUSH# signal for cache.

edit: We were also meandering close to this topic here Alaris Leopard - Added new CPU (not original IBM) stuck on HIMEM TEST with a couple of insightful posts about things that might have relevant info.

TI486SXLC2 CPUs (8Kb cache) solder on and work straight away with all 386sx motherboard I tried. However the BIOS needs to know about 486 SLC/DLC chips. TheRetroWeb may have a BIOS update, or the BIOS may already know about 486 CPUs.

If the BIOS knows it's a 486 CPU, then FLUSH# signal is not needed as there's a flush op-code included in 486 instructions. You need to use the Cyrix utility to turn cache on even if the BIOS has the option.

486 instructions are far faster, and in 3D bench video/ISA clock becomes the bottleneck not CPU anymore.

Soldering the TI486SXLC2 should only be done with a soldering iron & low melt solder. Everyone I've seen solder it using a hot air gun had trouble using the double-clock feature.

The TI486SXLC2 needs a fan if using double clock or running benchmark/cpu intensive apps above 25Mhz. For a laptop if the CPU is touching/near touching the chassis then a thick thermal pad would work.

Can't use the 387 socket. The pins are different from the CPU.

MikeSG wrote on 2024-12-15, 08:14:

If the BIOS knows it's a 486 CPU, then FLUSH# signal is not needed as there's a flush op-code included in 486 instructions. You need to use the Cyrix utility to turn cache on even if the BIOS has the option.

That's not how it works. A true 486 doesn't use invalidate ops except some really special situations, like a driver that switches hardware RAM pages in memory-mapped devices. Assuming that area is cacheable in the first place. You do need FLUSH# on the SLC/DLC/SXL(C) class chips for DMA device-to-memory writes to work properly. So on most systems that only affects reading floppy disks, and only when the floppy is swapped. And even then the puny L1 on the SLC will usually just spill simply running the code so you might not ecounter any issues right away. But with 8k cache on SXLC chips the corruption is noticable.

These chips need FLUSH# or have to work in BARB mode if DMA is used. No way around it. Well I suppose not using the floppies, ever, and/or recording from soundcard (which is rare even under Windows) would also "fix" it. The A20 gate mask signal should also be connected because the workaround is to not cache certain memory regions, that's costly and makes the whole CPU swap very questionable.

Though I agree that 386 to SLC swap is not going to do much due to the narrow bus and very small cache. These CPUs are already bus limited, although there will be some minor speedup in pure 16-bit code. The 8k cache is doing better but also can't work miracles since it's difficult to feed the cache through the narrow bus, and 286/386 code optimization requires loop unrolling, the opposite of what 486+ CPUs want.

Such CPU swap in a laptop is questionable due to power usage. Most laptops would be using AMD chip, or Intel's 386SX in the low power variant. IIRC the 486SLC from Cyrix draws twice the current of these 386, and the SXLC is even worse, and more often then not will run quite hot. SXLC with clock doubler and cache enabled pretty much requires some form of cooling or it will slowly cook itself and everything around it.

You might be right about needing the FLUSH# signal. To boot from floppy I have to disable L1 cache in the BIOS. In normal booting, and after loading "cyrix.exe -f -b- -m", floppies work, but it's probably not writing to memory (loading a program), so I didn't test that properly.

I did get an Acer ALI M1217 board to run 3x faster using the TI486SXL2 at 66mhz. Sis Info runs mostly in the L1 cache though. Which I read is 32-bit not 16-bit.

Compilers will unroll loops if the programmer specifies fast code optimisation. 486s+ want them all the same as any other CPU.

98.4 for the TI486SXLC2 @ 66
35.9 for the standard 386sx

Deunan wrote on 2024-12-15, 13:27:

You do need FLUSH# on the SLC/DLC/SXL(C) class chips for DMA device-to-memory writes to work properly. So on most systems that only affects reading floppy disks,

Exactly. The idea is that the SLC chip may have "old" data in its cache when DMA updates the memory "in the background". The SLC chip must invalidate either the whole cache or at least the address area that has been modified by DMA to not use old stale data. Some BIOS vendors may have put a cache flush instruction in their floppy read function, eliminating the requirement for working FLUSH# as long as the floppy is only ever accessed using the BIOS (and not via direct floppy controller programming).

Deunan wrote on 2024-12-15, 13:27:

and only when the floppy is swapped.

I can't follow this reasoning. Obsiously, if you read the same sector of the floppy into the same location of memory, it doesn't matter whether the 486SLC uses the stale old value from its cache or the new value written by DMA, as those values happen to be identical. If the floppy has been swapped in-between, the new data written by DMA will be different to the old data in the sector buffer. I guess this is what you might have thought of. But on the other hand, even if you read a different sector from the same floppy to the same buffer area, a cache flush (either manually using a 486 INVD instruction or using the FLUSH# signal) is required.

Deunan wrote on 2024-12-15, 13:27:

These chips need FLUSH# or have to work in BARB mode if DMA is used.

And that's what makes MikeSGs statement about "the BIOS knows the 486" not entirely wrong. If the BIOS knows the 486SLC (not just any kind of 486), and it knows that the mainboard does not properly signal FLUSH#, the BIOS might enable the SLC BARB mode to also work around DMA problems (at a higher performance cost).

Deunan wrote on 2024-12-15, 13:27:

Though I agree that 386 to SLC swap is not going to do much due to the narrow bus and very small cache. These CPUs are already bus limited, although there will be some minor speedup in pure 16-bit code. The 8k cache is doing better but also can't work miracles since it's difficult to feed the cache through the narrow bus, and 286/386 code optimization requires loop unrolling, the opposite of what 486+ CPUs want.

Yeah, I like to joke that the 486SLC2 waits for the bus twice as fast as the 486SLC, especially for 32-bit software. The 486 is at the tipping point between "loop unrolling is good" and "loop unrolling is bad". Huge unrolled loops waste precious cache space on the 486, which is a point against unrolled loop. Nevertheless, the 486 still doesn't have jump prediction, and every taken jump flushes the execution pipeline, which is a point for unrolled loops. "Unrolling hurts" is much more true on the Pentium than on the 486, especially for short loops.

Deunan wrote on 2024-12-15, 13:27:

SXLC with clock doubler and cache enabled pretty much requires some form of cooling or it will slowly cook itself and everything around it.

Just as a data point: I have a Taiwanese Cx486SLC2-50 Laptop, which died some time after I upgraded the hard drive from 120MB to 500MB. Possibly the in-rush current of the bigger drive killed the laptop in the long run. The hard drive took two attempts to spin up every time it spun up, likely due to insufficient +5V supply. That laptop did not have any kind of cooling on the SLC2-50, which didn't seem to impose a problem. I do understand that the SXLC with clock doubler is a different thing due to the bigger (much more sensibly sized) cache, which might be considerably more power hungry.

Yeah I am hoping that the BIOS I've got on my PT-319A fixer uppers with apparently factory installed Ti486SLC and apparently flush line incapable chipset has the workaround.

For mitigation if one were to put one in a system with one of this are there strategies that you could use. Like on a single drive system, keep going to B: and back to A: where DOS does that floppy aliasing thing and asks you to insert disk for drive B or A every time you switch, would that do it?

Or I was also thinking about the "wrong" or "suboptimal" floppy set up where it never knows there's a disk in until it tries to read it, thus having to re-read the FAT every time, is that the DC line or jumper setting on a drive if it has it? Anyway, forcing it to do that, though a bit more annoying might stop it corrupting things with out of date stuff.

Then a third thought, something about the DOS "FILES" handler, keeping track of what files were open, if you set that real low and it couldn't keep more files open at one time, would that help? Or is that just internal DOS stuff and wouldn't really matter for CPU cache.

BitWrangler wrote on 2024-12-15, 19:11:

For mitigation if one were to put one in a system with one of this are there strategies that you could use. Like on a single drive system, keep going to B: and back to A: where DOS does that floppy aliasing thing and asks you to insert disk for drive B or A every time you switch, would that do it?

...

Or is that just internal DOS stuff and wouldn't really matter for CPU cache.

You are looking at the issue at an inappropriate level. The issue does not (only) happen with DOS buffers, and it is not limited to disk swaps at all. The problem can occur every time a floppy sector is read into memory. When you call INT13 to read a sector, you pass a drive number, a sector number and a destination pointer to the BIOS. The BIOS then instructs the floppy controller and the DMA controller to read data from the floppy into the memory area you specified, and returns when the floppy controller claims that it has passed all data to the DMA controller (which also means the DMA controller has written all data to main memory). As soon as the BIOS returns to the application program, the application program expects to find the data read from the floppy when it accesses the memory at the address that had been given to the BIOS. If the 486SLC still has that address in cache from a read that occurred before the DMA controller wrote the floppy data to that address, your application will get bad data. As the L1 cache of the 486SLC is just 1K, it is quite likely that executing the DOS fixup code for INT13 (which circumvents the DMA 64K boundary limitation) and the BIOS code for INT13 uses sufficient space in the L1 cache for the code that all stale data is purged from the cache anyway when INT13 returns. In that case, you won't observe any issues.

As Deunan already said: While executing the DOS and BIOS code for INT13 like drains most of the L1 cache just from code execution on the Cx486SLC with just 1KB cache, the 8KB cache of the TI 486SXLC or the 16KB cache of the IBM 486SLC is usually not fully flushed from just fetching those instructions.

keropi wrote on 2024-12-14, 20:16:

although it sounds cool and great on paper the speed boost you gain from 386sx->486slc is only a benchmark one (because of the 1 […]
Show full quote

although it sounds cool and great on paper the speed boost you gain from 386sx->486slc is only a benchmark one (because of the 1kb L1 cache) and in real-life apps/games the speed boost won't really make any noteworthy difference.
take a look here: Re: Amstrad Mega PC , I did the upgrade to a 386sx25 mobo that had a 486slc version from factory by Amstrad - alongside a proper bios upgrade... in the end you can see the results from 386sx->486slc:

386sx -> 486slc
Sysinfo: 18.1 -> 33.8
Landmark: 34.15 -> 92.76
Wolf3d: 14.1 -> 14.4 fps
3Dbench: 7.8 -> 8.4

notice the ram banks stuff on the top of the post - might also be an issue on a laptop

What is the VGA card in that system?

When I upgraded motherboard from 286-16 to 486slc-33 and using the same components I was very disappointed. Even though the CPU benchmarks would show significant upgrade, the games were almost the same. Mainly F1GP that I played at that time. Only by a pure chance I tested the 486slc with another VGA card - a Trident 8900... now this was a completely another beast 🤣 The performance was pretty much between a 386DX-33 and 386DX-40.

kixs wrote on 2024-12-15, 22:04:

When I upgraded motherboard from 286-16 to 486slc-33 and using the same components I was very disappointed. Even though the CPU benchmarks would show significant upgrade, the games were almost the same. Mainly F1GP that I played at that time. Only by a pure chance I tested the 486slc with another VGA card - a Trident 8900... now this was a completely another beast 🤣 The performance was pretty much between a 386DX-33 and 386DX-40.

As you mention the Trident 8900 card that gave you a significant speed-up: Readers beware! Don't just buy the next Trident 8900 card to get the same experience. The Letters behind 8900 are very important for the performance. If you want a fast Trident 8900 card, it has to be a Trident 8900CL or an Trident 8900D. The 8900C (without "L") might also be acceptably fast, but the 8900A and 8900B are known for their lack of speed.

mkarcher wrote on 2024-12-15, 16:49:

I can't follow this reasoning.

Sorry, brainfart. Not too long ago I was dealing with another floppy and cache issue but this time it was write-back mode on 486 not being handled properly by the chipset. That is what came to my mind, because it requires a floppy swap to corrupt data. For the chips discussed here lack of FLUSH# or BARB can corrupt any sector read, even on the same floppy - except as I mentioned the small L1 can often mask this issue. But it will happen in certain situations.

MikeSG wrote on 2024-12-15, 15:47:

Compilers will unroll loops if the programmer specifies fast code optimisation. 486s+ want them all the same as any other CPU.

Some loop unrolling is beneficial, true, because a jump is "wasted" CPU cycles. But on 486 and above you also want to keeep the code in L1 as much as possible, so there is a limit to unrolling. The 8086/88 don't care all that much but on 286+ (186 too I think?) there is a prefetch queue. On 386DX especially since it can fetch code in 4-byte chunks and most instructions are shorter than that, and any jump will flush the queue. So these CPUs want extreme loop unrolling, even if it bloats the code a lot. If it fits in RAM it's still all good. That kind of optimization is not helping CPUs with small on-die cache. And the SLC/DLC cache is very small, it often helps to score better in benchmarking software due to test loops being short I guess, and some instructions being much faster. But my point was that it doesn't translate well into software that was written for, and optimized for, 286 and 386.

Well, that's my 2c, I don't want to derail this topic with my ramblings.

mkarcher wrote on 2024-12-15, 23:20:

kixs wrote on 2024-12-15, 22:04:

When I upgraded motherboard from 286-16 to 486slc-33 and using the same components I was very disappointed. Even though the CPU benchmarks would show significant upgrade, the games were almost the same. Mainly F1GP that I played at that time. Only by a pure chance I tested the 486slc with another VGA card - a Trident 8900... now this was a completely another beast 🤣 The performance was pretty much between a 386DX-33 and 386DX-40.

As you mention the Trident 8900 card that gave you a significant speed-up: Readers beware! Don't just buy the next Trident 8900 card to get the same experience. The Letters behind 8900 are very important for the performance. If you want a fast Trident 8900 card, it has to be a Trident 8900CL or an Trident 8900D. The 8900C (without "L") might also be acceptably fast, but the 8900A and 8900B are known for their lack of speed.

In my case even the Trident 9000 would be much better than the 256KB VGA card with Chips F82C451 I used 😉

keropi wrote on 2024-12-14, 20:16:

although it sounds cool and great on paper the speed boost you gain from 386sx->486slc is only a benchmark one (because of the 1 […]
Show full quote

although it sounds cool and great on paper the speed boost you gain from 386sx->486slc is only a benchmark one (because of the 1kb L1 cache) and in real-life apps/games the speed boost won't really make any noteworthy difference.
take a look here: Re: Amstrad Mega PC , I did the upgrade to a 386sx25 mobo that had a 486slc version from factory by Amstrad - alongside a proper bios upgrade... in the end you can see the results from 386sx->486slc:

386sx -> 486slc
Sysinfo: 18.1 -> 33.8
Landmark: 34.15 -> 92.76
Wolf3d: 14.1 -> 14.4 fps
3Dbench: 7.8 -> 8.4

Wolf 3d or 3dbench are going to be VGA limited if you have a slow VGA chip on an ISA bus <=8mhz. What video chip was in your Amstrad? Paradise PVGA1A, yes ? What was the ISA bus speed? CPU / 4? Speeding up your CPU is going to have limited impact in this situation. It's like the people who paid $$$ to upgrade a 350Mhz CPU to a 450Mhz CPU to play Half-Life, but kept their S3 Virge video card. Begging to be disappointed.

Enabling a 1K on-chip cache produces a speed improvement about the same as adding a 32KB cache to the motherboard. The on-chip cache is better at small data sets, the 32KB better at large data sets, but they are pretty close either way. If you have a 25Mhz CPU, it should make your CPU perform close to a 33Mhz 386sx that has no cache. Might not be super noticeable on day to day stuff but it would be easily measurable for long running CPU limited tasks.

So what sort of long running CPU limited tasks would a 386sx face in retro computing? PKzip ? Installing software from CAB files? World generation in Civilization? Windows apps if you had a decent 2d accelerated video card?

edit: Here are the results that I got with a 40Mhz chip and Mach 64 isa graphics card @ 13.3Mhz

1CPU        CPU   Mobo    Doom    Speedsys
2          Cache Cache     FPS   CPU Index
3Ti486DLC   1KB  256KB    10.3     10.29   
4Ti486DLC   1KB   32KB     9.8     10.20   
5Ti486DLC  none   32KB     7.5      9.47   
6Ti486DLC   1KB   none     7.1      9.88   
7AM386-40  none  256KB     7.0      6.88   
8AM386-40  none   32KB     6.7      6.88   
9AM386-40  none   none     3.2      5.19   
10Ti486DLC  none   none     2.9      5.76   

The amstrad mobo has an onboard WD90C11A chip - not dead slow but not a rocket too
ISA is probably at stock 8mhz - no options to change this in BIOS
On the same system at one point I had a slc2/40mhz upgrade - again it was a mediocre speed boost (back then I did not have the special 486SLC BIOS or the wire mod needed for cache - cache was enabled and managed via CYRIX.EXE)

I have used several 486SLC(2) upgrades over the years - none were really worth it unless they upgraded a 286 system *or* there was L2 cache involved in the mix.
You might get better results when you upgrade some fully customizable system but the allure of 486slc upgrades is the use in OEM/special/fixed systems that you just need a little more ooomph - and since these systems offer little in the way of customization then ultimately the upgrade just does not worth it IMHO.

I like the 486slc cpus - always looking out for nice mobos using it and so far the best I have is the WH386SX-D that is a 486slc33/64kb cache motherboard.

kixs wrote on 2024-12-15, 23:43:

mkarcher wrote on 2024-12-15, 23:20:

kixs wrote on 2024-12-15, 22:04:

When I upgraded motherboard from 286-16 to 486slc-33 and using the same components I was very disappointed. Even though the CPU benchmarks would show significant upgrade, the games were almost the same. Mainly F1GP that I played at that time. Only by a pure chance I tested the 486slc with another VGA card - a Trident 8900... now this was a completely another beast 🤣 The performance was pretty much between a 386DX-33 and 386DX-40.

As you mention the Trident 8900 card that gave you a significant speed-up: Readers beware! Don't just buy the next Trident 8900 card to get the same experience. The Letters behind 8900 are very important for the performance. If you want a fast Trident 8900 card, it has to be a Trident 8900CL or an Trident 8900D. The 8900C (without "L") might also be acceptably fast, but the 8900A and 8900B are known for their lack of speed.

In my case even the Trident 9000 would be much better than the 256KB VGA card with Chips F82C451 I used 😉

One thing I noticed recently, is that should your motherboard and RAM support it, Trident 8900 and 9000 cards are very sensitive to the hidden refresh setting. With it enabled, they are 50% faster. Other chipsets seem more insensitive to it. Anyway, comes to mind that that might mean any other hiccups in memory cycles might have adverse effects on Tridents, so they might not be the best card in systems that don't have full support of the Flush# in the chipset, when using SLC. Also they are dog slow jumpered wrong, like for 8 bit mode in an AT or with the waitstates on. You get all that right on lower half 486 class and slower, and the CL and D are top bracket ISA performers... they might not scale high with DX4 or Pent, but they can do the business for slower stuff.

keropi wrote on 2024-12-16, 13:58:

You might get better results when you upgrade some fully customizable system but the allure of 486slc upgrades is the use in OEM/special/fixed systems that you just need a little more ooomph - and since these systems offer little in the way of customization then ultimately the upgrade just does not worth it IMHO.

How do these rules work?

If you double the CPU clock speed, you will feel the difference.
If you pay $300 to add an on chip cache, you have a rich man's hobby.
If you spend 30 hours installing a $30 surface mount chip from Alibaba, you better post a video!!