VOGONS


First post, by feipoa

User metadata
Rank l33t++
Rank
l33t++

I recently obtained the 3.6 V version of the Texas Instruments 486SXL2-66 on a PGA132 inteposer board. I was able to run this chip at 2x40 MHz, instead of the traditional 2x33 MHz, on various motherboards, including those based on the VIA 481/495, UMC 481/482, SiS 310/320/330, CHIPS 351/355/356, and SiS 460 chipset. I would type cyrix.exe -cd and this would set the CPU into clock doubled mode. Confirmation was checked with Landmark speedtest and CHKCPU. Both confirmed it was in clock-doubled mode.

TI486SXL2-G66-HBN.jpg
Filename
TI486SXL2-G66-HBN.jpg
File size
310.95 KiB
Views
1951 views
File license
Fair use/fair dealing exception

Of course, my main motherboard of interest to run this CPU in, an AMI Mark V Baby Screamer based on the VLSI 320/331/332, is the one which causes trouble. I first tested the SXL2-66 at 66.66 MHz using a 66.666000 MHz crystal. It clock doubles just fine as indicated by Larnmark Speed.exe and CHKCPU.exe. I'm attaching a photo of the motherboard below, not because it is needed, but it seems like posts get better attention with more photos. This photo is from user elianda. My motherboard is in the case and I didn't want to take everything apart to snap a photograph.

386babyscreamer.jpg
Filename
386babyscreamer.jpg
File size
1.14 MiB
Views
1951 views
File license
Fair use/fair dealing exception

My trouble starts when I try to run the CPU at 80 MHz. Before acquiring the 486SXL2-66, I would run a SXL-40 in this system, so it is accustomed to using a 40 MHz FSB. Everything works fine with 1540 SCSI DMA and L1 cache in Windows 3.11. Now when I try to clock-double the SXL2-66 CPU to run at 80 MHz using the cyrix.exe -cd command, CHKCPU.exe indicates that the freq. did not change. I ran Landmark's speed.exe and it confirmed that the ALU results are the same as if the CPU is in single-clock mode. How can this be? I tried using Evergreen TI486SXL program to enable the clock-doubling, e.g. 486CACHE.exe /c2, which says it ran just fine. But when I check with CHKCPU.exe and SPEED.exe, the CPU appears to still be in single-clock mode. So why does the 486SXL2-66 clock double with a 33 MHz FSB, but not with a 40 MHz FSB? And why only when placed in the AMI Mark V Baby Screamer motherboard?

I have other oscillators between 66.66 and 80 MHz which I tried. I ran the Baby Screamer with a 70 MHz OSC, so the FSB would be 35 MHz. The CPU clock doubled just fine. CHKCPU indicates that the internal CPU freq. is 79.7 MHz though, not the 70 MHz I would expect. CHKCPU is not always right with these older oddball configurations though. I then ran the system with a 72 MHz OSC, thus an FSB of 36 MHz. The CPU was able to clock-double and CHKCPU indicated that the system is running at 80.1 MHz. Moving up the ladder, I then tried a 74.5 MHz OSC, and the SXL2 would not clock double. Thus, for 74.5 and 80 MHz oscillators, the SXL2-66 would not clock doubled when used in my AMI Mark V Baby Screamer motherboard. Why? What is preventing it from clock doubling and only in this motherboard and at >36 MHz FSB?

Is it just a coincidence that right around where CHKCPU is indicating the freq. to be 80 MHz is where the CPU stops clock doubling? Is there some kind of function built into the CPU which prevents clock doubling if it thinks the FSB is above 40 MHz? Is there a way to tricking the CPU to thinking the FSB is less than 40 MHz? And why is CHKCPU over reporting the FSB? Even with a SXL-40, CHKCPU thinks the FSB is 45 MHz.

This is not the first time I have witnessed odd behaviour like this. If you use a 486SXL-40 with a 25 MHz FSB (or was it 33 MHz, I forget) and try to clock-double it, it just won't clock double. But if you use a FSB less than a certain amount, e.g. 25 MHz, it will clock double. I don't recall which motherboard I witnessed this on. It may have been the Baby Screamer or another one. The point is that the issue is not specific to the 3.6 V of the 486SXL2-66.

