From folkert at vanheusden.com Mon Apr 7 17:22:31 2025 From: folkert at vanheusden.com (Folkert van Heusden) Date: Mon, 07 Apr 2025 09:22:31 +0200 Subject: [TUHS] running BSD 2.11 on my PDP 11/70 emulator Message-ID: <122fede123f3d5bd5df3b9bf3ccb83dc@vanheusden.com> Hi, For fun I'm developing a PDP 11/70 emulator. It runs on everything from ESP32 microcontrollers up to linux, windows, etc https://vanheusden.com/emulation/PDP-11/kek/ Currently it can run UNIX 7 in multi user mode. Of course I would like it to run BSD 2.11 as well (because of the networking support). It boots, but after outputting the memory amounts it produces a lot of garbage. It does eventually complete booting and then allows you to log in. I wonder if you sees this: https://paste.nurd.space/mqIDB_0SjoDoJoasOGkiNQ_NjpRsCufAJCnKTA7ZxUI (text) or https://imgpaste.nurd.space/pics/437bcf0d149a017168cbbf2def8560917a037a3935c5c3aa1fbea2f7e43b485a.png (image), does this ring a bell to anyone? I verified with simh that the disk-image should work. regards -- www.vanheusden.com From kennethgoodwin56 at gmail.com Mon Apr 7 22:02:30 2025 From: kennethgoodwin56 at gmail.com (Kenneth Goodwin) Date: Mon, 07 Apr 2025 12:02:30 -0000 Subject: [TUHS] running BSD 2.11 on my PDP 11/70 emulator In-Reply-To: <122fede123f3d5bd5df3b9bf3ccb83dc@vanheusden.com> References: <122fede123f3d5bd5df3b9bf3ccb83dc@vanheusden.com> Message-ID: To me it looks like a memory issue of some sort. Setup of the MMU etc. 1. Your user memory is less than 10% of "available memory" which should be the amount left after the kernel loads and allocates dynamic buffers. User memory should be alot closer to available number. Unless it is referring to limits of mmu per process and not total available for all user level programs. 2. The bulk of the text dump seems to just be random initialized data dumped from Ram. Aka - Printf() format strings. Indicates that the wrong address in memory is potentially being accessed. Perhaps the pdp11 emulator configuration does not have a correct mmu for your image file. For example, you are running the 11/70 emulation and the binary image you are running is actually compiled for a pdp 11/45. The 11/70 has an mmu supporting split instruction and data spaces. 64k instruction, 64k data. But the kernel you are using was compiled to run on a non split I And D version of the pdp11 supporting only 64kb of combined user and data. On Mon, Apr 7, 2025, 3:30 AM Folkert van Heusden wrote: > Hi, > > For fun I'm developing a PDP 11/70 emulator. It runs on everything from > ESP32 microcontrollers up to linux, windows, etc > https://vanheusden.com/emulation/PDP-11/kek/ > Currently it can run UNIX 7 in multi user mode. > Of course I would like it to run BSD 2.11 as well (because of the > networking support). It boots, but after outputting the memory amounts > it produces a lot of garbage. It does eventually complete booting and > then allows you to log in. > I wonder if you sees this: > https://paste.nurd.space/mqIDB_0SjoDoJoasOGkiNQ_NjpRsCufAJCnKTA7ZxUI > (text) or > > https://imgpaste.nurd.space/pics/437bcf0d149a017168cbbf2def8560917a037a3935c5c3aa1fbea2f7e43b485a.png > (image), does this ring a bell to anyone? I verified with simh that the > disk-image should work. > > > regards > > -- > www.vanheusden.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kennethgoodwin56 at gmail.com Mon Apr 7 22:07:59 2025 From: kennethgoodwin56 at gmail.com (Kenneth Goodwin) Date: Mon, 07 Apr 2025 12:07:59 -0000 Subject: [TUHS] running BSD 2.11 on my PDP 11/70 emulator In-Reply-To: References: <122fede123f3d5bd5df3b9bf3ccb83dc@vanheusden.com> Message-ID: Something is definitely off with memory layout. That 300000 user memory is not a reference to even the maximum split i/d image size. If your bsd image has kernel dynamic buffer configuration limit parameters, you could tweak those down say 50% to see what happens. (Not a BSD kernel hacker and it's been a while since I last read over the source code) On Mon, Apr 7, 2025, 8:02 AM Kenneth Goodwin wrote: > To me it looks like a memory issue of some sort. Setup of the MMU etc. > > 1. Your user memory is less than 10% of "available memory" which should be > the amount left after the kernel loads and allocates dynamic buffers. User > memory should be alot closer to available number. Unless it is referring to > limits of mmu per process and not total available for all user level > programs. > > 2. The bulk of the text dump seems to just be random initialized data > dumped from Ram. > Aka - Printf() format strings. Indicates that the wrong address in memory > is potentially being accessed. > > Perhaps the pdp11 emulator configuration does not have a correct mmu for > your image file. > > For example, you are running the 11/70 emulation and the binary image you > are running is actually compiled for a pdp 11/45. > > The 11/70 has an mmu supporting split instruction and data spaces. 64k > instruction, 64k data. But the kernel you are using was compiled to run on > a non split I And D version of the pdp11 supporting only 64kb of combined > user and data. > > On Mon, Apr 7, 2025, 3:30 AM Folkert van Heusden > wrote: > >> Hi, >> >> For fun I'm developing a PDP 11/70 emulator. It runs on everything from >> ESP32 microcontrollers up to linux, windows, etc >> https://vanheusden.com/emulation/PDP-11/kek/ >> Currently it can run UNIX 7 in multi user mode. >> Of course I would like it to run BSD 2.11 as well (because of the >> networking support). It boots, but after outputting the memory amounts >> it produces a lot of garbage. It does eventually complete booting and >> then allows you to log in. >> I wonder if you sees this: >> https://paste.nurd.space/mqIDB_0SjoDoJoasOGkiNQ_NjpRsCufAJCnKTA7ZxUI >> (text) or >> >> https://imgpaste.nurd.space/pics/437bcf0d149a017168cbbf2def8560917a037a3935c5c3aa1fbea2f7e43b485a.png >> (image), does this ring a bell to anyone? I verified with simh that the >> disk-image should work. >> >> >> regards >> >> -- >> www.vanheusden.com >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Tue Apr 8 02:15:34 2025 From: ron at ronnatalie.com (Ron Natalie) Date: Mon, 07 Apr 2025 16:15:34 -0000 Subject: [TUHS] running BSD 2.11 on my PDP 11/70 emulator In-Reply-To: References: <122fede123f3d5bd5df3b9bf3ccb83dc@vanheusden.com> Message-ID: The 45 also has split I/D. The 11/ 70 is designed that if you can put a kernel that is cognizant only of the lower numbers in the line, it will still work. ------ Original Message ------ >From "Kenneth Goodwin" To "Folkert van Heusden" Cc "The Eunuchs Hysterical Society" Date 4/7/2025 8:02:01 AM Subject [TUHS] Re: running BSD 2.11 on my PDP 11/70 emulator >To me it looks like a memory issue of some sort. Setup of the MMU etc. > >1. Your user memory is less than 10% of "available memory" which should >be the amount left after the kernel loads and allocates dynamic >buffers. User memory should be alot closer to available number. Unless >it is referring to limits of mmu per process and not total available >for all user level programs. > >2. The bulk of the text dump seems to just be random initialized data >dumped from Ram. >Aka - Printf() format strings. Indicates that the wrong address in >memory is potentially being accessed. > >Perhaps the pdp11 emulator configuration does not have a correct mmu >for your image file. > >For example, you are running the 11/70 emulation and the binary image >you are running is actually compiled for a pdp 11/45. > >The 11/70 has an mmu supporting split instruction and data spaces. 64k >instruction, 64k data. But the kernel you are using was compiled to >run on a non split I And D version of the pdp11 supporting only 64kb of >combined user and data. > >On Mon, Apr 7, 2025, 3:30 AM Folkert van Heusden > wrote: >>Hi, >> >>For fun I'm developing a PDP 11/70 emulator. It runs on everything >>from >>ESP32 microcontrollers up to linux, windows, etc >>https://vanheusden.com/emulation/PDP-11/kek/ >>Currently it can run UNIX 7 in multi user mode. >>Of course I would like it to run BSD 2.11 as well (because of the >>networking support). It boots, but after outputting the memory amounts >>it produces a lot of garbage. It does eventually complete booting and >>then allows you to log in. >>I wonder if you sees this: >>https://paste.nurd.space/mqIDB_0SjoDoJoasOGkiNQ_NjpRsCufAJCnKTA7ZxUI >>(text) or >>https://imgpaste.nurd.space/pics/437bcf0d149a017168cbbf2def8560917a037a3935c5c3aa1fbea2f7e43b485a.png >>(image), does this ring a bell to anyone? I verified with simh that >>the >>disk-image should work. >> >> >>regards >> >>-- >>www.vanheusden.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From kennethgoodwin56 at gmail.com Tue Apr 8 21:17:44 2025 From: kennethgoodwin56 at gmail.com (Kenneth Goodwin) Date: Tue, 8 Apr 2025 07:17:44 -0400 Subject: [TUHS] running BSD 2.11 on my PDP 11/70 emulator In-Reply-To: References: <122fede123f3d5bd5df3b9bf3ccb83dc@vanheusden.com> Message-ID: It is the BSD kernel or the emulator setup I question as to being correct. The clues being An almost 4 mb available memory coupled to a roughly 300 kb user space. The 300kb doesn't make sense at all from the limits of the split i/d memory layout. It's roughly 10% of available. It's inferring that the kernel itself is being configured as a 3.5 mb runtime image. Almost as if dynamic kernel level buffers are being over allocated by a configuration parameter or a miscalculation. The other clue being the dump of the printf style format strings from the data portion of the involved user space program images as it boots. That's the sign of a wrong address potentially being used. An address fault causing an abend happening to multiple binaries being launched for example These are the anomalies I see. The solution requires someone very familiar with the bsd 2.11 boot up sequence and the underlying executables involved. I am a V6, v7. System V head. Unfortunately Mr. Jolitz is no longer with us. As I recall, the bsd folks were back porting some of the features of the Vax virtual version of the bsd kernel as appropriate to the pdp version. I dont recall what was involved in that effort. The source code environment for 2.11 would help. I also don't know if those failure messages are coming from the bsd image handling address faults etc. or the actual emulator underneath detecting problems in the binary as it executes it. So the questions to be answered are 1. Why is the user memory only 10% of the available? 2. What is dumping and the "why of it" the text strings in the data space portion of the program image? I don't the answer. But it all strikes me as odd. On Mon, Apr 7, 2025, 12:15 PM Ron Natalie wrote: > The 45 also has split I/D. The 11/ 70 is designed that if you can put a > kernel that is cognizant only of the lower numbers in the line, it will > still work. > > > ------ Original Message ------ > From "Kenneth Goodwin" > To "Folkert van Heusden" > Cc "The Eunuchs Hysterical Society" > Date 4/7/2025 8:02:01 AM > Subject [TUHS] Re: running BSD 2.11 on my PDP 11/70 emulator > > To me it looks like a memory issue of some sort. Setup of the MMU etc. > > 1. Your user memory is less than 10% of "available memory" which should be > the amount left after the kernel loads and allocates dynamic buffers. User > memory should be alot closer to available number. Unless it is referring to > limits of mmu per process and not total available for all user level > programs. > > 2. The bulk of the text dump seems to just be random initialized data > dumped from Ram. > Aka - Printf() format strings. Indicates that the wrong address in memory > is potentially being accessed. > > Perhaps the pdp11 emulator configuration does not have a correct mmu for > your image file. > > For example, you are running the 11/70 emulation and the binary image you > are running is actually compiled for a pdp 11/45. > > The 11/70 has an mmu supporting split instruction and data spaces. 64k > instruction, 64k data. But the kernel you are using was compiled to run on > a non split I And D version of the pdp11 supporting only 64kb of combined > user and data. > > On Mon, Apr 7, 2025, 3:30 AM Folkert van Heusden > wrote: > >> Hi, >> >> For fun I'm developing a PDP 11/70 emulator. It runs on everything from >> ESP32 microcontrollers up to linux, windows, etc >> https://vanheusden.com/emulation/PDP-11/kek/ >> Currently it can run UNIX 7 in multi user mode. >> Of course I would like it to run BSD 2.11 as well (because of the >> networking support). It boots, but after outputting the memory amounts >> it produces a lot of garbage. It does eventually complete booting and >> then allows you to log in. >> I wonder if you sees this: >> https://paste.nurd.space/mqIDB_0SjoDoJoasOGkiNQ_NjpRsCufAJCnKTA7ZxUI >> (text) or >> >> https://imgpaste.nurd.space/pics/437bcf0d149a017168cbbf2def8560917a037a3935c5c3aa1fbea2f7e43b485a.png >> (image), does this ring a bell to anyone? I verified with simh that the >> disk-image should work. >> >> >> regards >> >> -- >> www.vanheusden.com >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at ultimate.com Wed Apr 9 04:42:26 2025 From: phil at ultimate.com (Phil Budne) Date: Tue, 08 Apr 2025 14:42:26 -0400 Subject: [TUHS] running BSD 2.11 on my PDP 11/70 emulator In-Reply-To: References: <122fede123f3d5bd5df3b9bf3ccb83dc@vanheusden.com> Message-ID: <202504081842.538IgQDM074804@ultimate.com> A fun thing 2.11BSD does is it runs networking in supervisor code in supervisor mode so that mbufs don't need to appear in the kernel address space. It was the first thing that came to my mind when you mentioned having trouble. This is what I see booting 2.11 under SimH: 44Boot from ra(0,0,0) at 0172150 : unix Boot: bootdev=02400 bootcsr=0172150 2.11 BSD UNIX #19: Sun Jun 17 16:44:43 PDT 2012 root at pdp11:/usr/src/sys/ZEKE ra0: Ver 3 mod 3 ra0: RA82 size=1954000 attaching de0 csr 174510 attaching lo0 phys mem = 3932160 avail mem = 3553344 user mem = 307200 May 26 12:08:51 init: configure system dz 0 csr 160100 vector 310 attached ra 0 csr 172150 vector 154 vectorset attached erase, kill ^U, intr ^C # A quick look at the code (the best documentation): "user mem" output is the result of: printf("user mem = %D\n", ctob((long)MAXMEM)); in init_main.c MAXMEM is defined in param.h: /* * MAXMEM is the maximum core per process is allowed. First number is Kb. */ #define MAXMEM (300*16) So the number being output seems like the intended value. From folkert at vanheusden.com Wed Apr 9 05:11:47 2025 From: folkert at vanheusden.com (Folkert van Heusden) Date: Tue, 08 Apr 2025 21:11:47 +0200 Subject: [TUHS] running BSD 2.11 on my PDP 11/70 emulator In-Reply-To: References: <122fede123f3d5bd5df3b9bf3ccb83dc@vanheusden.com> Message-ID: 1. sounds like a calculation bug of some sort. possible, but not likely: I patched simh to output a set of large JSON-files with tests and their outcomes so that I can verify my emulator with the gold standard of pdp emulation without simply copying the simh-code (hopefully one day I can produce that set with a real hardware pdp 11/7). sofar I fixed all problems I found (a few flag problems and handling of the PSW). 2. yeah I have a suspicion that it might be a problem in one of the more complex addressing modes (@xxx(R7) for example where some of it comes from I space and some of D-space). am writing tests or that now. regarding the 11/45 versus 11/70: I set the cpu to 11/70 when verifying the disk-image with simh. so it should run in a 11/70. 3. if I do that, the "avail mem" goes down with it, user mem stays 307200. [1*: https://vanheusden.com/git/folkert/simh-testsetgenerator/src/branch/valgen look for test.c] On 2025-04-07 14:02, Kenneth Goodwin wrote: > To me it looks like a memory issue of some sort. Setup of the MMU etc. > > 1. Your user memory is less than 10% of "available memory" which should > be the amount left after the kernel loads and allocates dynamic > buffers. User memory should be alot closer to available number. Unless > it is referring to limits of mmu per process and not total available > for all user level programs. > > 2. The bulk of the text dump seems to just be random initialized data > dumped from Ram. > Aka - Printf() format strings. Indicates that the wrong address in > memory is potentially being accessed. > > Perhaps the pdp11 emulator configuration does not have a correct mmu > for your image file. > > For example, you are running the 11/70 emulation and the binary image > you are running is actually compiled for a pdp 11/45. > > The 11/70 has an mmu supporting split instruction and data spaces. 64k > instruction, 64k data. But the kernel you are using was compiled to > run on a non split I And D version of the pdp11 supporting only 64kb of > combined user and data. > [ this suggestion came from Kenneth's 2nd reply, added in this message to prevent a lot of reply-mails by me ] > 3. If your bsd image has kernel dynamic buffer configuration limit > parameters, you could tweak those down say 50% to see what happens. > (Not a BSD kernel hacker and it's been a while since I last read over > the source code) From henry.r.bent at gmail.com Wed Apr 9 06:01:33 2025 From: henry.r.bent at gmail.com (Henry Bent) Date: Tue, 8 Apr 2025 16:01:33 -0400 Subject: [TUHS] 2.11BSD Patch Announcements Message-ID: Hi all, I see that there has been quite a bit of activity in the last few weeks with 2.11BSD, resulting in the release of a number of patches. Is there any sort of announcement list that one could subscribe to in order to be notified of when these patch releases occur? Would it make sense to post patch announcements to the TUHS or SIMH lists? TUHS seems somewhat natural since one of the patch distribution methods is through their archive, though I am open to thoughts that anyone else has about this. I only happened to be aware of the patches because I have the "History of the Berkeley Software Distribution" page on my Wikipedia watchlist and someone has been very diligent about updating the 2.11BSD patch status there. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Wed Apr 9 06:24:51 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 08 Apr 2025 20:24:51 +0000 Subject: [TUHS] Current Status of AT&T/USL Licensing? Message-ID: So System V shops had to hold a license with AT&T to modify and redistribute code based on UNIX System V and they would then license directly with their customers correct? This being distinct from the way licensing with BSD was concerned in that you had to pursue the license with AT&T to then use BSD. That is my current understanding anyway that I base this question on. So IBM, DEC, Sun, HP, Microsoft, etc. approach AT&T, got a source license, and started producing their System V value adds out there in the world. In this present day and age, for those still shipping genuine System V derivatives, what does this licensing landscape actually look like? Do the players still in the game still refer to whatever license they started with back in the 80s, did they renew up until say SVR4 when folks stopped drinking from the USL well, or are there still ongoing licenses that the remaining vendors have to renew to distribute their software? Where I'm going with this is just another angle on the whole "who owns System V" question which comes up in my mind all the time. Knowing the specific legal entities involved in the most recent licensing documentation would certainly factor into understanding the landscape a little better. To boil that down to a specific example, once upon a time, Sun held a license with AT&T to use, modify, and redistribute UNIX System V. At the present moment, Oracle is the distributor of Solaris. If there is a piece of licensing paperwork sitting in a filing cabinet at Oracle somewhere, who would that paperwork say is the original licensor of the product? Would that even matter in this year of 2025? - Matt G. From athornton at gmail.com Wed Apr 9 07:07:20 2025 From: athornton at gmail.com (Adam Thornton) Date: Tue, 8 Apr 2025 14:07:20 -0700 Subject: [TUHS] 2.11BSD Patch Announcements In-Reply-To: References: Message-ID: I hear about most of them on the PiDP-11 mailing list. I think PiDP-11 users have provided most of the recent motivation for the flurry of 2.11BSD activity. Adam On Tue, Apr 8, 2025 at 1:19 PM Henry Bent wrote: > Hi all, > > I see that there has been quite a bit of activity in the last few weeks > with 2.11BSD, resulting in the release of a number of patches. Is there > any sort of announcement list that one could subscribe to in order to be > notified of when these patch releases occur? Would it make sense to post > patch announcements to the TUHS or SIMH lists? TUHS seems somewhat natural > since one of the patch distribution methods is through their archive, > though I am open to thoughts that anyone else has about this. I only > happened to be aware of the patches because I have the "History of the > Berkeley Software Distribution" page on my Wikipedia watchlist and someone > has been very diligent about updating the 2.11BSD patch status there. > > -Henry > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Wed Apr 9 07:20:09 2025 From: imp at bsdimp.com (Warner Losh) Date: Tue, 8 Apr 2025 15:20:09 -0600 Subject: [TUHS] Current Status of AT&T/USL Licensing? In-Reply-To: References: Message-ID: On Tue, Apr 8, 2025 at 2:25 PM segaloco via TUHS wrote: > Where I'm going with this is just another angle on the whole "who owns > System V" > question which comes up in my mind all the time. Knowing the specific > legal > entities involved in the most recent licensing documentation would > certainly > factor into understanding the landscape a little better. > We don't even know, for sure, who owns Unix, apart from The Open Group definitely owns the trademark and the whole POSIX stuff. Though we can make some good guesses. Novell had the copyrights, as far as anybody could tell. Let's assume that was true (not a big leap, but a point that's been contested in the past). They sold it to attachmate, who sold it to MicroFocus who sold it to OpenText. At least that's the paper trail, except the last step, that I think I can document on the US copyright registration web site. There's changes that release interest in the copyright filed 1/31/2023, which corresponds with the sale to OpenText. But I can't find OpenText's name on the new copyright paperwork, which is a bit weird since the older filings for the sale to MicroFocus have their name on it. It's part of a huge bundle of works transferred (like 1800 works). It includes System V, System V release 2; release 3; release 4, unixware and a couple of other things you'd expect to find here. But nothing for OpenText or Open Text that I saw. I'm sure those more skilled than I will surface those records. https://cocatalog.loc.gov/cgi-bin/Pwebrecon.cgi?v1=1&ti=1,1&Search%5FArg=Unix%20System%20V&Search%5FCode=TALL&CNT=25&REC=0&RD=0&RC=0&PID=Yig8CwgSX_JCL5yGUgrC0eBzQf4i16&SEQ=20250408171535&SID=3 might be useful to people to mine further. I imagine that OpenText is still getting at least a tiny royalty stream from sales of System V derived software, but I can't imagine that would be very large since I recall reading IBM, Digital, Sun and SGI all getting "paid up" licenses that required no future royalty. But I have no original sources for this information. Interestingly enough,on the above loc.gov web site, there's nothing for 6th edition, 7th edition or 32V or any of the variations I could think of. This fits with Clem's assertion that these were only trade secrets whose secret status was blown up decades ago. System III also has no registration (though System 3 found too many IBM System/3 systems to be a useful search). Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Wed Apr 9 07:24:21 2025 From: henry.r.bent at gmail.com (Henry Bent) Date: Tue, 8 Apr 2025 17:24:21 -0400 Subject: [TUHS] 2.11BSD Patch Announcements In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 at 17:07, Adam Thornton wrote: > I hear about most of them on the PiDP-11 mailing list. I think PiDP-11 > users have provided most of the recent motivation for the flurry of 2.11BSD > activity. > > Adam > > On Tue, Apr 8, 2025 at 1:19 PM Henry Bent wrote: > >> Hi all, >> >> I see that there has been quite a bit of activity in the last few weeks >> with 2.11BSD, resulting in the release of a number of patches. Is there >> any sort of announcement list that one could subscribe to in order to be >> notified of when these patch releases occur? Would it make sense to post >> patch announcements to the TUHS or SIMH lists? TUHS seems somewhat natural >> since one of the patch distribution methods is through their archive, >> though I am open to thoughts that anyone else has about this. I only >> happened to be aware of the patches because I have the "History of the >> Berkeley Software Distribution" page on my Wikipedia watchlist and someone >> has been very diligent about updating the 2.11BSD patch status there. >> >> -Henry >> > It's wonderful that there is activity around that particular implementation of the PDP-11, but since this is a much larger community I'm trying to think of ways that will engage the widest possible audience, hopefully without disturbing anyone or feeling off-topic. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Apr 9 07:33:31 2025 From: clemc at ccc.com (Clem Cole) Date: Tue, 8 Apr 2025 17:33:31 -0400 Subject: [TUHS] running BSD 2.11 on my PDP 11/70 emulator In-Reply-To: References: <122fede123f3d5bd5df3b9bf3ccb83dc@vanheusden.com> Message-ID: Do you pass the DEC diagnostics? They are not perfect, but they can sometimes tease out some of the interesting corner cases, although the OS's are known to be even better at that, albeit with less interesting diagnostics. Also, did you try Ultrix, which is one step farther than V7 but not quite as far as 2.11BSD? Another thing I learned from reading your comments that got me thinking a little: IIRC the red/yellow zone stuff for the stack is different between PDP-11 implementations. As Phil noted, 2.11BSD differs from V7 and Ultrix in that they tried adding more Vax logic into it. >>I have not looked at the 2.11BSD sources<< to check, but it possible/likely that Steven and team redid that code. So I would check to see what V7 is doing on a 70 when it gets a stack fault and needs to grow it vs. the 2.11BSD code. ᐧ On Tue, Apr 8, 2025 at 3:11 PM Folkert van Heusden wrote: > 1. sounds like a calculation bug of some sort. possible, but not likely: > I patched simh to output a set of large JSON-files with tests and their > outcomes so that I can verify my emulator with the gold standard of pdp > emulation without simply copying the simh-code (hopefully one day I can > produce that set with a real hardware pdp 11/7). sofar I fixed all > problems I found (a few flag problems and handling of the PSW). > > 2. yeah I have a suspicion that it might be a problem in one of the more > complex addressing modes (@xxx(R7) for example where some of it comes > from I space and some of D-space). am writing tests or that now. > regarding the 11/45 versus 11/70: I set the cpu to 11/70 when verifying > the disk-image with simh. so it should run in a 11/70. > > 3. if I do that, the "avail mem" goes down with it, user mem stays > 307200. > > [1*: > https://vanheusden.com/git/folkert/simh-testsetgenerator/src/branch/valgen > look for test.c] > > On 2025-04-07 14:02, Kenneth Goodwin wrote: > > > To me it looks like a memory issue of some sort. Setup of the MMU etc. > > > > 1. Your user memory is less than 10% of "available memory" which should > > be the amount left after the kernel loads and allocates dynamic > > buffers. User memory should be alot closer to available number. Unless > > it is referring to limits of mmu per process and not total available > > for all user level programs. > > > > 2. The bulk of the text dump seems to just be random initialized data > > dumped from Ram. > > Aka - Printf() format strings. Indicates that the wrong address in > > memory is potentially being accessed. > > > > Perhaps the pdp11 emulator configuration does not have a correct mmu > > for your image file. > > > > For example, you are running the 11/70 emulation and the binary image > > you are running is actually compiled for a pdp 11/45. > > > > The 11/70 has an mmu supporting split instruction and data spaces. 64k > > instruction, 64k data. But the kernel you are using was compiled to > > run on a non split I And D version of the pdp11 supporting only 64kb of > > combined user and data. > > > > [ this suggestion came from Kenneth's 2nd reply, added in this message > to prevent a lot of reply-mails by me ] > > > 3. If your bsd image has kernel dynamic buffer configuration limit > > parameters, you could tweak those down say 50% to see what happens. > > (Not a BSD kernel hacker and it's been a while since I last read over > > the source code) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Apr 9 09:09:55 2025 From: clemc at ccc.com (Clem Cole) Date: Tue, 8 Apr 2025 19:09:55 -0400 Subject: [TUHS] Current Status of AT&T/USL Licensing? In-Reply-To: References: Message-ID: On Tue, Apr 8, 2025 at 4:25 PM segaloco via TUHS > wrote: > So System V shops had to hold a license with AT&T to modify and > redistribute > code based on UNIX System V and they would then license directly with their > customers correct? You are talking about two different licenses (with three fees, actually). > This being distinct from the way licensing with BSD was > concerned in that you had to pursue the license with AT&T to then use BSD. > That > is my current understanding anyway that I base this question on. > Right... that would worked for any version of the UNIX license from Fifth Edition through SVR5, which I believe was the last license that Novell released to the world. If you are a *commercial customer*, the license grants you the right to have the sources and use them on a >>single<< CPU, which is named (via make and serial number) in the license. Each additional CPU must be named and licensed separately at a reduced fee. The universities and research institutions had a non-commercial license that did not name a CPU. They could use the AT&T IP anywhere as long as it was for non-commercial purposes [more in a minute—there is a catch-22]. Either of these licenses also gives you the right to *share your sources with anyone else who has a source license from AT&T for the same (or a lesser) version*. That is, if you had a System 3.0 [renamed Sys III] or later System V license, you could still obtain things from someone with a V6 or V7 license (like UCB say), but since you were Sytem III and they V7 or V32, you could only give them code that was based on the license they had. For example, SCCS was part of PWB 2.0 originally and officially left the labs as part of and Sytem 3.0. Remember the research license only included V5, V6, V7, and V32 — not PWB, nor System 3 While SCCS "leaked" to some of the Universities via AT&T Employee's (the OYOCs), the Universities were technically not licensed for it, which is why, of course, even though it is being used at UCB, it's not in the BSD source distribution and also why UCB switched to RCS as soon as it was available (because it done at another University and was >>freely<< open source, not just AT&T licensed and open with the AT&T license community. The interesting catch-22 came about when Universities (like CMU originally) started using UNIX commercially internally for things like billing and student records. A few of us grew uncomfortable about this pretty blatant misuse in Mellon Institute, CMU's semi-cokmerical arm, which was using UNIX as its development system for the projects they contracted (like the Pittsburgh Press automation, USS Steel, Alcoa, and even the Israeli Army. In fact, in mid-1978, Danny Klein and I went on strike at Mellon Institute, and Al Arm's of AT&T Patent and Licensing team offered a compromise where CMU bought one commercial license and named the Mellon Institute PDP-11 as the CMU commercial host. Officially, any work, like the work that started to be done for the CMU back-office, even if it ran on a different system, was officially designated as work for Mellon. I know Case-Western got a similar license in late 1979 because I told Fred Park about it when he was working with us at Tektronix in the Summer of 1979. I believe UCB and Purdue also followed suit, but I never knew. > So IBM, DEC, Sun, HP, Microsoft, etc. approach AT&T, got a source license, err.. Sun was not there, thank you very much... [they would not exist for another 6 years]. With the release of the V7 license, a group of Prof. Dennis Allison's clients were brought together at Ricki's Hyatt in Palo Alto [I was there, and it is, as I have said in other messages, the only time I ever met Gates]. The firms I remember that were there (besides Al Arms for AT&T) were IBM, Tektronix, DEC, HP, Microsoft, 3Com, and what would eventually become SCO. There were a couple of others, but I do not remember who they were. Somebody like Bruce Borden, who was representing 3Com, might, and Dennis might remember who he invited from his client list. At that point, AT&T had produced the V7 "redistribution" license, which once you had a source license, then allowed you (for a per CPU fee) the right redistribute the AT&T IP. Let's just say the terms were pretty bad. I'll not go into them here. This first meeting resulted in a set of follow-up meetings to create what would eventually become the Sytem 3.0 redistribution license (and the new Sytem 3.0 source license). This group would also eventually create what would become /usr/group, but that's another story. As I said, AT&T Marketing decided to change the marketing materials to System III at the last minute. But all the docs and the licenses say *System 3.0* because they were already through the print cycle for the former and the legal approval cycle for the latter. The key is that a commercial firm had to pay for the right to have the source only on >>specific<< CPUs and then the rights redistribution, and then on a per redistributed binary, a license for each of those CPUs (3 different fees). BTW, the whole X-user license stuff for end-user binaries was because of the redistribution license fees. The fee the licensee paid to AT&T for a binary that ran a "workstation" was significantly cheaper than one that ran an eight or 16-user, much less 32 or 64-user time-sharing machine [thank you, Microsoft and DEC actually -- I can explain how this all happened in another email if folks are interested]. With later redistribution licenses for later AT&T releases such as System V, SRV2, SRV3, SRV4, some of the source license storage requirements were relaxed, but for this list, please understand there is the core source license (which is based on each release) and then a redistribution license for the release, and per CPU license BTW: the primary reason why OSF was created was because everytime AT&T made a new OS release, they changed the redistribution license terms. If you look at the OSF found principles the first one is "*stable license terms.*" It really was a problem for everyone. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kennethgoodwin56 at gmail.com Wed Apr 9 13:11:55 2025 From: kennethgoodwin56 at gmail.com (Kenneth Goodwin) Date: Tue, 8 Apr 2025 23:11:55 -0400 Subject: [TUHS] running BSD 2.11 on my PDP 11/70 emulator In-Reply-To: References: <122fede123f3d5bd5df3b9bf3ccb83dc@vanheusden.com> Message-ID: Sorry I dont have time to look at source code. Usermem is a hard coded compile time static unless ctob() is pulling in some boot time variable from all appearances. Compare your output from the boot to the other parties to see what is different. As well as your emulator and bsd configurations. I think his name was Phil... sorry in advance 😅 😔 (Sorry. Can't split screen on this smart phone) I am personnel curious as to WHY USER MAXMEM has this hard coded value of 300kb It's bigger than the 128k limit of split i/d. Last bsd kernel I looked at years ago was 2.9 And the pieces that Pyramid Tech used for their dual universe 32 bit virtual based on the bsd Vax releases. Does 2.11 have some form of shared memory that is bank selected so that a physical process can be as large as 300kb ? Or is it limiting the aggregate memory of user process, mbufs. Disk buffers and other kernel resources an Individual process can utilize?? On Tue, Apr 8, 2025, 3:11 PM Folkert van Heusden wrote: > 1. sounds like a calculation bug of some sort. possible, but not likely: > I patched simh to output a set of large JSON-files with tests and their > outcomes so that I can verify my emulator with the gold standard of pdp > emulation without simply copying the simh-code (hopefully one day I can > produce that set with a real hardware pdp 11/7). sofar I fixed all > problems I found (a few flag problems and handling of the PSW). > > 2. yeah I have a suspicion that it might be a problem in one of the more > complex addressing modes (@xxx(R7) for example where some of it comes > from I space and some of D-space). am writing tests or that now. > regarding the 11/45 versus 11/70: I set the cpu to 11/70 when verifying > the disk-image with simh. so it should run in a 11/70. > > 3. if I do that, the "avail mem" goes down with it, user mem stays > 307200. > > [1*: > https://vanheusden.com/git/folkert/simh-testsetgenerator/src/branch/valgen > look for test.c] > > On 2025-04-07 14:02, Kenneth Goodwin wrote: > > > To me it looks like a memory issue of some sort. Setup of the MMU etc. > > > > 1. Your user memory is less than 10% of "available memory" which should > > be the amount left after the kernel loads and allocates dynamic > > buffers. User memory should be alot closer to available number. Unless > > it is referring to limits of mmu per process and not total available > > for all user level programs. > > > > 2. The bulk of the text dump seems to just be random initialized data > > dumped from Ram. > > Aka - Printf() format strings. Indicates that the wrong address in > > memory is potentially being accessed. > > > > Perhaps the pdp11 emulator configuration does not have a correct mmu > > for your image file. > > > > For example, you are running the 11/70 emulation and the binary image > > you are running is actually compiled for a pdp 11/45. > > > > The 11/70 has an mmu supporting split instruction and data spaces. 64k > > instruction, 64k data. But the kernel you are using was compiled to > > run on a non split I And D version of the pdp11 supporting only 64kb of > > combined user and data. > > > > [ this suggestion came from Kenneth's 2nd reply, added in this message > to prevent a lot of reply-mails by me ] > > > 3. If your bsd image has kernel dynamic buffer configuration limit > > parameters, you could tweak those down say 50% to see what happens. > > (Not a BSD kernel hacker and it's been a while since I last read over > > the source code) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lyndon at orthanc.ca Thu Apr 10 03:10:14 2025 From: lyndon at orthanc.ca (Lyndon Nerenberg (VE7TFX/VE6BBM)) Date: Wed, 09 Apr 2025 10:10:14 -0700 Subject: [TUHS] Current Status of AT&T/USL Licensing? In-Reply-To: References: Message-ID: <1c3485d580443b1a@orthanc.ca> segaloco via TUHS writes: > To boil that down to a specific example, once upon a time, Sun held > a license with AT&T to use, modify, and redistribute UNIX System > V. At the present moment, Oracle is the distributor of Solaris. > If there is a piece of licensing paperwork sitting in a filing > cabinet at Oracle somewhere, who would that paperwork say is the > original licensor of the product? Would that even matter in this > year of 2025? At some point Sun bought out their license from AT&T. My guess is it was pre-Solaris 9, as that buyout was what let them start offering up Solaris 9 source code on an experimental basis, and then fully unleashing it with the Solaris 10 release. As Warren mentions, others might have done the same, but I have no knowledge of any deals other than Sun's. --lyndon From tuhs at tuhs.org Thu Apr 10 03:39:51 2025 From: tuhs at tuhs.org (Alan Coopersmith via TUHS) Date: Wed, 9 Apr 2025 10:39:51 -0700 Subject: [TUHS] Current Status of AT&T/USL Licensing? In-Reply-To: <1c3485d580443b1a@orthanc.ca> References: <1c3485d580443b1a@orthanc.ca> Message-ID: On 4/9/25 10:10, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: > segaloco via TUHS writes: > >> To boil that down to a specific example, once upon a time, Sun held >> a license with AT&T to use, modify, and redistribute UNIX System >> V. At the present moment, Oracle is the distributor of Solaris. >> If there is a piece of licensing paperwork sitting in a filing >> cabinet at Oracle somewhere, who would that paperwork say is the >> original licensor of the product? Would that even matter in this >> year of 2025? > > At some point Sun bought out their license from AT&T. From Novell, since AT&T had already sold USL to Novell by then: https://www.upi.com/amp/Archives/1994/03/17/Sun-Micro-pays-Novell-825-million-to-end-license-deal/7075763880400/ -- -Alan Coopersmith- alan.coopersmith at oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/solaris From sjenkin at canb.auug.org.au Thu Apr 10 07:52:43 2025 From: sjenkin at canb.auug.org.au (sjenkin at canb.auug.org.au) Date: Thu, 10 Apr 2025 07:52:43 +1000 Subject: [TUHS] Current Status of AT&T/USL Licensing? In-Reply-To: <1c3485d580443b1a@orthanc.ca> References: <1c3485d580443b1a@orthanc.ca> Message-ID: <865365B1-E258-41B4-BE7D-15F50DAEC34B@canb.auug.org.au> For completeness, SUN & AT&T merged their lines, at least Userland, with SVR4, with, I believe, SUN paying a perpetual fee for its license. [ refs only for the merge, not license deal ] TUHS, Larry McVoy Excerpt from Solaris 8 System Admin Manual, 2000 Bill Calkins, ‘History of Solaris' Calkins makes the point the merge was to resolve the “Unix Wars”, to have one product going up against Windows NT. "UNIX is plural. It is not one operating system but, many implementations of an idea that originated in 1965." > On 10 Apr 2025, at 03:10, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: > > At some point Sun bought out their license from AT&T. My guess is > it was pre-Solaris 9, as that buyout was what let them start offering > up Solaris 9 source code on an experimental basis, and then fully > unleashing it with the Solaris 10 release. > > As Warren mentions, others might have done the same, but I > have no knowledge of any deals other than Sun's. > > --lyndon -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From folkert at vanheusden.com Wed Apr 16 06:05:13 2025 From: folkert at vanheusden.com (Folkert van Heusden) Date: Tue, 15 Apr 2025 22:05:13 +0200 Subject: [TUHS] running BSD 2.11 on my PDP 11/70 emulator In-Reply-To: References: <122fede123f3d5bd5df3b9bf3ccb83dc@vanheusden.com> Message-ID: Most of them do, the ones for instruction-emulation that is. MMU emulation not completely. I'll make a note to try Ultrix. This is also an update: I did fixes for MMR1 handling. It was reset at the wrong moment and not set correctly. Also I was throwing trap 4 instead of 250 for mmu errors - that doesn't help either :-) Now "make" starts without bus errors altough after cc fails with a "pushfile" error: 2.11 BSD UNIX (folkert.vanheusden.com) (console) login: root erase, kill ^U, intr ^C # cd /usr/src/sys # ls CURLY QT h netimp pdpif sys FVH autoconfig machine netinet pdpmba vaxif GENERIC bootrom mdec netns pdpstand vaxuba OTHERS conf net pdp pdpuba # cd FVH # make make -f Make.net I=/usr/include H=../h M=../machine AS="/bin/as -V" CPP="/lib/cpp -P -DKERNEL -DFVH -DINET -DSOFUB_MAP -I. -I../h -DSUPERVISOR" CFLAGS="-O -DKERNEL -DFVH -DINET -DSOFUB_MAP -I. -I../h -DSUPERVISOR" SED="/bin/sed" ED="/bin/ed" cc -O -DKERNEL -DFVH -DINET -DSOFUB_MAP -I. -I../h -DSUPERVISOR -S ../net/if_loop.c :1: warning: __BSD2_11__ redefined (previously defined at "" line 6) :2: warning: BSD2_11 redefined (previously defined at "" line 7) :3: warning: __pdp11__ redefined (previously defined at "" line 8) :4: warning: pdp11 redefined (previously defined at "" line 9) :5: warning: unix redefined (previously defined at "" line 10) :6: warning: __STDC__ redefined (previously defined at "" line 11) pushfile: error open >z(5\| *** Exit 1 Stop. *** Exit 1 Stop. Progress! On 2025-04-08 23:33, Clem Cole wrote: > Do you pass the DEC diagnostics? They are not perfect, but they can > sometimes tease out some of the interesting corner cases, although the > OS's are known to be even better at that, albeit with less interesting > diagnostics. Also, did you try Ultrix, which is one step farther than > V7 but not quite as far as 2.11BSD? Another thing I learned from > reading your comments that got me thinking a little: IIRC the > red/yellow zone stuff for the stack is different between PDP-11 > implementations. As Phil noted, 2.11BSD differs from V7 and Ultrix in > that they tried adding more Vax logic into it. >>I have not looked at > the 2.11BSD sources<< to check, but it possible/likely that Steven and > team redid that code. So I would check to see what V7 is doing on a 70 > when it gets a stack fault and needs to grow it vs. the 2.11BSD code. > ᐧ > > On Tue, Apr 8, 2025 at 3:11 PM Folkert van Heusden > wrote: > >> 1. sounds like a calculation bug of some sort. possible, but not >> likely: >> I patched simh to output a set of large JSON-files with tests and >> their >> outcomes so that I can verify my emulator with the gold standard of >> pdp >> emulation without simply copying the simh-code (hopefully one day I >> can >> produce that set with a real hardware pdp 11/7). sofar I fixed all >> problems I found (a few flag problems and handling of the PSW). >> >> 2. yeah I have a suspicion that it might be a problem in one of the >> more >> complex addressing modes (@xxx(R7) for example where some of it comes >> from I space and some of D-space). am writing tests or that now. >> regarding the 11/45 versus 11/70: I set the cpu to 11/70 when >> verifying >> the disk-image with simh. so it should run in a 11/70. >> >> 3. if I do that, the "avail mem" goes down with it, user mem stays >> 307200. >> >> [1*: >> https://vanheusden.com/git/folkert/simh-testsetgenerator/src/branch/valgen >> look for test.c] >> >> On 2025-04-07 14:02, Kenneth Goodwin wrote: >> >>> To me it looks like a memory issue of some sort. Setup of the MMU >>> etc. >>> >>> 1. Your user memory is less than 10% of "available memory" which >>> should >>> be the amount left after the kernel loads and allocates dynamic >>> buffers. User memory should be alot closer to available number. >>> Unless >>> it is referring to limits of mmu per process and not total available >>> for all user level programs. >>> >>> 2. The bulk of the text dump seems to just be random initialized data >>> dumped from Ram. >>> Aka - Printf() format strings. Indicates that the wrong address in >>> memory is potentially being accessed. >>> >>> Perhaps the pdp11 emulator configuration does not have a correct mmu >>> for your image file. >>> >>> For example, you are running the 11/70 emulation and the binary >>> image >>> you are running is actually compiled for a pdp 11/45. >>> >>> The 11/70 has an mmu supporting split instruction and data spaces. >>> 64k >>> instruction, 64k data. But the kernel you are using was compiled to >>> run on a non split I And D version of the pdp11 supporting only 64kb >>> of >>> combined user and data. >>> >> >> [ this suggestion came from Kenneth's 2nd reply, added in this message >> to prevent a lot of reply-mails by me ] >> >>> 3. If your bsd image has kernel dynamic buffer configuration limit >>> parameters, you could tweak those down say 50% to see what happens. >>> (Not a BSD kernel hacker and it's been a while since I last read over >>> the source code) -- www.vanheusden.com [1] Links: ------ [1] http://www.vanheusden.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: blocked.gif Type: image/gif Size: 118 bytes Desc: not available URL: From clemc at ccc.com Wed Apr 16 07:05:22 2025 From: clemc at ccc.com (Clem Cole) Date: Tue, 15 Apr 2025 17:05:22 -0400 Subject: [TUHS] running BSD 2.11 on my PDP 11/70 emulator In-Reply-To: References: <122fede123f3d5bd5df3b9bf3ccb83dc@vanheusden.com> Message-ID: On Tue, Apr 15, 2025 at 4:05 PM Folkert van Heusden wrote: > Most of them do, the ones for instruction-emulation that is. MMU emulation > not completely > That is a little worrisome to me. But of course, which ones. While I knew and probably worked with and thus probably have met who wrote the diagnostics, I do not think I can not come up with a name of the guilty party here to ask. As I said, where to loo, the stack grow logic is the real suspect because as the system runs, and it's not until you start to put a load on and start to swap a little that you are getting some failures. So some type of pressure is occurring. I guess that a number of mallocs have caused breaks to enlarge memory, but that happens a lot with so many commands. I reluctantly think there is something else wonky. Stack growth is surprisingly rare due to how processes are created. IIRC a stack on a separate I/D system is often about a few K to start which is usually "enough." Big compiles like the kernel, however, might push that limit, and the red/yellow zone stuff starts to get worked out. What I don't know is if there are diagnostics for that logic. I also know is the best description of what is >>supposed<< to happen is pages 278-279 of my 1981 processor handbook. (a.k.a. EB-19402-20 — https://bitsavers.org/pdf/dec/pdp11/handbooks/EB-19402-20_PDP-11_Processor_Handbook_1981.pdf ). I think there are two parts to this... You have the CPU itself generating 16-bit addresses (user mode) being mapped through your MMU. If the MMU has a >>slightly<< wonky corner case, I wonder if that is tripping up stack fault logic somehow, so 2.11BSD is getting confused. Since this is happening to >>user space<< code (we never "grow" kernel stacks), it's not fatal to the OS, but it will cause processes to go south. I can not guarantee this is the issue, but it certainly would be a scenario that would explain what you are seeing. Clem > ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Thu Apr 17 03:00:37 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 16 Apr 2025 17:00:37 +0000 Subject: [TUHS] Pre-Symposium on Operating System Principles Public UNIX Mentions? Message-ID: I see in many places the 1973 Symposium on Operating System Principles mentioned as one of the earliest if not the earliest discussion of UNIX in the public eye. This would be around the time of the Fourth Edition and the rewrite of the system for the PDP-11/45 in C. Well, I recently picked up Aho and Ullman's The Theory of Parsing, Translation, and Compiling. The very last sentence of the preface in Volume 1 reads: > The use of UNIX, an operating system for the PDP-11 computer designed by > Dennis Ritchie and Kenneth Thompson, expedited the preparation of certain > parts of this manuscript. Given that this text was published in 1972, would this have been a completely esoteric reference to the general target audience of these books or was knowledge of UNIX already well circulated in the computing community by then? What other sorts of notoriety/publicity did UNIX get out in the general public prior to its presentation in 1973 and subsequent publication of the paper in CACM? - Matt G. From lars at nocrew.org Fri Apr 18 13:28:49 2025 From: lars at nocrew.org (Lars Brinkhoff) Date: Fri, 18 Apr 2025 03:28:49 +0000 Subject: [TUHS] UniPress Emacs V2.20 from 1989 Message-ID: <7wy0vyrvv2.fsf@junk.nocrew.org> The floppy label says it's for AIX, but the source code hits it runs on Sun, IRIS, Apollo, HP, X10, X11, Amiga, Mac, MS-DOS, Xenix. https://github.com/larsbrinkhoff/emacs-history/tree/sources/Hans%20H%C3%BCbner From henry.r.bent at gmail.com Fri Apr 18 15:36:23 2025 From: henry.r.bent at gmail.com (Henry Bent) Date: Fri, 18 Apr 2025 01:36:23 -0400 Subject: [TUHS] UniPress Emacs V2.20 from 1989 In-Reply-To: <7wy0vyrvv2.fsf@junk.nocrew.org> References: <7wy0vyrvv2.fsf@junk.nocrew.org> Message-ID: On Thu, 17 Apr 2025 at 23:35, Lars Brinkhoff wrote: > The floppy label says it's for AIX, but the source code hits it runs on > Sun, IRIS, Apollo, HP, X10, X11, Amiga, Mac, MS-DOS, Xenix. > > > https://github.com/larsbrinkhoff/emacs-history/tree/sources/Hans%20H%C3%BCbner Neat! This built very cleanly on IRIX 4 (what I had up at the moment); I imagine that it will work with minimal effort on any commercial UNIX from the appropriate (~1989) timeframe. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From trnsz at pobox.com Sat Apr 19 04:44:06 2025 From: trnsz at pobox.com (Jeff Johnson) Date: Fri, 18 Apr 2025 14:44:06 -0400 Subject: [TUHS] UniPress Emacs V2.20 from 1989 In-Reply-To: References: <7wy0vyrvv2.fsf@junk.nocrew.org> Message-ID: <8f567939-973c-472e-83a5-48aa88d47fb5@app.fastmail.com> I got it mostly compiled on a modern Linux system with a bit of hacking, but got stuck at curses incompatibilities due to some defintions and it was more work than I was planning on. I might have time to take another look at it this weekend, though. What would be more worthwhile would be building the VMS, MS-DOS, etc. versions that were officially supported. -- Jeffrey H. Johnson trnsz at pobox.com On Fri, Apr 18, 2025, at 1:36 AM, Henry Bent wrote: > On Thu, 17 Apr 2025 at 23:35, Lars Brinkhoff wrote: >> The floppy label says it's for AIX, but the source code hits it runs on >> Sun, IRIS, Apollo, HP, X10, X11, Amiga, Mac, MS-DOS, Xenix. >> >> https://github.com/larsbrinkhoff/emacs-history/tree/sources/Hans%20H%C3%BCbner > > Neat! This built very cleanly on IRIX 4 (what I had up at the moment); I imagine that it will work with minimal effort on any commercial UNIX from the appropriate (~1989) timeframe. > > -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From blake1024 at gmail.com Sat Apr 19 10:19:28 2025 From: blake1024 at gmail.com (Blake McBride) Date: Fri, 18 Apr 2025 19:19:28 -0500 Subject: [TUHS] UniPress Emacs V2.20 from 1989 In-Reply-To: <8f567939-973c-472e-83a5-48aa88d47fb5@app.fastmail.com> References: <7wy0vyrvv2.fsf@junk.nocrew.org> <8f567939-973c-472e-83a5-48aa88d47fb5@app.fastmail.com> Message-ID: Greetings, I worked on the MS-DOS version many years ago. I'd really love to see this on modern Linux!! Thanks!! Blake McBride On Fri, Apr 18, 2025 at 1:44 PM Jeff Johnson wrote: > I got it mostly compiled on a modern Linux system with a bit of hacking, > but got stuck at curses incompatibilities due to some defintions and it was > more work than I was planning on. I might have time to take another look > at it this weekend, though. > > What would be more worthwhile would be building the VMS, MS-DOS, etc. > versions that were officially supported. > > -- > Jeffrey H. Johnson > trnsz at pobox.com > > On Fri, Apr 18, 2025, at 1:36 AM, Henry Bent wrote: > > On Thu, 17 Apr 2025 at 23:35, Lars Brinkhoff wrote: > > The floppy label says it's for AIX, but the source code hits it runs on > Sun, IRIS, Apollo, HP, X10, X11, Amiga, Mac, MS-DOS, Xenix. > > > https://github.com/larsbrinkhoff/emacs-history/tree/sources/Hans%20H%C3%BCbner > > > Neat! This built very cleanly on IRIX 4 (what I had up at the moment); I > imagine that it will work with minimal effort on any commercial UNIX from > the appropriate (~1989) timeframe. > > -Henry > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Sat Apr 19 10:21:58 2025 From: ron at ronnatalie.com (Ron Natalie) Date: Sat, 19 Apr 2025 00:21:58 +0000 Subject: [TUHS] UniPress Emacs V2.20 from 1989 In-Reply-To: References: <7wy0vyrvv2.fsf@junk.nocrew.org> <8f567939-973c-472e-83a5-48aa88d47fb5@app.fastmail.com> Message-ID: I might be inclined to take a stab. Gosmacs was my editor of choice for years. I even worked for Unipress for a few months. ------ Original Message ------ >From "Blake McBride" To "Jeff Johnson" Cc "TUHS" Date 4/18/2025 8:19:28 PM Subject [TUHS] Re: UniPress Emacs V2.20 from 1989 >Greetings, > >I worked on the MS-DOS version many years ago. I'd really love to see >this on modern Linux!! > >Thanks!! > >Blake McBride > > >On Fri, Apr 18, 2025 at 1:44 PM Jeff Johnson wrote: >>I got it mostly compiled on a modern Linux system with a bit of >>hacking, but got stuck at curses incompatibilities due to some >>defintions and it was more work than I was planning on. I might have >>time to take another look at it this weekend, though. >> >>What would be more worthwhile would be building the VMS, MS-DOS, etc. >>versions that were officially supported. >> >>-- >>Jeffrey H. Johnson >>trnsz at pobox.com >> >>On Fri, Apr 18, 2025, at 1:36 AM, Henry Bent wrote: >>>On Thu, 17 Apr 2025 at 23:35, Lars Brinkhoff wrote: >>>>The floppy label says it's for AIX, but the source code hits it runs >>>>on >>>>Sun, IRIS, Apollo, HP, X10, X11, Amiga, Mac, MS-DOS, Xenix. >>>> >>>>https://github.com/larsbrinkhoff/emacs-history/tree/sources/Hans%20H%C3%BCbner >>> >>>Neat! This built very cleanly on IRIX 4 (what I had up at the >>>moment); I imagine that it will work with minimal effort on any >>>commercial UNIX from the appropriate (~1989) timeframe. >>> >>>-Henry >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From whm at msweng.com Mon Apr 21 10:08:29 2025 From: whm at msweng.com (William H. Mitchell) Date: Sun, 20 Apr 2025 17:08:29 -0700 Subject: [TUHS] UniPress Emacs V2.20 from 1989 In-Reply-To: References: <7wy0vyrvv2.fsf@junk.nocrew.org> <8f567939-973c-472e-83a5-48aa88d47fb5@app.fastmail.com> Message-ID: <5562D2B5-CDEB-4072-A145-7DFDE588A68B@msweng.com> I started using Gosling’s Emacs around 1981-1982. "make" in Emacs was a game changer! I recall that in the Emacs documentation Gosling wrote something like, "The only similarity between MockLisp and Lisp is the syntax." I didn’t get it--MockLisp sure seemed like Lisp to me! Years later I did get it and viewed that as a measure of my coming along as a computer scientist. A couple of years later I did a project where I dropped in the Icon programming language as a peer of MLisp (UniPress’s name for MockLisp, I believe.) See https://www2.cs.arizona.edu/~whm/An_Icon_Subsystem_for_UNIX_Emacs_tr84_8.pdf From lars at nocrew.org Tue Apr 22 00:45:08 2025 From: lars at nocrew.org (Lars Brinkhoff) Date: Mon, 21 Apr 2025 14:45:08 +0000 Subject: [TUHS] UniPress Emacs V2.20 from 1989 In-Reply-To: <0EE64047-17A8-4255-8CA7-C0928A5584C1@seiden.com> (Mark Seiden's message of "Fri, 18 Apr 2025 17:00:35 -0400") References: <7wy0vyrvv2.fsf@junk.nocrew.org> <8f567939-973c-472e-83a5-48aa88d47fb5@app.fastmail.com> <0EE64047-17A8-4255-8CA7-C0928A5584C1@seiden.com> Message-ID: <7wjz7dh8uj.fsf@junk.nocrew.org> Mark Seiden writes: > the display updating code, as i recall, had a skull and crossbones on it > i remember there was a bit of a kerfuffle when richard stallman introduced > that code into gnu emacs This is true. Gosling Emacs from 1984 and GNU Emacs 13 from 1985 both have the skull and crossbones comment. From marc.donner at gmail.com Tue Apr 22 07:22:00 2025 From: marc.donner at gmail.com (Marc Donner) Date: Mon, 21 Apr 2025 17:22:00 -0400 Subject: [TUHS] UniPress Emacs V2.20 from 1989 In-Reply-To: <7wjz7dh8uj.fsf@junk.nocrew.org> References: <7wy0vyrvv2.fsf@junk.nocrew.org> <8f567939-973c-472e-83a5-48aa88d47fb5@app.fastmail.com> <0EE64047-17A8-4255-8CA7-C0928A5584C1@seiden.com> <7wjz7dh8uj.fsf@junk.nocrew.org> Message-ID: Yeah, the screen redraw stuff was tense. As I recall, the best way to see that was on a mid-speed line, say 9600 baud. Slower and you could see it but it was still just annoying. A lot faster and there was no visible magic. At 9600 you could see the screen optimization doing some startling stuff. ===== nygeek.net mindthegapdialogs.com/home On Mon, Apr 21, 2025 at 11:41 AM Lars Brinkhoff wrote: > Mark Seiden writes: > > the display updating code, as i recall, had a skull and crossbones on it > > i remember there was a bit of a kerfuffle when richard stallman > introduced > > that code into gnu emacs > > This is true. Gosling Emacs from 1984 and GNU Emacs 13 from 1985 both > have the skull and crossbones comment. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Sun Apr 27 23:51:08 2025 From: arnold at skeeve.com (Aharon Robbins) Date: Sun, 27 Apr 2025 16:51:08 +0300 Subject: [TUHS] V7 ls and dot files? Message-ID: Hi All. The V7 ls.c ignores `.' and `..', unless given the -a option. The V1 - V6 ls ignores all files that start with `.', unless given -a, and this is the default for all modern versions of ls. BWK tells me there's a story about the V7 behavior but he doesn't remember what it is. Does anyone here know? Thanks, Arnold From k0ga at shike2.net Mon Apr 28 00:20:38 2025 From: k0ga at shike2.net (Roberto E. Vargas Caballero) Date: Sun, 27 Apr 2025 16:20:38 +0200 Subject: [TUHS] V7 ls and dot files? In-Reply-To: References: Message-ID: Hi, On Sun, Apr 27, 2025 at 04:51:08PM +0300, Aharon Robbins wrote: > Hi All. > > The V7 ls.c ignores `.' and `..', unless given the -a option. > > The V1 - V6 ls ignores all files that start with `.', unless given -a, > and this is the default for all modern versions of ls. > > BWK tells me there's a story about the V7 behavior but he doesn't > remember what it is. Does anyone here know? I suppose this is related to [1]. I suppose Rob can give more details as he wrote the original post. [1] http://xahlee.info/UnixResource_dir/writ/unix_origin_of_dot_filename.html Regards, From arnold at skeeve.com Mon Apr 28 17:36:24 2025 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 28 Apr 2025 01:36:24 -0600 Subject: [TUHS] V7 ls and dot files? In-Reply-To: References: Message-ID: <202504280736.53S7aObT910408@freefriends.org> "Roberto E. Vargas Caballero" wrote: > Hi, > > On Sun, Apr 27, 2025 at 04:51:08PM +0300, Aharon Robbins wrote: > > Hi All. > > > > The V7 ls.c ignores `.' and `..', unless given the -a option. > > > > The V1 - V6 ls ignores all files that start with `.', unless given -a, > > and this is the default for all modern versions of ls. > > > > BWK tells me there's a story about the V7 behavior but he doesn't > > remember what it is. Does anyone here know? > > I suppose this is related to [1]. I suppose Rob can give more details > as he wrote the original post. > > [1] http://xahlee.info/UnixResource_dir/writ/unix_origin_of_dot_filename.html > > Regards, That's an interesting article, and the point is valid, but it doesn't answer the orignal question. Thanks, Arnold From douglas.mcilroy at dartmouth.edu Mon Apr 28 21:36:18 2025 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Mon, 28 Apr 2025 07:36:18 -0400 Subject: [TUHS] V7 ls and dot files? Message-ID: http://xahlee.info/UnixResource_dir/writ/unix_origin_of_dot_filename.html says > I'm not sure but I believe .. went in during the Version 2 rewrite .. was there from the beginning. The v1 man page directory(v) says, > By convention, the first two entries in each directory are for "." and "..". Doug From pugs78 at gmail.com Tue Apr 29 10:43:34 2025 From: pugs78 at gmail.com (Tom Lyon) Date: Mon, 28 Apr 2025 17:43:34 -0700 Subject: [TUHS] BTL 'S' manual from 1981 Message-ID: Not UNIX, but adjacent... With the permission of John Chambers, I'm sharing a scan of "S - A Language and System for Data Analysis" by Richard Becker and John Chambers, January 1981. Enjoy: https://drive.google.com/drive/folders/14ijVPw1DihydXFqTzj-wgl3C5LYEJdKX?usp=sharing I was pleased to learn that the first port of S to UNIX was on the Interdata 8/32, which I had my part in enabling. -------------- next part -------------- An HTML attachment was scrubbed... URL: From beej at beej.us Tue Apr 29 11:12:55 2025 From: beej at beej.us (Brian "Beej" Hall) Date: Mon, 28 Apr 2025 18:12:55 -0700 Subject: [TUHS] Searching for game history Message-ID: Hi everyone, I'm here with a Unix/Bell Labs history question at the suggestion of BWK. I have a bit of a computing mystery on my hands... _Conquest_ is an old game that apparently came to life in Bell Labs, but no one seems to know anything more about it, including who the author is. The instructions for the game[1] contain the following text at the bottom: Amiga port by Bob Shimbo, orginal author unknown. This game started life on a UNIX system at Bell Labs. It was ported to CP/M 80 by a Scott Kamin. The manual was thrown together in an afternoon. (Typos and corrections welcome). You can reach me through Compuserve (UID 70260,231) or TBBS of colorado (303)-693-4735. The LHA archive for the Amiga was packaged in 1986. I did get in touch with Bob Shimbo, but he writes: You can imagine how long ago I did that port given I referenced my Compuserve account.  I don't recall where I found the code originally. Sorry.  We've been through 3 house moves since then and I don't know where any references might have gotten to. Scott Kamin--I found a reference to someone by his name in the CP/M world in the 80s in New Jersey. (Internet Archive has lots of old computer magazine scans and his name showed up in the classified ads.) And a search turned up a snail mail address for someone in the right age range living a few miles from the business listed in the ad. A Hail Mary snail mail got no reply. Does any of it ring a bell, by any chance? I've begun the work of getting it to run on modern systems[2], and it would be great to be able to include more history in the man page. Cheers, -Beej [1] https://github.com/beejjorgensen/conquest/blob/master/instructions.txt [2] https://github.com/beejjorgensen/conquest/ -- Brian "Beej Jorgensen" Hall beej at beej.us https://beej.us/ From robpike at gmail.com Tue Apr 29 11:21:15 2025 From: robpike at gmail.com (Rob Pike) Date: Tue, 29 Apr 2025 11:21:15 +1000 Subject: [TUHS] V7 ls and dot files? In-Reply-To: References: Message-ID: So now I see that v1 had hierarchical path names. I thought that came in v2. I stand corrected. -rob On Mon, Apr 28, 2025 at 9:36 PM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > http://xahlee.info/UnixResource_dir/writ/unix_origin_of_dot_filename.html > says > > > I'm not sure but I believe .. went in during the Version 2 rewrite > > .. was there from the beginning. The v1 man page directory(v) says, > > > By convention, the first two entries in each directory are for "." and > "..". > > Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggm at algebras.org Tue Apr 29 13:17:44 2025 From: ggm at algebras.org (George Michaelson) Date: Tue, 29 Apr 2025 13:17:44 +1000 Subject: [TUHS] V7 ls and dot files? In-Reply-To: References: Message-ID: Aside from punched card stuff. I started life in TOPS-10. 78 vintage, not very heavily modified locally as I recall. (people did run local mods, I don't think we'd applied any) I had forgotten TOPS-10 had a logical equivalent of a mount point, the MFD. And I had forgotten inside the [xxx,yyy] group/user identity directory, you could nest 5 sub-directories deep. 5! such humongous nesting! who could need more than 5 levels deep! What I did remember is there was no evident ".." equivalent in the commands to "be" in a directory. The idea of needing to go back to your parent, positionally inside a subdirectory but without recourse to the actual path down from the MFD appeared to be missing. I suspect whoever designed this was living their best life in JCL and saw no interaction on paths as needing "optimisations" = SET DIRECTORY obviously demanded a path down from an MFD. Fool of a took! By the time of VMS, you had the same $MFD:[path.path.path...] structure but now up to 255 nesting levels deep, and the "-" nonce directory meant "the parent to the one you are talking about" so at least in hypothesis a "cd .." command was possible without needing to know the descent path. 255! magic numbers! Who could need so many nesting levels? When I got the great uplift to Unix in 82 and realized . and .. existed, It was a very strong mind-officially-blown moment. Its like the zen koan for the ages: Who the hell thought it was ok to design a filesystem ANY OTHER WAY. I simply cannot handle that I was using some system (Norsk Data?) around the same time and it didn't have cd .. -It still had a TOPS-10 class view of the world as a descent tree only. Stone Age! I still regret that the newcastle connections ... naming model didn't get up. I think it was very nice. G -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsg at jsg.id.au Tue Apr 29 16:25:52 2025 From: jsg at jsg.id.au (Jonathan Gray) Date: Tue, 29 Apr 2025 16:25:52 +1000 Subject: [TUHS] Searching for game history In-Reply-To: References: Message-ID: On Mon, Apr 28, 2025 at 06:12:55PM -0700, Brian "Beej" Hall wrote: > Hi everyone, > > I'm here with a Unix/Bell Labs history question at the suggestion of > BWK. I have a bit of a computing mystery on my hands... > > _Conquest_ is an old game that apparently came to life in Bell Labs, but > no one seems to know anything more about it, including who the > author is. > > The instructions for the game[1] contain the following text at the > bottom: > > Amiga port by Bob Shimbo, orginal author unknown. > > This game started life on a UNIX system at Bell Labs. It was ported > to CP/M 80 by a Scott Kamin. The manual was thrown together in an > afternoon. (Typos and corrections welcome). > > You can reach me through Compuserve (UID 70260,231) or TBBS of > colorado (303)-693-4735. > > The LHA archive for the Amiga was packaged in 1986. > > I did get in touch with Bob Shimbo, but he writes: > > You can imagine how long ago I did that port given I referenced my > Compuserve account.  I don't recall where I found the code originally. > Sorry.  We've been through 3 house moves since then and I don't know > where any references might have gotten to. > > Scott Kamin--I found a reference to someone by his name in the CP/M > world in the 80s in New Jersey. (Internet Archive has lots of old > computer magazine scans and his name showed up in the classified ads.) > And a search turned up a snail mail address for someone in the right age > range living a few miles from the business listed in the ad. A Hail Mary > snail mail got no reply. > > Does any of it ring a bell, by any chance? I've begun the work of > getting it to run on modern systems[2], and it would be great to be able > to include more history in the man page. An implementation of the Stellar Conquest board game? https://en.wikipedia.org/wiki/Stellar_Conquest From arnold at skeeve.com Tue Apr 29 16:55:05 2025 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 29 Apr 2025 00:55:05 -0600 Subject: [TUHS] Any Interdata war stories? Message-ID: <202504290655.53T6t5Sj1009885@freefriends.org> > From: Tom Lyon > > I was pleased to learn that the first port of S to UNIX was on the > Interdata 8/32, which I had my part in enabling. I would love to hear more about the Interdata port and what happened with it afterwards. Interdata seems to have disappeared into the dustbin of history. And Unix on it apparently never got out of Bell Labs; I don't think the code for it is in the TUHS archives. Was the Interdata system in use at Bell Labs for actual work once the port was complete? ISTR there was a meeting with Interdata about changes in the architecture that Bell Labs wanted, that Interdata didn't want to make. What was the full story? Any other info would be welcome. Thanks, Arnold From jsg at jsg.id.au Tue Apr 29 17:54:03 2025 From: jsg at jsg.id.au (Jonathan Gray) Date: Tue, 29 Apr 2025 17:54:03 +1000 Subject: [TUHS] Any Interdata war stories? In-Reply-To: <202504290655.53T6t5Sj1009885@freefriends.org> References: <202504290655.53T6t5Sj1009885@freefriends.org> Message-ID: On Tue, Apr 29, 2025 at 12:55:05AM -0600, arnold at skeeve.com wrote: > > From: Tom Lyon > > > > I was pleased to learn that the first port of S to UNIX was on the > > Interdata 8/32, which I had my part in enabling. > > I would love to hear more about the Interdata port and what > happened with it afterwards. Interdata seems to have disappeared > into the dustbin of history. And Unix on it apparently never > got out of Bell Labs; I don't think the code for it is in the > TUHS archives. Tom described some of the C portability problems in Inter-UNIX Portability https://archive.org/details/CLanguagePortability_Sept77/page/n15/mode/2up https://akapugsblog.wordpress.com/wp-content/uploads/2018/05/inter-unix_portability.pdf > > Was the Interdata system in use at Bell Labs for actual work once > the port was complete? > > ISTR there was a meeting with Interdata about changes in the architecture > that Bell Labs wanted, that Interdata didn't want to make. What > was the full story? Steve Johnson on the hardware problems https://www.tuhs.org/pipermail/coff/2023-August/001672.html > > Any other info would be welcome. > > Thanks, > > Arnold > From jaapna at xs4all.nl Tue Apr 29 21:28:03 2025 From: jaapna at xs4all.nl (Jaap Akkerhuis) Date: Tue, 29 Apr 2025 13:28:03 +0200 Subject: [TUHS] V7 ls and dot files? In-Reply-To: References: Message-ID: I seem to remember that V7 was the first suystem which had a mkdir system call. That might have changed what ls -a showed. jaap From beej at beej.us Wed Apr 30 02:45:45 2025 From: beej at beej.us (Brian "Beej" Hall) Date: Tue, 29 Apr 2025 09:45:45 -0700 Subject: [TUHS] Searching for game history In-Reply-To: References: Message-ID: On Tue, Apr 29, 2025 at 04:25:52PM +1000, Jonathan Gray wrote: > On Mon, Apr 28, 2025 at 06:12:55PM -0700, Brian "Beej" Hall wrote: > > _Conquest_ is an old game that apparently came to life in Bell Labs, > > but no one seems to know anything more about it, including who the > > author is. > > An implementation of the Stellar Conquest board game? > https://en.wikipedia.org/wiki/Stellar_Conquest Oooo, that seems like a good lead--very, very similar. The games are contemporary, too. I'd classify it as "highly probably". :) Now I gotta find a copy of that game. I found a scan of the instructions and there are photos of the game board itself out there. Thanks! Still dying to know who wrote the computer version. I can't help but wonder if it really came out of Bell Labs or maybe that's just a mistake. Cheers, -Beej -- Brian "Beej Jorgensen" Hall beej at beej.us https://beej.us/ From imp at bsdimp.com Wed Apr 30 03:00:02 2025 From: imp at bsdimp.com (Warner Losh) Date: Tue, 29 Apr 2025 11:00:02 -0600 Subject: [TUHS] Any Interdata war stories? In-Reply-To: <202504290655.53T6t5Sj1009885@freefriends.org> References: <202504290655.53T6t5Sj1009885@freefriends.org> Message-ID: On Tue, Apr 29, 2025 at 12:55 AM wrote: > > > From: Tom Lyon > > > > I was pleased to learn that the first port of S to UNIX was on the > > Interdata 8/32, which I had my part in enabling. > > I would love to hear more about the Interdata port and what > happened with it afterwards. Interdata seems to have disappeared > into the dustbin of history. And Unix on it apparently never > got out of Bell Labs; I don't think the code for it is in the > TUHS archives. > > Was the Interdata system in use at Bell Labs for actual work once > the port was complete? > > ISTR there was a meeting with Interdata about changes in the architecture > that Bell Labs wanted, that Interdata didn't want to make. What > was the full story? > > Any other info would be welcome. So on the marketing side, the Interdata port wound up being sold in the US by The Wollogong Group (TWG). They marketed it to Harris computer users more generally. Tom and Steve were frustrated that they couldn't market this in .au so effectively sold their rights to TWG who did market it. And then they branched out, using their V6 license to do a number of other things: * Eunice for VMS (4BSD environment for VMS) * TCP/IP for VMS (the TCP. from 4.2BSD (and later 4.3BSD) ported to VMS, as extracted from Eunice, not to be confused with TVG's Multinet). * TCP/IP for a bunch of other System V systems (mostly 3B2*'s) as well as HP (both HPUX and non unix systems) and a few other early odd-balls that my memory isn't responding well to. * Unix internals training with the Lions Book, including AT&T and Wollgong intellectual property markings (I wish I'd tried hard to snag a copy when I worked there: I had to settle for an Nth generation copy from a coworker). * Some other early porting work that may have just been marketing material to compete with Unisoft / raise funding. I just saw this stuff once at the TWG offices and was given some hand-wavey explanation that amounted to "don't worry about testing this"... * IP/TCP for DOS (though this was an independent thing, done at MIT, the licensing material for this product, IIRC, included some kind of unix permission that confused me at the time, but it may have just been lawyering to CYA rather than including anything). Warner From fjarlq at gmail.com Wed Apr 30 03:04:54 2025 From: fjarlq at gmail.com (Matt Day) Date: Tue, 29 Apr 2025 11:04:54 -0600 Subject: [TUHS] Searching for game history In-Reply-To: References: Message-ID: Looks like one of many games that were influenced by Empire, originally written by John Daleske in early 1973 at Iowa State for the PLATO system. https://en.wikipedia.org/wiki/Empire_(1973_video_game) On Tue, Apr 29, 2025 at 10:46 AM Brian "Beej" Hall wrote: > On Tue, Apr 29, 2025 at 04:25:52PM +1000, Jonathan Gray wrote: > > On Mon, Apr 28, 2025 at 06:12:55PM -0700, Brian "Beej" Hall wrote: > > > _Conquest_ is an old game that apparently came to life in Bell Labs, > > > but no one seems to know anything more about it, including who the > > > author is. > > > > An implementation of the Stellar Conquest board game? > > https://en.wikipedia.org/wiki/Stellar_Conquest > > Oooo, that seems like a good lead--very, very similar. The games are > contemporary, too. > > I'd classify it as "highly probably". :) > > Now I gotta find a copy of that game. I found a scan of the instructions > and there are photos of the game board itself out there. > > Thanks! > > Still dying to know who wrote the computer version. I can't help but > wonder if it really came out of Bell Labs or maybe that's just a > mistake. > > Cheers, > -Beej > > -- > Brian "Beej Jorgensen" Hall > beej at beej.us https://beej.us/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nobozo at gmail.com Wed Apr 30 03:18:07 2025 From: nobozo at gmail.com (Jon Forrest) Date: Tue, 29 Apr 2025 10:18:07 -0700 Subject: [TUHS] Any Interdata war stories? In-Reply-To: References: <202504290655.53T6t5Sj1009885@freefriends.org> Message-ID: On 4/29/25 10:00 AM, Warner Losh wrote: > And then they branched out, using their V6 license to do a number of other > things: > * Eunice for VMS (4BSD environment for VMS) Minor quible - Eunice was developed by David Kashtan at SRI, but then maintained and marketed the The Wollongong Group. (I used it on VMS at UCSB in the early 1980s). Jon P.S. A non-Unix Interdata memory. At UCSB we used 3 Interdata machines as terminal switchers. You could connect from a terminal in certain terminal rooms to any of a number of computers on campus that had support for the switching protocol. The names of the Interdata machines were "huey", "duey", and "louie". There was allegedly a fourth machine called "kablooey" that was used as a backup. From imp at bsdimp.com Wed Apr 30 03:25:48 2025 From: imp at bsdimp.com (Warner Losh) Date: Tue, 29 Apr 2025 11:25:48 -0600 Subject: [TUHS] Any Interdata war stories? In-Reply-To: References: <202504290655.53T6t5Sj1009885@freefriends.org> Message-ID: On Tue, Apr 29, 2025 at 11:18 AM Jon Forrest wrote: > > > > On 4/29/25 10:00 AM, Warner Losh wrote: > > > And then they branched out, using their V6 license to do a number of other > > things: > > * Eunice for VMS (4BSD environment for VMS) > > Minor quible - Eunice was developed by David Kashtan at SRI, but > then maintained and marketed the The Wollongong Group. > (I used it on VMS at UCSB in the early 1980s). True, I mentioned it only because they used their V6 license which had unusually favorable terms to do so... Which is an unanticipated "long hand" of the interdata port into the late 80s and early 90s. Warner > Jon > > P.S. A non-Unix Interdata memory. At UCSB we used 3 Interdata > machines as terminal switchers. You could connect from a terminal > in certain terminal rooms to any of a number of computers on campus that > had support for the switching protocol. The names of the Interdata > machines were "huey", "duey", and "louie". There was allegedly a > fourth machine called "kablooey" that was used as a backup. From aek at bitsavers.org Wed Apr 30 03:35:25 2025 From: aek at bitsavers.org (Al Kossow) Date: Tue, 29 Apr 2025 10:35:25 -0700 Subject: [TUHS] Any Interdata war stories? In-Reply-To: References: <202504290655.53T6t5Sj1009885@freefriends.org> Message-ID: <064f1f97-c3a2-f042-8554-40d2bbfb7c57@bitsavers.org> On 4/29/25 10:00 AM, Warner Losh wrote: > On Tue, Apr 29, 2025 at 12:55 AM wrote: >> >>> From: Tom Lyon >>> >>> I was pleased to learn that the first port of S to UNIX was on the >>> Interdata 8/32, which I had my part in enabling. >> >> I would love to hear more about the Interdata port and what >> happened with it afterwards. Interdata seems to have disappeared >> into the dustbin of history. And Unix on it apparently never >> got out of Bell Labs; I don't think the code for it is in the >> TUHS archives. >> Two different ports. TWG's port was written at the University of Wollongong, extensive documentation and SIMH emulation survives. No trace of the BTL port exists that I know of Interdata was bought by Perkin-Elmer, Perkin-Elmer sold it to Concurrent Computer Corp. From rich.salz at gmail.com Wed Apr 30 03:58:43 2025 From: rich.salz at gmail.com (Rich Salz) Date: Tue, 29 Apr 2025 13:58:43 -0400 Subject: [TUHS] Any Interdata war stories? In-Reply-To: References: <202504290655.53T6t5Sj1009885@freefriends.org> Message-ID: On Tue, Apr 29, 2025 at 1:00 PM Warner Losh wrote: > * IP/TCP for DOS (though this was an independent thing, done at MIT, > the licensing material for this product, IIRC, included some kind of > unix permission that confused me at the time, but it may have just > been lawyering to CYA rather than including anything). > The PC/IP software from MIT included a port of the "Portable C Compiler" to generate 8086-era code. It ran on a Unix machine and built binaries that you downloaded to the PC. So you need an ATT source license to get the full PCIP dev kit. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Apr 30 04:25:39 2025 From: clemc at ccc.com (Clem Cole) Date: Tue, 29 Apr 2025 14:25:39 -0400 Subject: [TUHS] Any Interdata war stories? In-Reply-To: References: <202504290655.53T6t5Sj1009885@freefriends.org> Message-ID: Yes, that was one of the RTS compilers for the NU machine. John Romkey may have done it, as he was the primary person behind PCIP, but I can not claim I remember who did the 8086 backend. IIRC Jack Test did the 68K backend. The RTS crew had the NU machine and NU bus that went with it. Very tean project Neat project. Similar idea, in fact to what CMU was doing with the Intel Mutlibus called the distributed front end (we had started with LSI-11 and cost reduced it to 8086 on a Intel Multibus). Andy Bechtolsheim would take with him to Stanford and rework with a 68K which became the Stanford Network Terminal - which used the RTS's C compilers. It's all very mixed up. [ Don't tell me there was not an open source culture back in the old days by the way]. Anyway the MIT RTS foilks made hardware and PCC back ends for the 68K, Z8000 and 8086. I believe that each had separate assemblers, tjt who sometimes reads this list might know more, as he wrote the 68K assembler. IIRC they had a common linker which is was rewrite/extension to the original V7 linker or maybe the 4.1 linker. Anyone with a V7 license could get it. If you had a PC license you get get the source to Romkey's PCIP. If you did not a license, you could only get a binary kit. ᐧ On Tue, Apr 29, 2025 at 1:59 PM Rich Salz wrote: > > > On Tue, Apr 29, 2025 at 1:00 PM Warner Losh wrote: > >> * IP/TCP for DOS (though this was an independent thing, done at MIT, >> the licensing material for this product, IIRC, included some kind of >> unix permission that confused me at the time, but it may have just >> been lawyering to CYA rather than including anything). >> > > The PC/IP software from MIT included a port of the "Portable C Compiler" > to generate 8086-era code. It ran on a Unix machine and built binaries that > you downloaded to the PC. So you need an ATT source license to get the full > PCIP dev kit. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Wed Apr 30 04:28:12 2025 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Tue, 29 Apr 2025 14:28:12 -0400 Subject: [TUHS] Any Interdata war stories? In-Reply-To: References: <202504290655.53T6t5Sj1009885@freefriends.org> Message-ID: <744c5a36-6aa9-44d5-8779-66cc8c5c584b@case.edu> On 4/29/25 1:00 PM, Warner Losh wrote: > And then they branched out, using their V6 license to do a number of other > things: > * Eunice for VMS (4BSD environment for VMS) "Congratulations. You aren't running Eunice." -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From imp at bsdimp.com Wed Apr 30 04:38:56 2025 From: imp at bsdimp.com (Warner Losh) Date: Tue, 29 Apr 2025 12:38:56 -0600 Subject: [TUHS] Any Interdata war stories? In-Reply-To: References: <202504290655.53T6t5Sj1009885@freefriends.org> Message-ID: On Tue, Apr 29, 2025, 12:26 PM Clem Cole wrote: > Yes, that was one of the RTS compilers for the NU machine. John Romkey > may have done it, as he was the primary person behind PCIP, but I can not > claim I remember who did the 8086 backend. IIRC Jack Test did the 68K > backend. The RTS crew had the NU machine and NU bus that went with it. > Very tean project Neat project. Similar idea, in fact to what CMU was > doing with the Intel Mutlibus called the distributed front end (we had > started with LSI-11 and cost reduced it to 8086 on a Intel Multibus). Andy > Bechtolsheim would take with him to Stanford and rework with a 68K which > became the Stanford Network Terminal - which used the RTS's C compilers. > It's all very mixed up. [ Don't tell me there was not an open source > culture back in the old days by the way]. > > Anyway the MIT RTS foilks made hardware and PCC back ends for the 68K, > Z8000 and 8086. I believe that each had separate assemblers, tjt who > sometimes reads this list might know more, as he wrote the 68K assembler. > IIRC they had a common linker which is was rewrite/extension to the > original V7 linker or maybe the 4.1 linker. > > Anyone with a V7 license could get it. If you had a PC license you get > get the source to Romkey's PCIP. If you did not a license, you could only > get a binary kit. > ᐧ > > On Tue, Apr 29, 2025 at 1:59 PM Rich Salz wrote: > >> >> >> On Tue, Apr 29, 2025 at 1:00 PM Warner Losh wrote: >> >>> * IP/TCP for DOS (though this was an independent thing, done at MIT, >>> the licensing material for this product, IIRC, included some kind of >>> unix permission that confused me at the time, but it may have just >>> been lawyering to CYA rather than including anything). >>> >> >> The PC/IP software from MIT included a port of the "Portable C Compiler" >> to generate 8086-era code. It ran on a Unix machine and built binaries that >> you downloaded to the PC. So you need an ATT source license to get the full >> PCIP dev kit. >> > Yea. The MIT compiler was also shipped with Venix/86 Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From aek at bitsavers.org Wed Apr 30 04:46:19 2025 From: aek at bitsavers.org (Al Kossow) Date: Tue, 29 Apr 2025 11:46:19 -0700 Subject: [TUHS] Any Interdata war stories? In-Reply-To: References: <202504290655.53T6t5Sj1009885@freefriends.org> Message-ID: <5a8d5bc1-35b2-7d70-7c4f-5caf5a213816@bitsavers.org> On 4/29/25 11:25 AM, Clem Cole wrote: > Yes, that was one of the RTS compilers for the NU machine.  John Romkey may have done it, as he was the primary person behind PCIP, but I > can not claim I remember who did the 8086 backend.  IIRC Jack Test did the 68K backend.  The RTS crew had the NU machine and NU bus that > went with it.   Very tean project Neat project.  Similar idea, in fact to what CMU was doing with the Intel Mutlibus called the distributed > front end (we had started with LSI-11 and cost reduced it to 8086 on a Intel Multibus).  Andy Bechtolsheim would take with him to Stanford > and rework with a 68K which became the Stanford Network Terminal - which used the RTS's C compilers.   It's all very mixed up. [ Don't tell > me there was not an open source culture back in the old days by the way]. > > Anyway the MIT RTS foilks made hardware and PCC back ends for the 68K, Z8000 and 8086.  I believe that each had separate assemblers, tjt who > sometimes reads this list might know more, as he wrote the 68K assembler.  IIRC they had a common linker which is was rewrite/extension to > the original V7 linker or maybe the 4.1 linker. > > Anyone with a V7 license could get it.   If you had a PC license you get get the source to Romkey's PCIP.   If you did not a license, you > could only get a binary kit. I have an image of the "MIT Compiler Tape" with a bunch of different PCC ports from a couple of different institutions. On the Stanford side, SUMACC was a hack of the compiler to work with the Macintosh I had the source for it at one point, but haven't been able to find it on any of my backups. From rik at rikfarrow.com Wed Apr 30 04:52:03 2025 From: rik at rikfarrow.com (Rik Farrow) Date: Tue, 29 Apr 2025 11:52:03 -0700 Subject: [TUHS] V7 ls and dot files? In-Reply-To: References: Message-ID: I thought so too, but found this reference to a Version 1 mkdir: https://man.cat-v.org/unix-1st/1/mkdir I recall reading a Version 6 or 7 man page about mkfs that included the ability to populate a file system with some directories, and I thought that implied that users couldn't create directories. The man page referenced above hints that mkdir is run as the 'system user', presumably root, and becomes the owner of new directories. Rik On Tue, Apr 29, 2025 at 4:28 AM Jaap Akkerhuis wrote: > I seem to remember that V7 was the first suystem which had a mkdir system > call. That might have changed what ls -a showed. > > jaap > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aek at bitsavers.org Wed Apr 30 05:07:12 2025 From: aek at bitsavers.org (Al Kossow) Date: Tue, 29 Apr 2025 12:07:12 -0700 Subject: [TUHS] Any Interdata war stories? In-Reply-To: <5a8d5bc1-35b2-7d70-7c4f-5caf5a213816@bitsavers.org> References: <202504290655.53T6t5Sj1009885@freefriends.org> <5a8d5bc1-35b2-7d70-7c4f-5caf5a213816@bitsavers.org> Message-ID: On 4/29/25 11:46 AM, Al Kossow wrote: > I have an image of the "MIT Compiler Tape" with a bunch of different PCC ports from a couple of different institutions. I forgot I put this up a while ago http://bitsavers.org/bits/MIT/trix/MIT_Compiler_Tape I wish I had more information about what went on wrt Steve Ward's lab From imp at bsdimp.com Wed Apr 30 05:10:51 2025 From: imp at bsdimp.com (Warner Losh) Date: Tue, 29 Apr 2025 13:10:51 -0600 Subject: [TUHS] Any Interdata war stories? In-Reply-To: References: <202504290655.53T6t5Sj1009885@freefriends.org> <5a8d5bc1-35b2-7d70-7c4f-5caf5a213816@bitsavers.org> Message-ID: On Tue, Apr 29, 2025 at 1:07 PM Al Kossow wrote: > > On 4/29/25 11:46 AM, Al Kossow wrote: > > > I have an image of the "MIT Compiler Tape" with a bunch of different PCC ports from a couple of different institutions. > > I forgot I put this up a while ago > http://bitsavers.org/bits/MIT/trix/MIT_Compiler_Tape > > I wish I had more information about what went on wrt Steve Ward's lab I've tried building that for modern systems and the code is definitely very K&R... In one spot, IIRC, there's even a vax queue instruction. Warner From tuhs at tuhs.org Wed Apr 30 05:18:25 2025 From: tuhs at tuhs.org (Jaap Akkerhuis via TUHS) Date: Tue, 29 Apr 2025 21:18:25 +0200 Subject: [TUHS] V7 ls and dot files? In-Reply-To: References: Message-ID: > On 2025 Apr 29, at 20:52, Rik Farrow wrote: > > I thought so too, but found this reference to a Version 1 mkdir: > > https://man.cat-v.org/unix-1st/1/mkdir That is the command in man(1) and always existed. System calls documentation live in man(2). jaap > > I recall reading a Version 6 or 7 man page about mkfs that included the ability to populate a file system with some directories, and I thought that implied that users couldn't create directories. The man page referenced above hints that mkdir is run as the 'system user', presumably root, and becomes the owner of new directories. > > Rik > > > On Tue, Apr 29, 2025 at 4:28 AM Jaap Akkerhuis > wrote: >> I seem to remember that V7 was the first suystem which had a mkdir system call. That might have changed what ls -a showed. >> >> jaap >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Wed Apr 30 05:27:39 2025 From: crossd at gmail.com (Dan Cross) Date: Tue, 29 Apr 2025 15:27:39 -0400 Subject: [TUHS] V7 ls and dot files? In-Reply-To: References: Message-ID: On Tue, Apr 29, 2025 at 3:01 PM Rik Farrow wrote: > I thought so too, but found this reference to a Version 1 mkdir: > > https://man.cat-v.org/unix-1st/1/mkdir > > I recall reading a Version 6 or 7 man page about mkfs that included the ability to populate a file system with some directories, and I thought that implied that users couldn't create directories. The man page referenced above hints that mkdir is run as the 'system user', presumably root, and becomes the owner of new directories. That's the man page for the `mkdir` command, but I think the distinction was for the system call. Before the introduction of `mkdir(2)`, directories were created by `mknod(2)`, and that was true through the 7th Edition and into 32/v. I would have thought that `mkdir` came with FFS and indeed, it's not in 3BSD or 4.0BSD; looks like it came with 4.1c.1, which is where UFS starts to be integrated. - Dan C. > On Tue, Apr 29, 2025 at 4:28 AM Jaap Akkerhuis wrote: >> >> I seem to remember that V7 was the first suystem which had a mkdir system call. That might have changed what ls -a showed. >> >> jaap >> From tuhs at tuhs.org Wed Apr 30 05:33:15 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 29 Apr 2025 19:33:15 +0000 Subject: [TUHS] V7 ls and dot files? In-Reply-To: References: Message-ID: On Tuesday, April 29th, 2025 at 12:19 PM, Jaap Akkerhuis via TUHS wrote: > > > > > On 2025 Apr 29, at 20:52, Rik Farrow wrote: > > > > I thought so too, but found this reference to a Version 1 mkdir: > > https://man.cat-v.org/unix-1st/1/mkdir > > > That is the command in man(1) and always existed. System calls documentation live in man(2). > > jaap > > > > > > I recall reading a Version 6 or 7 man page about mkfs that included the ability to populate a file system with some directories, and I thought that implied that users couldn't create directories. The man page referenced above hints that mkdir is run as the 'system user', presumably root, and becomes the owner of new directories. > > > > Rik > > > > > > On Tue, Apr 29, 2025 at 4:28 AM Jaap Akkerhuis wrote: > > > > > I seem to remember that V7 was the first suystem which had a mkdir system call. That might have changed what ls -a showed. > > > > > >         jaap What I see in the history is: V1 - mkdir(1) and mkdir(2) are both present, mkdir(1) indicates that: > The standard entries "." and ".." are made automatically. and this text persists through to V6 at least. Whereas mkdir(2) states: > The special entries "." and ".." are not present. With V2, mkdir(2) is renamed makdir(2) but still retains this text. In V4, this is replaced with mknod(2) which drops this text. So for the purposes of . and .. the situation should be unchanged from V1 to V3, with V4 switching to mknod(2). This is all from my mandiff project which is paused at V6 until a few more manuals from the time (namely USG PG-III and PWB/2.0) manage to crop up. Comparing between V6 and V7 should lend more clarity to the situation. - Matt G. From clemc at ccc.com Wed Apr 30 05:45:02 2025 From: clemc at ccc.com (Clem Cole) Date: Tue, 29 Apr 2025 15:45:02 -0400 Subject: [TUHS] Any Interdata war stories? In-Reply-To: References: <202504290655.53T6t5Sj1009885@freefriends.org> <5a8d5bc1-35b2-7d70-7c4f-5caf5a213816@bitsavers.org> Message-ID: Thanks for the refresh -- National chip (16032), not the Z8000 but right idea. ᐧ On Tue, Apr 29, 2025 at 3:07 PM Al Kossow wrote: > On 4/29/25 11:46 AM, Al Kossow wrote: > > > I have an image of the "MIT Compiler Tape" with a bunch of different PCC > ports from a couple of different institutions. > > I forgot I put this up a while ago > http://bitsavers.org/bits/MIT/trix/MIT_Compiler_Tape > > I wish I had more information about what went on wrt Steve Ward's lab > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Wed Apr 30 06:14:41 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 29 Apr 2025 20:14:41 +0000 Subject: [TUHS] Any Interdata war stories? In-Reply-To: References: <202504290655.53T6t5Sj1009885@freefriends.org> <5a8d5bc1-35b2-7d70-7c4f-5caf5a213816@bitsavers.org> Message-ID: <-U1zn9lLa4fm6jSFFwVyRRNlE4aUv9K1Y4dJ2dM2ujmFpIODHl8qhEuwah27Cyv7bD8HRe7PtPqNME8lzvf6s7oOS4kg0nxUiQo43sLw6l4=@protonmail.com> On Tuesday, April 29th, 2025 at 12:45 PM, Clem Cole wrote: > Thanks for the refresh -- National chip (16032), not the Z8000 but right idea. > ᐧ > > On Tue, Apr 29, 2025 at 3:07 PM Al Kossow wrote: > > > On 4/29/25 11:46 AM, Al Kossow wrote: > > > > > I have an image of the "MIT Compiler Tape" with a bunch of different PCC ports from a couple of different institutions. > > > > I forgot I put this up a while ago > > http://bitsavers.org/bits/MIT/trix/MIT_Compiler_Tape > > > > I wish I had more information about what went on wrt Steve Ward's lab Just fyi, thread from a couple years back in which Steve Johnson offered some recollections of his time involved in the Interdata 8/32 work at BTL: https://tuhs.org/mailman3/hyperkitty/list/tuhs at tuhs.org/thread/WH4IEMFZEZEDPG5VQHDWKTS6UTRMTRLL/ His recollections above touch on the microcode bug that prevented the Interdata port from being viable beyond porting exercises. - Matt G. From jnc at mercury.lcs.mit.edu Wed Apr 30 06:30:44 2025 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 29 Apr 2025 16:30:44 -0400 (EDT) Subject: [TUHS] Any Interdata war stories? Message-ID: <20250429203044.4C65318C074@mercury.lcs.mit.edu> > From: Rich Salz > The PC/IP software from MIT included a port of the "Portable C > Compiler" to generate 8086-era code. It ran on a Unix machine and built > binaries that you downloaded to the PC. ... So you need an ATT source > license to get the full PCIP dev kit. That makes sense. The 'MIT license' (about which Jerry Saltzer did a note for the October-December 2020 issue of the 'IEEE Annals of the History of Computing', available here: https://www.mit.edu/~Saltzer/publications/MITLicense.pdf and which mentions that it was initially done for the MIT PC/IP code) only applied to the MIT-written applications, not a 'derived work' (to use the intellectual property law 'term of art') based on Bell code. Noel From henry.r.bent at gmail.com Wed Apr 30 07:03:01 2025 From: henry.r.bent at gmail.com (Henry Bent) Date: Tue, 29 Apr 2025 17:03:01 -0400 Subject: [TUHS] Any Interdata war stories? In-Reply-To: <744c5a36-6aa9-44d5-8779-66cc8c5c584b@case.edu> References: <202504290655.53T6t5Sj1009885@freefriends.org> <744c5a36-6aa9-44d5-8779-66cc8c5c584b@case.edu> Message-ID: On Tue, 29 Apr 2025 at 14:36, Chet Ramey via TUHS wrote: > On 4/29/25 1:00 PM, Warner Losh wrote: > > > And then they branched out, using their V6 license to do a number of > other > > things: > > * Eunice for VMS (4BSD environment for VMS) > > "Congratulations. You aren't running Eunice." Perl has some good quips hidden in Configure but that was always one of my favorites, even well before I had any real idea what Eunice was. Personally I want a t-shirt that says "configure: error: cannot guess host type; you must specify one" which nicely sums up my experiences with both historic computing and my general life. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsg at jsg.id.au Wed Apr 30 09:27:20 2025 From: jsg at jsg.id.au (Jonathan Gray) Date: Wed, 30 Apr 2025 09:27:20 +1000 Subject: [TUHS] Any Interdata war stories? In-Reply-To: <5a8d5bc1-35b2-7d70-7c4f-5caf5a213816@bitsavers.org> References: <202504290655.53T6t5Sj1009885@freefriends.org> <5a8d5bc1-35b2-7d70-7c4f-5caf5a213816@bitsavers.org> Message-ID: On Tue, Apr 29, 2025 at 11:46:19AM -0700, Al Kossow wrote: > On 4/29/25 11:25 AM, Clem Cole wrote: > > Yes, that was one of the RTS compilers for the NU machine.  John Romkey > > may have done it, as he was the primary person behind PCIP, but I can > > not claim I remember who did the 8086 backend.  IIRC Jack Test did the > > 68K backend.  The RTS crew had the NU machine and NU bus that went with > > it.   Very tean project Neat project.  Similar idea, in fact to what CMU > > was doing with the Intel Mutlibus called the distributed front end (we > > had started with LSI-11 and cost reduced it to 8086 on a Intel > > Multibus).  Andy Bechtolsheim would take with him to Stanford and rework > > with a 68K which became the Stanford Network Terminal - which used the > > RTS's C compilers.   It's all very mixed up. [ Don't tell me there was > > not an open source culture back in the old days by the way]. > > > > Anyway the MIT RTS foilks made hardware and PCC back ends for the 68K, > > Z8000 and 8086.  I believe that each had separate assemblers, tjt who > > sometimes reads this list might know more, as he wrote the 68K > > assembler.  IIRC they had a common linker which is was rewrite/extension > > to the original V7 linker or maybe the 4.1 linker. > > > > Anyone with a V7 license could get it.   If you had a PC license you get > > get the source to Romkey's PCIP.   If you did not a license, you could > > only get a binary kit. > > I have an image of the "MIT Compiler Tape" with a bunch of different PCC ports from a couple of different institutions. > > On the Stanford side, SUMACC was a hack of the compiler to work with the Macintosh > I had the source for it at one point, but haven't been able to find it on any of my backups. in the TUHS archive Distributions/UCB/4.3BSD/new.tar.gz contains sumacc.tar.Z which has source From arnold at skeeve.com Wed Apr 30 17:08:25 2025 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 30 Apr 2025 01:08:25 -0600 Subject: [TUHS] Any Interdata war stories? In-Reply-To: References: <202504290655.53T6t5Sj1009885@freefriends.org> Message-ID: <202504300708.53U78PeQ1115830@freefriends.org> Thanks for this, and to everyone else who replied. I'm guessing the hardware problems prevented the system from being used further. Thanks, Arnold Jonathan Gray wrote: > On Tue, Apr 29, 2025 at 12:55:05AM -0600, arnold at skeeve.com wrote: > > > From: Tom Lyon > > > > > > I was pleased to learn that the first port of S to UNIX was on the > > > Interdata 8/32, which I had my part in enabling. > > > > I would love to hear more about the Interdata port and what > > happened with it afterwards. Interdata seems to have disappeared > > into the dustbin of history. And Unix on it apparently never > > got out of Bell Labs; I don't think the code for it is in the > > TUHS archives. > > Tom described some of the C portability problems in > Inter-UNIX Portability > > https://archive.org/details/CLanguagePortability_Sept77/page/n15/mode/2up > https://akapugsblog.wordpress.com/wp-content/uploads/2018/05/inter-unix_portability.pdf > > > > > Was the Interdata system in use at Bell Labs for actual work once > > the port was complete? > > > > ISTR there was a meeting with Interdata about changes in the architecture > > that Bell Labs wanted, that Interdata didn't want to make. What > > was the full story? > > Steve Johnson on the hardware problems > https://www.tuhs.org/pipermail/coff/2023-August/001672.html > > > > > Any other info would be welcome. > > > > Thanks, > > > > Arnold > > From arnold at skeeve.com Wed Apr 30 17:09:34 2025 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 30 Apr 2025 01:09:34 -0600 Subject: [TUHS] V7 ls and dot files? In-Reply-To: References: Message-ID: <202504300709.53U79Yx11115926@freefriends.org> Jaap Akkerhuis wrote: > I seem to remember that V7 was the first suystem which had a mkdir system call. That might have changed what ls -a showed. > > jaap > Thanks. IIRC it was 4.2 BSD. V8 may have picked it up. Arnold From arnold at skeeve.com Wed Apr 30 17:21:35 2025 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 30 Apr 2025 01:21:35 -0600 Subject: [TUHS] Any Interdata war stories? In-Reply-To: <064f1f97-c3a2-f042-8554-40d2bbfb7c57@bitsavers.org> References: <202504290655.53T6t5Sj1009885@freefriends.org> <064f1f97-c3a2-f042-8554-40d2bbfb7c57@bitsavers.org> Message-ID: <202504300721.53U7LZUg1116830@freefriends.org> Al Kossow wrote: > Two different ports. > TWG's port was written at the University of Wollongong, extensive > documentation and SIMH emulation survives. Ah! I was shown a V6 port on SIMH, but Bell Labs didn't do a port of V6. This explains it. > No trace of the BTL port exists that I know of > > Interdata was bought by Perkin-Elmer, Perkin-Elmer sold it to > Concurrent Computer Corp. CCI made the Tahoe that 4.4 ran on, but I'm guessing it's a different architecture than the Interdata? Thanks, Arnold From tuhs at tuhs.org Wed Apr 30 17:35:25 2025 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Wed, 30 Apr 2025 00:35:25 -0700 Subject: [TUHS] Any Interdata war stories? In-Reply-To: <202504300721.53U7LZUg1116830@freefriends.org> References: <202504290655.53T6t5Sj1009885@freefriends.org> <064f1f97-c3a2-f042-8554-40d2bbfb7c57@bitsavers.org> <202504300721.53U7LZUg1116830@freefriends.org> Message-ID: <7FB4CEA6-6745-4DEB-8DF2-B92A5EA2D45F@iitbombay.org> On Apr 30, 2025, at 12:21 AM, arnold at skeeve.com wrote: > > Al Kossow wrote: > >> Two different ports. >> TWG's port was written at the University of Wollongong, extensive >> documentation and SIMH emulation survives. > > Ah! I was shown a V6 port on SIMH, but Bell Labs didn't do > a port of V6. This explains it. The story of this first port (by Richard Miller) here: https://www.tuhs.org/Archive/Distributions/Other/Interdata/uow103747.pdf From tuhs at tuhs.org Wed Apr 30 17:39:30 2025 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Wed, 30 Apr 2025 00:39:30 -0700 Subject: [TUHS] Any Interdata war stories? In-Reply-To: <7FB4CEA6-6745-4DEB-8DF2-B92A5EA2D45F@iitbombay.org> References: <202504290655.53T6t5Sj1009885@freefriends.org> <064f1f97-c3a2-f042-8554-40d2bbfb7c57@bitsavers.org> <202504300721.53U7LZUg1116830@freefriends.org> <7FB4CEA6-6745-4DEB-8DF2-B92A5EA2D45F@iitbombay.org> Message-ID: <07D3ED48-22A8-4C20-929A-311E15DEEA00@iitbombay.org> On Apr 30, 2025, at 12:35 AM, Bakul Shah wrote: > > On Apr 30, 2025, at 12:21 AM, arnold at skeeve.com wrote: >> >> Al Kossow wrote: >> >>> Two different ports. >>> TWG's port was written at the University of Wollongong, extensive >>> documentation and SIMH emulation survives. >> >> Ah! I was shown a V6 port on SIMH, but Bell Labs didn't do >> a port of V6. This explains it. > > The story of this first port (by Richard Miller) here: > > https://www.tuhs.org/Archive/Distributions/Other/Interdata/uow103747.pdf More details in Richard's invited talk @ Usenix: https://www.usenix.org/legacy/publications/library/proceedings/usenix98/invited_talks/miller.ps From jnc at mercury.lcs.mit.edu Wed Apr 30 23:11:35 2025 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 30 Apr 2025 09:11:35 -0400 (EDT) Subject: [TUHS] Any Interdata war stories? Message-ID: <20250430131135.B8A3E18C074@mercury.lcs.mit.edu> > From: Clem Cole > Yes, that was one of the RTS compilers for the NU machine. John Romkey > may have done it, as he was the primary person behind PCIP I decided to poke around in the 'MIT-CSR' dump, since that was the machine the PC/IP project started on, to see what I could find. Hoo boy! What an adventure! In the PC/IP area, I found a 'c86' directory - but it was almost empty. It did have a shell file, 'grab', which contained: tftp -g $1 xx "PS:$1" and a 'graball' file which called 'grab' for the list of compiler source files. ('xx' was MIT-XX, the TOPS-20 main time-sharing machint of LCS.) So I did a Web search for Wayne Gramlich (with whom I hadn't communicated in many decades), and he popped right up. (Amazing thing, this Internet thingy. Who'd have ever thought, back in the day, that it would turn into what it did? Well, probably John Brunner, whom I (sadly) never met, who was there before any of us.) I took a chance, and called his number, and he was there, and we had a long chat. He absolutely didn't do it, although he wrote the loader the project used ('l68', the source for which I did find.) He's virtually certain Romkey didn't (which would have been my guess too; Romkey was like a sophmore when the project started). His best (_very_ faded) memory was that they started off with a commercial compiler. (But see below.) That leaves several mysteries. 1) Why would a commercial compiler not come with a linker? 2) Why did people who wanted to work with the PC/IP source need a Bell license? I did some more poking, and the list of files for the 86 compiler, from 'graball': trees.c optim.c pftn.c code.c local.c scan.c xdefs.c table.c reader.c local2.c order.c match.c allo.c comm1.c manifest mfile1 common macdefs mfile2 mac2defs matched the file names from 'pcc', as given in "A Tour Through the Portable C Compiler": https://maibriz.de/unix/ultrix/_root/porttour.pdf (in section "The Source Files"). So whether the 86 compiler was done at MIT (by someone in RTS), or at a company, it was definitely a 'pcc' descendant. (Possibly adding to the confusion, we had some other C compilers for various ISA's in that project [building networking software for various micro-computers], including an 8080 C compiler from Whitesmiths, Ltd, which I have also found. It's possible that Wayne's vague memory of a commercial compiler is of that one?) I really should reach out to Romkey and Bridgham, to see what they remember. Later today. Whether the main motivation for keeping the compiler source on XX was i) because disk space was short on CSR (we had only a hand-me-down pair of CalComp Model 215 drives - capacity 58 Mbytes per drive!); ii) to prevent version skew; or iii) because it was a commercial compiler, and we had to protect the source (e.g. we didn't have the source to the 8080 compiler, only the object modules), I have no idea. > Anyway the MIT RTS folks made hardware and PCC back ends for the 68K, > Z8000 and 8086. I believe that each had separate assemblers, tjt who > sometimes reads this list might know more, as he wrote the 68K assembler. There is an 'a86' directory on CSR, but it too is empty, except for a 'grab' command file. That contains only: tftp -g $1 xx "PS:$1" I have no memory of who 'novick' might have been. A Web search for 'novick mit lcs' didn' turn anything up. (I wonder if it might have been Carol Novitsky; she was in our group at LCS, and I have a vague memory of her being associated with the networking software for micro-computers project.) Anyway, it probably doesn't matter; the c86 'grab' referred to Wayne, but he didn't write c86; 'novick' might not have written a86. Something else to ask Romkey and Bridgham about. Noel From stewart at serissa.com Wed Apr 30 23:19:45 2025 From: stewart at serissa.com (Lawrence Stewart) Date: Wed, 30 Apr 2025 09:19:45 -0400 Subject: [TUHS] Any Interdata war stories? In-Reply-To: <20250430131135.B8A3E18C074@mercury.lcs.mit.edu> References: <20250430131135.B8A3E18C074@mercury.lcs.mit.edu> Message-ID: <5CAE2DC1-30CF-4E2B-8E02-6B1FF1B99A58@serissa.com> > On Apr 30, 2025, at 9:11 AM, Noel Chiappa wrote: > >> > Who'd have ever thought, back in the day, that it would turn into what it > did? Well, probably John Brunner, whom I (sadly) never met, who was there > before any of us.) > The reference here is to Shockwave Rider, by John Brunner in 1975. I did meet him once. He came by PARC to talk to John Shoch and John Hupp, who had written a network “worm” after Brunner’s naming. A very prescient author! “The “worm” programs — early experience with a distributed computation”. Shoch and Hupp https://dl.acm.org/doi/10.1145/102616.102636 -Larry -------------- next part -------------- An HTML attachment was scrubbed... URL: From stewart at serissa.com Wed Apr 30 23:34:05 2025 From: stewart at serissa.com (Lawrence Stewart) Date: Wed, 30 Apr 2025 09:34:05 -0400 Subject: [TUHS] Any Interdata war stories? In-Reply-To: <5CAE2DC1-30CF-4E2B-8E02-6B1FF1B99A58@serissa.com> References: <20250430131135.B8A3E18C074@mercury.lcs.mit.edu> <5CAE2DC1-30CF-4E2B-8E02-6B1FF1B99A58@serissa.com> Message-ID: <6416B3C8-71B5-4465-90F0-238BAD6FC9C2@serissa.com> It isn’t Unix related, but it is a fun Interdata war story. I hung out at the MIT Architecture Machine in the early 70’s (the Media Lab before it was the Media Lab.) The lab used Interdata minis, with homegrown software. My part was designing and building various I/O devices, including parts of a network interconnecting the various minis. There were Interdata model 3, model 5, model 75, and one blazing fast model 85 with semiconductor memory. The rest were core. I think the first 7/32 we got had two 32K core modules. There was a microcode bug, such that in some case the microcode did not disable a non-maskable interrupt, so if the ISR was so foolish as to cause one, the machine got stuck in an interrupt loop. You couldn’t clear it by reset or by power cycling the machine, because core! The bad state was in the memory and was non-volatile. It was possible to clear (sometimes) by swapping the two core modules with the power off, if the other one didn’t have the poison bits, but if they did, the only thing that worked was to unplug the memory module with the power on. Luckily the OS guys figured out how to fix the ISR before we trashed anything permanently. -L From usotsuki at buric.co Wed Apr 30 23:53:43 2025 From: usotsuki at buric.co (Steve Nickolas) Date: Wed, 30 Apr 2025 09:53:43 -0400 (EDT) Subject: [TUHS] Any Interdata war stories? In-Reply-To: <20250430131135.B8A3E18C074@mercury.lcs.mit.edu> References: <20250430131135.B8A3E18C074@mercury.lcs.mit.edu> Message-ID: On Wed, 30 Apr 2025, Noel Chiappa wrote: > That leaves several mysteries. 1) Why would a commercial compiler not come > with a linker? 2) Why did people who wanted to work with the PC/IP source > need a Bell license? A possible answer for 1, since we're probably talking about a compiler for MS-DOS: most releases of MS-DOS and PC DOS, at least through version 3.3, came with a linker, so maybe they didn't deem it necessary. -uso.