I tested new IDT 12 ns DIP SRAM on the UUD board, but it offered no timing advantage compared to 15 ns when run at 66 MHz. The "fake" Chinese 10 ns Winbond DIP SRAMs also offer no advantage at 66 MHz compared to 15 ns.

EDIT: I also tried the IDT 12 ns SRAM modules with an AMD "DX2" (really an Am5x86-133 with 2x multiplier) at 60 MHz x2, but I cannot use anything faster than 3-2-2-2. Your ability to run 60x3 with an Am5x86 at 2-1-1-1 is astounding. Is it just that one particular set of SRAM modules you have which allow for this? And if not the response time, what makes those modules so special?

EDIT2: I tried the 12 ns IDT modules at 50 MHz x 3 and they couldn't cope with 2-1-1-1. I put my old Winbond 15 ns, and later Alliance 15 ns, modules from 1995 back in and they can cope with 2-1-1-1 at 3x50 MHz. So what's up with the brand new 12 ns modules? They weren't cheap.

IMO it's all that when, where and how they were binned, if next bin was 10ns when the 15ns was binned, you might be lucky and have chips that can do as good as 10.1 ns, (Or even meet specs for 10 at lower heat and better volts than worst case scenario testing a top tier manufacturer might use) If next bin was 11ns when the 12ns was binned then they might do 11.1 at best. But! you say, 12ns should do 83mhz! Yah, but here we usually have some 74F series logic involved that sucks up 5ns, so dead nuts on 12ns plus the 5 we get ~58Mhz top speed, where if the chips are doing 10 or damn close we get 66Mhz.

I also tried my 'fake' Chinese 10 ns chips, 9 pieces, and they didn't fair any better than the 15 ns pieces. I've been waiting ages for a cheap SRAM response time tester to appear on the market. That would allow us to cherry pick with ease.

Confirming from my corner. Good 15ns chips can handle well 66MHz base frequency on UUD, assuming 9 32x8 chips (256Kb).
From other motherboards 512/1024 tend to be much more picky and faster rated chips tend to help, especially if tightest BIOS timings are desired.
Yet to try your 1024Kb mod, so just a presumption in the context of UUD. To be verified.

I would have expected brand new 12 ns chips to at least meet the specs. of old 15 ns chips. This is what I don't understand. For the most part, 32kx8 in DIP-28 went as fast as 12 ns, not 10 ns, so even if the old 15 ns parts were binned next to 12 ns parts, I would not expect the old 15 ns parts to be better than 12 ns parts. It might be worth looking at other specs like, e.g. impedance, to see if there is more to this mystery than just the advertised response time.

It can be gate capacitance that limits switching speed in transistors. However, with smaller process nodes the areas of the gates are smaller, thus capacitance less. So if new parts are on a smaller process, they should be even cleaner switching than old parts, and thus push further, even rated the same.

From my corner - ISSI/UMC branded 386-486-early_Pentium class L2 cache chips (those 24-to-32 pin dip packages) rated 15ns or lower latency are more or less the same, given the 66MHz practical frequency limit of these systems.
Die quality of a given chip is much more important than its latency rating.

No idea if new chips are produced chips with the same technology from 20 years ago, but so far didn't notice improved stability/reliability for sure 😀

It has been awhile for me, so pardon my lossy memory, but I assume you are referring primarily to the gate-source capacitance, and perhaps also to the gate-drain capacitance, which becomes more prominent with increasing frequency? Source-body and drain-body being negligible? I think that the ratio of the channel length to the drain width need to be decreased to lower propagation delay, not just the channel length.

From what I recall when working at a semiconductor company, wafer "quality" has to do with impurities that occur during growth of the boule. Once the boule is sliced, we would work around those impurities. The smaller impurities, which can be harder to detect via IR inspection, esp. if your wafers are thick (ours were), apparently grow over time. The growth of these impurities short out the device in due course. It is tough for me to remember exactly, but I think the impurities were holes in the lattice structure, areas of improper doping, dust or other foreign matter, etc.

Trying to put this into perspective, I can see how certain SRAM modules would worsen over time, and I've definitely had some short out on me, but these IDT modules are supposedly new. Assuming the response time is really 12 ns when run at 66 MHz, I suspect there are various other physical parameters affecting performance while plugged into the MB-8433UUD, e.g. output impedance, interconnect impedance/capacitance, transmission line impedance, etc. It may be that the input/output impedance of these modules don't work well with this board. Not sure. Some years ago I was implementing a custom additional 2x PLL to this motherboard and noticed that there was a very narrow range in which I could match the line impedances for it to work.

Right, maybe they're causing an impedance mismatch on the data lines, like an unterminated SCSI bus, yuck, transmission line theory... crap how do you sort that out... steal ideas from antenna design, quarter wave stub to match it? have to swap 'em out for every bus speed, what's the speed of light in a 486 motherboard? 🤣

BitWrangler wrote on 2021-09-09, 03:12:

crap how do you sort that out...

Engineering textbook mates with an undergraduate geography book and the Smith Chart is born!

Well here's some clues about impedence matching, https://www.bourns.com/pdfs/dram.pdf

edit: skimming stuff in relation to that, I realised that with high output/input impedences millimeters might become important, and by not setting components direct in the board, like leaving a few mm of leg on a cap replacement to allow it to bend out the way, miiight screw with impedence matching because it's going from FRP with a dielectric constant of around 4.5 to air... ergo... ima blodge hotglue or epoxy on the leads when I do that now to try to bring it back the right way.

