Does your motherboard have PS/2 SIMM slots (72 pin) too?
I haven't heared about 30 pin EDO SIMMs at all.
Note that just a few of the 486 chipsets and revisions of chipsets support EDO at all.

The only 486 chipsets that take advantage of EDO RAM are late, PCI-based chipsets like the SiS 496 and UM8881.

The issue is discussed in much greater detail elsewhere, but you can't just drop EDO RAM into a board like this. The issue is that the EDO RAM continues to drive the bus during portions of the memory access cycle where FPM would "let go" (allowing cache or a VLB card to drive it, for example) and this is compounded by pins on the EDO SIMMs or underlying memory chips that aren't connected on a PC-compatible design that might otherwise allow the EDO RAM to be temporarily disconnected without closing the row--if I understand it all right!

Someone did save the datasheet for your chipset: http://www.bitsavers.org/components/sis/SiS_85C460.pdf
It explains the meanings of the RAM settings, and unfortunately recommends de-tuning everything if you want 50 MHz operation. This is the reason of the shift from the 486DX-50 to the 486DX2-66, as lowering the bus to 33 MHz allows you to boost the RAM and cache timing a bit.

This board only supports FPM. 4MB modules memory, 70ns or 60ns does exist for FPM. Four modules of 4MB will give you 16MB plus four 1MB modules then this will be 20MB total. Not too bad.

Cheers,

Perhaps the 460 and 461 are different after all, but I bet much of the datasheet still applies.

jakethompson1 wrote on 2023-08-01, 21:47:

The only 486 chipsets that take advantage of EDO RAM are late, PCI-based chipsets like the SiS 496 and UM8881.

I think you should better word it as: The only 486 chipsets that can deal with EDO RAM are late, PCI-based chipsets like the latest revision of the SiS 496 and UM8881. If you have unusually high L2 cache read miss rates, they might even take a slight advantage on EDO RAM. Yes, I am the one who started the thread with the clickbaity title "The winner is EDO without any cache", but in typical circumstances, EDO is often a disadvantage.

jakethompson1 wrote on 2023-08-01, 21:47:

The issue is discussed in much greater detail elsewhere, but you can't just drop EDO RAM into a board like this. The issue is that the EDO RAM continues to drive the bus during portions of the memory access cycle where FPM would "let go" (allowing cache or a VLB card to drive it, for example) and this is compounded by pins on the EDO SIMMs or underlying memory chips that aren't connected on a PC-compatible design that might otherwise allow the EDO RAM to be temporarily disconnected without closing the row--if I understand it all right!

That's how I explained it before I fully understood it. You might be repeating what I explained on VOGONs some years ago. Actually, there are three ways to make EDO RAM stop driving the bus:

1. Close the row/page (in this context, page and row mean the same thing). This is detrimental to performance, because you mostly give up (fast) page mode. You can still use page mode during a burst (usually a cache line fill), because you don't need to have the RAM give up the bus during a burst.
2. Deassert the /OE pin. That's the pin on EDO RAM that can be used to (temporarily) take it off the bus, even when it is still in active read mode. The /OE pin is not routed on the PS/2 SIMM connector, and (contrary to what I claimed years ago) not output by typical chipsets. I mixed up a control pin for a RAM data driver with a pin meant to be connected to /OE of the RAM itself.
3. The actually clever way implemented in PC chipsets: Fake the start of a write cycle. The main feature of EDO RAM is that it does not abort the read process as soon as /CAS is deasserted. Deasserting /CAS is the standard way to tell FPM to stop driving the data bus. Nevertheless, EDO RAM does this just to be helpful, not to be evil. So as soon as you indicate that you are going to write (by asserting /WE), EDO RAM stops driving the bus, so the processor can drive the data it wants to write. The write actually happens when /CAS is asserted while /WE is already asserted. If you just want to make an EDO chip shut up, you just pulse /WE to terminate the data output phase, but you do not assert /CAS so you do not start an actual write.

Oftentimes, the /WE pulse to make the EDO RAM free the bus is inserted after every EDO read operation (uncached single read or 16-byte burst to read a whole cache line). That /WE pulse usually takes one FSB clock, during which the FSB is still "blocked", because the RAM is still driving the data lines. This single clock of FSB unavailability hurts only if the FSB is the bottleneck of the current program. With 5x86 processors operating at 4x the FSB clock internally, being FSB limited actually happens in practice. In case you can't use the advantage of EDO RAM, i.e. performing a one-word-per-clock burst, the only effect of EDO you will observe is this workaround cycle that slows down your system. Getting a read burst of 2 clocks per word is possible at typical FSB clocks even when using FPM. In my experience, I wasn't able to get EDO X-1-1-1 bursts at FSB speeds above 33MHz. With everyone and their dog running their high-end 486 socket 3 systems at 4*40, the possible improvement at 33 MHz isn't that interesting.

jakethompson1 wrote on 2023-08-01, 21:47:

It explains the meanings of the RAM settings, and unfortunately recommends de-tuning everything if you want 50 MHz operation.