The last thing I can think to try is to use the Cyrix DRx2 software as opposed to the two utilities I have already tried. On this forum, http://www.uncreativelabs.net/phpBB2/viewtopic.php?t=922 , I read that the SXL2 can have issues clock-doubling (no specifics given), but it the following was suggested:

I now have TI486SXL2 working properly in clock doubled mode with cache enabled and coprocessor installed. I had to do some goofy things to get this working properly. I used the Cyrix 486DRx2 control software, but instead of using the software frontend I manually programmed the cx486.cfg to configure CCR0 (control register 0) to hex value of 55.

Anyone have any novel (and practical) ideas to try to get this Baby Screamer working at 2x40 with the 486SXL2?

Plan your life wisely, you'll be dead before you know it.

Reply 1 of 21, by Anonymous Coward

User metadata
Rank l33t
Rank
l33t

That post from Uncreative Labs was written by me many years ago before I had a better understanding of the DLC type CPUs. At the time I hadn't read the 486SXL reference manual, and I didn't know that TI switched the function of the CCR0 register that controls caching scheme (direct mapped/two way associated) to enable/disable clock doubling. It wasn't necessary for me to manually edit cx486.cfg. All I had to do in the DRx2 software to get clock doubling was to set the cache type to "direct mapped".

Besides, my problem was very different from what you are experiencing. Although I have had many issues with the SXL chips in my OPTI495 board, getting the doubling function going is not one of them. The problem you describe seems to be fairly common if you look back on newsgroups postings, though generally it was resolved by replacing the FPU with a more up to date model. This is the first time I've heard of clock doubling being frequency independent.

Have you tried disabling the L2 cache or slowing down your memory timings to see if it makes a difference. I am very skeptical there are any timing routines built into the TI chip that test the FSB.

"Will the highways on the internets become more few?" -Gee Dubya
V'Ger XT|Upgraded AT|Ultimate 386|Super VL/EISA 486|SMP VL/EISA Pentium

Reply 2 of 21, by feipoa

User metadata
Rank l33t++
Rank
l33t++

I have confirmed that the Cyrix DRx2 program, cx486.exe w/cx486.cfg, did not solve my problem. A quick side note, though, is that after using the DRx2 program, there is an easy means to enable pipelining, that is, by altering the cc_3 value to 08 in cx486.cfg. Enabling pipeling did not improve DOOM's, nor Landmark's benchmark results and Win311 booted just fine.

I have not tried disabling the L2 cache or slowing the memory timings down, but that is a good idea. There is no option to disable the cache. There aren't any RAM speed options in the BIOS either.

AMISETUP shows nothing hidden of interest. There is almost nothing hidden; the BIOS is just feature limited.

I got a little side tracked. When fishing around for Cyrix SXL programs, I ran across Paul Gortmaker's DRAM.exe program, which allows you to adjust the refresh rate of the DRAM. The motherboard's BIOS doesn't have a hidden or slow refresh option and Paul's file was mentioning that if you need to use the BARB method to flush the L1 cache that standard refresh rates can cause a performance hit. I'm gaining about 100 realtics by setting DRAM to 250-1000 uS. The gain is non-linear, e.g. with 1000 us, I gain 104 realtics, for 500 us, I gain 103; for 250 us, I gain 101 realtics; for 100 us, I gain 91 realtics. I think a 250 uS setting is reasonable to use in this case. Even a DRAM refresh rate of every 1000 us boots Win311 fine and runs WordPerfect, IE, etc.

Back on track, I was trying to find that SXL/DLC/DRx2 utility which had somewhat of a GUI and went through all the register options. I always have trouble finding it in my archive of programs. I thought it was part of the DRx2 software, but I'm not seeing it. EDIT: Think I found it, it is M5B.exe found in CYRIXTST folder.

EDIT: M5B also is unable to enter clock doubling when 74.5 MHz or greater oscillator is used, although it claims that the cache mode is "direct-mapped", which translates to "2x" mode for SXL CPUs.

Plan your life wisely, you'll be dead before you know it.

