jakethompson1 wrote on 2025-07-22, 22:30:

the system only "lost" the ability to operate at 2-1-1-1 & 1 W/S with the CE after switching the ISA SVGA card out for the VLB SVGA. Perhaps the CE was just barely fast enough in the first place, and the presence of the VLB card on the address lines pushed it over the edge into too slow?

Yeah, that's exactly what I thought and tried to express between all the other stuff I wrote in that post.

mkarcher wrote on 2025-07-22, 21:49:

The idea of asserting ADS# one cycle late is to add a full FSB clock period to the setup time of the address and command lines. Those lines are guaranteed to be valid some setup time before ADS#. The master will drive the address and command lines some clearly defined time after the end of the previous clock (so some time into T1), so the remaining time of T1, which will be less the higher the FSB clock is is the setup time. You can look at 486 data sheets to find the maximum time between the previous rising clock edge and the validity of the address and command lines. The higher the 486 FSB clock specification, the less time the 486 may "waste" before having valid address and command outputs. The remaining time of the cycle is required to deal with charging capacitive loads on the front side bus (likely including VL devices, as VL is typically unbuffered), propagation along the traceson the board, and yet the signals have to arrive some time before the next clock edge at the VL target. The "some time before" (the setup time at the receiver) is meant for propagation delays through the logic on the VL card. The VL 2.0 specification guarantees 7ns setup time at FSB33 and 5ns setup time at FSB40 and FSB50. VL card designers should know this constraint and design their cards in a way that this amount of setup time is sufficient. Hmm, well... now look at the CL-GD542x data sheet that requires at least 8ns setup time for the address, command, and UADDR# line. UADDR# is meant to be decoded using external logic, and well, the signals may already be 1 nanosecond late at the inputs of the decoder if the VL board is at the edge of allowed timings. Now, if the inputs are 1 nanosecond too late, how the heck are you supposed to generate the output in time?! Delaying ADS# by one clock would surely help.

Different motherboard here, a UMC 82C491-based one (instead of 498) -- unlike the 498, the pinout of the 491 is known (but no datasheet).

It has this jumper:
JP7: 1 . . . 3
Per manual: 1-2 for <= 33 MHz, 2-3 for 40 or 50 MHz
This jumper does NOT go to the VLB slot. Instead, there is a separate jumper that grounds ID3 when shorted. ID2 appears to be hardwired to a 10K ohm pulldown.

JP7 pin 1 goes to 74F74 pin 12
JP7 pin 2 goes to 82C491 pin 7 "PADS#"
JP7 pin 3 goes to 74F74 pin 9

Seems they are just implementing this "ADS# delay by one cycle" in hardware, here?

By the way, interesting quote from this Microprocessor Report article, Cyrix Readies 486DX-Compatible CPU:

Cyrix says that its chip is easier to design with than Intel’s 50-MHz 486 because of the way the timing is specified. Intel’s timings are specified with no capacitive loading, and delays must be derated for the appropriate loading. Cyrix’s specifications, on the other hand, include a 50-pF load.

jakethompson1 wrote on 2025-07-29, 22:40:

It has this jumper: JP7: 1 . . . 3 Per manual: 1-2 for <= 33 MHz, 2-3 for 40 or 50 MHz This jumper does NOT go to the VLB slot. […]
Show full quote

It has this jumper:
JP7: 1 . . . 3
Per manual: 1-2 for <= 33 MHz, 2-3 for 40 or 50 MHz
This jumper does NOT go to the VLB slot. Instead, there is a separate jumper that grounds ID3 when shorted. ID2 appears to be hardwired to a 10K ohm pulldown.

JP7 pin 1 goes to 74F74 pin 12
JP7 pin 2 goes to 82C491 pin 7 "PADS#"
JP7 pin 3 goes to 74F74 pin 9

Seems they are just implementing this "ADS# delay by one cycle" in hardware, here?

Yes, seems like it. 74F74 pin 12 should be connected to ADS# in the CPU socket, and pin 11 should receive the processor clock (or a copy of it). I don't think you have to verify that, but if you want to be extra sure, you can do it. This kind of delaying ADS# provides maximal setup time of ADS#, as the 74F74 will change its output just after the rising edge of the clock. So the actual delay is the ADS# signel is less than a whole clock, but the point in time at which ADS# is sampled low is indeed one clock later. On the other hande, I don't expect the timing of ADS# to be critical in a way that the increased setup time matters, as I can't imagine a sensible circuit that performs multi-stage logic before sampling ADS# on the rising CLK edge.

jakethompson1 wrote on 2025-07-29, 22:40:

By the way, interesting quote from this Microprocessor Report article, Cyrix Readies 486DX-Compatible CPU:

Cyrix says that its chip is easier to design with than Intel’s 50-MHz 486 because of the way the timing is specified. Intel’s timings are specified with no capacitive loading, and delays must be derated for the appropriate loading. Cyrix’s specifications, on the other hand, include a 50-pF load.

