[rescue] Sun 3/160 and CADDStation 32 deskside

Dave McGuire mcguire at neurotica.com
Thu Aug 14 18:34:47 UTC 2025


On 8/14/25 13:13, Romain Dolbeau wrote:
>>    One could easily fill the address space with some nice low-power, high-density surface mount SRAMs.
> 
> Not so easily, unfortunately; Sun-3 are just a bit too old or too
> modern for that.
> Too old because the MMU isn't built-in (like the '030 and later), too
> modern because it does have an external, discrete component MMU and it
> can't be ignored for timing reasons.
> 
> One would need to compute the timings based on the Physical Address
> (PA) bits coming from the 2-levels MMU, so after the delay of 2
> consecutive SRAMs. Possible, but slow - it would likely add at least a
> cycle or two of waiting on each access. With DRAM, machines like the
> 3/60 (the one I examined in detail) save time by using low-order
> untranslated address bits for RAS (available when the CPU assert /AS),
> and then the PA bits for CAS - as they are only needed after a fairly
> lengthy required delay between RAS and CAS.. That way they don't pay a
> huge latency penalty for having the MMU. It also limits how many bits
> can be used during RAS and therefore how much DRAM can be easily
> shoehorned into the 3/60 design (a side-effect is also that byte
> selection is done the "wrong" way CAS vs. RAS so 72-pins SIMMs aren't
> directly usable as replacement for a set of four 30-pins SIMMs...).
> 
> Of course this assumes you're putting the SRAMs directly on the CPU
> bus. However for an external board they would live on the P2 bus. From
> the pinouts (available in the 3/160 schematics, not sure where/if
> there is any available documentation of it), the P2 isn't just the
> '020 bus after translation; signals include "P2.CAS-", "P2.ENDRAS-",
> "P2.REFR-", which suggest some DRAM timings are handled by the CPU
> board. And some signals are missing, as I don't see e.g. DSACK[01]-.
> 
> Finally, 5V SRAM of interesting size aren't very cheap. One could get
> away with level shifters, but they also add costs and potentially
> latency.
> 
> We've thought quite a bit on how to expand RAM easily/cheaply on Dan's
> recreation of the 3/60, and it turned out to be a lot harder than what
> we originally expected :-(

   Ahh, dang.  Well, it was a thought.

            -Dave

-- 
Dave McGuire, AK4HZ
New Kensington, PA


More information about the rescue mailing list