Reply 3 of 21, by Anonymous Coward

User metadata
Rank l33t
Rank
l33t

Are you sure the screamer doesn't have hidden or slow refresh? Maybe the ability to toggle them is just not available. We really need to get MR-BIOS for this board.

"Will the highways on the internets become more few?" -Gee Dubya
V'Ger XT|Upgraded AT|Ultimate 386|Super VL/EISA 486|SMP VL/EISA Pentium

Reply 4 of 21, by feipoa

User metadata
Rank l33t++
Rank
l33t++

If there is a hidden refresh feature, it isn't listed in the BIOS and its not hidden in the BIOS. The default refresh rate on this board appears to be 15 uS, which is really too frequent for refreshing. I found that if I keep the DRAM refresh rate at 250 uS, I cannot access the floppy drive. Even at 100 uS, there is a large delay at accessing the floppy drive. I found that 40 uS is as high as I want to go to still have decent floppy access time.

My AMIBIOS has a date listed on the sticker of 1991. I noticed a user in this post, Baby Screamer Mark V-ish Boards , has the same board with a date sticker of 1992. I was wondering if his BIOS is updated compared to mine. I sent him a PM to see if he could send me a BIOS image, but no reply.

With further testing, it was revealed that I could only use the grey-top Cyrix FasMath FPU if I wanted to use up to a 72 MHz OSC. The problem with that is that after 5-60 seconds of playing an mp3 file in Win311, the system would hang. This is only an issue when using clock-doubled CPUs; the SXL-40 and the greytop worked fine together. So to get sound reliably working in Win311, I need to use a black top FPU, however 70 and 72 MHz crystal oscillators when using the black FPU won't allow the SXL2 to clock double. I can only use up to 66.666 MHz OSC when using blacktop (or DLC) FPU to enable clock doubling of the SXL2. Weird 'eh? Wish there was a CTCHIP34 config file for this chipset.

Plan your life wisely, you'll be dead before you know it.

Reply 5 of 21, by IanB

User metadata
Rank Member
Rank
Member
feipoa wrote:

My trouble starts when I try to run the CPU at 80 MHz. Before acquiring the 486SXL2-66, I would run a SXL-40 in this system, so it is accustomed to using a 40 MHz FSB. Everything works fine with 1540 SCSI DMA and L1 cache in Windows 3.11. Now when I try to clock-double the SXL2-66 CPU to run at 80 MHz using the cyrix.exe -cd command, CHKCPU.exe indicates that the freq. did not change. I ran Landmark's speed.exe and it confirmed that the ALU results are the same as if the CPU is in single-clock mode. How can this be? I tried using Evergreen TI486SXL program to enable the clock-doubling, e.g. 486CACHE.exe /c2, which says it ran just fine. But when I check with CHKCPU.exe and SPEED.exe, the CPU appears to still be in single-clock mode. So why does the 486SXL2-66 clock double with a 33 MHz FSB, but not with a 40 MHz FSB? And why only when placed in the AMI Mark V Baby Screamer motherboard?

I've been looking at these CPUs recently as I've been working on modding the BIOS for the Toshiba T5200 (see here Toshiba T5200 mods and upgrades )
I've patched the BIOS to auto detect which type of CPU (386 / DLC / DRx2 / SXL) is fitted and then I config the CPU appropriately. I also detect if the A20/flush pins are connected and enable them if appropriate so I've been reading up on the documentation for these CPUs including the TI databook which has the following about clock doubling:

clock.jpg
Filename
clock.jpg
File size
46.82 KiB
Views
1813 views
File license
Fair use/fair dealing exception

So the cpu won't enable clock doubled mode if the phase locked loop won't lock to the doubled frequency. I guess your CPU's PLL won't overclock to 80Mhz in this motherboard so it stays in single clock mode. Most clock doubled CPUs don't have a switching option so they would just fail to overclock but these TI processors have this more graceful failure mode.

This failure looks marginal as you have it working on other motherboards so it likely is down to voltage drop or noise on the CPU supply rails affecting the PLL. You could try extra decoupling caps soldered across the CPU power supply and ground pins and also running thick cables from the PSU header directly to the CPU supply pins. Maybe even trying a different PSU with a slightly higher +5v rail would help.

