Hello,
Since I need to make some more space here, the following systems are
for sale. Location is The Netherlands, I can ship internationally
(probably expensive), delivery in the southern part of the UK in early
August might also be possble.
HP9000/300 double-height enclosure (IIRC this was a 317, I'll have to
check).
HP-HIl audio extension 46081A
HP-HIL Mouse + keyboard
HP 7958 hpib disk
IEM HP-IB mass storage unit with 2 3.5" floppy drives
HP-IB cables + documentation
HP9000/310 with keyboard and mouse
and also some other stuff for sale:
Philips PC200 (rebadged grid XT laptop), power supply is broken but it
will also work on DC
IBM 43p/140: 332MHz processor, 256MB ram and 9GB disk
with regards,
Michiel
Johnny Billquist <bqt at softjar.se> wrote:
> Good thinking.
> But I'm surprised by some numbers here. The J11 at 20 MHz is
> only slightly faster than an 11/70. In fact, if you can throw
> the 11/70 into running all from cache, it might even be slightly
> faster than an 11/9x.
> Or so I seem to remember from looking at the numbers back when
> I last was digging into this.
>
> Maybe I'm mixing some numbers up here... What I do remember for
> sure is that the 11/9x machines run at 20 MHz, and that they are
> not more than maybe 1.2 times the speed of an 11/70 in general.
oops, you are right, I was mixing numbers here and forgot about
a factor of four. Here the revised arguments:
See http://www.village.org/pdp11/faq.pages/prfmnc.html , there
is a table comparing 11/70 with various J11 systems:
11/23 11/53 11/73 11/83 11/93
----- ----- ----- ----- -----
CPU F-11 J-11 J-11 J-11 J-11
Microcycle(ns) 300 267 267 222 222
Clock (MHz) ? 15 15 18 18
Performance 0.2 0.5 0.7 1.2 1.4
(11/70 = 1)
Cache no no yes yes no
Floating-Pt opt no no yes yes
Coprocessor
My mistake was to forget that the J11 needs 4 clock cycles per
microcycle (MC), that's why 18 MHz clock leads to 222 ns MC period.
In the end the J11 (222ns MC) is faster than the 11/70 (150 ns MC)
because it has a better micro architecture (three stage pipeline
vs. instruction prefetch only). The J11 is roughly a factor two
better compared to 11/70 in terms of MC efficiency.
The w11a on the other side does one microcycle per clock cycle. So
one can expect that is roughly a factor 5.5 faster than a 18 MHz J11
(MC rate is 11 times higher (50/4.5), but J11 has a factor two better
MC efficiency).
Let's look at the Dhrystone benchmarks again:
w11a 11500 lps
11/53 830 lps
So the w11a is measured to be ~14 faster than a 11/53. The 11/53
has half the performance of a 11/70, so one expects that the w11a
is about a factor 7 faster than a 11/70. Because w11a and 11/70
have a similar micro architecture that should match the MC rate,
and indeed it does (50/6.7). So the numbers are consistent, finally.
Thanks for pointing that out.
Walter
Johnny Billquist <bqt at softjar.se> wrote
> You do know that the J11 is already designed for mP usage, except that
> DECs testing of that was even more secret than the 11/74?
Sure, the mP instructions WRTLCK and the TSTSET of the J11 are
documented, and allow cleaner way to implement spin locks than
the 'asrb hack' of the 11/74. In a future version of the w11a I'll
probably also implement the instructions supported by 11/34 and
J11 and make the 'processor profile' selectable at start time, much
like in the simh simulator.
> But FPP is among the most important things in there as well, I'd say.
> Lots of software who won't be happy without it.
That's true from a performance point of view. However
- you can run RSX and Fortran without FPP (did this 30 years ago
when the FPP broke on the 11/45 I was working with...).
- you can run 2.11BSD without FPP (I'm doing that each time I
boot 2.11BSD).
So a FPP is very good to have, but not my highest priority. Also,
it's quite a project to design, implement and verify it, with the
verification, as usual, being the most time consuming part.
> By the way. You don't have to worry about cache coherency. The
> PDP-11/74 do not do that. Cache coherency is managed by software
> on the PDP-11 (well, in RSX, since that's the only system that
> supports the hardware). In short, the real hardware do not implement
> any sort of cache coherency in hardware.
I know, but I'll go for a cache with full cache coherency. That will
make it a lot easier to try a MP hack for 2.11BSD. And RSX, if I ever
get to it, will not mind.
Walter
Johnny Billquist <bqt at softjar.se> wrote:
> I wasn't aware that any prototypes ever were produced and came as
> far as being functional. I thought it was just paper work that
> had bee done.
The 11/74 wasn't marketed, as pointed out in this thread, but a
few systems were build by DEC. A picture of such 11/74 system
was made available by Tim Shoppa, see
http://www.trailing-edge.com/~shoppa/1174Xopen.jpg
You'll nicely see the four CPUs.
arcarlini at iee.org wrote:
> I've read somewhere that it [PDP-11/74] was full of flat ribbon
> cables and would have been a beast to maintain.
Well, you see on the picture that there was quite a bit of
flat ribbon cables :).
The 'PDP 11/70 Multiprocessor Technical Manual (Preliminary Version)'
is on bitsavers, see
http://www.bitsavers.org/pdf/dec/pdp11/1174/EK-70MP-TM_PRE_1170mp_Prelim_Te…
and gives you a feeling of the modules and interconnects.
Walter
Hi, Walter.
"Walter F.J. Mueller" <w.f.j.mueller at gsi.de> wrote:
> Johnny Billquist <bqt at softjar.se> wrote:
> > > "Walter F.J. Mueller" <W.F.J.Mueller at gsi.de> wrote:
> > > I've also implemented a PDP-11 on an FPGA. It is a full 11/70 with
> > > split I&D, MMU and cache. No FPP so far. Available peripherals are so
> > > far DL11, LP11, KW11L, PC11, and RK11. All I/O is channeled over via
> > > 'remote-register-interface' onto a single bi-directional byte stream
> > > interface, so the FPGA board needs a backend PC with a server program
> > > to handle the I/O requests.
>
> > Any plans on the FPP? It would be really nice and useful to have.
>
> Hi Johnny,
>
> sure, an FPP is on the 'todo-list', but it doesn't have the highest
> priority. After having put the first version on OpenCores I'd like to
> add a trace/debug unit (allowing hardware breakpoints ect), and add
> a few more peripherals, especially larger disks. Currently I have
> only an RK11 controller, good enough for proof-of-principle, but
> not enough for real usage.
Disks are definitely a good thing. And as usual, I'll advocate MSCP.
Even though it's not the simplest, it's simply just the best. :-)
But FPP is among the most important things in there as well, I'd say.
Lots of software who won't be happy without it.
> > As for traps and double errors, feel free to ask. I don't know if I have
> > all the answers, but I might be able to figure them out. Besides, I also
> > have access to one (or three) functional 11/70 machines.
>
> I've tested much of the implementation against simh and xxdp's, but there
> are still a few loose ends regarding corner cases. It be great to run a
> few test programs on simh, a real 11/70, and my fpga implementation,
> called now w11a.
Feel free to talk with me more offlist, and we can see when we can
schedule some testing on real hardware.
> > The 11/53 is a really slow machine. Not that helpful to compare with. But you
> > seem to push a nice number anyway. But 50MHz... The J11 in an 11/9x machine
> > runs at 20 MHz, which would suggest that you should only be able to push about
> > 2.5 times the performance, unless you do some more clever tricks.
> > (The 11/9x machine runs all memory as cache.)
>
> I know, but the 11/53 is the only pdp-11 where I know the Unix Benchmark
> and thus the Dhrystone results, so it became the reference.
>
> Even though my implementation is quite different from the organization of
> the original 11/70, it has essentially the same instruction timing as a
> 11/45 or 11/70 when expressed in clock cycles. The 11/45 or 11/70 CPU's
> ran with a 150 ns clock period (ignoring clock stretching here), thus a
> 6.7 MHz clock. A register-register operation takes 2 cycles, a
> "mov r0,(r1)+" for example 5 cycles.
>
> Because the cpi (cycles-per-instruction) for 11/70 and the w11a is very
> similar and both have a good cache the w11a should simply be 50/6.7 or a
> factor 7.5 faster than a 11/70.
>
> The 11/70 and the w11a have some pipelining, instruction fetch and
> decode/operate can overlap for register destination instructions. The
> J11 is more pipelined, here fetch, decode, and operate stage can overlap.
> Therefore register-register instructions take 1 cycle in the best case,
> a "mov r0,(r1)+" for example 3 cycles.
>
> Therefore a 50 MHz w11a will not be 2.5 times faster than a 20 MHz J11,
> maybe just 1.5 times faster. The w11a is intentionally implemented in a
> quite simple and conservative way, prime goal was to get it right and
> working, and not to get it fast.
Good thinking.
But I'm surprised by some numbers here.
The J11 at 20 MHz is only slightly faster than an 11/70. In fact, if you
can throw the 11/70 into running all from cache, it might even be
slightly faster than an 11/9x.
Or so I seem to remember from looking at the numbers back when I last
was digging into this.
Maybe I'm mixing some numbers up here... What I do remember for sure is
that the 11/9x machines run at 20 MHz, and that they are not more than
maybe 1.2 times the speed of an 11/70 in general.
> At some later time maybe I'll try a really fast design, with separate
> instruction and data caches and significantly more parallelism than
> the J11 had.
Hmm. I wonder if that might cause headaches? There might be code out
there that require your i-cache and d-cache to be consistent with each
other.
> > IIST is needed for RSX to be happy (the only OS that supports the 11/74),
> > and you also need to implement parts of the memory bus behaviour with
> > interlocking. You can ignore the MK11 box CSRs, even though it will look
> > a little funny, but you do need separate DL11s for each CPU core, along with
> > the rest of the I/O bus, or else things will probably not work. The 11/74
> > is a shared memory machine, but not shared I/O bus.
>
> I'm fully aware of this, the MP version will have one I/O bus per CPU and
> a shared memory and asrb interlock, and caches with proper cache coherency.
Yes. But what I was thinking of was the fact that at a level below this,
you have the CPU that be issuing read-modify-write cycles to memory, and
those needs to be interlocked to memory.
At a higher level, the 11/70 was modified for asrb to always bypass
cache, and then you had two other ways to bypass cache as well. But
bypassing cache is only half the problem, as you also need to make sure
some memory operations are atomic, as seen from other cpus.
But if you know a thing or two about cpu and memory design (which it
would appear you do), then you probably understand the problem already.
By the way. You don't have to worry about cache coherency. The PDP-11/74
do not do that. Cache coherency is managed by software on the PDP-11
(well, in RSX, since that's the only system that supports the hardware).
In short, the real hardware do not implement any sort of cache coherency
in hardware.
> It's true that RSX is the only OS that supports an 11/74. Unfortunately I
> don't have an RSX11-M plus license. So the plan is to patch 2.11BSD to support
> an MP system. Sounds like a long shot, but looking into the kernel sources
> I concluded that a funneling or 'big kernel lock' type MP support seems to
> be quite feasible. Will not scale well, but for a 'dual-core' this is likely
> good enough.
It's definitely doable. However, it is not that simple.
The reason why DEC choose RSX as the OS for implementing multi-processor
support is that it does not, in general, use interrupt priority levels
to serialize access to data, protect sections of code, or implement locks.
Unix do. So, in short, everywhere where the interrupt priority is
changed, you potentially need to change the code, since another
processor might still get interrupts at that level, and do things you
thought you had locked out.
But I see your problem. It would be great if we could solve the
situation with RSX at some point...
Johnny
>> 140420130808
> Looks like a 5ESS ate it, from the other material for sale in this lot.
They all seem to have Dilog CU160's. What was the CU160? Disk, communications?
My bet is the seller was once one of the Boston-area DEC used equipment dealer of the 70's/80's, who is now into Telecom instead.
Let's see, in the late 80's: American Used Computer was already pass? (wasn't he in Boston?). ELI was big. Who else was there? I used to know all the names by heart. There were several who weren't as big as ELI but still worthwhile.
Tim.
Item number:140420111955
If someone in Europe would be interested I should like to arrange it to get
one. Of course the price is high but It allows to make an offer.
Sergio
2010/6/15 Jim Stephens <jws at jwsss.com>
> Does anyone have some Prodos and or other software for one of these? My
> supply is locked up, and I don't know if I ever had Prodos.
>
> The system I'm getting had its prodos floppy stepped on by a misque long
> ago, and it was overwritten, so at a minimum I would appreciate that.
>
> I could send the damaged disk and let you overwrite at my expense as an
> alternative if media is a problem, or I can dig for some blanks in my pile.
>
> thanks
> Jim
>
