red-ray wrote on 2025-05-16, 11:14:

At the moment my best guess is to use DIR1 as in detect.pdf 0x0B is not Cyrix, but this could well be incorrect and I really need to see what more DX2 CPUs report.

It also says DIR1 30h - 35h is 6x86 / 6x86L which given the Cyrix reported 32h does not add up.

What is that detect.pdf you mention? Not Cyrix official datasheet I suppose?

0xFE / 0xFF form a pair (though some CPUs do not report anything useful for 0xFF), and according to my docs these are the values you are looking for:
0x1A / 0x05 - Cx686DX-40
0x1B / 0x08 - Cx686DX2-50
0x1B / 0x0B - Cx686DX2-66
0x1B / 0x31 - Cx686DX2-v80
0x1F / 0x36 - Cx686DX4-v100

I don't have 0x32 there but I suppose this is the difference between 3.3V v80 and the 5V variants.
The values 0x30 - 0x36 belonging to 6x86 family is true, but that's for DIR1 data (0xFE), not DIR0.

EDIT: I just looked at some of my own test results and sure enough the DX2-80 I have returns 0x32, so it's confirmed.
EDIT2: It's DX4-v100 not DX2, that was my copy and paste mistake. Fixed above.

Hi,
I have these in my notes. Maybe this is of any help.
(all values aquired on ASUS PVI-486SP3)

Cyrix:
Cx486DX-33GP (5V) -> M6, Model 1A, Step 04
Cx486DX-40GP (5V) -> M6, Model 1A, Step 04
Cx486DX-40GP (5V) -> M6, Model 1A, Step 05
Cx486DX2-66GP (5V) -> M7, Model 1B, Step 0A
Cx486DX2-66GP (5V) -> M7, Model 1B, Step 0A
Cx486DX2-80GP (5V) -> M7, Model 1B, Step 31
Cx486DX2-V66GP (3.45-4.0V) -> M7, Model 1B, Step 32
Cx486DX2-V80GP (3.3V) -> M7, Model 1B, Step 32
Cx486DX4-100GP4 (3.45V) -> M9, Model 1F, Step 36

ST:
ST486 DX-40 (5V) -> Model 1A, Step 08 [Edit: typo in model corrected A1 -> 1A]
ST486 DX2-66 (5V) -> Model 1B, Step 0C
ST486 DX2-66GS (5V) -> Model 1B, Step 32
ST486 DX2-80 (5V) -> Model 1B, Step 0C
ST486DX4V10HS (3.45V) -> Model 1F, Step 36
ST486DX4V10HS (3.45V) -> Model 1F, Step 36 [Edit: POST namestring: "CxDX4-S"]

TI:
486DX2-66 (3.45V) -> Model 1B, Step A0 [Edit: POST namestring: "Ti486"]
486DX2-80 (3.45V) -> Model 1B, Step 32 [Edit: POST namestring: "Cx486"]
486-DX4 100 (3.45V) -> Model 81, Step 91 [Edit: POST namestring: "CxDX4-S"]

IBM:
Blue Lightning DX2, IBM26 486-V266GA (3.3V) -> Model 1B, Step 32
Blue Lightning DX2, IBM26 486-V666GA (3.6V) -> Model 1B, Step 32
Blue Lightning DX2, IBM26 486-V580GA (4.0V) -> Model 1B, Step 32
486 DX4, IBM26 486-4V4100GC (3.6V) -> Model 1F, Step 36
486 DX4, IBM26 486-4V3100GIC (3.45V) -> Model 1F, Step 36 [Edit: POST namestring: "CxDX4-S"]
IBM 5x86C, IBM26 5x86C-3V3 100HF (3.45V) -> Model 2D, Step 05

Deunan wrote on 2025-05-16, 16:16:

What is that detect.pdf you mention?

Thank you all the information and it's the detect.pdf I attached to my initial post.

Deunan wrote on 2025-05-16, 16:16:

Cx686

I suspect these are all typos and should all be Cx486, should they?

ChrisK wrote on 2025-05-16, 16:51:

I have these in my notes. Maybe this is of any help.

Thank you and they help a lot, I can now see there are multiple Model 1B, Step 32 and several others so as I suspected my guess was incorrect.

Unless there are some differences in the CCRs or something else it looks like there is no way to tell them all apart. Hopefully I can get some dumps.

1Cyrix:   Cx486DX2-V66GP (3.45-4.0V) [M.7]            -> Model 1B, Step 32
2ST:      ST486 DX2-66GS (5V)                         -> Model 1B, Step 32
3TI:      486DX2-80 (3.45V)                           -> Model 1B, Step 32
4IBM:     Blue Lightning DX2, IBM26 486-V266GA (3.3V) -> Model 1B, Step 32
5         Blue Lightning DX2, IBM26 486-V666GA (3.6V) -> Model 1B, Step 32
6         Blue Lightning DX2, IBM26 486-V580GA (4.0V) -> Model 1B, Step 32

