> From: Wilko Bulte <wkb@chello.nl>
> X-PGP: finger wilko@freebsd.org
>
> On Sat, Apr 15, 2000 at 08:59:23PM -0400, der Mouse wrote:
> > >>> 30->72 pin converters
> > 
> > >> The surface-mount ICs are 14-pin and hence have pin count enough to
> > >> be address buffers (data buffers are, of course, unnecessary).
> > > Databuffers are not unecessary, RAM chips give substantial capacitive
> > > loading!  You have 4x the number of RAM chips compared to typical
> > > 72pin SIMMs.
> > 
> > Yes - but each *data* line is still connected to only one chip.
>
> But via substantially longer PCB traces. Anyway, these adapters are
> not a very good idea on any system.

For the RAM trivia collectors, a couple of subtle problems with RAM
socket gizmos is:

	The older ram cards they adapt are often two-layer, whereas
	the vanilla 70 nS FPM modules invariably have ground and power
	planes. So, high - Z traces with Z discontinuities and multiple
	long forks. (Www, forks in transmission lines attract evil.)

	The only good way to make RAM arrays on PCB boards with SIMMS is
	to use fairly thick traces and try to get the loads to lump together
	rather than look distributed on a transmission line .. the gizmo
	defeats that. Sadly, many board designers don't start with a good
	RAM design in the first place (high speed signal integrity not
	being well understood by many, especially in the old days) and so
	the design is often marginal to start with.

> > >> I can trace many of the etch runs on the adapter, and it certainly
> > >> looks as though the surface-mount chips are address buffers.
> > > Or address decoding.
> > 
> > Except there's no address decoding necessary on the adapter.
>
> Well, I wonder why they would not use standard data buffer chips instead
> of logic gates (F04, F08)?

Because standard data buffer chips are bigger physically, slower, a lot
more expensive, and use more power. The chips are there to isolate, not
to produce a lot more DC drive than a 72-contact SIMM DRAM would have had
anyway. And extra drive makes the transmission line problems worse, not
better.

> > > If worst come to worst I can maybe find you a 21066/166Mc chip.  Will
> > > have to do some digging.
> > 
> > It'd probably cost more to get it to me than it would for me to get one
> > locally. :-)  Besides, I wouldn't worry about it unless the machine
>
> Dutch PTT is not so greedy ;-) for a small packet.

Sadly, should your axppci33 actually work "perfectly", it's lack of speed
will be so pronounced that the distinction between "perfect" and "broken"
will be meaningless.  Sorry to be discouraging, but you need to know this
before you spend too much time beating your head against it...

Having said that, cjs somehow managed to build a set of snapshots and
a release or two on one. Don't ask me how.

Those come with and without cache, BTW. I'm not sure what the speed
contribution of the cache is, although it feels funny to even use
the word "speed" when referring to an LCA box. :-)

Now, having discouraged you from even caring, if you do want to try
a really deep hack you might be able to make a marginal kernel reliable
with a custom set of bank timing registers. The LCA has an integrated
DRAM controller, see page 5-20 in ec-qc4ga-te, which I think you already
got but anyway is at

	ftp://ftp.netbsd.org/pub/NetBSD/misc/dec-docs/ec-qc4ga-te.ps.gz

It's not a true fix, because (1) the SRM settings have to work well enough
to get the kernel loaded and (2) those registers are write-only (!@#!) so
you don't get to tweak them, you can only just load really conservative
values in.

	Ross