> Hi all,
> I am hoping this list is still alive, since I'd like to find out a bit
more info about this backplane.
> It's part of an 11/23 system (based on CPU) that is made by Netcom. It
had
> standard DEC
> cards in it DLV11, M8021 bootstrap board etc. Apparently the system ran
a
> few years back
> before it was put in storage.
I have a few Netcom boxes at home. I'll try to remember to look
at what models when I go home.
> I aquired it, in the hopes of bringing it
> back to life and getting
> it to successfully display a login: prompt.
That would depend on the OS more than the hardware. :-)
> I have read through the archives, esp. a post from Michael Sokolov back
in
> 98, where he describes
> the different types of QBus'es. Q/Q, Q/CD etc.
> It looks like the backplane that I have (according to some documents
written at SLAC in late 70's)
> is a serpentine or sinusoidal.
> A diagram on the cardcage describes as follows:
> A B C D
> ------------>
> <-----------
> ------------->
> <------------
> There is also a blurb about slot 2/CD being wired differently. Two slots
on the diagram are pre-printed for RL controllers.
There were backplanes like that for the two card RL controller.
> My CPU card is a later rev. D so it can do 22bit addressing. I'd like if
possible to run 22bits, since this would allow
> me at a later time to put in a 11/73 cpu that would run 2.11.
I may be wrong (but I am sure someone here will correct me) but if the
backplane is designed for the two card RL controller I think it will be 18
bit and not capable of 22 bit.
> How would I go about checking if the backplane is wired for 22bits or
not.
> I seem to remeber the standard qbuses had the W1-W4 pins (?)
> that you could wirewrap to change from 18to22, but this backplane has
nothing like that.
I would guess you could look at it and see how many bits are wired thru.
And, if you have a clear view of the wirewrap side you should be able to
see if it has two A-B-C-D slots in the middle. Difference in wirewrap
pattern will be obvious. :-)
> Also, in the present configuration, with an 11/23 and 128Kw, could I run
v6 or v7 (assuming I can get some form of supported disk storage)? At
present
> I only have a floppy controller and a bunch of 8" Shugart 801 drives..
What floppy controller? Dec didn't use the standard Shugart 8" inteface
for RX01/RX02 disks. If it is like the Terak which also used 801's you
are going to need to find drivers for what OS you decide to use. Good
luck with that.
> thanks in advance for any replies.
You might try asking on alt.sys.pdp11 as there are a lot much more
knowlegable people than I active over there.
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill(a)cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Ian,
Thanks for the response and the pointer to the web page. Looks like I can run 2.9 on the machine - I just have to find myself some RL's 8-)
Did some digging around on QBus, and think i found enough info, that coupled with some contiuity tests should allow me to figure out exactly how the backplane is laid out.
regards
alex
----- Original Message -----
>From: "Ian King" <IanK(a)LivingComputerMuseum.org>
>To: "azd30" <azd30(a)telus.net>, pups(a)minnie.tuhs.org
>Sent: Wednesday, October 23, 2013 11:47:19 AM
>Subject: RE: Netcom HV-1148 QBus Backplane
>You would probably be better served on the ClassicCmp mailing list. This list is primarily about software, specifically Unix on the PDP-11.
>I'd have to dig to answer your question, and there's probably someone on ClassicCmp who can do so off the top of his/her head. (And I already have my hands full: I'm at work looking at bringing up an IFS to talk to a Xerox Alto.)
>Take a look at the PUPS webpage for more information on installing e.g., V6 or V7 on various machines. My recollection is that these versions have requirements in hardware, such as the switch register, that may make them unsuitable for a Qbus machine - but the PUPS page >has a section that can answer definitively. -- Ian
Hi all,
I am hoping this list is still alive, since I'd like to find out a bit more info about this backplane.
It's part of an 11/23 system (based on CPU) that is made by Netcom. It had standard DEC
cards in it DLV11, M8021 bootstrap board etc. Apparently the system ran a few years back
before it was put in storage. I aquired it, in the hopes of bringing it back to life and getting
it to successfully display a login: prompt.
I have read through the archives, esp. a post from Michael Sokolov back in 98, where he describes
the different types of QBus'es. Q/Q, Q/CD etc.
It looks like the backplane that I have (according to some documents written at SLAC in late 70's)
is a serpentine or sinusoidal.
A diagram on the cardcage describes as follows:
A B C D
------------>
<-----------
------------->
<------------
There is also a blurb about slot 2/CD being wired differently. Two slots on the diagram are pre-printed for RL controllers.
My CPU card is a later rev. D so it can do 22bit addressing. I'd like if possible to run 22bits, since this would allow
me at a later time to put in a 11/73 cpu that would run 2.11.
How would I go about checking if the backplane is wired for 22bits or not. I seem to remeber the standard qbuses had the W1-W4 pins (?)
that you could wirewrap to change from 18to22, but this backplane has nothing like that.
Also, in the present configuration, with an 11/23 and 128Kw, could I run v6 or v7 (assuming I can get some form of supported disk storage)? At present
I only have a floppy controller and a bunch of 8" Shugart 801 drives..
thanks in advance for any replies.
--
alex
How to to extract a ".tap" file? What tools?
I found http://man.cat-v.org/unix-1st/1/tap manual but I haven't found
corresponding tool (even in tuhs source code archive).
The file I am trying to extract is
http://bitsavers.trailing-edge.com/bits/BSD/BSD4.1_bootable.tap.gz (12
MB). I can view some of the plain text in it.
I tried historical ar (which I have used for some other 1970's images),
restore, and tar. file(1) says it is a "Maple help database".
Jeremy C. Reed
echo 'EhZ[h ^jjf0%%h[[Zc[Z_W$d[j%Xeeai%ZW[ced#]dk#f[d]k_d%' | \
tr '#-~' '\-.-{'
PRESS RELEASE - PLEASE COPY AND SHARE!
APPLE 1
FRIDAY, Sept. the 13th
at the "Museo dell'Informatica Funzionante" Computer Museum
Via Carnevale 17, 96010 Palazzolo Acreide (SR) - ITALY
http://museo.freaknet.org/en/presentazione-progetto-apple-1/
The APPLE 1 marked the start of the era of "personal computing",
a computer that people could keep at home on their desks, a
pioneer vision at that time, that opened the way for the future
of human-machine interfaces. Born from the genius of Steve
Wozniak, it transformed Apple into today ‘s success, thanks also
to the entrepreneurial audacity of Steve Jobs.
At that time only about 200 pieces were produced; today only
about 50 of them survived, of which only a dozen are fully
working. The APPLE 1 was an open project since its birth: he
schematics and instructions were already circulating among fans
well before the creation of Apple as a company. From this early
computer, Steve Wozniak created the legendary APPLE 2, a
colossal success that transformed him and Steve Jobs into
billionaires.
We started this adventure almost two years ago at the "Museo
dell'Informatica Funzionante" Computer Museum: to rebuild from
scratch, starting from a completely blank electronic card, a
working APPLE 1, using tools and components dated exactly or
before its creation: 1976.
A year and a half was spent searching for integrated circuits,
connectors, electronic components of various types, bought new
or second-hand, found in various parts of the world, but all
identical to the originals, with the right features and from the
same historical period. The project, managed by a local team,
involved fans and professionals from all the world.
So we present today our creation, made entirely in
Sicily, Palazzolo Acreide, Italy: a specimen of APPLE Computer
1, fully functional, rebuilt with attention to every detail and
using only original components at the best of our possibility!
With this release we intend to invite everyone to the event of
his first start, in person or remotely via our live streaming.
Friday, September 13, 2013:
19:00 - Presentation of the APPLE 1 project and the computer
19.30 - Booting up the rebuilt APPLE 1 Computer, and operational
demo
20:00 - Aperitif
Remote presence:
Via live chat on IRC: https://irc.dyne.org, channel #museo
Live video streaming: http://bambuser.com/channel/musif
On Twitter: follow @FreaknetMuseum
All people in Palazzolo Acreide can also have a guided tour of
our exibithion "Apple, il genio di Steve Wozniak", dedicated to
the genius of Steve Wozniak and his creations, with working
Apple computers and memorabilia from 1978 to 1999.
For more information, press kits and interviews please write to
museo(a)freaknet.org
Spam detection software, running on the system "www.oztivo.net", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
@@CONTACT_ADDRESS@@ for details.
Content preview: ÀÎÁõÆäÀÌÁö½Ã¾È1 [...]
Content analysis details: (6.0 points, 5.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
1.4 RCVD_IN_BRBL_LASTEXT RBL: RCVD_IN_BRBL_LASTEXT
[211.32.24.57 listed in bb.barracudacentral.org]
0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
1.1 URI_HEX URI: URI hostname has long hexadecimal sequence
0.0 WEIRD_PORT URI: Uses non-standard port number for HTTP
0.4 HTML_IMAGE_RATIO_02 BODY: HTML has a low ratio of text to image area
0.0 HTML_MESSAGE BODY: HTML included in message
0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60%
[score: 0.5000]
0.7 MIME_HTML_ONLY BODY: Message only has text/html MIME parts
0.8 RDNS_NONE Delivered to internal network by a host with no rDNS
0.0 T_REMOTE_IMAGE Message contains an external image
The original message was not completely plain text, and may be unsafe to
open with some email clients; in particular, it may contain a virus,
or confirm that your address can receive spam. If you wish to view
it, it may be safer to save it to a file and open it with an editor.
> CB/UNIX was developed to address deficiencies inherent in Research Unix,
> notably the lack of interprocess communication and file locking
CB/UNIX was one of several versions in various divisions of Bell Labs
to implement IPC facilities beyond pipes and signals. Top management
in a division would declare that they wanted to use Unix, but needed
some particular IPC mechanism: semaphores, events, message passing, etc.--
and needed it right away. I always believed that these demands stiffer
as they percolated up through channels to the point that no alternative
mechanism would do. We in research would have preferred to seek a
general solution that would suffice to serve the various demands.
Besides, anything that we produced but didn't use ourselves would
automatically be suspect. We were very wary of featuritis.
Roughly speaking, each demand led to a different local flavor of
Unix, each (I like to think) reflecting the particular variant of
IPC with which one of its system designers worked in graduate
school. Somewhere between the wariness of research Unix, where
an ethos of generality ruled, and Linux, which offers a dozen ways
to do anything, there must lie a happy medium--a medium that I
believe would be much closer to Unix than Linux. That, alas, has
not proved to be the way of open source.
All, I'll be moving house sometime in the next few months, so I thought
I would start scanning in the paper documents that I've got. I've just
completed the scan of the CB/UNIX manuals that Larry Cipriani sent in
a while back. You can find them here:
http://www.tuhs.org/Archive/PDP-11/Distributions/other/CB_Unix/
and here is the blurb I put in there.
Cheers,
Warren
CB/UNIX was a variant of the UNIX operating system internal to Bell
Labs. It was developed at the Columbus, Ohio branch and was little-known
outside the company. CB/UNIX was developed to address deficiencies
inherent in Research Unix, notably the lack of interprocess communication
and file locking, considered essential for a database management
system. Several Bell System operation support system products were
based on CB/UNIX such as Switching Control Center System. The primary
innovations were power-fail restart, line disciplines, terminal types,
and IPC features similar to System V's messages and shared memory.
So far we have a scanned copy of the CB/UNIX manuals which were donated
to TUHS by Larry Cipriani. Copies of the binaries and source code would
be much appreciated. There were two volumes of manuals. The first volume
held cbunix_intro, cbunix_man1 and cbunix_man1L. The second volume held
the remaining sections. The 'L' in the scans indicates local sections of
the manuals, i.e. those elements created and maintaned at Columbus.
In an e-mail from Larry, he asked a retired CB/UNIX developer about the
major features that were added to UNIX by CB/UNIX. Was it primarily messages,
semaphores, named pipes, shared memory? The developer replied:
Other things that immediately come to mind that we added first
in Columbus Unix were power-fail restart (myself and Jim McGuire did the
initial work) and line-disciplines and terminal types (Bill Snider did
the initial work). Hal Person (or Pierson?) also rewrote the original
check disk command into something that was useful by someone other than
researchers. Bill Snider and Hal Pierson were really instrumental in
taking UNIX from research and applying it to SCCS (Switching Control
Center System). I worked with them when I first hired on. When we
first used UNIX on an 11/20 with core memory it was written in assembler
(1974). It quickly went through "B" and we started using the C version
in early 1975 as I recall. We also did some enhancements to the scheduling
algorithms in UNIX to make them more "real-time" capable.
On Jul 24, 2013, at 7:00 PM, tuhs-request(a)minnie.tuhs.org wrote:
> What parts are missing from the archive mentioned by Poul-Henning Kamp?
>
> http://www3.alcatel-lucent.com/bstj/
>
> It has 1922 to 1983. I was assuming that missing issues like 1942 issues 2
> through 4 were not ever published.
I've got Vol 68, No. 8 October 1984, the second 'Unix System' edition of the BLTJ.
Additional articles on all things Unix:
Evolution of the UNIX Time-sharing system
Program Design in the UNIX System Environment
The Blit: A Multiplexed Graphics Terminal
Debugging C programs with the Blit
UNIX Operation System Security
File Security and the UNIX System Crypt Command
The Evolution of C - Past and Future
Data Abstration in C by B. Stroustrup - The first C++ mention that I know of in the Journal
Multiprocessor UNIX Systems
A UNIX System Implementation for System/370
UNIX Operating System Porting Experiences
The evolution of UNIX System Performance
Cheap Dynamic Instruction Counting
Theory and Practice in the Construction of a Working Sort Routine
The Fair Share Scheduler
The Virtual Protocol Machine
A Network of Computers Running the UNIX System
A Stream Input-Output System (D M Richie) - SYS V streams implementation description
David
Ken Thompson has famously said that the only thing he'd do
differently if he were to do Unix afresh would be to spell
"create" with a final e. The BSTJ cameo (or product placement?)
reveals another example: he'd spell Unix as an ordinary proper
name. Once the marketers had glommed onto "UNIX" as a trademark,
we were regularly badgered when when we tried to naturalize
the name. References to "Unix" in internal documents were
scrubbed to "UNIX" for external consumption. I'd like to think
that by exhibiting "Unix" in an image Netravali et al
intentionally cocked a snook at corporate orthodoxy.
Incidentally, the online BSTJ is complete. A new publication,
the AT&T Technical Journal took its place after 1983, with
a new format and quite different content. The replacement
publication was a house organ, not a research journal.
Doug