ChrisK wrote on 2025-05-16, 16:51:

ST486 DX2-66GS (5V) -> Model 1B, Step 32

Was about to buy this one for testing - not anymore I guess. Turns out my list is very incomplete but then again I'm no CPU collector. I just buy what I find cheap, and frankly I think I have enough of various 386 and 486 CPUs. Unless I find A-steps but that is rare and prices are unacceptable.

Anyway, so it seems the step can be low (like 0x0C) or high (0x30 range), I wonder what changed between those. Looking at voltages and clocks it seems to be somewhat random, per-die tested and binned I suppose. My point here being it's possible some of the non-Cyrix branded CPUs might actually be Cyrix dies but in different package. That would mean there is no way to tell them apart, at least not all of them.

What I can say is that some TIs had a TI-specific POST-name while others (non-Cyrix branded) were recognized as Cx-something. So there seems to be a way to distinguish at least some of them.
I cannot say anymore how the STs behaved in that regard. Maybe I have some more notes about that somewhere. Will have a look in the next days.

Is this SIV program also available for DOS? Then I could make some reports quite easyly if time allows. I have no Windows setup for these CPUs right now.

ChrisK wrote on 2025-05-16, 16:51:

ST: ST486 DX-40 (5V) -> Model A1, Step 08
TI: 486DX2-66 (3.45V) -> Model 1B, Step A0

Are these a typos, should they be Model 1A + Step 0A?

ChrisK wrote on 2025-05-16, 20:14:

Is the SIV program also available for DOS?

Thank you for the offer and no, SIV32L.exe is 32-bit only and about 6MB in size which is way too big for DOS. It works best on Windows NT V4.00 and later, will also run on Windows 9x/Me and there is SIV32O.exe for NT V3.51.

If you check http://rh-software.com/ it says:

After downloading siv.zip you should use SIV64X.exe on 64-bit Windows x64, SIV32X.exe on 32-bit Windows 2000 x86 and later, SIV32N.exe on Windows NT4 x86, SIV32L.exe on legacy Windows x86, SIV64I.exe on Intel Itanium Servers and SIV32A.exe on Digital Alpha Windows systems.

The Texas 486DX4 is quite easy to detect, AFAIK it's the only CPU which is Model 8 Stepping 1.

ChrisK wrote on 2025-05-16, 20:14:

What I can say is that some TIs had a TI-specific POST-name while others (non-Cyrix branded) were recognized as Cx-something. So there seems to be a way to distinguish at least some of them.

I don't know about the "true" 486 cores but SLC/DLC chips from TI lack the DIR0/DIR1 registers for example, while Cyrix chips do have them. I don't have any ST chips on hand and I've only tested one or two before, but AFAIR these did have DIR signature and it was identical to Cyrix.

And BTW yes, the chips in my list should all be Cx486 not 686. My brain is not firing on all cylinders today for some reason. Might be the weather.

ChrisK wrote on 2025-05-16, 20:14:

What I can say is that some TIs had a TI-specific POST-name while others (non-Cyrix branded) were recognized as Cx-something. So there seems to be a way to distinguish at least some of them.

Well, my ST DX2 doesn't have specific name. My TI DX4 does.

Deunan wrote on 2025-05-16, 20:44:

SLC/DLC chips from TI lack the DIR0/DIR1 registers for example, while Cyrix chips do have them.

They seem to be there and return 0xFF which I suspect is what a read of I/O Port 0x23 returns

SIV uses bit-03 of CCR0 to decide it's a TI486SXL, but can't remember where this came from. I know I looked at https://github.com/torvalds/linux/blob/master … nel/cpu/cyrix.c a long time ago when I wrote the code as there is a comment.

Below is from a SIV save I got on 2020-02-18.

red-ray wrote on 2025-05-16, 21:31:

SIV uses bit-03 of CCR0 to decide it's a TI486SXL

Huh. But that's KEN input enable bit, isn't it? It is present on both DLC and SXL chips (as well as the pin-reduced variants)?
I went the datasheet suggested way, I test internal cache TAG line size via TR4 and TR5. This is a comment in my ASM code:

1  ; 486: Tag [31:11] + Valid [10]
2  ; DLC: Tag [31:9]
3  ; SXL: Tag [31:12]
4  ; on 486 bit 10 of TR4 can be flipped, but not bit 9
5  ; on SXL(C) neither bit 9 nor 10 can be flipped

As for the DIR registers on TI, no, not present. The R/W is therefore mapped to the bus, as usual. In fact the whole reason I had to come up with some other kind of detection code was a system in which access to port 0x22 will mess it up.

Deunan wrote on 2025-05-16, 22:36:

red-ray wrote on 2025-05-16, 21:31:

SIV uses bit-03 of CCR0 to decide it's a TI486SXL, but can't remember where this came from.

Huh. But that's KEN input enable bit, isn't it?

Yes and as I specified "I can't remember where this came from.", I wish I could.

Looking at a dump from a Cyrix Cx486DLC then KEN is clear even though it has a 1KB L1 Unified Cache so I guess checking bit-03 will always work.

Below is from a save I got a long time ago, but as the date is 1980-01-01 I can't reliably tell when I got it, new saves would be helpful.

red-ray wrote on 2025-05-16, 23:26:

Looking at a dump from a Cyrix Cx486DLC then KEN is clear even though it has a 1KB L1 Unified Cache so I guess checking bit-03 will always work.

All the bits in this register are set by BIOS, or user-run CPU config tool. So in NT case it will be BIOS unless someone hacks the bootloader (or BIOS - I did on one mobo) but still, it has nothing to do with the CPU itself. Rather it's a motherboard preferred config that depends on what the chipset can do and what signals are routed to the CPU. And that is assuming the BIOS actually knows what it's doing, quite often DLC support is broken or missing completly. KEN input is very rarely used so I think you just got a lucky find with that SXL. We have at least one good thread about these config bits here on Vogons.

You can test that yourself - just set that bit to 1 running your code (which will effectively disable CPU cache on mobo that doesn't have KEN connected, so it's "safe" to do) and run the program again. This time it will misdetect the CPU due to the bit being set. If nothing else it shouldn't work that way.

The cache TAG method does work, but a "true" 486 core with 8KiB cache must be ruled out first (which can be done with flags NE bit) before it can reliably detect 486S which has 2KiB of on-chip cache. I don't have such a chip and never tested that particular code path.

Deunan wrote on 2025-05-17, 10:23:

If nothing else it shouldn't work that way.

red-ray wrote on 2025-05-16, 23:26:

Yes and as I specified "I can't remember where this came from.", I wish I could.

Again I am pretty sure this is something I was told and can't remember who told me this.

Have you tested your code on a Windows NT system? I suspect what is possible/sensible using DOS is likely to be different when you are running NT.

Deunan wrote on 2025-05-17, 10:23:

You can test that yourself - just set that bit to 1 running your code (which will effectively disable CPU cache on mobo that doesn't have KEN connected, so it's "safe" to do) and run the program again.

How can I "test it myself" when I don't have a Cyrix Cx486DLC or similar? What makes you think I have given I specified "new saves would be helpful", clearly if I had one I would generate a new save myself!

Deunan wrote on 2025-05-17, 10:23:

This time it will misdetect the CPU due to the bit being set.

Not necessarily, provided I also measured the L1 cache size all would be fine, but implementing this without having test CPUs would be tricky.

Update: I have just realised all SIV needs to do is measure the L1 cache size and in it's 8KB then it's a TI486SXL or similar rather than a Cyrix Cx486DLC or similar.

Below is what happened on my Intel DX4 which has a 16KB L2 cache.

1SIV32L  CPU-0   Time 0.003812  Size 0.5KB  Cycles 0
2SIV32L  CPU-0   Time 0.003757  Size   1KB  Cycles 0
3SIV32L  CPU-0   Time 0.003720  Size   2KB  Cycles 0
4SIV32L  CPU-0   Time 0.003749  Size   4KB  Cycles 0
5SIV32L  CPU-0   Time 0.003755  Size   8KB  Cycles 0
6SIV32L  CPU-0   Time 0.003727  Size  16KB  Cycles 0
7SIV32L  CPU-0   Time 0.063236  Size  32KB  Cycles 0

red-ray wrote on 2025-05-16, 20:27:

ChrisK wrote on 2025-05-16, 16:51:

ST: ST486 DX-40 (5V) -> Model A1, Step 08
TI: 486DX2-66 (3.45V) -> Model 1B, Step A0

Are these a typos, should they be Model 1A + Step 0A?

The first one I can confirm: "A1" should be "1A".
The second one I'm not sure. Notes say "A0" so I can't say for sure, unfortunately.
I have corrected the values in my original post and also added the POST strings of the CPUs I have noted something for (which weren't all since I didn't regard that as necessary at time of testing).
So the listing is a bit uncomplete regarding this aspect. My apologies.

Edit: Thinking about it again I'd say that "A0" stepping for the TI must be correct, since it had a distinctive Ti-POST string. Would it be "0A" then it would match the Cyrix DX2-66 in model & stepping and then it would have had a general DX2 oder Cx486 string...

ChrisK wrote on 2025-05-16, 20:14:

Is this SIV program also available for DOS? Then I could make some reports quite easyly if time allows.

You may use ASTRA for DOS.
The latest beta version saves Cyrix DIR and CCR registers to a text report.