I also added a shot compat. table here:
http://rayer.g6.cz/hardware/retropc2.htm#SIMM_4MB_AG3

RayeR wrote on 2026-02-11, 06:58:

When I used CLI, HLT sequence the CAS# locked high and RAS# had short low pulses every 64us.

CAS# permanently high and RAS# short low pulses at a regular interval perfectly sensible to /RAS-only refresh. In that mode of operation, the address lines need to count up (I would expect A0 to togle on every RAS pulse, A1 at every second, A2 at every fourth, A3 at every eight and so on). On the other hand, "every 64µs" sounds wrong, unless every 64µs there is a burst of 4 RAS pulses refreshing 4 rows. Unless you have low-power SIMMs, an average period between refresh cycles of 16µs is required according to the specification, not 64µs. Some boards have a "slow refresh" option that is intended to skip 3 out of 4 refreshes, which could explain the 64µs cycle if that option is enabled.

RayeR wrote on 2026-02-11, 06:58:

On MX chipset the CAS# pulses has much more longer period 55ms... Hidden refresh was enabeld. On Octek Panther there's no such option only wait states.

On none of your scope pictures there seems to be any evidence of CAS-before-RAS refresh. 55ms is the period of IRQ0, so possibly something happens to /CAS when an interrupt is generated? I wouldn't have expect that in a CLI/HLT situation. The Soyo board is very busy with /RAS. Does /RAS generally oscillate at a period of 1250ns (1.2µs), or is it just that shape close to the /CAS spike? Anyhow, as /CAS is high most of the time, the refresh is clearly /RAS only, and that only only works of you get 16ms of refresh cycles in which A10 is low followed by 16ms of refresh cycles in which A10 is high. You should be able to see that on your scope at a 10ms timescale. The images at 5µs timescale posted in Re: 386 Systems and Memory Instability With 4mb SIMMs? (Errors) are not very helpful on its own, as there are valid intervals of 512 successive refresh cycles in which A9 is high (i.e. pulsing) while A10 is low, as there are valid intervals of 512 successive cycles in which both A9 and A10 are high. If you looked at the scope for some time, and A10 was never pulsing, that's clearly bad, though.

mkarcher wrote on 2026-02-11, 21:49:

The images at 5µs timescale posted in Re: 386 Systems and Memory Instability With 4mb SIMMs? (Errors) are not very helpful on its own, as there are valid intervals of 512 successive refresh cycles in which A9 is high (i.e. pulsing) while A10 is low, as there are valid intervals of 512 successive cycles in which both A9 and A10 are high. If you looked at the scope for some time, and A10 was never pulsing, that's clearly bad, though.

I can tell that I tried to vary the timebase to low range but no any pulses on A10 at all...
I'm not sure if I executing CLI HLT couldn't affect the refresh if it's driven by interrupt/timer but as A9 doesn't stop...
In that case the CAS# locked high all the time so as I was not sure if I didn't just stop the refresh so then I scoped during boot instead after CLI HLT. So yes, it't possible that the timer ISR generated some CAS# activity itself and it would be RAS# only...

On my Acer SIS Rabbit 386DX chipset if I want to use 4x4MB RAM I need to add one CAS latency. I can only run lowest CAS on 3x4MB RAM. All 60ns chips at a normal 33MHz bus speed.

I'm sure there is some instability going on.

OK, please can you write exact type of your MB, chipset and CPU?

UPDATE: I found datasheet for chips 82C351 chipset: http://oldcomputers-ddns.org/public/pub/rechn … ips_cs82310.pdf
There's mentioned it supports:
* up to 128MB RAM
* prog. WS and RAS precharge time
* supports 256k, 1M, 4M DRAMs in cfg. up to 8 banks
* supports staggered RAS during refresh
* supports AT style refresh (strobing row address RAS# 0:7 while CAS# remains high)
* supports hidden refresh
no explicit mention about CAS before RAS...

The Chips 82C351 chipset supports 128MB, but all motherboards I've seen only implement 32MB (8x SIMM slots). The other lines are attached to a custom bus slot nearby and support an additional 32MB - if you were to make a custom card with the extra RAM slots. Two motherboard jumpers specify which of the RAS/CAS lines are used.

My 386DX is an AcerPower V5 motherboard, SIS 310/320/330 chipset. 4x 72pin SIMM slots. CPU is a DX4-100 ODP because it has a 486 socket.

Have you tried adding extra CAS latency in BIOS settings?

Yes I tried the laziest timings but no way. As with default settings the 1MB 70ns modules works fine while 4MB 60ns not so I think this points rather to refresh issue than timings.

On 486 systems I wouldn't expect such issues, esp. on those with 72p SIMM modules as the memory chips I used was desoldered from a 72pin module... Some chipsets was probably made for both use with 386 and 486 so 386 MBs using them should run OK...

RayeR wrote on 2026-02-14, 00:11:

Yes I tried the laziest timings but no way. As with default settings the 1MB 70ns modules works fine while 4MB 60ns not so I think this points rather to refresh issue than timings.

As we confirmed on the scope that the boards use /RAS-only refresh, at least while the system is idle (CLI/HLT), you can verify refresh issues by checking that both A9 and A10 are sometimes high and sometimes low during refresh. Suggestion: trigger on /RAS, falling edge, second channel A10. The level of A10 during trigger is relevant. You should see both clearly high and clearly low samples. Depending on the refresh mode of the scope, possibly enabling persistence might help to see whether in fact "high" and "low" rows are refreshed.

Another, less scientific, but equally effective way to validate refresh issues: The requirement of refreshing 2048 rows only applies most to 4M*4 chips, but not to most 4M*1 chips. So if your issue is caused by bad refresh addresses, 9-chip 4M modules should work.