Reply 20 of 55, by rmay635703
- Rank
- Oldbie
BitWrangler wrote on 2025-06-19, 19:28:Wasn't it also the only space certified x86 until 2005 or so?
That was my understanding as to why a lot of antiques continued onward forever
BitWrangler wrote on 2025-06-19, 19:28:Wasn't it also the only space certified x86 until 2005 or so?
That was my understanding as to why a lot of antiques continued onward forever
feipoa wrote on 2025-06-19, 05:17:The PS/2 header caught my eye. How does this board compare against other socket 3 boards with the SiS 471 chipset?
The datasheet for this chipset (https://bitsavers.org/components/chipsAndTech … 4045_199510.pdf) is the most detailed of any 486 chipset datasheet I have seen. It gives the rationale behind some of the decisions and explains what each pin is for. It goes into detail about "cache test mode" explaining how a BIOS would use it rather than just giving bits in a register. So it is an interesting read.
It indeed seems to be the "ultimate 486 chipset." If people only knew that these boards were being made until 2010 (or possibly later), I bet there would have been buyers among the forum.
Why would anyone be designing a chipset without PCI in 1995, though? Maybe that doomed it, so that we see UM8881 and SiS 496 represented among late 486 boards instead.
In addition to 7+1 tag, it can use 8+1 and 10+1. The latter two would require a second tag RAM. 10+1 tag would be enough to cache 256MB of RAM in write-back mode with only 256KB of cache. CLKIN is given as up to 80 MHz.
The DRAM timings look similar to the SiS 471.
For cache, the C&T claims to support 2-1-1-1 read & 1 W/S write at 50 MHz (with 15 ns data and 12 ns tag), or 2-1-1-1 read & 0 W/S write at 40 MHz (with 20ns data and 15ns tag), slightly better claims than the SiS 471.
Hopefully some quantitative benchmark results emerge to showcase this "ultimate 486" chipset.
Plan your life wisely, you'll be dead before you know it.
Wjg6260 reviewed that board here
pshipkov wrote on 2025-06-20, 06:23:Wjg6260 reviewed that board here
Thanks. Looks like it's going to need a bit of cajoling/tuning to run fast.
this is in line with Chips based motherboards.
little rigid. cannot do anything interesting outside spec.
plenty of options in bios but touch any and the system crumbles.
It also REALLY doesn't like a bad cache chip, bought 4 more of the Cypress ram chips from a vendor in china, and they arrived, 1 tested as bad, but I stuck them in to see what it would do... well... each power on would give a random code on the diag board I have, and it would occasionally actually get to POST only to lock up, so note to self, put working hardware on this board only.
ESA TF-486 board. Like the one feipoa shown in the first post.
ALI M1489 A1 chipset; M1487 southbridge. 2004 date code.
I'm now interested in getting a board like this for testing but not for crazy ebay prices.
JuddSandage wrote on 2025-06-21, 23:28:It also REALLY doesn't like a bad cache chip, bought 4 more of the Cypress ram chips from a vendor in china, and they arrived, 1 tested as bad, but I stuck them in to see what it would do... well... each power on would give a random code on the diag board I have, and it would occasionally actually get to POST only to lock up, so note to self, put working hardware on this board only.
I ended up ordering one of these too.
The chipset supports up to an 11-bit tag, and the board seems to have provisions for two 8-bit tag chips, or one 9-bit tag chip.
TAG0 through TAG7 go to U39; TAG9 through TAG10 go to U38; TAG8 can be jumpered to go to either.
While waiting for a Dallas chip to come, I am looking at the cache jumpers. I want to figure out whether it can be modified for 1MB cache. I think so, but am not sure yet.
JP26:
1-2: U38 & U39 are x8 SRAM (connect U39, pin 12 with A16) [factory]
2-3: U38 is empty & U39 is x9 SRAM (connect U39, pin 12 with TAG8)
JP27:
1-2: Cache is 256KB or larger (connect U38 & U39 pin 28 with A17)
2-3: Cache is 128KB or smaller (pull U38 & U39 pin 28 to Vcc) [factory]
JP28:
1-2: Cache is 512K or 1024K and U38 & U39 are 64Kx8 (connect U38 & U39 pin 3 with A18)
2-3: U38 is empty & U39 is x9 (connect U38 & U39, pin 3 with A16)
OPEN: All other situations [factory]
JP29:
1-2: Cache is 512K and U39 is 32Kx9 (connect U39, pin 31 with A18)
2-3: Cache is 1024KB (connect U39, pin 31 with A19)
OPEN: All other situations [factory]
Note, U38 & U39, pin 31, are not wired together. I think a bodge wire is needed there to support two-chip, 9- or 11-bit tag. Or, it could be intentional, as a 7+1 tag with 1MB is enough to cache 128MB and the board supports no more DRAM than that.
U38 & U39, pin 2 seems to be NC; a pull-up should be used there if using 128Kx8 SRAM as if it were 64Kx8.
Well, that sound awesome, also what date codes are on the chips of your board? and did you luck out and find a black PCB?
JuddSandage wrote on 2025-06-26, 09:39:Well, that sound awesome, also what date codes are on the chips of your board? and did you luck out and find a black PCB?
Mostly 98 and 99, and no, it is green.
Initial testing suggests hindered memory performance compared to an SiS 471 or even a UM498 or UM491+working dirty bit. Three DRAM read timing options are available: 3-2-2-2, 4-3-3-3, and 5-4-4-4. However, the datasheet states, the 3-2-2-2 option is only valid in 2X clock mode (this chipset can either take double the bus clock, like a 386, or a 1X one, like most 486 systems). Indeed, 3-2-2-2 instantly hangs even at 33 MHz. I haven't even thought about whether the board could be modified to use 2X operation.
The board came with an Enhanced Am486DX2-66 and I also tried my Am5x86-P75. 2X40 MHz and 2X50MHz operation wasn't stable enough to fully benchmark, however, to the extent I did test I did find I had to lower the cache from 2-1-1-1 to 2-2-2-2 at 50 MHz even with 15ns cache chips (since 2-X-X-X still works, presumably a 12ns tag wouldn't help). 4X40MHz could not POST, and I have not messed with the voltage on this board as of yet.
CACHECHK v4 2/7/96 Copyright (c) 1995 by Ray Van Tassle. (-h for help)
CMOS reports: conv_mem= 640K, ext_mem= 31,744K, Total RAM= 32,384K
"AuthenticAMD" 486 Clocked at 133.6 MHz
Reading from memory.
MegaByte#: --------- Memory Access Block sizes (KB)-----
1 2 4 8 16 32 64 128 256 512 1024 2048 4096 <-- KB
0: 8 8 8 8 8 18 18 18 18 34 -- -- -- µs/KB
2: 8 8 8 8 8 18 18 18 18 34 34 34 34 µs/KB
3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 <--- same as above.
20 21 22 23 24 25 26 27 28 29 30 31 <--- same as above.
Extra tests----
Wrt 24 24 24 24 24 24 24 24 24 24 24 24 24<-Write mem
This machine seems to have both L1 and L2 cache. [read]
L1 cache is 16KB -- 137.7 MB/s 7.6 ns/byte (423%) (221%) 3.9 clks
L2 cache is 256KB -- 62.2 MB/s 16.9 ns/byte (191%) (100%) 8.6 clks
Main memory speed -- 32.5 MB/s 32.3 ns/byte (100%) [read] 16.4 clks
Effective RAM access time (read ) is 129ns (a RAM bank is 4 bytes wide).
Effective RAM access time (write) is 91ns (a RAM bank is 4 bytes wide).
"AuthenticAMD" 486 Clocked at 133.6 MHz. Cache ENABLED.
Options: -t0
CACHECHK v4 2/7/96 Copyright (c) 1995 by Ray Van Tassle. (-h for help)
CMOS reports: conv_mem= 640K, ext_mem= 31,744K, Total RAM= 32,384K
"AuthenticAMD" 486 Clocked at 66.8 MHz
Reading from memory.
MegaByte#: --------- Memory Access Block sizes (KB)-----
1 2 4 8 16 32 64 128 256 512 1024 2048 4096 <-- KB
0: 16 16 16 16 16 24 24 24 24 40 -- -- -- µs/KB
2: 16 16 16 16 16 24 24 24 24 40 40 40 40 µs/KB
3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 <--- same as above.
20 21 22 23 24 25 26 27 28 29 30 31 <--- same as above.
Extra tests----
Wrt 24 24 24 24 24 24 24 24 24 24 24 24 24<-Write mem
This machine seems to have both L1 and L2 cache. [read]
L1 cache is 16KB -- 69.5 MB/s 15.1 ns/byte (250%) (149%) 3.8 clks
L2 cache is 256KB -- 46.6 MB/s 22.5 ns/byte (167%) (100%) 5.7 clks
Main memory speed -- 27.8 MB/s 37.7 ns/byte (100%) [read] 9.6 clks
Effective RAM access time (read ) is 150ns (a RAM bank is 4 bytes wide).
Effective RAM access time (write) is 91ns (a RAM bank is 4 bytes wide).
"AuthenticAMD" 486 Clocked at 66.8 MHz. Cache ENABLED.
Options: -t0
It's possible to modify the board in a straightforward way to obtain 2X clock mode.
Move R27 to R28
Lift pin 18 of the clock generator chip
Connect pin 17 of the clock generator chip to the near side of R73
Unfortunately, 3-2-2-2 DRAM mode still doesn't work with the modification. Even using DEBUG to change chipset register 10h from 01h to 00h, the system hangs instantly.
I've also found I can't use the 32-bit IDE option; it results in massive write corruption (leading 1-bits in bytes within a sector sometimes flipped) even with all the other settings on their most conservative values.
How does 3-2-2-2, 4-3-3-3, and 5-4-4-4 for DRAM wait states compare to the more standard nomenclature of, e.g., 1 ws read, 0 ws write?
Bummer concerning the 2x mode mod not working. Did it work at 25 MHz FSB (50 MHz on the PLL)?
Is it outputting only 3.3 V on the VRM? If yes, do you have an Am5x86 which you know works at 160 MHz at 3.3 V?
What IDE controller is on the board? Strange that 32-bit mode wouldn't work. Did you try it with a traditional, spinning plates, hard drive? Do we have any benchmark results for 32-bit vs. 16-bit mode in, say, Windows 95 in order to quantify its value?
So far, results aren't very optimistic.
Plan your life wisely, you'll be dead before you know it.
feipoa wrote on 2025-06-27, 21:20:How does 3-2-2-2, 4-3-3-3, and 5-4-4-4 for DRAM wait states compare to the more standard nomenclature of, e.g., 1 ws read, 0 ws write?
That's basically 0ws, 1WS and 2WS. Also, the write timing is either 1WS or 2WS, so we do not get 0WS writes to RAM at all on the CS4041 chip set.
feipoa wrote on 2025-06-27, 21:20:What IDE controller is on the board?
The IDE controller is integrated in the "north bridge", the C&T 84041 chip.
Also, SiS calls 3-2-2-2, 4-3-3-3, and 5-4-4-4 Fastest, Faster, and Slower respectively.
It is 3.3V, when I get a chance, I will mess with the resistor to bump it up to 3.6V. I don't think I have any Am5x86 that overclock at 3.3V.
I am using a conventional IDE hard drive (relevant rant is here: Re: IDE to Sata strangeness - Startech IDE2SAT)
As an experiment, I used Watcom C to make a protected mode program that turns on 3-2-2-2 DRAM mode. My theory was that in protected mode, if the faster speed causes DRAM to return bad data, then maybe the CPU will at least triple-fault and cause the board to reset itself (or generally react to an invalid opcode in a better manner). It doesn't, still a hard-lock. So I wonder if the state machine in the DRAM controller itself seizes up at 3-2-2-2 at least on this board?
I have two of these, but still need to put the new Dallas on the other one. That will help identify whether the 32-bit IDE issue and possibly the 3-2-2-2 DRAM issue are broad, or somehow related to damage on the first board.
jakethompson1 wrote on 2025-06-27, 22:30:So I wonder if the state machine in the DRAM controller itself seizes up at 3-2-2-2 at least on this board?
I guess the requirement for using 2x clock mode at 3-2-2-2 is because the RAS-to-CAS-delay is half a clock shorter in that mode. While you could derive a half clock from the falling edge, they likely didn't do that due to chip design constraints. Possibly your system crashes at 3-2-2-2 because the RAS-to-CAS delay is shortened to 1.5 clocks from 2.0 clocks (although that should be mitigated if you select a sufficiently low FSB clock). Nevertheless, it is worth trying to choose 2.5/3.0 as RAS-to-CAS-delay before entering 3-2-2-2 mode. Furthermore, even at FSB33, 3-2-2-2 RAM burst is only recommended by the datasheet without L2 cache and with 60ns RAM. At all other configurations, 4-3-3-3 (1WS) is suggested, although with an asterisk indicating that 3-2-2-2 might work as well if the board design leaves enough margin.
jakethompson1 wrote on 2025-06-27, 22:30:That will help identify whether the 32-bit IDE issue
According to the data sheet: "The Command Recovery Time is also used between commands on a 32 bit I/O operation."
Did you try setting the command recovery time to quite high values before enabling 32-bit I/O?
mkarcher wrote on 2025-06-28, 14:54:jakethompson1 wrote on 2025-06-27, 22:30:So I wonder if the state machine in the DRAM controller itself seizes up at 3-2-2-2 at least on this board?
I guess the requirement for using 2x clock mode at 3-2-2-2 is because the RAS-to-CAS-delay is half a clock shorter in that mode. While you could derive a half clock from the falling edge, they likely didn't do that due to chip design constraints. Possibly your system crashes at 3-2-2-2 because the RAS-to-CAS delay is shortened to 1.5 clocks from 2.0 clocks (although that should be mitigated if you select a sufficiently low FSB clock). Nevertheless, it is worth trying to choose 2.5/3.0 as RAS-to-CAS-delay before entering 3-2-2-2 mode. Furthermore, even at FSB33, 3-2-2-2 RAM burst is only recommended by the datasheet without L2 cache and with 60ns RAM. At all other configurations, 4-3-3-3 (1WS) is suggested, although with an asterisk indicating that 3-2-2-2 might work as well if the board design leaves enough margin.
It hangs even at 20 MHz. Also, I tried setting all the RAM settings but 3-2-2-2 to their most conservative values, and disabling external cache, same hang.
edit: If you were to set 3-2-2-2 anyway in 1X clock mode, would it most likely implicitly degrade to 6-4-4-4, be disregarded, or hang? There is a read back register in the datasheet you can read to verify you are indeed in 2X mode, and I am.
Also, last night I tried a program that disabled interrupts, set memory to 3-2-2-2, then spun in a loop (interrupts still off) continually incrementing a byte and outputting it to my POST card at 80h. That all fits on a 16 byte cache line so it was guaranteed to be in L1 cache. In that configuration, the codes kept looping on the POST card, so it does seem the hang isn't until the first DRAM access after setting 3-2-2-2 and it isn't immediate.
mkarcher wrote on 2025-06-28, 14:54:jakethompson1 wrote on 2025-06-27, 22:30:That will help identify whether the 32-bit IDE issue
According to the data sheet: "The Command Recovery Time is also used between commands on a 32 bit I/O operation."
Did you try setting the command recovery time to quite high values before enabling 32-bit I/O?
The BIOS doesn't allow timings individually, just a PIO mode.
However, since it's only writes that malfunction with 32-bit I/O, I am able to boot with it on, then use DEBUG to poke at the IDE registers. I tried a few experiments setting various settings to their most conservative values (recovery time, data hold time, etc.) and it didn't make a difference. Then copying a file from a floppy to C:, then fc /b, showed the first 1-bit on various bytes to be flipped. I didn't keep a detailed log of each setting I tried making conservative, but it was all of them (and switching BIOS from PIO mode 4 to 0 would be pretty much the same thing anyway).
My DigiKey order with the Dallas+machine pin socket has arrived, and also has some IDE cables in it, just in case it's that. The IDC connectors on my older cables are starting to pull apart with each removal.
jakethompson1 wrote on 2025-06-28, 18:55:edit: If you were to set 3-2-2-2 anyway in 1X clock mode, would it most likely implicitly degrade to 6-4-4-4, be disregarded, or hang?
I didn't even think about degrading to 6-4-4-4, but that might indeed be a possiblity if the DRAM state machine grabs its clock before the optional /2 divider in the 3-2-2-2 mode. As we don't know much about the internal design of the DRAM state machine, it is difficult to estimate what exactly happens in the unsupported configuration.
An immediate lock-up sounds like the DRAM state machine does never finish its access cycle, and never returns RDY# to the processor. I wonder whether the designers of your board took a shortcut with the clock pins. It seems the idea of the 84041 clockin is that you present a 1x or 2x clock at CLKIN. That clock then gets divided by the power management for doze modes, and output to CLK2OUT (1x or 2x, as you input it) and to SCLKOUT (always 1x). In 1x clock mode, both of these output pins are supposed to output the same clock frequency with minimal skew. These clocks are not yet used internally in the 84041, but you are supposed to buffer them (e.g. with a 74F244), which will introduce some delay on them. The output of the buffers is then fed back into 84041 (into CLK2 and SCLK respectively) so the logic in the 84041 can operate at a clock that is in phase with the clock that is distributed over the boards (to the VL slots and the 84045). As SCLKOUT and CLK2OUT are nearly identical in 1x clock mode, you might get away with a single driver of the 74F244 connected to either one of the outputs, and feed the driver output back into both CLK2 and SCLK. If the board designers did that, it would make the 2x clock mode unusable.
jakethompson1 wrote on 2025-06-28, 18:55:Also, last night I tried a program that disabled interrupts, set memory to 3-2-2-2, then spun in a loop (interrupts still off) continually incrementing a byte and outputting it to my POST card at 80h. That all fits on a 16 byte cache line so it was guaranteed to be in L1 cache. In that configuration, the codes kept looping on the POST card, so it does seem the hang isn't until the first DRAM access after setting 3-2-2-2 and it isn't immediate.
Given that symptoms, I suppose the 84041 fails to return a RDY# signal to the 486 processor on DRAM (read?) cycles. You can test whether your test program still doesn't crash if you write to memory in that loop, but don't read from memory. I suppose it doesn't crash, because the 3-2-2-2 setting is only supposed to affect reading.
Are you testing with an Am5x86? Do you think there's a specific CPU which may be more inclined to work with 3-2-2-2 DRAM timings, e.g. 486S, or another obscure/slow CPU?
Plan your life wisely, you'll be dead before you know it.
I've been testing with an Am5x86, as well as the Enhanced Am486DX2-66 that came with it. I guess I could try a DX-33, but I doubt it makes any difference.