Have you checked the switches according to the linked manual?
Maybe the Fast Post does something?
Intel, Cyrix and AMD behave slightly different, that's why older 486 boards have dozens of jumpers (had tested my 486-collection on a 486PIO3 board several days ago.)

LeFlash wrote:

Do you have an 486dx (33 or 40mhz) for testing?
I can only imagine that there's a problem with the built-in FPU in the DX or later processors.

Just in case I just ordered a dx as they are dirt cheap, but anyone else have any other suggestions? 😕

LeFlash wrote:

Have you checked the switches according to the linked manual?
Maybe the Fast Post does something?
Intel, Cyrix and AMD behave slightly different, that's why older 486 boards have dozens of jumpers (had tested my 486-collection on a 486PIO3 board several days ago.)

Yeah I played with different settings, most seemed to boot just fine with the 486sx that the upgrade board came with. I turned off fast post just in case, didn’t make a difference.

Ok so a quick update - so I installed an AMD AM486 SX2-66 and it worked just fine. I'm waiting on the mail for a few more 486 CPUs (SX2, various Overdrives) to test out.

Does anyone know what the exact pinout differences are between a 486 SX2 and a 486 DX2? Is there an easy way trick the board to think that I am using an SX when actually I'm using a DX? Will update more when I get more to test.

uscleo wrote:

Does anyone know what the exact pinout differences are between a 486 SX2 and a 486 DX2?

http://www.pchardwarelinks.com/486pin.htm
http://www.pchardwarelinks.com/486pin2.htm

