[-- Attachment #1: Type: text/plain, Size: 1017 bytes --] Hi, I have an 11/45 I'm hoping will be running soon. I'd like to run 2.9BSD on it because it's the most highly functional system I know of that has "official hopes" to fit on such a restrictive machine. I've heard that it's really unlikely / tough to get a kernel built that'll run tcp (I care mostly about ftp and telnet) on such a small-memory-footprint machine. Is this true? Would anyone be willing to do a quick mentoring / working session with me to get me up to speed with the constraints I'm facing here and possibly give me a jump on making adjustments to build such a kernel if possible? thx jake P.S. There's kind of an implied challenge in the 2.11bsd setup docs, mentioning that "2.11BSD would probably only require a moderate amount of squeezing to fit on machines with less memory, but it would also be very unhappy about the prospect." I'm sure it's been attempted before, but would anyone be up to the challenge of trying to get that going with networking on an 18-bit-address-space pdp11? [-- Attachment #2: Type: text/html, Size: 1311 bytes --]
It is going to be very difficult. If this is real HW you might try practicing configuration using simh. It will be faster and easy to play with until you have the config that meets your needs. That said for telnet and ftp you are going to need tcp.
Btw. I might suggest setting up and Arduino, an RPi or the like and connect via serial ports to the 11. That way you might not need networking.
Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
> On Dec 10, 2018, at 5:05 PM, Jacob Ritorto <jacob.ritorto@gmail.com> wrote:
>
> Hi,
> I have an 11/45 I'm hoping will be running soon.
>
> I'd like to run 2.9BSD on it because it's the most highly functional system I know of that has "official hopes" to fit on such a restrictive machine.
>
> I've heard that it's really unlikely / tough to get a kernel built that'll run tcp (I care mostly about ftp and telnet) on such a small-memory-footprint machine. Is this true?
>
> Would anyone be willing to do a quick mentoring / working session with me to get me up to speed with the constraints I'm facing here and possibly give me a jump on making adjustments to build such a kernel if possible?
>
> thx
> jake
>
> P.S. There's kind of an implied challenge in the 2.11bsd setup docs, mentioning that "2.11BSD would probably only require a moderate amount of squeezing to fit on machines with less memory, but it would also be very unhappy about the prospect."
>
> I'm sure it's been attempted before, but would anyone be up to the challenge of trying to get that going with networking on an 18-bit-address-space pdp11?
>
[-- Attachment #1: Type: text/plain, Size: 336 bytes --] On 12/10/18 6:21 PM, Clem cole wrote: > That said for telnet and ftp you are going to need tcp. What protocols did 2.9BSD support? Did it have NCP? Or was it strictly serial protocols like interactive terminals / UUCP? Would it be any easier to use an external NCP to TCP/IP gateway? -- Grant. . . . unix || die [-- Attachment #2: S/MIME Cryptographic Signature --] [-- Type: application/pkcs7-signature, Size: 4008 bytes --]
> From: Grant Taylor > What protocols did 2.9BSD support? Did it have NCP? NCP was turned off on 1 January, 1983. What do you think?a > Would it be any easier to use an external NCP to TCP/IP gateway? Such as? Noel
[-- Attachment #1: Type: text/plain, Size: 783 bytes --] On 12/10/18 7:11 PM, Noel Chiappa wrote: > NCP was turned off on 1 January, 1983. What do you think?a I don't know 2.9BSD's time frame (and did not look it up) so I can't say one way or the other. Based on your response I'm going to assume that it's not possible. > Such as? I'd have to go back and look, but I think I have read about an NCP and IP speaking host in the last few months. It may have been related to MULTICS. The idea is that it might be simpler to speak TCP/IP to such a machine and then connect from it to 2.9BSD, if 2.9BSD supported NCP. If the OPs goal is to get network connectivity on an 18-bit PDP, then that might be another option that doesn't require shoehorning TCP/IP into said PDP. -- Grant. . . . unix || die [-- Attachment #2: S/MIME Cryptographic Signature --] [-- Type: application/pkcs7-signature, Size: 4008 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1187 bytes --] On Mon, Dec 10, 2018 at 7:37 PM Grant Taylor via TUHS <tuhs@minnie.tuhs.org> wrote: > On 12/10/18 7:11 PM, Noel Chiappa wrote: > > NCP was turned off on 1 January, 1983. What do you think?a > > I don't know 2.9BSD's time frame (and did not look it up) so I can't say > one way or the other. > > Based on your response I'm going to assume that it's not possible. > I kinda doubt it has good NCP support: it was released in November of 1983. > > Such as? > > I'd have to go back and look, but I think I have read about an NCP and > IP speaking host in the last few months. It may have been related to > MULTICS. > > The idea is that it might be simpler to speak TCP/IP to such a machine > and then connect from it to 2.9BSD, if 2.9BSD supported NCP. > > If the OPs goal is to get network connectivity on an 18-bit PDP, then > that might be another option that doesn't require shoehorning TCP/IP > into said PDP. > I'd get it running in simh, then move to real hardware. It's going to take a lot of elbow grease to make that work, I think. But I haven't looked in detail at things. Ultrix-11 is of similar vintage, and similar functionality and does boot on the 18-bit 11's. Warner [-- Attachment #2: Type: text/html, Size: 1810 bytes --]
> From: Warner Losh > I kinda doubt it has good NCP support: it was released in November of > 1983. Wow, that far back? I'd assumed it was later (considerably later). Looking at the 2.9 networking stuff: https://minnie.tuhs.org//cgi-bin/utree.pl?file=2.9BSD/usr/net/sys/net it does indeed have _no_ NCP support. > I'd get it running in simh, then move to real hardware. Absolutely; running in an emulator is, I have found, a key step on getting an old OS running. I've found Ersatz-11 to be really good for PDP-11 emulation. > It's going to take a lot of elbow grease to make that work, I think. Indeed; part of the problem, if the goal is going to be 'run it on real hardware' is 'what network interface to use'. All the ARPANET interfaces are out. There are drivers there for Proteon, Ungermann-Bass, Xerox 3MB Ethernet, etc interfaces, but i) where you gonna find one, and ii) you'll need a router to connect up to most other things. There's a driver for the Interlan Ethernet interface, but AFAIK, those are non-existent. (If anyone has one they're willing to part with, please let me know!) DEC Ethernet interfaces are available, but i) only the QBUS ones are common, DEUNAs and DELUAs are almost impossible to find, that I've even seen, and ii) it would need a driver. > Ultrix-11 is of similar vintage, and similar functionality and does boot > on the 18-bit 11's. Yes, definitely worth looking at; I know it had TCP/IP (we had it on our -11/73 at Proteon), but I don't know which interfaces it supported; probably just the DEC ones (which, given the above, is not necessarily a Bad Thing). Noel
Grant Taylor wrote: > What protocols did 2.9BSD support? Did it have NCP? Or was it > strictly serial protocols like interactive terminals / UUCP? > > Would it be any easier to use an external NCP to TCP/IP gateway? It's actually a challenge to find *any* NCP software today. I think it would be interesting to recreate a small ARPANET. Here's a copy of "Network Unix" from Illinois: https://github.com/larsbrinkhoff/network-unix-v6
[-- Attachment #1: Type: text/plain, Size: 3878 bytes --] Having had an extremely small part to play in 2.x story (some of my code is in there), I can offer a little of the history which hopefully you can glean some wisdom: re: NCP 1. The NCP code from Illinois, Rand *et al* - talked to the BBN-1822 interface. To my knowledge, no other networking interface was connected to that code base. - 1822 interface board are not be found - what would you connect the other end too? - Which means that you need to write an NCP driver for some other networking HW you can find for the Unibus 2. The only PDP-11 @ UCB that might have ever run the NCP code was Ing70 and that was long before 2BSD was released (much less 2.X) - As Noel pointed out, there is no NCP code in the 2.9 BSD distribution re: BSD 2.x & BSD 3.0 - 4.1 1. BSD 2.0 was the Seventh Edition changes from UCB for the PDP-11 (primarily what was running on the Cory Hall System) 2. BSD 3.0 was the first Vax release for "Ernie" in Evans. For all intents this is 2.0 + changes to the Kernel to allow V7 to run on a 780 with paging turned on [I don't remember if csh is default shell for root, it might be -> a user used to the way the 7th edition worked if presented with BSD 3.0 will find 'finger ROM/muscle memory' compatibility]. 3. BSD 4.1 was the widely released Vax distribution where Research Editions and BSD began to diverge. This was the system that convinced ARPA to make UNIX the supported OS for the next generation being VMS [which was being pushed by Stanford]. 4. Anything in the 2.X line post the original 2BSD tape was a group of mostly undergrads trying to move features from Ernie back to the Cory Hall system. These changes were then duplicated around campus (Math and Stat Depts as an example) who had purchased PDP-11s. The first big change was adding overlays for applications so larger address user programs like vi could keep running. But you tended to need at least sperate I/D (i.e. the 17th address bit as I like to call it). 5. Once the kernel overlay code (which I think was about 2.7) was added, it was pretty amazing how much the PDP-11 team did getting many of the later Vax kernel features supported, such a FFS, MIT's Job Control for the csh, new signals and even networking on some systems with 'enough' main memory [i.e. the 22BIT ones]. re: IP and BSD 1. UCBVAX (running BSD 4.1) was spliced to the Internet via IP/TCP using the BBN 1.0 IP/TCP release for the Vax by Eric Cooper 2. BSD 4.1a thru 4.2 were different versions of Vax work from the new CSRG team with new features for the Arpa community; including the creation of sockets and resplicing the BBN stack back the new kernel. So the issue you will run into is that to get all of the features that were crammed into BSD 2.X from the Vax, you need 'enough' memory to keep the overlays loaded. I do not believe the Kernel can swap itself out. Besides the kernel (i-space) code itself, space for I/O buffers becomes a huge issue (it always was before you added networking on the Research systems). To compound the issue, the networking code has its own memory scheme call 'mbufs' which came from the original BBN code [Rob wrote it to be portable to multiple OS's not just UNIX - the BBN distribution works on things like the HP/3000 also]. Space for all the buffers is going to be your problem. The less kernel code you have resident, the more room you have for applications code and I/O buffers. This is why I suggested that if you really want telnet and ftp to the PDP-11, you might be better off moving the networking stack out of the kernel and put a serial line (or even a DR-11B with a simple transfer protocol) via an Arduino or the like. ᐧ [-- Attachment #2: Type: text/html, Size: 5495 bytes --]
> From: Clem Cole <clemc@ccc.com> > This is why I suggested that if you really want telnet and ftp to the > PDP-11, you might be better off moving the networking stack out of the > kernel Really, the answer is that I need to get off my @ss and put the MIT V6+ system up (I have all the files, just need to get a round tuit). It has TCP/IP, but is it not all crammed into the kernel. And unlike the early BBN V6, it doesn't do TCP as a single process to which all the other client/server processes talk via IPC. Instead, the only thing in the kernel is inbound demuxing, and minimal outbound processing. (IIRC, outbound packets are copied into kernel buffers; an earlier version of the networking interface driver actually did do inbound and outbound DMA directly from buffers in the user's process, but only one process could use the network interface at a time.) The TCP code was a library that was built into the user process which did the server/client applications. (The servers which supported login, like FTP, needed to run as root, like the ordinary login, setuid'ing to the entered user-id.) I don't remember if we supported server Telnet, but I think we did. So we must have added PTY's of some sort, I'll have to check. Since the TCP was in the user process, we actually had a couple of different ones, depending on the application. Dave Clark had done a quick-n-dirty TCP on the Alto (in BCPL) which was only good for things like user Telnet, not for applications that sent a lot of data. We ported that one for the first TCP; we later did a 'high-speed bulk data' TCP, used for FTP, etc. I don't remember which one SMTP used. The whole thing worked _really_ well. Alas, I don't think anyone else picked up on it. The kernel code is not that large, it should even run on a /40, without overlays (although the number of disk buffers would probably get hit). And since the TCP is in user processes, it could all get swapped out, so it would run OK on machines without that much physical memory. The issue is going to be that it will need a new network interface driver, since I think the only driver ever done for it was for Pronet. And now we get back to the 'what interfaces are available' question. Doing a DEC driver would allow use of DEQNA's and DELQA's on QBUS machines, which would be optimal, since they are common. And people could bring up Unix with TCP/IP on -11/23's. But we'd have to add ARP (which I would do as a process, with only the IP->Ether address mapping table stored in the kernel). I wrote a really nice ARP for the C Gateway that could easily be used for that. Noel
[-- Attachment #1: Type: text/plain, Size: 3304 bytes --] IIRC is how UNET worked for V7. FWIW: UNE T was the original product from 3COM and somewhere I have the package with the Postmark as the 32nd of December - because 3Com had a requirement to ship by the end of the year to their VCs. At the last hours, Greg Shaw and Bruce Borden ran into a problem, so it shipped a day late [they obviously got their money]. Clem ᐧ On Tue, Dec 11, 2018 at 11:17 AM Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote: > > From: Clem Cole <clemc@ccc.com> > > > This is why I suggested that if you really want telnet and ftp to the > > PDP-11, you might be better off moving the networking stack out of > the > > kernel > > Really, the answer is that I need to get off my @ss and put the MIT V6+ > system > up (I have all the files, just need to get a round tuit). > > > It has TCP/IP, but is it not all crammed into the kernel. And unlike the > early > BBN V6, it doesn't do TCP as a single process to which all the other > client/server processes talk via IPC. > > Instead, the only thing in the kernel is inbound demuxing, and minimal > outbound > processing. (IIRC, outbound packets are copied into kernel buffers; an > earlier > version of the networking interface driver actually did do inbound and > outbound > DMA directly from buffers in the user's process, but only one process > could use > the network interface at a time.) > > The TCP code was a library that was built into the user process which did > the > server/client applications. (The servers which supported login, like FTP, > needed to run as root, like the ordinary login, setuid'ing to the entered > user-id.) I don't remember if we supported server Telnet, but I think we > did. So we must have added PTY's of some sort, I'll have to check. > > Since the TCP was in the user process, we actually had a couple of > different > ones, depending on the application. Dave Clark had done a quick-n-dirty > TCP on > the Alto (in BCPL) which was only good for things like user Telnet, not for > applications that sent a lot of data. We ported that one for the first > TCP; we > later did a 'high-speed bulk data' TCP, used for FTP, etc. I don't remember > which one SMTP used. > > The whole thing worked _really_ well. Alas, I don't think anyone else > picked > up on it. > > > The kernel code is not that large, it should even run on a /40, without > overlays (although the number of disk buffers would probably get hit). And > since the TCP is in user processes, it could all get swapped out, so it > would > run OK on machines without that much physical memory. > > The issue is going to be that it will need a new network interface driver, > since I think the only driver ever done for it was for Pronet. And now we > get > back to the 'what interfaces are available' question. Doing a DEC driver > would > allow use of DEQNA's and DELQA's on QBUS machines, which would be optimal, > since they are common. And people could bring up Unix with TCP/IP on > -11/23's. > > But we'd have to add ARP (which I would do as a process, with only the > IP->Ether address mapping table stored in the kernel). I wrote a really > nice > ARP for the C Gateway that could easily be used for that. > > Noel > [-- Attachment #2: Type: text/html, Size: 4557 bytes --]
PS: > IIRC, outbound packets are copied into kernel buffers IDRC; according to the documentation, outbound packets are DMA'd directly from user memory. I have yet to read the code to verify this. > we must have added PTY's of some sort There is indeed a PTY driver; it has comments from BBN'ers who edited it, so perhaps we got it from BBN. > I don't remember which one SMTP used. The 'simple' TCP. > The whole thing worked _really_ well. Alas, I don't think anyone else > picked up on it. So I found a long list of people we sent tapes to. Oh well.... > The kernel code is not that large, it should even run on a /40, without > overlays (although the number of disk buffers would probably get hit). Well, maybe... Here is the output of 'size' on the last Unix image for that machine: 40560+3098+44594 It was a /45, so split I/D (no overlays, though). How much could be trimmed out of that, I'm not sure. Noel
Too bad Keith Bostic isn't on this list. IIRC, he did a lot of the PDP-11 Unix integration work. Jon
Clem Cole wrote:
> * 1822 interface board are not be found
> * what would you connect the other end too?
If you really wanted to, I guess you could use a UniBone running a
simulation of the 1822 interface.
[-- Attachment #1: Type: text/plain, Size: 1194 bytes --] On Tue, Dec 11, 2018 at 11:57 AM Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote: > > we must have added PTY's of some sort > > There is indeed a PTY driver; it has comments from BBN'ers who edited it, > so > perhaps we got it from BBN. > Hmm, I could be mis remembering, but IIRC the original PTY driver goes back to the Rand and/or UofI for the NCP. I suspect BBN got it from the Bruce Borden's Rand distribution tape which was 74 or 75, I think. Named Piped were definiately a Rand-ism (they were originally called 'Rand Pipes') and were on that tape along with their Editor. It's too bad Greg is not here to ask. My memory and Noel may know by the IMP release dates, is that Rand was on connected before UofI. But there were issues and somethings were not 100% until the UofI NCP; which was the first really complete NCP for UNIX. I'm pretty sure that Greg's version went back to Bruce, as well as to BBN and Harvard and I would have assumes MIT also. I don't remember if the original Rand Pipes and PTYs were 5th or 6th edition originally. I'm fairly sure, UofI's NCP was 6th edition but think that Rand goes back to at least 5th if not 4th. ᐧ [-- Attachment #2: Type: text/html, Size: 2591 bytes --]
> From: Clem Cole > I could be mis remembering No... :-) > IIRC the original PTY driver goes back to the Rand and/or UofI for the > NCP. Yup. I found a pty.c in the NCP system, it's clearly the ancestor (comments match): https://minnie.tuhs.org//cgi-bin/utree.pl?file=SRI-NOSC/dmr/pty.c > I suspect BBN got it from the Bruce Borden's Rand distribution tape Or possibly indirectly; my copy of the NCP came from NOSC via SRI. In addition to the one above, there are also these: https://minnie.tuhs.org//cgi-bin/utree.pl?file=SRI-NOSC/dmr/misc/pty.c.ill https://minnie.tuhs.org//cgi-bin/utree.pl?file=SRI-NOSC/dmr/misc/pty.c.x Here: https://minnie.tuhs.org//cgi-bin/utree.pl?file=BBN-V6/dmr/pty.c is the BBN version, you can compare the them all. The MIT one is derived from the BBN one. > Named Piped were definiately a Rand-ism (they were originally called 'Rand Pipes') Well, _RAND_ called them 'ports': https://minnie.tuhs.org//cgi-bin/utree.pl?file=BBN-V6/doc/ipc/ports > But there were issues and somethings were not 100% until the UofI NCP; > which was the first really complete NCP for UNIX. Somewhere I found a document about the UofI code, I think they wrote it from scratch? Sorry, too lazy to look at it. See here: https://minnie.tuhs.org//cgi-bin/utree.pl?file=SRI-NOSC for links. Noel
[-- Attachment #1: Type: text/plain, Size: 393 bytes --] On Tue, Dec 11, 2018 at 1:43 PM Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote: > > > Named Piped were definiately a Rand-ism (they were originally called > 'Rand Pipes') > > Well, _RAND_ called them 'ports': > > https://minnie.tuhs.org//cgi-bin/utree.pl?file=BBN-V6/doc/ipc/ports > > Absolutely right... Rand Ports ... I stand corrected. Ports/Pipes -- same thing ... ᐧ [-- Attachment #2: Type: text/html, Size: 1278 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1259 bytes --] Man, this thread is really going! Excellent to see; thank you, all! I'm going to of course begin with what Clem and others suggested and do it on a simh 11/45 initially to try to get the needed tcp stuff compiled in. In looking at https://minnie.tuhs.org//cgi-bin/utree.pl?file=2.9BSD/usr/net/sys/net/NOTES , it's mentioned that >>> The 4K bytes of in address malloc space for dynamic structures is ok for an >>> I/D machine, but may be tight on a /34 or /23. Not sure yet whether this >>> will squeeze in. , so it feels like there's hope that it can be done. Lots of rereading and research for me to get to the point of completely understanding that NOTES file. Anyway, I'm going to try and get a simh instance up somewhere publicly accessible (will provide creds to those curious / interested) and see where I get stuck. Will be back with more questions! Thanks again for the initial engagement on this! jake P.S. I do have a Xylogics Annex "terminal server" that'd be a great front end to the real 11/45's serial lines as Clem suggested, but for me, the romance of having the machine truly speaking tcp as intended is one of the goals. I'll keep the Annex handy for when it's running SysV and other things that definitively can't speak tcp. [-- Attachment #2: Type: text/html, Size: 1737 bytes --]
> I'm sure it's been attempted before, but would anyone be up to the > challenge of trying to get that going with networking on an > 18-bit-address-space pdp11? By coincidence I’m in the middle of a project to make V6 run with the Gurwitz TCP stack on a TI990 clone (which is pretty similar to a PDP11). It runs without separate I/D as two processes in about 100KB. The Gurwitz TCP stack was the reference implementation for the VAX that BBN did in 1981. It is in the THUS archive: https://minnie.tuhs.org//cgi-bin/utree.pl?file=BBN-Vax-TCP As documented in IEN168, the actual TCP processing happens in a separate kernel process, much like process 0 (swapper) in Unix itself. It turns out that the network process shares no data (other than the u struct) with the kernel proper and can be run in a separate address space. Just a few ’thunks’ are needed: open/read/write/close from the kernel to the TCP stack and sleep/wakeup in the other direction. A V6 Unix kernel runs in 48KB with buffers, the TCP stack with buffers needs about the same; both must remain resident - i.e. it ties up about 100KB of the 256KB core on a 18-bit machine. I suppose when using separate I/D it can run without thunks: the code size is about 25KB for both a minimal V6 kernel and the TCP stack, the rest is data. In my setup, network connectivity is via a SLIP interface. The Gurwitz code also has an Ethernet driver (note ARP was not invented yet), but I’m not using that. I’m happy to report that this 1981 tcp/ip code can still talk to current OSX and Linux machines. Just yesterday I got the setup working and I can run minimalist telnet connections etc. Alas it is not quite stable yet, it tends to crash after 5-10 minutes of use. The BBN reference implementation includes FTP and Telnet servers and clients which I think will still interoperate with current versions. As a final remark note that this BBN code uses an API that is almost unchanged from the API as used on NCP Unix. As compared to sockets this means that a listening connection is not a rendez-vous, but blocks until a connection is made (and then becomes an active connection, i.e. stops listening), and that there is no “select” type functionality.
> From: Paul Ruizendaal > project to make V6 run with the Gurwitz TCP stack on a TI990 clone > (which is pretty similar to a PDP11). Neat! > the code size is about 25KB for both a minimal V6 kernel and the TCP > stack, the rest is data. That's impressively small; the MIT V6+ with 'demux only in the kernel' was 40KB for the combined code (although I can't easily get separate figures for the networking part and the rest). > The Gurwitz code also has an Ethernet driver (note ARP was not invented > yet) How did it get Ethernet addresses? Noel
> From: Paul Ruizendaal > a project to make V6 run ... on a TI990 clone Oh, about the basic part of this: did you start with a plain V6 distribution? So you've had to do all the machine language stuff from scratch (and modify things in C like estabur())? What are you using for a C compiler ? Is there one out there, or did you have to do your own? > In my setup, network connectivity is via a SLIP interface. Yeah, that's probably the way to go, to start with. Noel
> > the code size is about 25KB for both a minimal V6 kernel and the TCP > > stack, the rest is data. > > That's impressively small; the MIT V6+ with 'demux only in the kernel' was > 40KB for the combined code (although I can't easily get separate figures for > the networking part and the rest). I think my sentence was confusing: it is ~25KB each, so about 50KB combined. The original V6 kernel was about 29KB (says here https://www.tuhs.org//cgi-bin/utree.pl?file=V6). I've simplified the TTY driver, only support one type of disk driver, dropped shared text segments, dropped FP emulation. Remains about 25KB. Note that the SLIP is merely via a "super RAW" mode on the TTY driver, so I don't need to include the bulky IMP interface driver. Even at 30KB, the V6 kernel must have offered the best bang/buck ratio in the history of software, imho. > > The Gurwitz code also has an Ethernet driver (note ARP was not invented > > yet) > > How did it get Ethernet addresses? :^) See here: https://www.tuhs.org//cgi-bin/utree.pl?file=BBN-Vax-TCP/bbnnet/netconf.c "Someday this will be generated from the configuration file." I think later it did, but I don't have that code. > > a project to make V6 run ... on a TI990 clone > > Oh, about the basic part of this: did you start with a plain V6 distribution? > So you've had to do all the machine language stuff from scratch (and modify > things in C like estabur())? > What are you using for a C compiler ? Is there one out there, or did you have > to do your own? I has been a journey. I started with the 2.11BSD compiler and ported that to the TI990 architecture (more precisely the 9995 chip, which is similar to a T11 chip). I debugged that to make XINU run, and then moved on to LSX (as recovered by the BK-UNIX project). Then I started with the V6 kernel from the TUHS website and made that work. Dave Pitts made it work on a real TI990 (he has a TI990/10 and a TI990/12 in working order). So, yes, I did bootstrap all the low level stuff from scratch. After a three year hiatus I resumed work on this, integrating the Gurwitz TCP stack. The journey is documented here: http://1587660.websites.xs4all.nl/cgi-bin/9995/timeline The network code is in a different tree, I'll move it over to the above tree over the weekend. Paul
> The journey is documented here:
> http://1587660.websites.xs4all.nl/cgi-bin/9995/timeline
>
> The network code is in a different tree, I'll move it over to the above tree over the weekend.
Posted the network bit in the online repo; it's in the v6net directory.
Also fixed the instability - it is quite satisfying to login to v6 from a 'nc' client on modern hardware.
However, I also found that the BBN code from November 1981 is what is says on the can: beta.
I'll move to the October 1982 code when I find some time.
Paul
PS, this is the 'server' that nc connects to:
#define unchar unsigned char
#define netaddr unsigned long
#include "con.h"
#include <stdio.h>
#include <string.h>
unsigned long
ipaddr(w,x,y,z)
int w,x,y,z;
{
unsigned long ip;
ip = w;
ip = (ip<<8)|x;
ip = (ip<<8)|y;
ip = (ip<<8)|z;
return ip;
}
struct con con;
void
child(fd)
int fd;
{
close(0);
dup(fd);
close(1);
dup(fd);
close(2);
dup(fd);
close(fd);
execl("/bin/sh", "[net-sh]", 0);
}
main()
{
int i, n, sd;
con.c_mode = CONTCP;
con.c_fcon = ipaddr(192,168,1,114);
con.c_lcon = ipaddr(172,16,0,2);
con.c_fport = 0;
con.c_lport = 4000;
sd = open("/net", &con);
printf("Connected\n", sd);
child(sd);
close(sd);
}