1 Jan
2009
1 Jan
'09
2:46 p.m.
Guy Sotomayor <ggs at shiresoft.com> wrote:
There are built in limitation in the bus which always will cause it to
be much slower than running against cache. This should be obvious when
we talk about an asynchronous bus. You have a protocol with handshakes
and acknowledges that goes back and forth for each memory access. And
each of those phases of the protocol needs a minimum time.
Of course, the 600ns minimum times of the MK11 are are partially because
of the limitations of the MK11, but exactly how much you should blame
each half for is unknown.
After all, the access times for the memory chips in the MK11 box are not
anywhere near 600ns.
Definitely overkill. But there is nothing wrong with overkill, as long
as it don't cost a lot extra.
:-)
I think I have the drawings somewhere, along with a bunch of manuals
that aren't on bitsavers either.
One of these years I really should try to get it scanned, or
something... (Along with a bunch of other documentation that I have
lying around for various DEC stuff...)
And as someone else said, the MJ11 drawings should also be good for the
information you're asking for.
(And yes, I've kept one real MJ11 around, just for nostalgia. But it's
not hooked up.)
I also have some third party memory boxes. I think they were made by
Plessey. You could try find something from there as well.
Johnny
On Dec 31, 2008, at 6:14 PM, Johnny Billquist wrote:
Still, the level of integration today is much higher. So if it could be
done 20 years ago, it should definitely not be a problem today.
Remember, SETASI did this on a hex card something
like 20 years ago,
if not more. Most of the area was probably memory chips, which can
be reduced extremely much by now.
Actually, they used some surface mount for the memory chips. The
memory was pretty dense on that board but certainly not the majority
of the area. And to make a
few comments on other stuff that's been mentioned.
You don't seem to appreciate the speed of things on the memory bus.
A read cycle form the MK11 was typically something like 600ns, and
could be as much as 1200ns (when error correction was required), if
I remember right. Write was just as bad, while modify was worse. The
max speed possible is still much lower than 150 ns, which is what
the CPU will run at when you have cache hits (assuming my memory is
right). There is setups, handshakes and signal propagations on a big
bus involved.
I thought that was driven by the memory and not the memory bus. There
appear to be some minimum timings (50ns & 100ns pulses) but from what
I could tell from the docs, the speed was dictated by the MK11s and
not necessarily the memory bus. Of course there are deskew times as
well. I'll have to go into it in more detail though. If this were 15-20 years ago, I'd agree that speed
would be a
principle concern, but space and power seem to be more important these
days. Given that this solution (just like the PEP-70/Hypercache) is
completely reversible I don't see a fundamental problem with this
approach.
Me neither. As I said before, if someone wants to do it, I'll definitely
not try to prevent it.
But it's not something that I find particularly interesting myself.
I mostly do this stuff out of interest in preserving
the systems in as
much of a runnable state as possible. All of the the 11/70s I
acquired over the past few years have been CPUs only. There have been
no memory boxes (or peripherals of any kind). I haven't been
particularly worried about this issue since I also managed to acquire
a fair number of PEP-70's & Hypercaches. But I suspect there may be
other people out there that aren't as fortunate and want to run an
11/70 without having to have large numbers of racks. I don't worry
too much about space/power since I am restoring a 2065 after all and
11's pale in comparison (but I'm also planning to do a memory
replacement for that too which is where I discovered the SSRAMs since
they are the perfect geometry for a '10).
Well, both the 11/70s around here have enough memory as it is, so that
if anything, it's the speedup that I'd be interested in.
Power...? Well, we have two -2060s, as well as two VAX-8650 around as
well. Compared to those, the 11/70s are nothing. :-)
The biggest power consumer is the memory system of the DEC-20 by the
way. It uses a linear power supply... Heavy as hell as well. :-)
(I couldn't possibly talk you out of a HC-70/PEP-70 combo would I?
Anything you might want in return?)
70ns memory
will definitely be sufficient for whatever we would
design.
I plan on using 200Mhz SSRAMs 'cause they're relatively easy to
interface to. Of course, this is way overkill (5ns memory access
times) for this but they're cheap (~$8/ea and only 2 would be
needed). I probably won't clock it that fast. I figure something on
the order of a 40MHz base clock (25ns) would give me enough
granularity for any timing that would need to be done. I very much
doubt that we'd have any problems getting it all into
one or two cards.
One advantage of replacing the cache is that then we'd definitely
just talk TTL. No buses with drivers at all.
Much simpler and cheaper from that point of view.
The driver/receivers are my principle concern. I did find a bus
transceiver last night that's open-collector on one side and tri-state
on the other. That simplifies things *alot* if it's compatible
(though I suspect that with a 4-8" run of cables almost anything would
work). Now if I could just find one that was LVTTL on the tri-state
side I'd be happy (it would eliminate level shifters). :-) Absolutely
best would of course be if we could find drawings for the
HC-70/PEP-70 combination, and use those as the basis for a design,
and just improve by using current available technology.
That would be ideal. However, does anyone have drawings for the
MK11? The most I could find was the tech manual on Bitsavers. I
mainly want to understand the transceivers a bit more.