I've always liked these IC manufacturer supplied tech education documents, they get right to the point at hand, while textbooks really beat around the bush.

From that Bourns doc:

1Termination of address and control lines is typically accomplished with low-valued resistors placed in series at the driver output. Selection of the proper resistance value is performed in two steps: approximation of the proper resistance using transmission line equations, and secondly, through trial and error, changing the resistance value to account for real world deviations such as PCB vias and bends.
2
3Thus on a theoretical basis, the design will require the resistance of 38 ohms to match the trace impedance of the PCB. However, the actual impedance will differ from this theoretical value due to the non-ideal characteristics of the PCB trace geometry (i.e., bends, curves and vias in the trace), as well as the manufacturing variations inherent in the components and materials. Therefore, a trial-and-error process must be employed in order to optimize the value of the damping resistor.
4
5Typically, resistance values for memory damping will be in the range of 10 ohms to 50 ohms, with the most common values in the 20 ohm to 30 ohm range.

Yup, that is pretty much what I had to do with my 2x PLL. There was as very narrow range which worked. Also, I have noticed ranges for the fanout resistor on the UUD between 20 and 33 ohms.

EDIT: I always cut my caps to the shortest possible lengths.

So now I'm tryna think of a way to hammer the cache in memtest while penciling over the resistors in play until the errors disappear or something.

So cap legs length - how real this is ?
I mean outside of the theoretical formulation.
So far I didn't encounter a case where this was a thing.
Also, many isa / vesa Diamond cards keep the tantalum long legged.
But I also do cap legs short.

It would certainly be a fun experiment to take a slot 1 or socket 939 and recap them using maximum length leads. They are usually around 1 to 1.5". I could be wrong, but I bet the 939 would have a tough time even with the slowest timings.

BitWrangler wrote on 2021-09-09, 04:07:

So now I'm tryna think of a way to hammer the cache in memtest while penciling over the resistors in play until the errors disappear or something.

Good times.
Just a friendly reminder that the usual utilities around here such as memtest, checkit, cachecheck, etc, are more of a first pass coarse approximation, than a sign off on mem stability.

To follow-up on my comment to use the AHA-1542CP card with a SCSI2SD HDD, the results are in and are disappointing. I thought I could get at least 5 MB/s, but not even close. With the ISA bus at 66.6 /2 / 3, or 11.1 MHz, Speedsys reports only 1718 KB/s buffered read. That result is the same with the host controller's DMA set at 3.3 MB/s, 5.0 MB/s, or 8.0 MB/s. The only small boost is with DMA set at 10 MB/s, in which case the benchmark is 1935 KB/s. The default is 5 MB/s and there is a warning when you change it that some system don't support more than 5 MB/s and HDD corruption could result.

I made sure to shadow the BIOS address used by the card, which I have set to C8000h. Enabling or disabling this shadow had no affect. Why is it so slow?

I started wondering if SCSI2SD was at fault, so I pulled out my Slot A Thunderbird which has an Adaptec PCI Ultra160 and SCSI2SD benchmarked at 8722 KB/s. The interface on the SCSI2SD v6 only goes up to 10 MB/s, so SCSI2SD is working at its rated speed.

pshipkov wrote on 2021-09-09, 05:13:

So cap legs length - how real this is ? I mean outside of the theoretical formulation. So far I didn't encounter a case where th […]
Show full quote

So cap legs length - how real this is ?
I mean outside of the theoretical formulation.
So far I didn't encounter a case where this was a thing.
Also, many isa / vesa Diamond cards keep the tantalum long legged.
But I also do cap legs short.

Well bottom of page here is the theoreticals that started me thinking... https://web.mst.edu/~kosbar/ee3430/ff/transmi … ngth/index.html

Hmm, the last time i tried AHA-1542C was in the 50MHz 386 Symphony rig and it was gravitating around 5Mb/s reported by SpeedSys @10Mb/s SCSI BIOS speed setting. That uses one of those Acard SCSI-IDE adapters.
But ~2Mb/s on a next-next-next-gen 66MHz system is more humble than what i expected it to be when we made that bet in previous post.

@bitwrangler
You are going all scientific and everything now. 😀

feipoa wrote on 2021-09-09, 11:59:

To follow-up on my comment to use the AHA-1542CP card with a SCSI2SD HDD, the results are in and are disappointing. I thought I could get at least 5 MB/s, but not even close. With the ISA bus at 66.6 /2 / 3, or 11.1 MHz, Speedsys reports only 1718 KB/s buffered read. That result is the same with the host controller's DMA set at 3.3 MB/s, 5.0 MB/s, or 8.0 MB/s. The only small boost is with DMA set at 10 MB/s, in which case the benchmark is 1935 KB/s. The default is 5 MB/s and there is a warning when you change it that some system don't support more than 5 MB/s and HDD corruption could result.

I made sure to shadow the BIOS address used by the card, which I have set to C8000h. Enabling or disabling this shadow had no affect. Why is it so slow?

I started wondering if SCSI2SD was at fault, so I pulled out my Slot A Thunderbird which has an Adaptec PCI Ultra160 and SCSI2SD benchmarked at 8722 KB/s. The interface on the SCSI2SD v6 only goes up to 10 MB/s, so SCSI2SD is working at its rated speed.

Never used a SCSI2SD before, but I'm getting 2677kB/s using DISKTEST in DOS on my 286-20 (10MHz ISA bus speed) with AHA-1542B connected to a 2GB 7200RPM Barracuda drive. DMA speed jumper set to 5.7 MB/s