The data sheets are very conservative about RAM and cache timings. With 60ns or 50ns RAM, you can sometimes run the timings recommended for 33MHz at 50MHz. The timings recommended for 40MHz nearly always work. Some data sheets even state that the timings specified "provide a lot of margin, even at 70ns RAM".

mkarcher wrote on 2023-08-01, 22:39:

In my experience, I wasn't able to get EDO X-1-1-1 bursts at FSB speeds above 33MHz. With everyone and their dog running their high-end 486 socket 3 systems at 4*40, the possible improvement at 33 MHz isn't that interesting.

Given that late (1995-1997) PCI 486 boards would likely target the Am5x86-133 which was running at 33 MHz anyway, plus the awkwardness of 40 MHz operation due to the lack of 5/6 PCI divider, do you think the EDO support (or perhaps a better term, EDO tolerance), in these late 486 chipsets was more about making them viable in a world where the price per byte of EDO RAM was dropping below FPM RAM, rather than genuine interest of taking advantage of EDO RAM?

jakethompson1 wrote on 2023-08-01, 22:47:

Given that late (1995-1997) PCI 486 boards would likely target the Am5x86-133 which was running at 33 MHz anyway, plus the awkwardness of 40 MHz operation due to the lack of 5/6 PCI divider, do you think the EDO support (or perhaps a better term, EDO tolerance), in these late 486 chipsets was more about making them viable in a world where the price per byte of EDO RAM was dropping below FPM RAM, rather than genuine interest of taking advantage of EDO RAM?

There are multiple reasons why an EDO revision of 486 chipsets made sense:

• As you said, EDO price was dropping below FPM price, at least for bigger memory modules.
• If you get EDO to work at X-1-1-1, you will get quite good performance without any L2 cache. Even at price parity between FPM and EDO, omitting the SRAM on EDO systems is okay-ish, while it is simply a no-go on FPM systems. See 486 board with UMC 8881E/8886B: The winner is: EDO without L2 (if your only other option is L2 at 3-2-2-2) , the table in the first post. 3-1-1-1 EDO was borderline stable at FSB40 on that system, but it likely would work OK at FSB33. People are correct that Quake is not a representative 486 benchmark, so take the numbers with a grain of salt. Comparing the three cacheless options is still valid, though: EDO @ 3-1-1-1 got 17.0fps, EDO @ 4-2-2-2 got 16.0fps and FPM got 16.3fps. At 4-2-2-2, the term "EDO tolerance" is likely the better term, but at 3-1-1-1, Quake gets close to the performance it can obtain with L2 cache. But again, Quake is especially bad at profitting from L2 cache on a 486 board, so take the "EDO nearly as fast as an L2-equipped system" with a grain of salt. The comparison between the different memory types without L2 is likely representative, though.
• And finally: marketing! If your board supports the new fast type of RAM, and the competition doesn't, that's great news!

As you said, the official target was 4*33, which enabled X-1-1-1 bursts on EDO with the 486 chipset technology available. Today, most retro people are overclocking to 4*40, and at that point, EDO gets useless on the UM8881. If you cross out the 3-1-1-1 benchmark (which happened to work that day in a cold room in the winter), there is no point at all in equipping that system with EDO RAM.

Thanks everyone for all the replies. I learned a lot more about FPM and EDO than I expected. And thank you Jake for the datasheet. I'll proceed with plain FPM for this build!

mkarcher wrote on 2023-08-01, 22:39:

[*]The actually clever way implemented in PC chipsets: Fake the start of a write cycle. The main feature of EDO RAM is that it does not abort the read process as soon as /CAS is deasserted. Deasserting /CAS is the standard way to tell FPM to stop driving the data bus. Nevertheless, EDO RAM does this just to be helpful, not to be evil. So as soon as you indicate that you are going to write (by asserting /WE), EDO RAM stops driving the bus, so the processor can drive the data it wants to write. The write actually happens when /CAS is asserted while /WE is already asserted. If you just want to make an EDO chip shut up, you just pulse /WE to terminate the data output phase, but you do not assert /CAS so you do not start an actual write.
[/list]

Oftentimes, the /WE pulse to make the EDO RAM free the bus is inserted after every EDO read operation (uncached single read or 16-byte burst to read a whole cache line). That /WE pulse usually takes one FSB clock, during which the FSB is still "blocked", because the RAM is still driving the data lines. This single clock of FSB unavailability hurts only if the FSB is the bottleneck of the current program.

wouldnt you solve this by dropping a bus arbitrator between system data bus and ram? looking at INTEL MODEL 430VX.pdf thats what two 82438VX are for, sadly datasheet cuts out before 82438VX https://0x04.net/~mwk/doc/intel/29765303.pdf Those two chips on VX boards look to me as a beefier versions of NeoGeo https://wiki.neogeodev.org/index.php?title=NEO-BUF (https://www.youtube.com/watch?v=UnSGLKsPmTg shows struggle to replace blown ones)

rasz_pl wrote on 2023-08-02, 07:40:

wouldnt you solve this by dropping a bus arbitrator between system data bus and ram?

