Is A20M# only required when using the BARB method?

When I use the FLUSH method, I still need to enable the A20M pin using software to avoid that failing mark from the A20M_TST program. Do you have CYRIXTST.zip?

Yes, I am pretty sure I have the test software already.
It doesn't look like the A20M pin on my 386 socket is connected to anything. Where does yours go?

I did not look to see where it goes, but I did check to see if the A20M pin on the KBC went to the A20M pin on the 386 socket; it does not, neither on the SiS Rabbit, nor the UMC-based board. One document I read says that these two points should be connected together, and if not, then the NC0 CCR0 bit must be enabled. I do not understand this comment becausxe the NC0 bit is the non-cacheable at 1 Mbyte boundaries register bit. MR BIOS on the UMC board is not enabling the NC0 bit as far as I can tell and the L1 functions fine.

A quick update to this thread. I implemented the NAND gate modification shown on page 1. The only thing it did was made it so that I did not need to use software to enable the FLUSH pin. It is still necessary to use software to set region 1 as cacheable. I ended up needing to soldering to the DMAHLDA pin on the SiS 85C320 pin as the HLDA pin on the chipset is the same one as on the CPU. I first soldered to the HLDA pin on the CPU, however I witnessed hanging in the DOOM timedemo. From these outcome, I suspect the L2 cache controller on these SiS 310/320/330 boards is of the serial (look-through) architecture.

feipoa wrote:

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.

Could you post the A20 and DMA test software as it wasn't included in the floppy image and I'm looking for a copy of them (especially the A20 one) as I'm modifying my Toshiba T5200 to work with a TI486SXL2 and I need to check that the A20 is working OK with the cache.

Actually, I found that the A20 and the DMA floppy test weren't entirely conclusive. A better test seemed to be loading HIMEM, using cachechk, read/writing to the floppy drive, and testing the sound card. For the latter two tests, confirm this in both DOS and Win3.11.

Also, the SXL chip works best with a DLC version of the FPU. If you can't get your sound working in Win 3.11, e.g. with wave and mp3 playback, then swap the FPU for a DLC variant.

I will look for those DOS tests later today or tomorrow, however it was my experience that they are not very conclusive.

Attached are the test files for DMA and A20.

feipoa wrote:

Attached are the test files for DMA and A20.

Thanks, The A20 test does seem to behave a bit randomly. It also hangs after running the test on my T5200 even with caching disabled. I'll investigate further.

Which part numbers do you recommend for a 387 co-processor for the TI486SXL2 and also the CX486DRx2?
I have some IIT XC87DLC-33 chips which seem to work OK with the DRx2 but won't work with my CX486DLC which is an early one. (Not tried with TI chip yet)
Any experience with the CX-83D87-33-GP?

I found some technical info on how the DRx2 handles cache flushing:
https://www.google.com/patents/US5724549
This is actually the patent for the Cyrix "Flush board" which was a PCB with several chips that sat between the processor and the motherboard to generate the flush signal but the same or similar circuitry was later incorporated into the DRx2. It seems to flush the cache whenever certain interrupts, memory locations and I/O locations are accessed. I wonder if some of the undocumented bits in registers C2 and C3 will disable these features and turn it back into a regular DLC as it might perform slightly better if the correct A20 and Flush signals are available.

If I recall correctly, you will have problems with the SXL2 or DRx2 in 2x mode if using a grey-top Cyrix 83D87. In such a configuration, I believe the computer crashed with sound access. I will check my notes later today to confirm exactly what problem occurred. It is best to use a black-top Cyrix 83D87-33 or Cyrix 87DLC. I have not checked to see which IIT or ULSI FPUs have the same problem with the SXL in 2x mode, but the Cyrix FPUs are faster so it seems only natural to use them.

I have not seen the information in that patent document. Thank you for sharing it. I would like to read it in detail sometime. It certainly provides a lot more information than what is in the little section of the Ti manual for implementing the flush circuit.

I see you are upgrading a Toshiba laptop. Not many of that around here. Does the laptop have a heatsink or heatsink fan on the CPU? If not, is there space for one? This CPU gets really hot and should really have at least a heatsink on it, especially in a confined area like a laptop.

