My first unibus-pdp...
I picked up the box this weekend, without any additional equipment or
information.
They also told me is is configured for a 20 mA current loop, but i don't
have a working current loop term. is there a easy way of converting 20mA
current loop to RS-232 ?
I found a posting in classiccmp that says M7090 might be configured for
RS232 or current loop(i don't know if they meant the MUX or the CIM M7090
or both), is there a way to find out without blowing things up ? i do have
a VT420, maybe i can do current loop <-> rs422 ?
i didn't power up the box yet, first i'd like to connect the correct
console and check the configuration. maybe reduce the configuration to
RL11, DEUNA and disk-controller? another problem is the media, i'd like to
install 2.9BSD, but how ? i still hope that one of those unidentified cards
turns out to be a ciphertape-controller (Pertec-interface for my second
cipher F880).
any help, information or link is very welcome.
-- regards, lothar
This is the actual configuration:
<-power supply / frontpanel->
M 7090 - - - - dual height KD11-Z 11/44 console interface module
- - - - - - empty (this is where the optional CIS belongs)
------M 7093------ hex height FP11-F 11/44 floating point module
------M 7094------ hex height KD11-Z 11/44 data path module
------M 7095------ hex height KD11-Z 11/44 control module
------M 7096------ hex height KD11-Z 11/44 multifunction module
------M 7097------ hex height KK11-B 11/44 4-Kword cache module
------M 7098------ hex height KD11-Z 11/44 UNIBUS interface
------M 8743------ hex height MS11-PB 1-Mbyte ECC RAM (-BH)
- - - - - - empty
------M 7486------ hex height UDA52 Controller for SDI disk drives (UDA
SI)
------M 7485------ hex height UDA50-A UNIBUS to radial disk interface
------M 7762------ hex height RL11 RL01/02 disk controller
M 9202 ---M 8729-- dual height M9202 / quad height M8729 no info.
M 9202 - - - - empty (badge says hex SPC slot)
- - - - - - empty
- - - - - - empty
- - - F - - empty, F is a bus grant continuity (single height)
------SC4110------ hex height
------M 7814------ hex height DZ11-C 8-line 20mA data MUX, 50 to
100-Kbaud
------M 7792------ hex height see below
------M 7793------ hex height see below
- - --Ramtek--- quad height no info
- - - - - -
addition to descriptions:
M7485-YA UDA50-A UNIBUS to radial disk interface PR board with blasted
ROMs
M7792 DEUNA port module, UNIBUS to ethernet microprocessor. (1 of 2)
M7793 DEUNA link module, M7792 to ethernet bus line unit. (2 of 2)
i don't have any reliable description for the M8729, i found a with google:
"DRU-11 CA" parallel DMA.
the SC4110 (Emulex) is probably a SMD disk controller, at least the heavy
disk was attached to it.
there are two cards for which i found nothing:
Ramtek 508295/508297 (has a 50 pin connector)
Eikonix 821-015cs (handwritten: 785-283)(has two 50 pin connectors)
while cleaning the box i found three bus grant continuity cards (single
height). it is possible they fell out during transport.
i've read akos varga's unibus basics, but i still can't tell if this is a
valid configuration. i found a badge on top of the box, which says the
M8729 is in a SPC slot and the "second" part of the M9202 is in a hex. SPC
slot.
Warren wrote :-
>I think the phrase `successor systems' covers PWB, as PWB is derived
>from 6th Edition. Yes, I suppose we could ask for Mini-UNIX, PWB,
>Mert, RT and TS also to be added to the list.
I'd really like to get my hands on MERT, but past correspondence from DMR
suggests that it was probably never released outside the labs. So, are there
any tapes lying about?
Any hints on making the v7_rk05_1145 boot image work with Ersatz11 v3
demo?
John Perkins Willis
Software Engineer/Database Architect
Ariel Technologies
(505) 524-6860
jwillis(a)arielusa.com
In article by Fred N. van Kempen:
> Isn't PWB more closely related to USG and/or Sys III ?
> --f
SysIII is related to PWB and TS, which means both PWB and TS came
before SysIII and so are covered by the Caldera license.
I still have a number of PWB `things' in the archive: supposed releases,
parts of releases, etc. I need to sit down one day and try to reconstitute
a canonical release set from these bits and pieces.
Warren
In article by Lars Buitinck:
> ftp://minnie.tuhs.org/UnixArchive/COPYRIGHTS
> says "See Caldera-license.pdf for [Caldera's] license conditions
> for thrse [sic] systems," where "these systems" includes PWB.
> The Caldera license doesn't even mention PWB. It's (apparently)
> still illegal to copy PWB (unless they consider it a version of
> V6?). I don't think they'll prosecute you for it (:-) but I'd
> change it anyway.
> Lars
I think the phrase `successor systems' covers PWB, as PWB is derived
from 6th Edition. Yes, I suppose we could ask for Mini-UNIX, PWB,
Mert, RT and TS also to be added to the list.
Cheers,
Warren
P.S I'll fix thrse at least :)
hi all, here's asbesto from FreakNet Medialab in Catania, Italy.
our pdp11/34 is still alive !!!
the local mayor and the municipalty shutted down electric power in our
old place. now we have a new place for our computers (here in italy
we have a really bad politic situation so the municipalty hate us)
the pdp11 was so cutted in parts and mounted again, and it seem
working ... only a weird sound come from the rl01 disk when working.
it SEEM the sound of the disk head "touching" the disk .. maybe ?
the disk is ok and a copy test of all files is working.
any idea ? :)
p.s. soon i will ask HELP to install any kind of UNIX on this pdp11/34:
we have no tape. only 8" floppy disks and the rl01 (and, of course, serial
port for terminal & printer)
sorry for my bad english, i'm very tired now
to know more about us, http://www.freaknet.org
gabriele "asbesto"
Hi,
On 03/03/2002 01:47:34 AM PST "Steven M. Schultz" wrote:
>
> Glad to hear you're current and are not seeing 'df' weirdness. You
> may want to upgrade P11 to 2.9 though - that would, I think, have
> fixed that problem before you saw it ;)
No, wouldn't :-)
I used 2.10a all the time.
regards,
chris
On Mon, Jan 28, 2002 at 10:03:45PM +0100, Jonathan Naylor wrote:
> With so much open source code out there, it'd be a relatively simple
> task to find C code for IDE disc access and such like. I would even
> suggest getting older Linux code from the 2.0.x days as its likely to
> be a little less complex, while still being stable.
Linux!? why not one of the three BSD-licensed BSD-derived Net/Free/Open
BSDs? keep it "in the family" so to speak. :)
--
Aaron J. Grier | "Not your ordinary poofy goof." | agrier(a)poofygoof.com
"[...] I generally haven't found IDM guys to be very good
live acts, most of them just sit down at their laptop and
tweak reaktor." -- Brandon Daniel
Howdy -
> From: Christian Groessler <cpg(a)aladdin.de>
> I just last week installed v6 from tape image. I have to admit, I like
> working boot images more :-) (Since I only have an emulator and not
An emualtor of course would use an emulated tape image ;) That's
how I typically install. There are instructions and sources to
the program to create the 'virtual tape' from the dump and tar files.
> the real thing, I don't have the need to physically transfer the stuff.)
I keep forgetting that not everyone has a SCSI<->Qbus adaptor :)
(it was _expensive_ at the time but gosh, after 10 years the initial
$ pain is long long gone and I've gotten a lot of use out of it)
> Hmm, I just did this now, but I have to admit, I only browsed the
> instructions of most of them. I followed the instructions of 412/413
> because I feared I'd forget to update init before rebooting the new kernel.
Yes, screwing up 'init' is, to put it mildly, catastrophic. During
the development and testing of that set of updates I did render my
system unbootable. Thankfully I had a spare OS installed on the
SCSI Zip drive - I just booted from "DU 1" and put back a working
'init' (turns out that a 100MB Zip disk can contain a *full* 2.11BSD
system - not a lot of space left, but it includes all sources and
will boot).
> But otherwise I applied all patches to 442, and then rebuilt the
> kernel, rebooted, and did "make build; make installsrc". Seemed to work.
That's fantastic to hear!
> I noticed 2 patches, which patched /usr/src/sys/GENERIC/Makefile, but
> this is a generated file I think. At least it wasn't present, because
Yes and No. YES - it is generated by running './config' in /sys/conf.
NO - it's an integral part of the OS as distributed.
> I removed /usr/src/sys/GENERIC.
You really didn't want to do that ;)
The Make* files for custom kernels will (100% guaranteed) diverge
from the defaults. That's expected. The GENERIC kernel is a special
case though. When changes are made to the Make* files (overlay sizes
change for example) the patches will not attempt to find and "fix"
any locally created kernels - but the guarantee has always been that
the GENERIC kernel _will_ build, thus the patches presume that the
/sys/GENERIC directory hasn't been removed. Indeed the kernel patches
usually suggest rebuilding GENERIC.
It is a Good Idea (saved my system a couple times) to keep a known
good working _non_networking kernel (i.e. GENERIC) in /genunix. That
way if you are tinkering around (or a bad patch ends up in /unix) you
have something to boot. Many is the time (during development, testing
of course) that I've had to rely on a /genunix to get the system
back alive.
Glad to hear you're current and are not seeing 'df' weirdness. You
may want to upgrade P11 to 2.9 though - that would, I think, have
fixed that problem before you saw it ;)
Cheers,
Steven Schultz
sms(a)2bsd.com
