I would try the parallel method first, because it's easier to pull off and doesn't require messing with surface mount chips. There is a DMA test program that comes with the Cyrix cache software. If you run it, and it fails, try the serial method. Based on what I read in newsgroups (people tapping the chipset pin), it sounds like many boards used serial secondary cache.

I was able to do the parallel cache mod without using any solder on the motherboard. I used a spare 386 socket and a card edge connector. The circuit was built on breadboard. It didn't work, because OPTi 495SX uses serial cache. I could confirm this, because my board already had support for the DLC and I traced the cyrix specific jumpers to the cache controller, not the CPU.

Well, the board I would try first is the SiS Rabbit board, which I do not have a clear understanding of which pin to solder to. To which newsgroups are you referencing? Perhaps I can check the chipset pin they taped to and relate it to the pin options on the SiS board.

I am referring to google groups. I do not remember which newsgroup specifically, but if you do a search for "486dlc" and "coherency" you can probably dig something up.

groups.google.com

I just noticed there is an easier way to determine if you have serial or parallel l2 cache. It says right in the cyrix manual "Flushing the cache cannot be accomplished by setting the BARB bit in CCR0 because bus arbitration occurs between the serial cache controller and the system". In other words, if the Cyrix software utility works, then you have parallel cache. I guess this might explain why the BARB method didn't work on my 495SX board. It still doesn't explain why my DMA SCSI controller doesn't work with my DLC.

How do you know if the L1 cache actually gets invalidated when setting BARB? I think regardless of serial or parallel cache type, you can still invoke BARB.

I have been searching Google Groups but have not run across a thread discussion about soldering to the chipset. Most threads concern software, which seems fairly straight forward.

If your L1 cache becomes stale, you will know immediately because the system will crash. Anything that uses DMA should cause problems...like floppy drive accesses and playing digital sounds through a sound card.

I was experimenting with my SiS Rabbit board today. The Ti486DLC L1 cache works with either the BARB and FLUSH pins (no hardware mod was performed). I played wave and mp3 music playback in Win3.11 as the test. HOWEVER, when I use a Ti486SXL, I cannot load Windows 3.11 when the L1 cache is enabled. Can anyone make sense out of this?

I've attached the differences between the DLC and SXL as noted in the Ti literature. Click image for larger view.

That's a very interesting observation. I think now I would like to get a hold of a 486DLC for testing on my 386 board. (currenty my only DLC is part of a 286 upgrade module). Maybe it was wrong to assume 486DLC and 486SXL are completely interchangeable?

Anonymous Coward wrote:

That's a very interesting observation. I think now I would like to get a hold of a 486DLC for testing on my 386 board. (currenty my only DLC is part of a 286 upgrade module). Maybe it was wrong to assume 486DLC and 486SXL are completely interchangeable?

It is wrong to assume that. The SXL is made to be used with a 386SX motherboard. The DLC is made for a 386DX motherboard.

sliderider wrote:

Anonymous Coward wrote:

That's a very interesting observation. I think now I would like to get a hold of a 486DLC for testing on my 386 board. (currenty my only DLC is part of a 286 upgrade module). Maybe it was wrong to assume 486DLC and 486SXL are completely interchangeable?

It is wrong to assume that. The SXL is made to be used with a 386SX motherboard. The DLC is made for a 386DX motherboard.

I thought that the 486SXL was made to be used with a 386DX motherboard, whereas a 486SXLC was made to be used with a 386SX motherboard.
If memory serves, they are both Texas Instruments derivatives of the Cyrix DLC & SLC CPU's respectively (they had 8kb onboard cache and also came in clock doubler versions).

sliderider wrote:

It is wrong to assume that. The SXL is made to be used with a 386SX motherboard. The DLC is made for a 386DX motherboard.

Could you provide your source which indicates that the PGA-132 Ti486SXL was intended for use in SX motherboards? The Ti486SXL reference guide mentions

The 132-pin PGA TI486SXL and TI486SXL2 are backward compatible with the TI486DLC/E

Ti486SXLC and Ti486SXL - High-performance, footprint-compatible upgrade path for existing TI486SLC and TI486DLC platforms

TI486SXLC series uses 100-pin QFP (486SLC footprint)

TI486SXL series uses 132-pin PGA (486DLC footprint)

I can see why it would be confusing. It was already bad enough that Cyrix tried to fool everyone into thinking their 386 CPUs were really 486s, and then stealing the "DLC/SLC" naming convention from IBM making them hard to distinguish. Then TI came along, stole Cyrix's designs and use a different but equally confusing naming convention...one chip using three different CPU busses with basically the same model name.

I wonder if it is possible that the software I am using to enable the L1 cache will only work properly with the DLC and that certain chipset combinations when using the SXL causes problems with said software. The SXL removed the ability to alter the L1 cache type (2-way or direct-mapped). Perhaps the cache software I am using (cyrix.exe) is trying to write to these cache type bits or probe them in a way which causes the SXL not to function properly. It is a long short, but maybe some of the other L1 enabling problem will work better with the SXL. I have 5 programs in total. Failing that, I will try the NAND gate mode on 1) the CPU's HLDA pin, and 2) the DMAHLDA chipset pin. Any other ideas?