The flush board you are referring to came as part of the Cyrix DRu package. I believe that board could also be used as a clock doubler. The kit came with a regular DLC-40 CPU.

Interesting. So the clock doubling was on a PCB and not inside the CPU package? Any advantage of the DRu2 over the DRx2?

In my opinion it is much more interesting to have a separate clock doubling circuit so that you can use it with different types of CPUs (assuming that actually works). Let's say you fry your cache overclocking a DLC-40, you can can toss the CPU and try another. DRx2s are by comparison pretty rare and not nearly as as cheap. On the other hand, the DRx2 is supposed to have other enhancements like pipelining which make them a little faster.

Well I got the TI486SXL2 working on my T5200 with DMA cache flushing and a20 gate support.
Here's a photo of the mods:

The blue wire is the A20 gate and the yellow ones plus the IC are the recommended flush circuit from the TI486SXL2 databook (wired for serial cache).
I also had to patch the BIOS to switch the cache off on a warm restart as it was messing up the BIOS initialisation code.
I'm still not 100% convinced about the A20gate but if I disable the input, HIMEM complains which seems to indicate it's doing something.

feipoa wrote:

I see you are upgrading a Toshiba laptop. Not many of that around here. Does the laptop have a heatsink or heatsink fan on the CPU? If not, is there space for one? This CPU gets really hot and should really have at least a heatsink on it, especially in a confined area like a laptop.

Well it isn't really a laptop, just a 20lb luggable with an orange gas plasma display (I've seen it described as a lap-crusher!). There is enough space to add a heatsink and it seems to be stable.

feipoa wrote:

If I recall correctly, you will have problems with the SXL2 or DRx2 in 2x mode if using a grey-top Cyrix 83D87. In such a configuration, I believe the computer crashed with sound access. I will check my notes later today to confirm exactly what problem occurred. It is best to use a black-top Cyrix 83D87-33 or Cyrix 87DLC. I have not checked to see which IIT or ULSI FPUs have the same problem with the SXL in 2x mode, but the Cyrix FPUs are faster so it seems only natural to use them.

Did you confirm what the issue with the grey-top FPUs was. Would any black-top do or do they have to be manufactured after a certain date?

The CPU certainly runs faster than the DRx2 but not spectacularly so. e.g. the Doom timedemo is only about 10-15% faster but that's probably because the slow screen access is a limiting factor. Simple benchmarks show little or no difference because their test loop is small enough to fit in the cache on both processors.
Any other benchmarks you would recommend?

Did you first confirm that you needed the Flush circuit as described in the TI SXL2 databook? On all the boards I tried, it was not needed, though adding it didn't make things worse. On one board, I remember that adding the Flush circuit just meant that I did not need to use software to enable the FLUSH pin.

When you say that you rae not entirely convinced about the A20gate and that if you disable the input... Do you mean that when you do not enable the input with the Cyrix.exe software? or do you mean if you disconnect the A20M wire going to the KBC?

Well, I only have one black top FPU, but I sorta recall that all the black tops should be the same. My tests revealed that I could use a black top Cyrix FasMath, or a Cyrix 87DLC.

In my notes I have that grey-top Cyrix FasMath FPU when combined with SXL2 or DRx2 will cause Winplay in Win3.11 to hang. It also causes PCPBench not to exit properly. It gets to 99% finished, then trys to exit and hangs up. These problems correct themselves with a black-top FasMath.

Recently, I have been trying to get an IBM BlueLightning BL3 working, but it is having issues with the A20 handler.

The best I have achieved with DOOM and the SXL is 18.4 fps. If I can get the BL3 working, it will surely be over 20 fps.
For benchmarks, you can try 3dbench, pcpbench, Landmark, Roy Longbottom's Dhrystones (e.g. dhry1od.exe) and Whetstones (e.g. whetcod), cachechk v7, Sysinfo 8, and some circuit analysis program for FPU testing called CABT. Since I do not have a lot of FPU-targeted programs, I also run Quake. I have achieved 3.1 fps thus far.