feipoa wrote:

Is it just a coincidence that right around where CHKCPU is indicating the freq. to be 80 MHz is where the CPU stops clock doubling? Is there some kind of function built into the CPU which prevents clock doubling if it thinks the FSB is above 40 MHz? Is there a way to tricking the CPU to thinking the FSB is less than 40 MHz? And why is CHKCPU over reporting the FSB? Even with a SXL-40, CHKCPU thinks the FSB is 45 MHz.

Yes I think it's just a coincidence that the overclock stops when CHKCPU reports 80Mhz. The reason some programs over report the CPU frequency on Cyrix CPUs is that they assume the instructions used to determine CPU frequency excute in a certain number of clock cycles based on the time taken by Intel CPUs and the Cyrix ones execute some instructions in fewer clock cycles so they appear to be running at a higher frequency unless the CPU timing program is aware of Cyrix CPUs and compensates accordingly.

Reply 6 of 21, by feipoa

User metadata
Rank l33t++
Rank
l33t++

For Cyrix DLC/SXL support, I read an old document by Ernie van der Meer stating that the PGA132 pins should connect to the motherboard as follows:

ADS# - pull-up to Vcc thru 10K
LOCK# - pull-up to Vcc thru 10K
A20M# - connection to Gate A20 on KBC
FLUSH# - NAND IC for hardware-based cache invalidation (two circuit types, 1 for systems with serial secondary cache, the other for parrallel secondary cache).

MEMW# on ISA slot connects to the NAND IC, as does HLDA from CPU (for serial) or HLDA from cache controller (for parallel). My SiS Rabbit board needed the parallel type connectin.

I don't know to what extent all of these connections are necessary. I've found boards which do not have the hardware flush circuit connected, however enabling the FLUSH# pin in software works just fine.

On most, LOCK# is not connected. On some, ADS#, LOCK#, and A20M# not connected, yet the board seems to invalidate fine with just the hardware flush circuit. On the board in question, the AMI Mark 5 Baby Screamer, A20M# on the PGA-132 is not connected to Gate A20 of the KBC, but is connected directly to VCC. I'm not sure why the difference. Could it be causing my issues at 80 MHz? Doubtful.

Thank you for provided the caption from the databook. There certainly is some funny business going on with the internal PLL and its detection scheme. What I can tell you is that the AMI Mark 5 Baby Screamer is in a case and uses a different PSU compared to all the other motherboards I tested in conjuction with the TI486SXL2-66. So perhaps there is an issue with the voltage levels. I know that this particular motherboard's PSU had two bulging caps and one exploded cap in it from 7 years ago. I did replace the caps 7 years ago, but with used ones because, at the time, I didn't have anything else of the right size and capacitance/voltage. I have not checked the PSU in 7 years for issues. To rule out the PSU, I guess I should really swap out the PSU and try again (a hassle!). I could also measure the voltage and ripple of Vcc on the PGA-132 with multi-meter and scope.

For decoupling capacitors under the PGA-132, what capacitance do you recommend? Any configuration in particular, e.g. 10 V, tantalum/ceramic/niobiumOxide?

Plan your life wisely, you'll be dead before you know it.

Reply 7 of 21, by IanB

User metadata
Rank Member
Rank
Member
feipoa wrote:

For decoupling capacitors under the PGA-132, what capacitance do you recommend? Any configuration in particular, e.g. 10 V, tantalum/ceramic/niobiumOxide?