That's interesting. I verified this claim by looking at an Intel data book on Bitsavers, and it is indeed true. That data book specifies the timings of the 25 MHz and the 33 MHz model at a capacitive load of 50pF (just as Cyrix does), but the timing for Intel's 50 MHz model is specified with this note: "Specifications assume CL = 0pF. I/O buffer model must be used to determine delays due to loading (trace and component). First order I/O buffer models for the Intel486 processor are available. Contact Intel for the latest release." I suppose the idea is that the load is typically less than 50pF, especially if the FSB is buffered, which seems to make sense at the 50MHz model. The timing margins at 50MHz were known to be small, and seeing that 1 WS at 50MHz and 0 WS at 33 MHz provides the same timing for non-burst cycles, it is also quite understandable why Intel preferred the 66MHtz DX2 over the 50MHz non-doubled variant. If you follow the advice of your UMC 491 board, you get this forced wait state, and unless the board is able to do a single-cycle read burst from cache at 50MHz, the front side bus at 33MHz (no ADS# delay) is strictly faster than at 50MHz (with ADS# delay).

In retrospect, it's quite funny that Cyrix advertises their chip being easier to design with because the specification is more helpful (which might actually be true), because common experience is that the timing of Cyrix 486 CPUs for the 486 socket is more critical than Intel/AMD CPUs for that socket.

mkarcher wrote on 2025-07-30, 05:53:

jakethompson1 wrote on 2025-07-29, 22:40:

It has this jumper: JP7: 1 . . . 3 Per manual: 1-2 for <= 33 MHz, 2-3 for 40 or 50 MHz This jumper does NOT go to the VLB slot. […]
Show full quote

It has this jumper:
JP7: 1 . . . 3
Per manual: 1-2 for <= 33 MHz, 2-3 for 40 or 50 MHz
This jumper does NOT go to the VLB slot. Instead, there is a separate jumper that grounds ID3 when shorted. ID2 appears to be hardwired to a 10K ohm pulldown.

JP7 pin 1 goes to 74F74 pin 12
JP7 pin 2 goes to 82C491 pin 7 "PADS#"
JP7 pin 3 goes to 74F74 pin 9

Seems they are just implementing this "ADS# delay by one cycle" in hardware, here?

Yes, seems like it. 74F74 pin 12 should be connected to ADS# in the CPU socket, and pin 11 should receive the processor clock (or a copy of it). I don't think you have to verify that, but if you want to be extra sure, you can do it. This kind of delaying ADS# provides maximal setup time of ADS#, as the 74F74 will change its output just after the rising edge of the clock. So the actual delay is the ADS# signel is less than a whole clock, but the point in time at which ADS# is sampled low is indeed one clock later. On the other hande, I don't expect the timing of ADS# to be critical in a way that the increased setup time matters, as I can't imagine a sensible circuit that performs multi-stage logic before sampling ADS# on the rising CLK edge.

Knowing that UM491 (among others) is a combo 386/486 chipset, is it possible that this delay of ADS# using external logic was an attempt to retrofit something simulating 386 address pipelining when using a fast 486?
At least one other board/chipset (ISA486GXi, ALi M1419) appears to have an ADS/DADS jumper as well.

mkarcher wrote on 2025-07-30, 05:53:

That's interesting. I verified this claim by looking at an Intel data book on Bitsavers, and it is indeed true. That data book specifies the timings of the 25 MHz and the 33 MHz model at a capacitive load of 50pF (just as Cyrix does), but the timing for Intel's 50 MHz model is specified with this note: "Specifications assume CL = 0pF. I/O buffer model must be used to determine delays due to loading (trace and component). First order I/O buffer models for the Intel486 processor are available. Contact Intel for the latest release." I suppose the idea is that the load is typically less than 50pF, especially if the FSB is buffered, which seems to make sense at the 50MHz model. The timing margins at 50MHz were known to be small, and seeing that 1 WS at 50MHz and 0 WS at 33 MHz provides the same timing for non-burst cycles, it is also quite understandable why Intel preferred the 66MHtz DX2 over the 50MHz non-doubled variant. If you follow the advice of your UMC 491 board, you get this forced wait state, and unless the board is able to do a single-cycle read burst from cache at 50MHz, the front side bus at 33MHz (no ADS# delay) is strictly faster than at 50MHz (with ADS# delay).

In retrospect, it's quite funny that Cyrix advertises their chip being easier to design with because the specification is more helpful (which might actually be true), because common experience is that the timing of Cyrix 486 CPUs for the 486 socket is more critical than Intel/AMD CPUs for that socket.

I was actually having more trouble with an ISA 542x than with VLB cards. VLB works even with non-delayed ADS#. For now I have the cache chips pulled as the ones that came with it were 20ns & 15ns tag, and weren't working except at the slowest possible settings (3-2-2-2 read & 2 W/S write).
The ISA 542x issue seems particular to certain video BIOS accesses: with non-delayed ADS#, the character glyphs loaded during POST are reliably corrupted on the screen. With delayed ADS#, sometimes they are corrupted and sometimes not, depending on each boot. Possibly compounding this is that the BIOS doesn't seem to distinguish DX-50 from DX2-50, and is trying aggressive settings when left on autoconfigure like ISA speed of CPUCLK/3 (ie AMI "power-on" defaults are more reliable than "BIOS" defaults).