feipoa wrote:

Did you first confirm that you needed the Flush circuit as described in the TI SXL2 databook? On all the boards I tried, it was not needed, though adding it didn't make things worse. On one board, I remember that adding the Flush circuit just meant that I did not need to use software to enable the FLUSH pin.

Yes without the flush mod, it failed the Cyrix floppy DMA test and it wouldn't even boot an MSDOS floppy. It did work if I enabled the BARB bit but I looked at the Hold pin on the processor with an oscilliscope and as well as being pulsed on floppy access, it was also pulsed every time there was a cache miss and a DRAM refresh was ongoing so the cache was being flushed every few milliseconds. Looking at the output of the flush mod circuit with an oscilliscope, that only pulsed on floppy access and presumably any othe DMA access.

feipoa wrote:

When you say that you rae not entirely convinced about the A20gate and that if you disable the input... Do you mean that when you do not enable the input with the Cyrix.exe software? or do you mean if you disconnect the A20M wire going to the KBC?

Both, they effectively do the same thing. It's just that I couldn't get it to pass the A20 Cyrix test software you posted although it did pass the HIMEM.SYS tests but I think I'll write my own just to be sure.

It's now booting 16+ operating systems off an 8GB compact flash:

Nice work! Yes, using the BARB method does produce slightly lower benchmark scores. If a motherboard's BIOS has it enabled by default, I usually turn it off.

feipoa wrote:

I first soldered to the HLDA pin on the CPU, however I witnessed hanging in the DOOM timedemo.

One thing I forgot to mention, when I first got my 486SXL2 working it would randomly freeze in windows NT4, always at similar points during bootup or shutdown but this didn't happen when the cache was disabled. After a lot of experimentaion I noticed that the PSU has a slight inductor whistle which changed pitch at times when the freeze occurred. The pitch change is due to varying current load and the only thing that has significantly varying load like that is the CPU (no HD as I use compact flash) so I theorised that when the cache was enabled and the CPU was running at full speed from code in the cache that it was causing momentary spikes on the supply rails. I added a few 100n capacitors across the +5v line by the CPU and this improved things but it wasn't fixed until I added a 1000uF capacitor as well. That was probably overkill but it shows that random freezes may simply be decoupling issues rather than cache coherency as the motherboards weren't designed for that CPU.

1000 uF does sound like a lot. Is the only drawback the capacitor charge time? Did you experiment with values between 100 nF and 1000uF? It would be kinda neat to determine the min. value capacitor needed the correct the hanging issues.

I find that Windows NT 4.0 is a really good OS to test for stability. A lot of instability makes it way past Win9x.

Personally, I have never attempted NT 4.0 on my 386 systems, but I suppose it would be sorta unique to have a dual boot environment with Win 3.11 and NT4, or NT 3.5.

I am still working on getting the BL3 working, though it is not looking very promising. It is having issues with loading HIMEM because it cannot control A20, but only when the L1 cache is enabled.

I also have some 55 Mhz and 60 MHz crystal oscillators which I might try out on the SXL2. 55 Mhz might be a realistic overclock for that chip.

IanB wrote:

It's now booting 16+ operating systems off an 8GB compact flash:

boot.jpg

Would be neat to add OS/2 as well.

feipoa wrote:

1000 uF does sound like a lot. Is the only drawback the capacitor charge time? Did you experiment with values between 100 nF and 1000uF? It would be kinda neat to determine the min. value capacitor needed the correct the hanging issues.

It would make the rise and fall times of the +5v a little slower, I'll probably replace it with something smaller but I wanted it to have a significant effect first to make sure it was going to fix things.

feipoa wrote:

I find that Windows NT 4.0 is a really good OS to test for stability. A lot of instability makes it way past Win9x.

Yes I'd heard that in the past as well, there seemed to be no issue with the other operating systems.

feipoa wrote:

Would be neat to add OS/2 as well.

Yes and the Digital Research ones as well.
I'm thinking of writing a tutorial on how to setup such a multiboot system as I've found workarounds for so many limitations on booting old versions of DOS/NT in this way that don't seem to be documented anywhere else.