See if you can track down the Evergreen software that came with their 486 SXL upgrade. I wasn't able to find it last time I looked.

Good idea. I'll do a search when all else fails. I do have package called Ti486SXL.EXE.

I may have solved the issue with non-functional SXL cache on this Chaintech 340SCD board. The issue is somehow related to the Gate A20 handler, which I do not really understand well at all.

Some background 1st: Basically, for this board to boot into DOS and load HIMEM, I needed to set the Fast Gate A20 Option to DISABLED in the BIOS, otherwise I get a HIMEM error which reports that it is unable to control the A20 line. This is regardless of whether the L1 cache is enabled or not.

The conditions I was facing were as follows:

486DLC
Fast Gate A20 off, enable L1 cache on 486DLC, Windows 3.11 boots fine.

486SXL
Fast Gate A20 off, enable L1 cache on 486SXL, Windows 3.11 will not boot.

Something in my gut was telling me the issue was somehow related to the Gate A20 Option, but why it affects the SXL and not the DLC, I do not know. I needed to figure out that HIMEM error of not being able to control the Gate A20 line. After a good search, I did some adjustments to my HIMEM command line, however I don't really understand what is going on and why it is needed. https://support.microsoft.com/en-us/kb/96711

In short, if I want to enable Fast Gate A20 Option, I need load HIMEM.SYS (in config.sys) with the following additions:

/CPUCLOCK:ON /MACHINE:1 /V

My config.sys file now looks like:

C:\Windows\HIMEM.SYS /TESTMEM:ON /CPUCLOCK:ON /MACHINE:1 /V

The Ti486SXL now boots into Windows 3.11 without issue. Results of WinTune seem to indicate that the L1 is enabled because there is an increase in Dhrystone from 15.2 (off) to 17.4 (on), a Video increase from 771 (off) to 877 (on), etc. I used the FLUSH method to enable L1 (not BARB). No hardware mod was performed.

After HIMEM loads, I receive this message:

Installed A20 handler number 1,3.
64K High Memory Area is available.

I am not too familiar with how much high memory should be available. Does this sound right?

Can you please make ti486sxl.exe available? I can't find it anywhere.

By definition, high memory is the first 64k after the 1MB boundary.

I've tried the himem.sys flags in the past, and I tried it again just to be sure...it still doesn't help the situation on my OPTI495 board with the SXL.

I will try again with the PEAK/DM board.

ti486sxl.exe as not necessary. That just happens to be one of my half-dozen dlc/sxl programs which mentions the SXL specifically. It mentions it specifically because it has the ability to set the clock doubled mode.

Those Gate A20 flags only seem to be important if you enable "Fast Gate A20" or "Turbo Switch" feature in the BIOS.

I recall there is also a hardware mod you can do to ensure the A20 line is connected properly.

Anonymous Coward wrote:

Can you please make ti486sxl.exe available?

Attached.

It also includes a DMA test program and an Gate A20 test program to test cache coherency. The DMA test was successful, however I received only 3 of 4 passes on the test for the Gate A20. Not sure why. Apparently, if you do not connect the A20M# pin from the chipset or the A20Gate# from the KBC to the A20M# of the CPU, then you need to set the NC0 register bit. I read this in some groups discussion. I haven't looked into it yet.

The software also allows for the ability to activate the A20 pin, the Ken# pin, or setting 1Mbyte boundaries and/or 640KB-1MB as uncacheable. I do not have a clear understanding of which conditions would warrent using any of these settings with respect to getting L1 cache working properly.

Attached is an image of the defaults that my UMC481/482 w/MR BIOS motherboard sets up when the SXL is installed. I don't know why those particular regions are set as non-cacheable. CTCM7 does not report any non-cacheable regions in the 32 MB of installed system RAM. The WinTune results are the same whether or not those non-cacheable regions are set.

Also interesting is that MR BIOS is using the BARB method, which is supposed to be not as efficient as the FLUSH method, however the UMC481/482 supports hidden refresh, so the L1 cache won't be flushing everytime the system RAM is refreshed. In a system which supports hidden refresh, is the BARB method equally as effecient as the FLUSH method for invalidating the L1 cache?

Next I noticed how MR BIOS is enabling the A20M pin. Having this pin enabled causes the A20 cache coherency test to have all 4 PASSES. If I disable the A20M pin, Test #4 fails the coherency test, just as on the SiS Rabbit board.

I manually disabled those non-cacheable regions, disabled A20M, disabled BARB, and enabled FLUSH. The DOOM timedemo results for both the BARB and FLUSH method were nearly identical. BARB = 5471 realtics, FLUSH = 5464 realtics.

Since the BARB method seems fully functional on this UMC board, does that imply that UMC 481/482 uses parallel (look-aside) architecture?