Cyrix DLC (and SLC) Processor Configuration Utility =================================================== ***************** *IMPORTANT NOTE:* This package contains subdirectories! If you used ***************** "pkunzip" to unpack it, and did *not* use the "-d" option, then FILES WILL HAVE BEEN OVER-WRITTEN! Delete everything (except for the zipfile!) and Start again with the "-d" option, or use "unzip" instead, as it automatically creates stored subdirs. Introduction: ============= This program is to be used to set the Cyrix specific registers on the DLC and SLC line of 386 pin compatible CPU's. If you have a "Cyrix aware" motherboard, then you may not need this. This is intended for those users who have replaced an existing 386DX/SX chip with a Cyrix (or Texas Instruments) 486DLC/SLC chip. These chips have 1 kb of internal cache, which is disabled by default on power-up. Either the BIOS (hence the "cyrix aware" motherboards) or the user must enable this cache to get maximum performance from the chip. (Note that users who have either a Cx486DRu2 or a Cx486DRx2 or the SX part Cx486SRu2 can also make use of this program, as these are essentially DLC/SLC based parts. See the section "More Information:" regarding these parts.) Note that the chip that IBM is presently selling as a "slc" is entirely different, and this is of no use for that chip. The FLUSH input: ================ However, there is more to it then just "enabling the cache". The cache holds a small part of the sytems memory in close reach to the CPU. But during DMA (Direct Memory Access), things like floppy drives can access the systems memory directly, and hence the image of the system memory stored in the cache memory is no longer up to date. As you can guess, this can lead to memory corruption, especially if the cache memory (with "old" data) is written back to the system memory. So, to get around this, the Cyrix DLC has a FLUSH input, which (if enabled) will flush (i.e. invalidate) the cache contents after a DMA event. The BARB input: =============== But on most old 386 boards the FLUSH pin is not respected. So what now? Well, there is another input: the BARB input. This input is raised when the CPU enters a HOLD state, which happens when a DMA transfer occurs. *But* it also is raised on every memory refresh, which is 15us (microseconds) by default. (Your memory forgets what it is remembering unless you give it a jab (refresh) every so often.) This means that you will be dumping the cache contents *all* the time, and it will slow performance. This is your only choice though, if your motherboard does not respect the FLUSH input. However, there is a work-around. Some motherboards have a BIOS option "Slow Refresh", which changes the refresh from 15us to a more reasonable value, like 120us. (The "standard" of 15us was set in the XT days when memory was pretty poor quality. Todays DRAM chips on SIMM memory are capable of having a refresh only once every 500 --> 1000 us or more.) Even if your BIOS does *not* have this option, you can sometimes change the time period of the refresh timer via a simple DOS program. I have written such a program and included it in the DRAM subdirectory, so you can use it, if required. You will know when you have exceeded a reasonable refresh time for your memory, as you will get NMI's (Non Maskable Interrupts) which will report "parity errors" meaning that your memory is starting to forget stuff. Changing the period of the refresh timer is an old trick used by the speed hungry since "way back" in the XT days, to get up to a 5% speed increase for free. More details can be found in the "readme" in the "DRAM" directory. Using the Program: ================== The cache is activated by default, *but* the first non-cacheable region is set from 0x0000 to 4 Gigabytes, which is the *entire* memory space of the PC. (32 bit --> 2^32 = 4*1024*1024*1024 = 4 Gb) So, as you can see, the cache is effectively disabled. (Cache activation is controlled by the 486 specific 32 bit register called "cr0" which is usually set so that the cache is enabled.) Most users can enable the cache on their machine by simply using cyrix -i1 -f This inhibits non-cacheable region one, and enables the flush input. You can see what you have done by typing: cyrix -q which will display the present configuration of the Cyrix chip. Here is the entire list of options. Things in "[]" are optional and change the effect of the command. An optional "-" will invert the behaviour of the switch. Option Action ------ ------ -a[-] Enable [disable] A20M input. -b[-] Enable [disable] BARB input. -c[d] Two way assoc. [direct-mapped] cache. -d Raw dump of control registers and exit. -e[-] Enable [disable] 1k cache via CR0. -f[-] Enable [disable] FLUSH input. -h Print this help screen and exit. -i Inhibit non-cachable region , where n={1,2,3,4}. -k[-] Enable [disable] KEN input. -m[-] Enable [disable] cache of 1st 64k of each Mb. -o Override check for existence of Cyrix DLC chip. -p Disable all power saving modes. -q Query DLC configuration status and exit. -r[-] Disable [enable] cache of 640k -> 1M ROM shadow area. -s[-] Enable [disable] SUSP i/o. -v Print version number and exit. -x, Don't cache kb from segment . Examples: ========= cyrix -i2 -i3 -i4 -r -cd -f- -b -k- -e -xCC00,16 This sets the first non cacheable region starting at CC00:0000 and with a size of 16kb. The other 3 non-cacheable regions are set inactive. The 640k --> 1Mb RAM area is not cached. The cache mode is set to direct- mapped. The flush input is disabled and the barb input is enabled. The ken input is disabled, and the 1k cache is set active via the CPU register CR0. cyrix -e- This turns off the 1k internal cache via the CPU control register 0. cyrix -x0000,4Gb This disables the 1k internal cache by setting all of the PC's memory space as non-cacheable. This is like the configuration you get when you boot up with a motherboard that isn't "Cyrix aware" cyrix -xc000,4 -xd000,8 -xE000,32 -xF000,64 This sets four non-cacheable regions of various sizes. Note that the hex address can be upper or lower case. Note that the size must be one of 4,8,16,32,64,....16384,32768, or 4Gb cyrix -q This tells you what the present state of affairs is with the Cyrix chip. It doesn't modify anything. It does probe to see if there is a Cyrix in the machine though. Installation: ============= There are two "cyrix.exe" programs. One is compiled with tools from Microsoft, and the other with tools from the Free Software Foundation (i.e. gcc, gas, etc.) -- they can be found in the sub- directories .\src_ms\ and .\src_gcc\ respectively. I suggest that you use the one in the .\src_ms\ directory, as it: 1) is smaller 2) uses some hand optimized assembly 3) does not need any special attention for machines witout a 387 4) does not get tripped up by the broken HIMEM.SYS from MSDOS v5.0 You can tell which one you are using, by the "-v" or the "-h" option, as the version number will be followed by either a "msc" or a "gcc". More information can be found in the following section, "The Source". Decide on a final resting place for the program, and copy it there. Edit your autoexec.bat file, and add the line: c:\mydir\cyrix -i1 -r -f Of course, use the options that work best for your computer. These are just typical ones. Locking/Crashing the Machine: ============================= This program does low level communication directly with the CPU via assembly language. You can lock up your computer by using an option that is not supported by your hardware, or cause a crash by memory corruption through cache incoherency. Note that this does *not* mean that there is a bug in the program. For example, if you use the FLUSH input, and your computer does not behave properly, then your motherboard does not support it, and you will most likely need to use the BARB input. Other Notes: ============ In most cases, the use of "-e" will not be needed, as the cache will already be enabled via CR0, but disabled via NCR1. You can find out what state your BIOS leaves the DLC in by running with the "-q" option before doing anything else. The power savings features require a motherboard that can make use of the power saving output pins of the Cyrix chip. Most m/b don't have any, so the "-p" option sets it to the default, which is to leave the Cyrix power savings pins floating. There is no special code included to do anything else, and I don't have any documentation that describes them either. A 40MHz DLC part should get 129 on Landmark v2.00 -- the 33MHz part should get about 108. For comparison, an intel chip gets about 110 at 33MHz, 134 at 40MHz and about 167 at 50MHz. Use your favourite benchmark to make sure it is enabled. ;-) The check for a DLC/SLC chip is done by observing the behaviour of the undefined flags after a div. This works to differentiate between an intel and a cyrix *DLC* chip. However, with all the new chips that cyrix is making, this may falsely recognise one of the new 486DX pin compatible chips as a DLC. I don't know. Besides, you *should* know what CPU you have. If the flag test fails on your machine, but you are *sure* there is a DLC part in there somewhere, use the "-o" switch. Again, I don't know if the flag test will sort out an AMD or an IBM 486SLC/66 chip from a cyrix chip either. The Source: =========== Yes, the source *is* included! (Unlike most DOS junk.) And to top that, there is *two* source trees. One is for use with Microsoft's C/C++ v7.0 and Microsoft's MASM v5.1. And for those who don't have access to Microsoft's wonderful (*cough*) development tools, the second source tree is for djgpp - a *free* c compiler available for ftp. The directories are .\src_ms\ and .\src_gcc\ respectively. I would imagine that porting the Microsoft source tree to Borland's C/C++ and TASM would be a trivial job. Feel free to go for it. Warranty: ========= This program/package and everything contained in it come with *NO WARRANTY* either expressed or implied. This includes, but is not limited to, the implied warranties of merchantability and fitness for a particular purpose. The entire risk as to the quality and performance of the program/package is with you. Should the program/package prove defective, you assume the cost of all necessary servicing, repair, correction, and any other related expenses. Copying: ======== Some of the assembly language portions of this program were shamelessly swiped from the UNIX SYSV driver written by Ti Kan, and then GNU-ified for GNU-as. And the MASM versions were based on this also, although they had to be changed from AT&T assembly syntax to intel syntax - ugh. Anyway, in keeping with his copyright, it is included here: /* * cx UNIX(tm) System V/386 driver to control the Cyrix(tm) * Cx486DLC/SLC CPU internal cache. * * by Ti Kan * E-mail: Internet: ti@amb.org * UUCP: ...!decwrl!sgiblab!bazooka!ti * ...!uunet!bazooka!ti * * Copyright (c) Ti Kan 1993, All rights reserved. * * This software can be distributed freely. This software, * and software based on or that uses code from it cannot * be used for commercial purposes without consent of the * copyright holder. This copyright notice must appear in * all products that is based on or uses code from this * software. */ Everything else here is Copyright (c)1994 Paul Gortmaker, and are released to the public under the terms and conditions of the GNU General Public License, version 2 or newer, at your discretion. This means you can upload it to your favourite BBS, give a copy to your friends and enemies, or even print it out and line your cat's litter box with it. Bugs: ===== I'm sure there are some. However, I'm not sure I *really* want to know about them. :-) You can reach me at "paul.gortmaker@anu.edu.au" if you find a bug. I prefer bugs accompanied with context diffs that fix it. (Don't we all?) Silly questions that are answered in the readmes will silently be ignored. More Information: ================= There is a file available for anon. ftp called "CxPatch.tar.z" which is to enable the 1k cache when you are using the Linux (a free UNIX variant) operating system. In this "gzip"ped tar file, there is a "README" file that contains more info on the registers that the Cyrix chip uses, and info on the Cyrix chip as well. Also, there is the sysV driver mentioned above, which was posted to the "alt.sources" usenet newsgroup on March 16/93 and should be available on usenet archives. There are some OS/2 drivers floating about under the name "cyrix.zip" here and there. Your local archie server should be able to help you find any of the above. And there is the Cyrix BBS as well. The phone number can most likely be found in the BBS phone list posted to one of the comp.sys.ibm.pc newsgroups. Have fun, Paul. ------------------------- Microsoft, Borland, Cyrix, GCC and the FSF are trademarks of their respective companies. (I hope...)