This CPU upgrade was explicitely made for a range of IBM PS/2 systems (that's what the -P70 in the model number is -- it was made for the PS/2 model P70 specifically) so you're probably lucky that it even boots at all in your Compaq.

https://stason.org/TULARC/pc/motherboards/K/K … 33PD3-25PS.html

MAYBE you can change the system type to something else and see if that does anything? But as to how to mod this adapter to accept a DX CPU, I have no idea...

uscleo wrote:

Does anyone know what the exact pinout differences are between a 486 SX2 and a 486 DX2?

Well 486 is where Intel started their sleazy sales techniques by manufacturing SX series CPUs with just a tiny pinout difference to prevent it from working in DX socket. The biggest issue is NMI vs IGNNE# - it'll most likely hang the CPU. If you have a non-PC system that doesn't use NMI, chances are it might just work if the pin is tied low and the OS/software uses internal exceptions to handle FPU errors rather than the silly external IRQ that IBM designed. On a PC I guess it would be possible to cut the connections and re-route with wires but I don't recommend testing it on such unique hardware.

EDIT: Oh I only just noticed you want it to work switching from SX to DX. I'd say forget it unless there are jumpers or you have a similar adapter that accepts a DX. The SX socket will most likely not even be wired for external FPU interrupt, and/or the PLD chips around will not route it to the correct pins. And you have no way of knowing which pin on the PLD (if any) is the FERR signal you need to connect. Even if the OS was to handle the FPU exceptions internally, the BIOS code just dies trying to test the IRQ I guess.

Ok so finally some success! It seems like the upgrade module somehow can only handle SX variants and not DX variants, which sadly limits my choices quite a bit.

I’ve gotten it to work the the original intel 486 sx -33, an AMD486 sx2-66 and a intel 486 sx2-50.

However it seems that no matter what cpu I put in, the performance is the same as the original 486sx-33, that is that if I put in the sx2, the computer sees the sx2 and says there is a clock multiplier, But there is no increase in performance. It’s like somehow the clock doubling is not enabled (but I think it’s built in and can’t be disabled?)

See my images showing the sx2 then the performance bar chart showing identical cpu speed to the original sx

Original sx:

Sx2:

Am I missing something here? Shouldn’t the cpu speed rating double? 😕

Deunan wrote:

uscleo wrote:

Does anyone know what the exact pinout differences are between a 486 SX2 and a 486 DX2?

Well 486 is where Intel started their sleazy sales techniques by manufacturing SX series CPUs with just a tiny pinout difference to prevent it from working in DX socket. The biggest issue is NMI vs IGNNE# - it'll most likely hang the CPU. If you have a non-PC system that doesn't use NMI, chances are it might just work if the pin is tied low and the OS/software uses internal exceptions to handle FPU errors rather than the silly external IRQ that IBM designed. On a PC I guess it would be possible to cut the connections and re-route with wires but I don't recommend testing it on such unique hardware.

EDIT: Oh I only just noticed you want it to work switching from SX to DX. I'd say forget it unless there are jumpers or you have a similar adapter that accepts a DX. The SX socket will most likely not even be wired for external FPU interrupt, and/or the PLD chips around will not route it to the correct pins. And you have no way of knowing which pin on the PLD (if any) is the FERR signal you need to connect. Even if the OS was to handle the FPU exceptions internally, the BIOS code just dies trying to test the IRQ I guess.

Yeah I did a little reading and it was soon apparent it’s not just “disabling a pin” or something. Sucks though as they stopped making sx variants early on.

I don't think the SX2 had the CLKMUL pin enabled, but maybe it does? See if pin R17 on the socket is connected to anything - if there are aren't any visible traces also check if it's tied low/high directly to power planes.

Another possibility is the upgrade is badly held back by lack of burst mode transfers. So it'll be very bus-bound. Run CACHECHK to see if you get any actual speedup on memory reads up to 8kB or not.

BTW if you are feeling brave then you can short pins A15 and B15 on the socket with a wire, somehow, or maybe put a tiny wire on the CPU pins, and test a DX CPU. It might just boot and work - until the first unmasked numerical error that is. But perhaps it'll run most DOS programs that don't even touch FPU.

Deunan wrote:

BTW if you are feeling brave then you can short pins A15 and B15 on the socket with a wire, somehow, or maybe put a tiny wire on the CPU pins, and test a DX CPU. It might just boot and work - until the first unmasked numerical error that is. But perhaps it'll run most DOS programs that don't even touch FPU.

But why then use a DX in the first place? The only difference between the SX and DX is the FPU, right?

Correct, but SX series ends with 5V SX2-66 chips, which run pretty hot BTW and are also a bit uncommon. With a DX you could try a 5V DX4 Overdrive from Intel or one of the AMDs with voltage adapter. Might be pointless though seeing how the upgrade seems to be struggling to feed the L1 even on SX2.

Disclaimer: I do have my own horse in this race, I was thinking about doing just that in an FM Towns system.

If the adapter flat out will not work with clock doubling and you absolutely want to make this system as fast as possible, there is maybe a last option:

UMC U5S Super 40. These are 40 MHz parts with SX pinouts. Furthermore, clock for clock they beat the Intel parts. They do exist but are exceedingly rare. This also means you'll have to replace the 33.3 MHz crystal oscillator with a 40 MHz one and pray that it works. 😀

Not so rare here in EU, and in general the SX2-66 is faster than 40MHz U5S, even if not by that much.

U5S pros:
- way lower power consumption than SX2 and even SX chips, thus lower temperature (usually the chip won't even need a heatsink)
- superior to any SX that's not clock-doubled
- fully compatible, a direct SX replacement running at 5V

Cons:
- U5S gets to about SX2-50 performance level at 40MHz, but at 33 (if the clock cannot be changed) the SX2 will be the faster chip, period
- one of the reasons the U5S is so fast is the internals were optimized, and possibly that also includes L1 latency - so if L1 can't be properly fed in this adapter and/or is flushed too often then the perfomance increase will be very small

Deunan wrote:

I don't think the SX2 had the CLKMUL pin enabled, but maybe it does? See if pin R17 on the socket is connected to anything - if there are aren't any visible traces also check if it's tied low/high directly to power planes.

Another possibility is the upgrade is badly held back by lack of burst mode transfers. So it'll be very bus-bound. Run CACHECHK to see if you get any actual speedup on memory reads up to 8kB or not.

BTW if you are feeling brave then you can short pins A15 and B15 on the socket with a wire, somehow, or maybe put a tiny wire on the CPU pins, and test a DX CPU. It might just boot and work - until the first unmasked numerical error that is. But perhaps it'll run most DOS programs that don't even touch FPU.

Ok attached are the board and I've highlighted R17 (the clock multiplier pin) and it's definitely not connected to anything. It also looks like the original socket 1 design doesn't have it connected either according to http://ptgmedia.pearsoncmg.com/images/chap3_0 … nks/03fig13.gif. How do I check to see if it's tied low or high power planes (I have a mulimeter, but not exactly sure how to test if its tied high / low, would be grateful for some pointers on that.

And here's the CACHECHK - it says there's no cache, but it looks like there is, just not for all the tests:

I'm assuming pin R17 needs to be connected to something to enable the clock doubling?
No idea how to interpret the results from CACHECHK - ran them twice, same result.

Deunan wrote:

I don't think the SX2 had the CLKMUL pin enabled, but maybe it does? See if pin R17 on the socket is connected to anything - if there are aren't any visible traces also check if it's tied low/high directly to power planes.

Another possibility is the upgrade is badly held back by lack of burst mode transfers. So it'll be very bus-bound. Run CACHECHK to see if you get any actual speedup on memory reads up to 8kB or not.

BTW if you are feeling brave then you can short pins A15 and B15 on the socket with a wire, somehow, or maybe put a tiny wire on the CPU pins, and test a DX CPU. It might just boot and work - until the first unmasked numerical error that is. But perhaps it'll run most DOS programs that don't even touch FPU.

Anyone second this? Shorting A15 and B15 on a DX? any chance it would damage the upgrade board? Not so concerned about the DX, more so worried about the board.

No SX2 should have CLKMUL and no DX2 either except maybe the later 3V and SL (power management) variants. Disconnect the adapter and test if R17 has low resistance to either GND or VCC (+5V). By low I mean 1k or less, it might not be tied to the power planes directly but rather by a pull-up/down resistor.

If you don't want to experiment you can wait a few weeks, sooner or later I will have the time to try that on one of my PC mobos. Same as you I'd rather not damage a pretty rare and expensive PCB - even though I don't expect any such issues.

As for the CACHECHK result, it's all over the place. My guess would be it's the result of L1 cache being flushed too often. That would also explain lack of any significant speedup in 2x mode. Do you have a "Hidden memory refresh" option in BIOS? Or "Slow refresh" maybe? If so, see if enabling it helps with the results.

So you are thinking that there is some aspect of the Kingston adapter board, perhaps through the PAL's, which is setting latency to that of the front-side bus? Its a long shot, but I suggest trying to use SetMul to enable the L1 cache. On my Transcomputer HPi upgrade module, which allows me to use an Am5x86 at 160 MHz reliably on a 386, the L1 cache appeared to be disabled. Fortunately, I was able to enable it with SetMul and the performance jumped way up.

This is the thread on the 486HPi, 386 upgrade kits and the Transcomputer 486HPi - Am5x86-160 anyone?

The problem with CPU-local cache memory is how to invalidate the entries when DMA is moving data (from FDC/HDD, sound card maybe) to RAM. There's obviously no protocol for that on a 386 since it's not supposed to have cache at all.

Cyrix assigned some unused 386 pins, both on PGA and SX PQFP packages, to new signals that allow maintaining rudimentary cache coherency. But since only newer mobos/chipsets had support for those (like ALI M1217 for SX series), and worse yet some mobos could have the N/C pins actually connected to GND or VCC by mistake, you need to enable those in software. If the BIOS doesn't know anything about Cyrix SLC/DCL-like CPUs, and will not do it at boot time, you have to run a DOS utility yourself. Sometimes you need to do that anyway to work around certain BIOS shortcomings.

The point here is, it's not just the CPU or the interface PCB that decide how well the upgrade will run. It's down to the mobo and BIOS as well. The best case scenario is full BIOS support - then you'll have a decent performance boost. Reasonably well designed mobo with no support can usually match that with some carefuly chosen BIOS settings and DOS utils. But if the mobo doesn't support hidden RAM refresh and is requesting bus hold for each refresh cycle, the perfomance will be bad and you can't do anything about it short of soldering wires and adding some extra logic to try and overcome that.

So you can't just compare the results from different mobos and upgrade kits, it might work great for one person and not at all for another. It's possible to misconfigure the cache settings so badly you'll get performace regression vs the native 386.

I'm assuming pin R17 needs to be connected to something to enable the clock doubling?
No idea how to interpret the results from CACHECHK - ran them twice, same result.

Why do you need to bother with R17 at all? The clock multiplier pin only works on DX4 and 5x86 chips. On the 5V DX2, doubling is always enabled no matter what and the pin goes nowhere.
On the DX4, 5x86 chips if the pin is not connected they will run at either 2x or 3x by default. None of these chips will ever default to 1x clock.

I use a program called DRAM (.exe or .com, I don't recall) to increase the refresh rate from the typical default of 15 us to 40 us. It is adjustable, but I found 40 us to be a good compromise for the AMI Mark V Baby Screamer. Others have found 200 us just fine. Each board will require its own diligence in experimentation.

On my Transcomputer interposer module, no matter which chip I installed and no matter which motherboard I put it in, even in those which have BIOS support for L1 cache, the L1 cache on the transcomputer was disabled. With SetMul, it would turn on. The Transcomputer module has jumpers for DX, SX, etc.

Since he is using an interposer for a standard 486SX, I assume that all the cache software for the Cyrix DLC/SXL/DRx do not apply. What other software can he try?