I suggest 10n or 100n ceramic caps although they might not have that much effect as the CPU is 3.3V and the adapter board will have it's own regulator and decoupling. You could also try extra decoupling on the adapter board itself if it's easy to fit. The motherboard might be noisier overall compared to the other ones which would affect all signals going to the CPU so may need extra decoupling all over but trying a different PSU is definitely worthwhile as I have seen some later motherboards vary in stability even at stock speeds depending on the PSU used (the PSUs weren't specifically faulty and worked with other motherboards, they probably varied in noise levels and the exact value of the +5v lines)

This was some decoupling I added to my T5200 when investigating stability issues:

decoupling.jpg
Filename
decoupling.jpg
File size
939.92 KiB
Views
1785 views
File license
Fair use/fair dealing exception

Reply 8 of 21, by feipoa

User metadata
Rank l33t++
Rank
l33t++

That's a good point, I don't think I can improve upon the upgrade module's VRM and onboard decoupling - everything on there is really close together. I also don't want to modify such a rare upgrade CPU. Maybe I will add components to the MB though. I'll swap out the PSU first. I have 2 or 3 more AT PSU's and about fifty (50) P4/Athlon era PSU's and an AT adapter.

What symptoms were you having on your motherboard such that adding those decoupling caps fixed?

You seem to be interested in 386 upgrade modules. Have you seen this thread: Custom interposer module for TI486SXL2-66 PGA168 to PGA132 - HELP! Perhaps you have some ideas as to how to get it running?

Plan your life wisely, you'll be dead before you know it.

Reply 9 of 21, by IanB

User metadata
Rank Member
Rank
Member
feipoa wrote:

What symptoms were you having on your motherboard such that adding those decoupling caps fixed?

I was getting random freezes with windows NT (Dos / Win95 were OK). That decoupling helped and I also added an electrolytic close to the CPU but although it reduced the problem it didn't fix it entirely. I eventually found that adding some more electrolytic decoupling (2x 100uF) close to the RAM on the RAM expansion board fixed it entirely.
These freezes are caused by Windows NT using the HLT instruction to halt the CPU when there is no activity. As a result the CPU stays cool when idle but the current demanded by it varies considerably depending on whether the CPU is executing code or in the halted state and this introduces variation in the +5v level if the PSU can't cope with the rapid changes in loading. This ripple is at relatively low frequency so needs large value low ESR electrolytic decoupling to fix.
This problem only happened with the TX486SXL, not the DRx2 or DLC as presumably the SXL has a greater variation in current demand due to the larger cache. (it certainly runs hotter so must need more current when loaded)

feipoa wrote:

You seem to be interested in 386 upgrade modules. Have you seen this thread: Custom interposer module for TI486SXL2-66 PGA168 to PGA132 - HELP! Perhaps you have some ideas as to how to get it running?

Yes I have seen that thread, the long leads which vary in length probably introduce crosstalk and skew into the signals but at a minimum you need to add a lot of decoupling (10n & 100n) between the CPU power pins and ground as close to the CPU as possible.

Reply 10 of 21, by feipoa

User metadata
Rank l33t++
Rank
l33t++

Which version of NT are you using? Were you able to view the low freq. ripple on the SXL's Vcc to Vss pins on a scope?

Concerning the PGA168 to PGA132 interposer, I did try adding a few extra decoupling caps to the interposer in two locations, but the symptoms persisted. There may be more on this in the vintage computer forum (I have two postings). So are you recommending I do what you did and solder as many ceramic caps to the bottom of the CPU to which ever are the closest Vcc to Vss pins? I can certainly do that. How do you determine which pins get the 100n and which get the 10n? How much ripple is acceptable? What was the freq. and amplitude of the ripple you just suppressed on your system? I can probe various Vcc and Vss pins with the scope.

Plan your life wisely, you'll be dead before you know it.

Reply 11 of 21, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++

Would all (or most of) the lines be parallel with no or few exchanges in orientation? If so, spinning a small double sided board might be inexpensive and straightforward. The random orientations of jumper wire probably generate a lot of cross talk. Proper perpendicular crossing (when necessary) should significantly reduce that, and at this scale that's easiest with a PCB.

I doubt skew is that significant a problem as propagation distances for copper wire will be on the order of 0.5m per cycle for a typical 386. You'd probably have to worry about propagation delay for faster CPUs, though.

All hail the Great Capacitor Brand Finder

Reply 12 of 21, by feipoa

User metadata
Rank l33t++
Rank
l33t++

You can view a photo of it here, Custom interposer module for TI486SXL2-66 PGA168 to PGA132 - HELP! Some groups are parallel, other groups are parallel, some cross, its a mess. I took the shortest route possible while keeping the prototype board as small as possible. Unfortunately, I do not have time to teach myself how to create and design a PCB at this time. Life keeps getting more and more noisy. But if someone else wants to, that would be great. I'm doubtful that a double-sided board could be realised for the small foot-print I envision. Ideally, I'd like to do what this SXL2-66 upgrade module did, with a straight-up approach, rather than a side-by-side approach as shown in the prototype.

How do you have proper perpendicular crossing on a PCB?

Plan your life wisely, you'll be dead before you know it.

Reply 13 of 21, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++

Different layers, or possibly with a metal link, just as you'd expect. Building wiring trays for something that small would be a bit of a challenge, I think.

All hail the Great Capacitor Brand Finder

Reply 14 of 21, by IanB

User metadata
Rank Member
Rank
Member
feipoa wrote:

Which version of NT are you using? Were you able to view the low freq. ripple on the SXL's Vcc to Vss pins on a scope?

I was testing with NT4. I didn't view the ripple on a scope.

feipoa wrote:

So are you recommending I do what you did and solder as many ceramic caps to the bottom of the CPU to which ever are the closest Vcc to Vss pins? I can certainly do that.

Yes, to reduce high frequency noise, the decoupling has to be as close to the Vcc and Vss pins as possible (i.e. soldered to them in this case)

feipoa wrote:

How do you determine which pins get the 100n and which get the 10n?

For best results, put them in parallel, in theory the 10n will be better at reducing the highest frequency noise and the 100n slightly lower frequency noise.

feipoa wrote:

How much ripple is acceptable? What was the freq. and amplitude of the ripple you just suppressed on your system? I can probe various Vcc and Vss pins with the scope.

I don't think your problem is the same as mine. I think your issue is likely high frequency noise on the supply to the CPU (assuming no other problems like incorrect wiring or signals that need processing with some extra logic), my issue was likely low frequency variation in the +5v line caused by the HLT instruction (something in the low Khz range) which is why my issue was ultimately fixed with electrolytic decoupling. There is no guarantee that adding lots of decoupling will fix the problem but it is certainly worth trying.

Reply 15 of 21, by feipoa

User metadata
Rank l33t++
Rank
l33t++

IanB, to confirm, your very last paragraph is in response to the PGA168 to PGA132 adapter? I'm going to be putting a digikey, mouser, or whomever electronics order for some ESD foam, so I can add this on if I don't already have 10n and 100n caps. I'll have to look first. Is there anything else you might think I should order to add to the PGA168 to PGA132 adapter? I'm pretty sure I don't need any extra logic - it seems to work at 4 MHz!

Unfortunately, I still haven't had time to get to changing the PSU on my Mark V Baby Screamer setup. Actually, I should pull that PSU out and order all new caps for that PSU. That PSU is original from 1992 and it came with the case.

Plan your life wisely, you'll be dead before you know it.

Reply 16 of 21, by feipoa

User metadata
Rank l33t++
Rank
l33t++

Attached is an image of the inside of my 386's PSU. Do you normally replace those giant high-voltage caps (200V)? What about the others?

Inside there are,
2x 330uF at 200V
2x 471uF at 25V
2x 1000uF at 25V
2x 2200uF at 25V

The smaller ones are,
1x 47uF at 50V
1x 3.3uF
5x 1uF

Attachments

  • 386_PSU_Caps.jpg
    Filename
    386_PSU_Caps.jpg
    File size
    744.74 KiB
    Views
    1668 views
    File license
    Fair use/fair dealing exception

Plan your life wisely, you'll be dead before you know it.

Reply 17 of 21, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++

The bulk caps withstand much less stress than the others. If you have an SCR meter, you can pull and test them, but I doubt they'll need replacement.

All hail the Great Capacitor Brand Finder

Reply 19 of 21, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++

For reconditioning, I'd replace everything but the (200V, 330uF) bulk caps. I might even replace those if I can find a good price for caps that size, although that's gilding the lily somewhat.

If you can, I suggest measuring ripple and transient response to see if the caps even require replacement.

All hail the Great Capacitor Brand Finder