Gentle persons:

I love these stories!

I'm sorry, Gene, that you had such a bad experience. I can only protest 
that a PDP11/23 wasn't a *real* PDP11. It came out nearly a decade after 
the 11/20, had an LSI-based CPU instead of a boatload of M-series logic, 
used the Q-bus instead of the Unibus, and (the most telling point for 
me) didn't have a *real* front panel. All this is just rationalization, 
of course. The truth is, you had to deal with a lemon at a time when DEC 
was already beginning to reel from competition and market conditions.

I (technically my advisor, since it was his grant money, but it was my 
lab partner and I who made the case and wrote the requisition) took 
possession of the third PDP11 sold out of DEC's Chicago office. As 
affordable as it was, it was so expensive compared to our research 
budget that we had to buy the CPU, ASR33 teletype, and power supply out 
of one grant, the 4(yes, 4!)-Kiloword core memory module out of another, 
and the high-speed paper tape reader/punch and relay rack out of a 
third. The system pictured on the home page http://hampage.hu/pdp-11/ 
might as well have have been my system.

The model line was so new that my escutcheon plate said "PDP11" and not 
"PDP11/20" as it did on later machines. It was so early in the 
production cycle that I got documentation in the form of a set of 
E-sized drawings red-lined with the ECOs installed during manufacturing 
and a bunch of prepublication drafts of manuals. Of course, all those 
last-minute ECOs meant my backplane was chock full of colorful 
wire-wrapped patches. With the exception of inevitable core-memory 
issues (what minicomputer maker didn't have to run core-memory tests all 
the time?), the only real problems I ever had over the years were 
inevitably the result of forgetting to observe proper Unibus etiquette 
or screwing up my wire wrapping.

When I complained about the lack of software documentation, the DEC 
Field Service Engineer surreptitiously passed me a number of source-code 
distributions which I cheerfully pored through at night while my 
experiments were running. It didn't take me long to discover that some 
of the early software was actually PDP8 software mangled so a PDP11 
could interpret it, albeit slowly (not nothing did the PDP11 instruction 
set include the EMT, or emulate trap, instruction). I was the best of 
friends with the Chicago office after I showed them my version of 
BASIC-11 running 4 times faster than theirs because I had replaced the 
emulated instructions with native code. I didn't do it for them. Real 
men wrote only in assembler or directly in machine code. I had to make 
BASIC work well because my advisor was hopeless with anything else and 
he had some experiments of his own to run.

In defense of my taking up bandwidth on the EMC mailing list, the reason 
we bought this PDP11 was to control and monitor a very large and 
complicated experimental apparatus. Like a fly-by-wire aircraft, this 
system would have crashed and burned if it weren't for computer-based 
real*-time command, control, data acquisition, and processing.

*I say "real" time, but keep in mind this was the early 1970s. I wrote 
my software and meticulously counted cycles before RSX11M or its 
country-cousin RT11 were available. Later, I got to spend some time 
debugging an RSX11M program as a favor to a medical researcher at the 
same university. Yikes.


Regards,
Kent


------------------------------------------------------------------------------
_______________________________________________
Emc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users

Reply via email to