A bus arbitrator would not help. The role of a bus arbitrator is to decide who is entitled to use the bus. The bus arbitrator relies on the devices to not drive data to the bus when they are told no not drive data to the bus. Currently, we are discussing EDO RAM in a system built for FPM RAM. EDO RAM drives the bus when the chipset expects the RAM to not drive the bus. So that's not an issue an arbitrator can solve.

On the other hand, you might be thinking about a buffer chip, especially as you mention the Intel Data Path Units in you next sentences, which are not arbitrators, but contain a buffering function. A buffer does indeed help, if one side of the buffer is connected to the bus, and the other side of the buffer is connected to a single device that drives its data lines even when the device must not drive the system bus. You do not insert a buffer chip without need, though, because the buffer chip also adds some latency to the signal. In the case of RAM, a buffer chip wouldn't solve the FPM/EDO problem completely, because you would have all SIMM banks connected to one side of the memory data buffer, and the system bus to the other side of the memory data buffer. While the SIMMs can no longer disturb the system buf with the buffer in-between, a good FPM chipset can keeps a page open in the first bank while it accesses another page in the second bank. Stuff like this is performed on later chipsets like the 440BX (even if they use SDRAM, the idea of having open and closed pages is the same in FPM, EDO and SDRAM), but I don't know whether any 486 chipset supports open pages in multiple banks at the same time. In case multiple banks have open pages at the same time, though, the memory banks conflict with each other on their side of the bus.

rasz_pl wrote on 2023-08-02, 07:40:

looking at INTEL MODEL 430VX.pdf thats what two 82438VX are for, sadly datasheet cuts out before 82438VX https://0x04.net/~mwk/doc/intel/29765303.pdf Those two chips on VX boards look to me as a beefier versions of NeoGeo https://wiki.neogeodev.org/index.php?title=NEO-BUF (https://www.youtube.com/watch?v=UnSGLKsPmTg shows struggle to replace blown ones)

Indeed, the NEO-BUF is also a buffer, not an arbitrator. As explained above, a buffer can work in some situations, but wouldn't fully solve it. The Intel DPU ("data path unit") is more than just a buffer. In case you can't find a data sheet for the 430VX DPU, go looking for a datasheet for the 430FX DPU, too. Those seem to be very similar. It's interesting that you have these dedicated DPU chips on the 430FX and the 430VX, but not on the 430HX, which was published between the 430FX and the 430VX. The reason there are dedicated buffer chips (and even two of them!) on the 430FX, but not on the 430HX is that the 430FX only uses chips in PQFP cases, and there is no standard PQFP case with more than 208 pins. To get good performance with write buffering and the possiblity of having the Pentium access the L2 cache while a PCI bus master accesses RAM calls for a complex buffer chip that has dedicated data pins for the RAM, the PCI bus and the Processor/L2. In the Intel 430 architecture, the Processor/L2 interface is 64 bits wide, the RAM interface is 64 bits wide and the PCI interface is 32 bits wides. This mean 160 pins just for the data lines, not talking about any address lines yet (the PCI bus doesn't need any extra address lines, as address/data is multiplexed on the same pins on the PCI bus). Obviously, you won't fit the RAM controller and PCI host bridge into 208 pins, as you will need 32 processor address pins and around 12 RAM address pins, yielding 204 data + address pins, and no clock pins and control pins are considered yet. That's why Intel split out the data handling from the "north bridge" into dedicated data buffer chips, the "data path units". They also contain a couple of FIFOs for write posting.

The design of the 82438FX data path units is interesting. Intel split the busses in half: One chip is going to handle the bytes at odd addresses, and the other chip is going to handle the bytes at even addresses. This part is quite straightforward. You would expect the chips to have 16 data lines for the PCI bus in this case - but they don't. They just have 8 data lines per chip! The idea is that the multiplexed PCI address/data lines are driven by the 82437FX, called the TSC. As the TSC handles the address bits, it needs to be connected to the PCI data/address pins anyway. The 82437FX needs assistance from the DPUs that contain the write buffers / FIFOs. To save on pin count, the PCI bus data is transferred at 16 bit width and 66MHz clock between the 82438 and the 82437, and converted to 32 bit at 33MHz inside the 82437.

The reason for Intel to "fall back" to dedicated DPU chips in the VX chipset after they already did away with them in the HX chipset is most likely that the HX chipset had the north bridge as a single BGA chip, which means a lot of signals in a very small PCB area, requiring a expensive PCB with many layers to route all these signals. As the VX is meant to be the "value edition" (aka cheaper chips allowing cheaper computers) of the HX, it makes sense to build it in a form factor that allows cheaper PCBs, i.e. multiple PQFP chips that can be distributed over the board instead of a single BGA chip.

Interesting thing is Intel also went back to TX chipset again, both BGA. What does this matters this time? I was not interested in VX as I find this odd for Intel to do this again even it is designed for SDRAM. Also all the years, I thought the VX chipset was budget oriented vs decent enough FX and HX chipsets at this time, which I had back in the day. But didn't with TX. I went on to BX with PII 350 as a upgrade.

Cheers,