ad2@j.cc.purdue.edu (Bill Bormann) (12/31/87)
We are interested in finding some combination of hardware and software that will give a PDP-11/70 running RSTS/E V9.1 TCP/IP capability. Any pointers or assistance would be greatly appreciated; please send any information to: ad2@j.cc.purdue.edu (Internet) -or- bormann@purccvm (BITNET) Thanks for your help. Bill Bormann Purdue University Computing Center
LYNCH@A.ISI.EDU (Dan Lynch) (01/02/88)
Bill, You should contact Phil Denzer at Process Software in Amherst, MA. They do a lot of PDP-11 based TCP/IP stuff. They are at 413-549-6994. Dan -------
martillo@ATHENA.MIT.EDU (01/02/88)
I believe that in some incarnation the PC/IP package ran on PDP-11s under unix. The software of course nowadays runs on PCs and makes no use of Unix (or Unix-like) system calls except I think for _exit() which is provided in the microsoft C library for DOS. If you have a C compiler, it might be worth trying to compile the PC/IP programs on your PDP-11.
JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") (01/05/88)
.... If you have a C compiler, it might be worth trying to compile
the PC/IP programs on your PDP-11.
All fine, except that PC-IP is 1) dependent on an 18 ticks/sec clock in a
lot of places 2) very 808x-dependent in the tasking, timer and display
modules and 3) has a built-in hardware driver which would need a complete
re-write for another interface/architecture. The problem with RSTS is
that DEC has never done anything to ease user-written device drivers,
and there was nothing like the VMS XE driver to allow user programs to
get at the raw ethernet the last I knew. It would be a good place to
start, but it won't be a short job.
jbvbmap@GAAK.LCS.MIT.EDU (Michael A. Patton) (01/05/88)
Date: Mon, 4 Jan 88 19:41:09 EST
From: "James B. VanBokkelen" <JBVB@AI.AI.MIT.EDU>
.... If you have a C compiler, it might be worth trying to compile
the PC/IP programs on your PDP-11.
All fine, except that PC-IP is ...
You missed the point earlier in that message where the author said
that they thought it had originally been done on PDP11s. That's
actually where the author went wrong. The PCIP code was originally
designed for the MS-DOS environment and is therefore probably
completely unsuited to conversion to RSTS. The MIT UNIX V6 code on
the other hand ... :-\
... The problem with RSTS is
that DEC has never done anything to ease user-written device drivers,
and there was nothing like the VMS XE driver to allow user programs to
get at the raw ethernet the last I knew.
I heard rumors (shortly after you left the RSTS community James, and
shortly before I did) that such an interface was in the offing. I
have not heard what came of that.martillo@ATHENA.MIT.EDU (01/06/88)
While the display code and the network interface code (which live in their own separate library modules) are rather dependent on characteristics of the PC and DOS, I would say the rest of the code is rather machine and OS independent even though small chunks of assembly code would have to be rewritten for a given target machine. I thought the PCIP code was developed under a Darpa grant for the DOS environment but that the starting point was a package which ran under PDP11 Unix and there is a comment in the tasking package to this effect. However, once I asked Jerry Saltzer why the event flag was cleared by the scheduler and not left for the task to clear so that useful information could be passed via the event flag to the task and he mentioned in reply that the tasking piece at least was running on Multics in 1966 (I may have the year off) so that large chunks of the code have run in at least 3 different environments. I think I saw that Tim Maroney ported the code to the Macintosh so that chunks of PCIP have run in at least 4 very different environments.
ROMKEY@XX.LCS.MIT.EDU (John Romkey) (01/07/88)
> All fine, except that PC-IP is 1) dependent on an 18 ticks/sec clock in a > lot of places 2) very 808x-dependent in the tasking, timer and display > modules and 3) has a built-in hardware driver which would need a complete > re-write for another interface/architecture. The problem with RSTS is It's not *that* much of a problem. The 18 ticks/second clock is parametrized in a constant in a header file so that all references to ticks can be done as seconds * (ticks/second). It's not really a problem through most of the code. The 8086 dependencies are simply that there's some assembly code. In the tasking package, you need to rewrite the code which does a context switch. The timer code isn't 8086 dependent, and anyone who might be porting PC/IP to another system would probably through out the entire display package, anyway. Any hardware drivers would have to be rewritten from scratch, anyway, since it's a different set of hardware. PC/IP origially ran on a PDP-11. If porting it back to a PDP-11 turns out to be difficult, it shouldn't be because of architectural problems or because of 8086 dependencies. PC/IP was derived from the PDP-11 V6 Unix code Mike Patton mentioned in a later message. I don't know if you can still find someone at MIT who can or will give you that code. - john romkey -------
beadel@OSWEGO.OSWEGO.EDU (Edward.F.Beadel@oswego.oswego.edu, Jr.) (01/08/88)
>> ... The problem with RSTS is >> that DEC has never done anything to ease user-written device drivers, >> and there was nothing like the VMS XE driver to allow user programs to >> get at the raw ethernet the last I knew. > I heard rumors (shortly after you left the RSTS community James, and > shortly before I did) that such an interface was in the offing. I > have not heard what came of that. In the RSTS/E V9.4 Programming Manual (DEC Order Number AA-EZ09A-TC { including AD-EZ09A-T1,T2}) the aboved problem is addressed: " In order to increase the flexibility of Ethernet on RSTS/E, DIGITAL has provided a direct interface to the Ethernet data link layer for RSTS/E users. This interface resembles the interface provided for the DMC/DMR communications devices, and can be programmed with or without DECnet/E on the system." (page 11-3) This allows use of both UNIBUS controllers (DELUA and DEUNA) as device XE: and the Q-bus controller (DEQNA) as device XH:. Edward F. Beadel, Jr. RSTS SIG Steering Committee UNIGIG rep to DECUS PDP-11 Task Force