[rescue] sun 3/60 update

[Romain Dolbeau]

Le jeu. 29 mai 2025 à 16:46, Romain Dolbeau <romain at dolbeau.org> a écrit :
> Of course the real problem would be that the refresh logic might also
> need updating...

So after trying to figure it out for a while, I think the 3/60 does
some cas-before-ras refresh, one cycle every 12.8microseconds.

U115 divides the (20 MHz) CPU clock by 256, sending a pulse evert
(0.05 * 256) microsecond to the U106 PAL.
U106 holds that value until it sees R.ACK-, to make sure it happens.
Meanwhile, U106 put this request on R.REQ- and sent it to DVMA
register U130, where it is further sent to the DVMA PAL U131.as
R.REX-.
This PAL will then request the CPU bus (via the MC68020's /BR, /BR and
/BGACK signals) and when it gets it, it activates R.ACK-.
R.ACK- is widely distributed so that no-one does anything wrong (U102,
U103, ...), but more importantly:
- to U802, forcing all per-bank CAS signals active
- to U800, forcing all per-bytes RAS signals active
- to U804 (via an U108 gate used as an inverter), where I *think* the
goal is to bypass the normal CAS-after-RAS timings of memory access -
normally, this AND-OR-invert gate waits to enable CAS-
But it is not sent to U803, which controls the global RAS- signal,
which threw me off at first - as far as I can tell, the RAS- signal is
enabled on the "normal" timing for a memory access (base on /AS and
some delays).

In short: except maybe for the refresh rate (easily changed by a new
clock/divider combination), the refresh circuitry should work with an
altered version of the memory controller for 72-pins SIMM, provided
the "cheating" timing for CAS/RAS can be preserved.

Cordially,

-- 
Romain Dolbeau