From Fred.van.Kempen at microwalt.nl Tue Feb 5 03:36:47 2002 From: Fred.van.Kempen at microwalt.nl (Fred N. van Kempen) Date: Mon, 4 Feb 2002 18:36:47 +0100 Subject: [pups] Problems booting PDP11/40 using vtserver Message-ID: <6F63E31101C6D41196490008C7B2BFC304B403@mwnt4.microwalt.nl> .. and I'm actually still alive, although only barely... :) I'll respond to Michael in email, and summarize here.. --f > -----Original Message----- > From: Warren Toomey [mailto:wkt at minnie.tuhs.org] > Sent: maandag 28 januari 2002 23:09 > To: Michael Werner > Cc: PUPS mailing list > Subject: Re: [pups] Problems booting PDP11/40 using vtserver > > > In article by Michael Werner: > > I have my PDP11/40 connected to a MicroVAX 2 (running NetBSD/vax > > 1.5.2) via serial line and want to boot a 2.9BSD or 2.11BSD > using the > > vtserver software. > > When I toggle in vtserver's boot code, the first file is > being loaded > > correctly by the PDP. Then, following the instructions in vtserver > > documentation, the serial line should be used as a serial > console - and > > some text should appear! And this is the problem: I don't > get any output. > > So, my question: Does anybody know what's going wrong here? > > Thanks in advance - Michi > > I've passed the baton of Vtserver development over to Fred van Kempen. > However, which version of Vtserver are you using? > > Cheers, > Warren > _______________________________________________ > PUPS mailing list > PUPS at minnie.tuhs.org > http://minnie.tuhs.org/mailman/listinfo/pups > InterNetworking en Network Security Consultant MicroWalt Corporation (Netherlands), Korte Heul 95, 1403 ND BUSSUM Phone +31 (35) 6980059 FAX +31 (35) 6980215 http://WWW.MicroWalt.NL/ Dit bericht en eventuele bijlagen is uitsluitend bestemd voor de geadresseerde. Openbaarmaking, vermenigvuldiging, verspreiding aan derden is niet toegestaan. Er wordt geen verantwoordelijkheid genomen voor de juiste en volledige overbrenging van de inhoud van dit bericht, noch voor de tijdige ontvangst ervan. From lothar.felten at gmx.net Tue Feb 5 05:27:35 2002 From: lothar.felten at gmx.net (lothar felten) Date: Mon, 4 Feb 2002 20:27:35 +0100 Subject: [pups] VT102 and other hardware.... was: solution for the disklabel In-Reply-To: Message-ID: > > > > Maybe it wants a DEL > character instead of > backspace (backspace *is* ctrl-H, > > shown as ^H or ^h). Change > it on the terminal by going > into setup, or use > > stty on the BSD system to > change the delete character > (stty del '^h'). > > On a real VT100 you cannot > get the delete key to > generate a backspace. He > must be pressing the > backspace key, or he's not > using a VT100 at all, but > instead some emulator, which > isn't doing things the VT100 way... thanks for helping me! i'm using a "real" vt102 box. now it works, problem was just i thought "backspace" should behave pc-like. the del-key does erase my letters and the backspace displays ^H. sorry but i'm just no used to this "behaviour" of the keys. this weekend i put a qbus serial card into the pdp, but i dont get a login prompt on this ports: i edited /etc/ttys, the special files in /dev are present. i'm still using the generic kernel (still not brave enough to start configuring & compiling a new one, how long would this approx. take on a 11/83 with 4mb? is it worth it?). on the console connected to the cpu-board i always get a #prompt without login, is this normal? i have a DEQNA-nic, but with the MAKEDEV script i can't make the qe0 device. i would make it myself with mknod, but wich major/minor number do i need? there are devices for my RL02 disks, but everytime i try to access them by disklabel the system stops (the run light goes off). is there a way to check if the controller is working ? on my RQDX3-distribution panel i found a 34 pin floppy connector. i connected two 5,25" diskdrives (pc drives, TEAC, jumpered different) they work fine. -- lothar From engdahl at safeaccess.com Thu Feb 7 01:09:35 2002 From: engdahl at safeaccess.com (Jonathan Engdahl) Date: Wed, 6 Feb 2002 10:09:35 -0500 Subject: [pups] bootstrapping an RT-11 image via VTserver Message-ID: I built an 11/23 with 256K RAM, a UDC11 disk controller, one 80 meg MFM hard drive. The hard drive formatter runs under RT-11. The assumption is that you have a working floppy from which you can boot RT-11. I want to devise a method to run the formatter via VTserver. I figured out how to do this for the RQDX3 and XXDP. You can run XXDP under E11, load the utility you want to run, then stop E11 and dump the entire 28K word memory image to a disk file. By hacking a header onto this memory image, you can turn it into a standalone that can be bootstrapped via VTserver, just like the disklabel, mkfs, and restor standlones. This is easy, because XXDP tells you what the restart address is when you load a program. The question: is is possible to restart RT11SJ in the same manner as XXDP? I read some of the manuals, and tried using ODT to restart RT-11 at various points pointed to by the vector table and fixed area. By starting at the trap 4 address I can get it to restart and live. However, this seems to make RT-11 forget that I had done a "GET" of the utility that I wanted to run. I tried restarting at the RMON address, but that crashes. One other experiment I've tried is to GET the utility then "START 1000", but that crashes too. If I GET then just type "START" it lives. What am I doing wrong? One assumption is that the utility only uses memory and TT: system calls -- no disk accesses or swapping. Is it possible to abuse RT-11 in this manner? The utilities I'm trying to run are the UDC11 OCT and UDCT utilities. I want to make it possible to reformat the hard drive on this single drive system without tearing it apart and moving pieces to another system. It is also possible to mess up the NVRAM on the UDC11 so that you cannot boot. If this happens, and you are lucky enough to have another running system (and I am), you can rejumper the CSR of the stuck board and fix it on the other system. Otherwise, you are in big trouble. I wonder if it would be possible to bootstrap a VM0: image into high RAM and boot from it? I realize there are other solutions. The standard answer to questions like this is "get more hardware". The reason for doing this is I want to invent a method that will work for a very minimal pile of hardware. And the whole point of that is to make it possible for people to get a PDP-11 running with minimal investment. -- Jonathan Engdahl                 Rockwell Automation Principal Research Engineer      1 Allen-Bradley Drive Advanced Technology              Mayfield Heights, OH 44124, USA Mayfield Heights Labs            engdahl at safeaccess.com 440-646-7326 http://users.safeaccess.com/engdahl/PDP-11.htm From shoppa at trailing-edge.com Thu Feb 7 21:23:46 2002 From: shoppa at trailing-edge.com (Tim Shoppa) Date: Thu, 7 Feb 2002 06:23:46 -0500 (EST) Subject: [pups] bootstrapping an RT-11 image via VTserver In-Reply-To: from "Jonathan Engdahl" at Feb 06, 2002 10:09:35 AM Message-ID: <20020207112346.A6A2218336@mudd.trailing-edge.com> > One assumption is that the utility only uses memory and TT: system calls -- > no disk accesses or swapping. Is it possible to abuse RT-11 in this manner? RT-11 does support magtape installation via a special version of DUP called MDUP. If you look on a full RT-11 V5.x distribution, you will find "MDUP.MT", "MDUP.MS", and (depending on version number) "MDUP.AI" and "MDUP.MU". These are "snapshots" of RT-11 systems with a single tape driver (MT, MS, or MU) and a number of different disk drivers installed (so they don't have to be FETCHed) and running the special install-only build of DUP. I think there is some MDUP info in the doc set, though it is heavily oriented (of course) towards magtape installtion, not serial port installation. But the idea is sound. > I wonder if it would be possible to bootstrap a VM0: image into high RAM and > boot from it? Yes, this works, and is even officially supported in the later 5.x releases (where it is used as part of the AI installation procedure.) Tim. From engdahl at safeaccess.com Fri Feb 8 15:13:04 2002 From: engdahl at safeaccess.com (Jonathan Engdahl) Date: Fri, 8 Feb 2002 00:13:04 -0500 Subject: [pups] Duh - how do you format an RX50? Message-ID: <002301c1b05f$4b317a40$c3e01840@rcs.ra.rockwell.com> I can't believe I haven't figured this out yet. I bought an RX50, and installed it in my PDP-11/53 running 2.11BSD. It's nice having that empty hole in the front of the BA23 plugged, but I hope for even more. The drive seems alive: if I say "cp /dev/ra1a /dev/null", it starts groaning and ticking as if it were reading the floppy. But how do you format the floppies? I tried XXDP/ZRQCH0 (downloaded via VTserver), but it says the floppies are UNFORMATTABLE. That does that mean? -- Jonathan Engdahl Rockwell Automation Principal Research Engineer 1 Allen-Bradley Drive Advanced Technology Mayfield Heights, OH 44124 http://users.safeaccess.com/engdahl engdahl at safeaccess.com "The things which are seen are temporary, but the things which are not seen are eternal." II Cor. 4:18 From bill at cs.scranton.edu Fri Feb 8 23:31:56 2002 From: bill at cs.scranton.edu (Bill Gunshannon) Date: Fri, 8 Feb 2002 08:31:56 -0500 (EST) Subject: [pups] Duh - how do you format an RX50? In-Reply-To: <002301c1b05f$4b317a40$c3e01840@rcs.ra.rockwell.com> Message-ID: <20020208082605.E6001-100000@server2.cs.scranton.edu> On Fri, 8 Feb 2002, Jonathan Engdahl wrote: > I can't believe I haven't figured this out yet. I bought an > RX50, and installed it in my PDP-11/53 running 2.11BSD. It's > nice having that empty hole in the front of the BA23 plugged, > but I hope for even more. The drive seems alive: if I say "cp > /dev/ra1a /dev/null", it starts groaning and ticking as if it > were reading the floppy. > > But how do you format the floppies? > > I tried XXDP/ZRQCH0 (downloaded via VTserver), but it says the > floppies are UNFORMATTABLE. That does that mean? RX50's came pre-formatted from DEC. There was never a way to format them on PDP's or VAX as far as I knew. I do think it is possible to create them using PUTR and an old PC with a proper floppy controller and a 1.2M floppy drive configured the right way. My understanding is they are 80 track, 96 tpi format but spin at the slow spead of normal 5.25 disks and not the higher speed used by IBM HD disks. As a curious note, I actually had (and may still have in the attic somewhere) a real shugart 80 track 5.25 drive that would have been the equivalent of an RX50, so it was not only DEC who used that format. I had them on a TRS-80 and NewDOS-80 and DOSPlus had no problems formatting and using the drive. This was long before my first PDP, but I now wonder if they would have been able to read and write (and maybe even format!) RX50's. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill at cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include From pete at dunnington.u-net.com Sat Feb 9 09:42:20 2002 From: pete at dunnington.u-net.com (Pete Turnbull) Date: Fri, 8 Feb 2002 23:42:20 GMT Subject: [pups] Duh - how do you format an RX50? In-Reply-To: Bill Gunshannon "Re: [pups] Duh - how do you format an RX50?" (Feb 8, 8:31) References: <20020208082605.E6001-100000@server2.cs.scranton.edu> Message-ID: <10202082342.ZM4837@mindy.dunnington.u-net.com> On Feb 8, 8:31, Bill Gunshannon wrote: > RX50's came pre-formatted from DEC. There was never a way to > format them on PDP's or VAX as far as I knew. I do think it is > possible to create them using PUTR and an old PC with a proper > floppy controller and a 1.2M floppy drive configured the right > way. You can format them on a Rainbow, but not an -11 or VAX. > My understanding is they are 80 track, 96 tpi format but spin > at the slow spead of normal 5.25 disks and not the higher speed > used by IBM HD disks. Very similar low-level format to IBM floppies, except that, as Bill says, they're 80-track. The spec is 80-track, 96 tpi, single-side, double density (not HD), 10 sectors per track, 512 bytes/sector. DEC squeeze the extra sector in by shortening some of the gaps; even so the timing is a little tight and the drive speed has to be better-than-averagely accurate. It doesn't matter whether you write them at 300 rpm or 360, so long as the controller adjusts its data rate accordingly (250kbps or 300kbps). Which is what a PC does (uses 250kbps for 300rpm and 300kbps for 360 rpm). However, many HD-capable drives use pin 2 on the interface not only to change the speed but change the write current. Some such drives have jumpers to set the correct values. > As a curious note, I actually had (and may still have in the > attic somewhere) a real shugart 80 track 5.25 drive that would > have been the equivalent of an RX50, so it was not only DEC who > used that format. I had them on a TRS-80 and NewDOS-80 and > DOSPlus had no problems formatting and using the drive. This > was long before my first PDP, but I now wonder if they would > have been able to read and write (and maybe even format!) RX50's. If the controller it was attached to can write MFM (double-density), then it would work. Drives of that type were very common before PCs took over. In fact you can fudge one to look like half of an RX50 (a real RX50 plays funny tricks with the SideSelect and Track00 signals, and some DEC controllers use that to recognise an RX50). -- Pete Peter Turnbull Network Manager University of York From cube1 at charter.net Sun Feb 10 00:37:50 2002 From: cube1 at charter.net (Jay Jaeger) Date: Sat, 09 Feb 2002 08:37:50 -0600 Subject: [pups] Duh - how do you format an RX50? In-Reply-To: <10202082342.ZM4837@mindy.dunnington.u-net.com> References: <20020208082605.E6001-100000@server2.cs.scranton.edu> Message-ID: <4.3.2.7.2.20020209083535.02048700@cirithi> Um, bzzzzt. Wrong. I have a floppy labeled: BL-FN7AP-MC CZFNAP0 M-11 FORMTR RX50 . This is a formatter program for a Micro PDP-11. It is a *diagnostic* program (not a user program) for formatting these beasties. Mine is for the -11, I would imagine that there is one for the MicroVAX as well. Of course, it is copyrighted. Jay At 11:42 PM 2/8/2002 +0000, Pete Turnbull wrote: >On Feb 8, 8:31, Bill Gunshannon wrote: > > > RX50's came pre-formatted from DEC. There was never a way to > > format them on PDP's or VAX as far as I knew. I do think it is > > possible to create them using PUTR and an old PC with a proper > > floppy controller and a 1.2M floppy drive configured the right > > way. > >You can format them on a Rainbow, but not an -11 or VAX. --- Jay R. Jaeger The Computer Collection cube1 at charter.net From bill at cs.scranton.edu Sun Feb 10 03:14:36 2002 From: bill at cs.scranton.edu (Bill Gunshannon) Date: Sat, 9 Feb 2002 12:14:36 -0500 (EST) Subject: [pups] Duh - how do you format an RX50? In-Reply-To: <4.3.2.7.2.20020209083535.02048700@cirithi> Message-ID: <20020209120052.L7548-100000@server2.cs.scranton.edu> On Sat, 9 Feb 2002, Jay Jaeger wrote: > Um, bzzzzt. Wrong. I have a floppy labeled: BL-FN7AP-MC CZFNAP0 M-11 > FORMTR RX50 . This is a formatter program for a Micro PDP-11. > > It is a *diagnostic* program (not a user program) for formatting these > beasties. Mine is for the -11, I would imagine that there is one for the > MicroVAX as well. I guess this constitutes the last straw for this myth. Or was it merely a business decision intended to promote the sale of pre-formatted RX-50 diskettes. (A practice not uncommon in those days. For example, at one place where I worked we were responsible for maintaining Terak Micros, a LSI-11 based system. Any time we reported a floppy problem the first question was, "Are you using Terak brand diskettes??" Of course, everyone at that time knew there were only 3 manufacturers of platens and everybody else just supplied labels!!) Other arguments: I have an Andromeda Disk Controller. I know one of the supported floppy formats is RX50. I'll bet the their formatting program won't care what drive is there and will happily format diskettes for use in this and other RX-50's. By the way, I mnentioned having a n on-DEC 80 track 5.25 drive. I was wrong about one thing, though. It was not a Shugart, it was a Tandon. Sadly, I don't think I still have it. But I think it is time to dig up some drives and controllers and see just what can be done to create RX50 diskettes. Who know, maybe I can take over the business that DEC had. Hmmm. I think they used to get $10.00 a diskette. They're rarer now. Maybe $25.00 each?? Yeah, that's the trick. I'll tell my daughter she can register for the next semester now.... :-) > > Of course, it is copyrighted. I wonder if there is anyone who could be contacted about releasing it?? Maybe even the VMS version, too. Or even, the source?? Somehow, I doubt that Compaq still sells many pre-formatted RX50's. And while we're on the subject, what about this supposed problem using anything put certain kinds of diskettes?? I used my 80 track 96tpi drive all the time with the same diskettes I used in my other SS/SD, DS/SD drives all the time and never had a problem. Is this perhaps another myth intended to foster the sale of pre-formatted diskettes?? bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill at cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include From pete at dunnington.u-net.com Sun Feb 10 04:18:48 2002 From: pete at dunnington.u-net.com (Pete Turnbull) Date: Sat, 9 Feb 2002 18:18:48 GMT Subject: [pups] Duh - how do you format an RX50? In-Reply-To: Jay Jaeger "Re: [pups] Duh - how do you format an RX50?" (Feb 9, 8:37) References: <20020208082605.E6001-100000@server2.cs.scranton.edu> <4.3.2.7.2.20020209083535.02048700@cirithi> Message-ID: <10202091818.ZM6506@mindy.dunnington.u-net.com> On Feb 9, 8:37, Jay Jaeger wrote: > Um, bzzzzt. Wrong. I have a floppy labeled: BL-FN7AP-MC CZFNAP0 M-11 > FORMTR RX50 . This is a formatter program for a Micro PDP-11. > > It is a *diagnostic* program (not a user program) for formatting these > beasties. Mine is for the -11, I would imagine that there is one for the > MicroVAX as well. > At 11:42 PM 2/8/2002 +0000, Pete Turnbull wrote: > >You can format them on a Rainbow, but not an -11 or VAX. Jay, I'd be very interested to know more about that. I never heard of it before, and I thought I had a pretty comprehensive collection of the PDP-11 (including microPDP-11) diagnostics. Was it standard issue with a particular model? Is there a date on it? -- Pete Peter Turnbull Network Manager University of York From pete at dunnington.u-net.com Sun Feb 10 04:40:21 2002 From: pete at dunnington.u-net.com (Pete Turnbull) Date: Sat, 9 Feb 2002 18:40:21 GMT Subject: [pups] Duh - how do you format an RX50? In-Reply-To: Bill Gunshannon "Re: [pups] Duh - how do you format an RX50?" (Feb 9, 12:14) References: <20020209120052.L7548-100000@server2.cs.scranton.edu> Message-ID: <10202091840.ZM7032@mindy.dunnington.u-net.com> On Feb 9, 12:14, Bill Gunshannon wrote: > On Sat, 9 Feb 2002, Jay Jaeger wrote: > > > Um, bzzzzt. Wrong. I have a floppy labeled: BL-FN7AP-MC CZFNAP0 M-11 > > FORMTR RX50 . This is a formatter program for a Micro PDP-11. > I guess this constitutes the last straw for this myth. Or was it merely > a business decision intended to promote the sale of pre-formatted RX-50 > diskettes. (A practice not uncommon in those days. For example, at one > place where I worked we were responsible for maintaining Terak Micros, a > LSI-11 based system. Any time we reported a floppy problem the first > question was, "Are you using Terak brand diskettes??" Of course, everyone > at that time knew there were only 3 manufacturers of platens and everybody > else just supplied labels!!) > > Other arguments: I have an Andromeda Disk Controller. I know one of the > supported floppy formats is RX50. I'll bet the their formatting program > won't care what drive is there and will happily format diskettes for use > in this and other RX-50's. I expect it would. It's not hard to write a formatter program. I wrote one for my Acorn Archimedes, and an RX50 copier program as well. > I wonder if there is anyone who could be contacted about releasing it?? > Maybe even the VMS version, too. Or even, the source?? Somehow, I doubt > that Compaq still sells many pre-formatted RX50's. I seem to recall that DEC let people copy XXDP between machines without too much excitement. > And while we're on the subject, what about this supposed problem using > anything put certain kinds of diskettes?? I used my 80 track 96tpi drive > all the time with the same diskettes I used in my other SS/SD, DS/SD drives > all the time and never had a problem. Is this perhaps another myth intended > to foster the sale of pre-formatted diskettes?? So long as they're labelled SD or DD and not HD, they have the right coercivity. Some people argue that the fineness of the emulsion may be a factor, but actually you'd have to be incredibly unlucky to have a flaw on a disk that would allow it to be perfect for SD but not DD. Some people have likewise argued that the disk head gap is only about half as wide for 80-track as it is for 40-track, but that's irrelevant: even if the gap is a third of the track pitch, thats around 1/300", the resulting bit density (300 bpi) on the radius of the disk is still much coarser than the bit density around the circumference (about 3300 bpi for single density). I do have a few very old S/S floppies with flaws on the second side, and which therefore aren't good to use as D/S (I value my data!) but I have hundreds more sold as S/S that are work fine as D/S. They just weren't certified that way; they probably just weren't tested, in the days when lots of disks didn't need to be. -- Pete Peter Turnbull Network Manager University of York From pete at dunnington.u-net.com Sun Feb 10 04:46:36 2002 From: pete at dunnington.u-net.com (Pete Turnbull) Date: Sat, 9 Feb 2002 18:46:36 GMT Subject: [pups] Duh - how do you format an RX50? In-Reply-To: Jay Jaeger "Re: [pups] Duh - how do you format an RX50?" (Feb 9, 8:37) References: <20020208082605.E6001-100000@server2.cs.scranton.edu> <4.3.2.7.2.20020209083535.02048700@cirithi> Message-ID: <10202091846.ZM7193@mindy.dunnington.u-net.com> On Feb 9, 8:37, Jay Jaeger wrote: > Um, bzzzzt. Wrong. I have a floppy labeled: BL-FN7AP-MC CZFNAP0 M-11 > FORMTR RX50 . This is a formatter program for a Micro PDP-11. > > It is a *diagnostic* program (not a user program) for formatting these > beasties. Mine is for the -11, I would imagine that there is one for the > MicroVAX as well. Jay, I just checked on that. It's not an RX50 formatter, it's the XXDP V2 formatting and diagnostics routines for an RXDX3. IIRC it will format RD5x hard drives, and RX33, but not an RX50. Can you get a directory listing of the disk? -- Pete Peter Turnbull Network Manager University of York From eric at brouhaha.com Sun Feb 10 09:27:35 2002 From: eric at brouhaha.com (Eric Smith) Date: Sat, 9 Feb 2002 15:27:35 -0800 (PST) Subject: [pups] Duh - how do you format an RX50? In-Reply-To: <4.3.2.7.2.20020209083535.02048700@cirithi> References: <4.3.2.7.2.20020209083535.02048700@cirithi> Message-ID: <2320.64.169.63.74.1013297255.squirrel@ruckus.brouhaha.com> > Um, bzzzzt. Wrong. I have a floppy labeled: BL-FN7AP-MC CZFNAP0 M-11 > FORMTR RX50 . This is a formatter program for a Micro PDP-11. > > It is a *diagnostic* program (not a user program) for formatting these > beasties. Mine is for the -11, I would imagine that there is one for > the MicroVAX as well. The "RX50" at the end of the title may just mean that the floppy is in RX50 format, not that the diagnostics contained therein can format RX50s. I'd almost be willing to bet money on that, since the Micro PDP-11 originally used the RQDX1 to control the RX50, and a disassembly of the RQDX1 firmware shows no evidence of floppy formatting code. From cube1 at charter.net Mon Feb 11 09:23:59 2002 From: cube1 at charter.net (Jay Jaeger) Date: Sun, 10 Feb 2002 17:23:59 -0600 Subject: [pups] Duh - how do you format an RX50? In-Reply-To: <2320.64.169.63.74.1013297255.squirrel@ruckus.brouhaha.com> References: <4.3.2.7.2.20020209083535.02048700@cirithi> <4.3.2.7.2.20020209083535.02048700@cirithi> Message-ID: <4.3.2.7.2.20020210172249.02039468@cirithi> Rats. So it would seem. Forgot about that angle. Useful program -- just not for floppies. Oh well. (Hmm. I wonder how "bzzzzt"s taste when you have to eat them with your hat?) I suspect that they kind of tingle, eh? Jay At 03:27 PM 2/9/2002 -0800, Eric Smith wrote: > > Um, bzzzzt. Wrong. I have a floppy labeled: BL-FN7AP-MC CZFNAP0 M-11 > > FORMTR RX50 . This is a formatter program for a Micro PDP-11. > > > > It is a *diagnostic* program (not a user program) for formatting these > > beasties. Mine is for the -11, I would imagine that there is one for > > the MicroVAX as well. > >The "RX50" at the end of the title may just mean that the floppy is in >RX50 format, not that the diagnostics contained therein can format RX50s. >I'd almost be willing to bet money on that, since the Micro PDP-11 >originally used the RQDX1 to control the RX50, and a disassembly of >the RQDX1 firmware shows no evidence of floppy formatting code. --- Jay R. Jaeger The Computer Collection cube1 at charter.net From pete at dunnington.u-net.com Mon Feb 11 10:25:28 2002 From: pete at dunnington.u-net.com (Pete Turnbull) Date: Mon, 11 Feb 2002 00:25:28 GMT Subject: [pups] Duh - how do you format an RX50? In-Reply-To: Jay Jaeger "Re: [pups] Duh - how do you format an RX50?" (Feb 10, 17:23) References: <4.3.2.7.2.20020209083535.02048700@cirithi> <4.3.2.7.2.20020210172249.02039468@cirithi> Message-ID: <10202110025.ZM5582@mindy.dunnington.u-net.com> On Feb 10, 17:23, Jay Jaeger wrote: > Rats. So it would seem. Forgot about that angle. Useful program -- just > not for floppies. > > Oh well. > > (Hmm. I wonder how "bzzzzt"s taste when you have to eat them with your > hat?) I suspect that they kind of tingle, eh? As far as I remember, yes. I've tried it a few times myself :-) -- Pete Peter Turnbull Network Manager University of York From talmage at cmf.nrl.navy.mil Thu Feb 14 08:24:18 2002 From: talmage at cmf.nrl.navy.mil (David W Talmage) Date: Wed, 13 Feb 2002 17:24:18 -0500 Subject: [pups] screen 3.9.9 vs. 2.11BSD write() to fifo and/or select() on socket Message-ID: <5706.1013639058@paul.cmf.nrl.navy.mil> Would someone please advise me about fifos and sockets in 2.11BSD? I'm having trouble porting screen 3.9.9, the multiplexing terminal emulator, to 2.11BSD because of them. I'm running Mr. Schultz's 2.11BSD with all patches up to #442 on Mr. Brandt's p11 emulator version 2.9. FWIW, I have INET in my kernel but I've ifconfig-ed only lo0. screen's configure complains that it finds no usable fifo or socket. The fifo test portion of the configure script fails when writing to the fifo. The write() returns -1 and sets errno == 79, "Inappropriate file type or format". This happens when I run the test as root, as I must in order to use mknod() to create the fifo. See fifotest.c, below. screen can use sockets instead of fifos. That portion of the configure script fails as well. It fails in that it does not return from the select() on the socket until the alarm goes off. See socketstest.c, below. /* fifotest.c */ #include "confdefs.h" #include #include #include #include /* #ifndef O_NONBLOCK #define O_NONBLOCK O_NDELAY #endif #ifndef S_IFIFO #define S_IFIFO 0010000 #endif */ char *fin = "/tmp/conftest254"; main() { struct stat stb; int f; (void)alarm(5); #ifdef POSIX if (mkfifo(fin, 0777)) { #else if (mknod(fin, S_IFIFO|0777, 0)) { #endif printf("mknod failed\n"); perror("mknod"); exit(1); } if (stat(fin, &stb) || (stb.st_mode & S_IFIFO) != S_IFIFO) { printf("stat failed\n"); exit(1); } close(0); #ifdef __386BSD__ /* * The next test fails under 386BSD, but screen works using fifos. * Fifos in O_RDWR mode are only used for the BROKEN_PIPE case and for * the select() configuration test. */ exit(0); #endif if (open(fin, O_RDONLY | O_NONBLOCK)) { printf("open #1 failed\n"); exit(1); } if (fork() == 0) { printf("f0\n"); close(0); if (open(fin, O_WRONLY | O_NONBLOCK)) { printf("f0 open #2 failed\n"); exit(1); } close(0); if (open(fin, O_WRONLY | O_NONBLOCK)) { printf("f0 open #3 failed\n"); exit(1); } if (write(0, "TEST", 4) == -1) { /* FAILS HERE */ printf("f0 write failed %d\n", errno); perror("write"); exit(1); } exit(0); } printf("f1\n"); f = 1; if (select(1, &f, 0, 0, 0) == -1) { printf("f1 select failed\n"); exit(1); } exit(0); } /* socketstest.c */ #include #include #include #include char *son = "/tmp/conftest254"; main() { int s1, s2, s3, l; struct sockaddr_un a; (void)alarm(5); if ((s1 = socket(AF_UNIX, SOCK_STREAM, 0)) == -1) { perror("socket"); exit(1); } a.sun_family = AF_UNIX; strcpy(a.sun_path, son); (void) unlink(son); if (bind(s1, (struct sockaddr *) &a, strlen(son)+2) == -1) { perror("bind"); exit(1); } if (listen(s1, 2)) { perror("listen"); exit(1); } if (fork() == 0) { if ((s2 = socket(AF_UNIX, SOCK_STREAM, 0)) == -1) { perror("f0 socket"); kill(getppid(), 3); } (void)connect(s2, (struct sockaddr *)&a, strlen(son) + 2); if (write(s2, "HELLO", 5) == -1) { perror("f0 write"); kill(getppid(), 3); } exit(0); } l = sizeof(a); if (close(0) == -1) { perror("close"); } if (accept(s1, &a, &l)) { perror("accept"); exit(1); } l = 1; if (select(1, &l, 0, 0, 0) == -1) { /* DOESN'T RETURN BEFORE SIG_ALARM */ perror("select"); exit(1); } exit(0); } -- David Talmage (talmage at cmf.nrl.navy.mil) ITT Industries, Advanced Engineering & Sciences, Advanced Technology Group From sms at 2BSD.COM Thu Feb 14 10:25:48 2002 From: sms at 2BSD.COM (Steven M. Schultz) Date: Wed, 13 Feb 2002 16:25:48 -0800 (PST) Subject: [pups] screen 3.9.9 vs. 2.11BSD write() to fifo and/or select() on socket Message-ID: <200202140025.g1E0Pmr20483@moe.2bsd.com> Hi! > From: David W Talmage > Would someone please advise me about fifos and sockets in 2.11BSD? Ok ;) Don't use fifos - they don't exist (as you probably have found out by now :)) > I'm having > trouble porting screen 3.9.9, the multiplexing terminal emulator, to 2.11BSD fifos and sockets are just the tip of the iceberg when it comes to 'screen'. Eons ago (when screen was a fairly new program) I made an attempt at porting it and ran into the address space problems - seems that screen wants to use lots of large buffers, has lots of strings (all the help, etc) and so on. > because of them. I'm running Mr. Schultz's 2.11BSD with all patches up to > #442 on Mr. Brandt's p11 emulator version 2.9. FWIW, I have INET in my kernel > but I've ifconfig-ed only lo0. Thanks for the "ownership" label but I think of it more as being a 'steward' and coordinator than anything else p11 2.9? Wow, I've an old patched/hacked 2.5 because I can't seem to find p11's home now - begemot.org doesn't mention anything about "p11". > The fifo test portion of the configure script fails when writing to the fifo. > The write() returns -1 and sets errno == 79, "Inappropriate file type or Right, FIFOs don't exist. One of those things I never could find the need or time for ;) > format". This happens when I run the test as root, as I must in order to use > mknod() to create the fifo. See fifotest.c, below. If 2.11's mknod can create fifos that is _news_ to me. I don't recall seeing (or adding) that capability. > screen can use sockets instead of fifos. That portion of the configure script > fails as well. It fails in that it does not return from the select() on the > socket until the alarm goes off. See socketstest.c, below. Now that is very strange. Unix domain sockets do work (syslogd uses them for example) so I'm at a loss to explain why the test program isn't working. One thing I did do is after running "./a.out&" was do an immediate 'ps'. That should see 2 a.out processes due to the 'fork()' call. I only say one. This tells me that the alarm was started (obviously since alarm(5) is the first thing executed) but the child process raced thru and exited before the parent got to the select() call. With the child exited the select() will block until interrupted by the alarm() call. Steven Schultz sms at 2bsd.com From lars at nocrew.org Thu Feb 14 18:22:48 2002 From: lars at nocrew.org (Lars Brinkhoff) Date: 14 Feb 2002 09:22:48 +0100 Subject: [pups] screen 3.9.9 vs. 2.11BSD write() to fifo and/or select() on socket In-Reply-To: <200202140025.g1E0Pmr20483@moe.2bsd.com> References: <200202140025.g1E0Pmr20483@moe.2bsd.com> Message-ID: <85lmdwfp5z.fsf@junk.nocrew.org> "Steven M. Schultz" writes: > p11 2.9? Wow, I've an old patched/hacked 2.5 because I can't seem > to find p11's home now - begemot.org doesn't mention anything about > "p11". ftp://ftp.fokus.gmd.de/pub/cats/usr/harti/p11/ -- Lars Brinkhoff http://lars.nocrew.org/ Linux, GCC, PDP-10, Brinkhoff Consulting http://www.brinkhoff.se/ HTTP programming From talmage at cmf.nrl.navy.mil Fri Feb 15 01:27:04 2002 From: talmage at cmf.nrl.navy.mil (David W Talmage) Date: Thu, 14 Feb 2002 10:27:04 -0500 Subject: [pups] screen 3.9.9 vs. 2.11BSD write() to fifo and/or select() on socket In-Reply-To: Your message of "Wed, 13 Feb 2002 16:25:48 PST." <200202140025.g1E0Pmr20483@moe.2bsd.com> Message-ID: <8332.1013700424@paul.cmf.nrl.navy.mil> "Steven M. Schultz" wrote: >> From: David W Talmage >> Would someone please advise me about fifos and sockets in 2.11BSD? >... > Don't use fifos - they don't exist (as you probably have found > out by now :)) I thought that I'd read in the FM that they do. I see now that I was mistaken, perhaps delusional. I see now that contains the gospel: #define S_IFIFO 0010000 /* named pipe (fifo) - Not used by 2.11BSD */ >> I'm having >> trouble porting screen 3.9.9, the multiplexing terminal emulator, to 2.11BSD > ... > an attempt at porting it and ran into the address space problems - seems > that screen wants to use lots of large buffers, has lots of strings > (all the help, etc) and so on. Sounds like I'm in for some deep hacking if I continue with this. Will overlays help me here? >... >> screen can use sockets instead of fifos. That portion of the configure script >> fails as well. It fails in that it does not return from the select() on the > >> socket until the alarm goes off. See socketstest.c, below. >... > With the child exited the select() will block until interrupted by > the alarm() call. I wonder if setitimer() will fare any better. alarm() is obsolete. I'll send a progress report if I decide to continue this project. Thanks for your help, Mr. Schultz. David Talmage From sms at 2BSD.COM Fri Feb 15 02:33:42 2002 From: sms at 2BSD.COM (Steven M. Schultz) Date: Thu, 14 Feb 2002 08:33:42 -0800 (PST) Subject: [pups] screen 3.9.9 vs. 2.11BSD write() to fifo and/or select() on socket Message-ID: <200202141633.g1EGXgs01723@moe.2bsd.com> Hi - > From: David W Talmage > I thought that I'd read in the FM that they do. I see now that I was > mistaken,perhaps delusional. I see now that contains the gospel: > > #define S_IFIFO 0010000 /* named pipe (fifo) - Not used by 2.11BSD */ :) Adding FIFOs to the kernel would make an interesting project though - perhaps when I become inspired/motivated I'll give it a try. > Sounds like I'm in for some deep hacking if I continue with this. Will > overlays help me here? Overlays will help if the code comes out to more than 64KB. Alas, overlays will _not_ help the dataspace requirements. The last time I looked at 'screen' I saw things like "char buf[32768];' sprinkled thru the code. So you might be in for some serious hacking to trim back the sizes of arrays/buffers/etc. It probably would also be a good idea to 'string'ify the program (there are tools to assist doing this - take a look at how sendmail and lint are built). > I wonder if setitimer() will fare any better. alarm() is obsolete. The gospel according to /usr/src/lib/libc/gen/alarm.c says: /* * Backwards compatible alarm. */ #include #include unsigned int alarm(secs) unsigned int secs; { struct itimerval it, oitv; register struct itimerval *itp = ⁢ timerclear(&itp->it_interval); itp->it_value.tv_sec = secs; itp->it_value.tv_usec = 0; if (setitimer(ITIMER_REAL, itp, &oitv) < 0) return (-1); if (oitv.it_value.tv_usec) oitv.it_value.tv_sec++; return (oitv.it_value.tv_sec); } > I'll send a progress report if I decide to continue this project. Thanks for > your help, Mr. Schultz. What I think you're seeing is the race condition that fork() has - there is no guarantee which process (parent or child) runs first. The test program does the fork() and the child runs to completion before the parent enters the select(). At that point the parent will wait until the alarm goes off. One thing you might try is create two separate programs. One would create the socket and wait for the other program to connect and send a string. If that works it shows that the UNIX domainsockets are working as expected and that the fork() race is indeed the problem. IF the client/server tests fail then there is something wrong in the UNIX domain socket handling that needs to be addressed. Good Luck! Cheers, Steven Schultz From p.visser at tip.nl Sat Feb 16 22:30:01 2002 From: p.visser at tip.nl (Pieter Visser) Date: Sat, 16 Feb 2002 13:30:01 +0100 Subject: [pups] PDP11-23 Message-ID: <000801c1b6e5$a9a03760$73e6f1c3@pieterprive> Hello, I ám still have a working Dec pdp11-23. It runs on CTS-300 with 10 Mb Harddisk and a Tape drive for back-ups I think the programm is writen in dibol. I f you want more information about this system please reply by email If anyone can help me with the following questions. Can i connect an windows/dos sytem to the pdp11-23 and run the program. Is it possible to copy the program and run it on a Windows/Dos based machine. Hope to hear from sombody, Pieter Visser The Netherlands e-mail p.visser at tip.nl handy +31-(0)6-53630275 phone +31-(0)165-313597 work +31-(0)76-5022800 fax +31-(0)76-5022090 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bqt at update.uu.se Sun Feb 17 00:09:01 2002 From: bqt at update.uu.se (Johnny Billquist) Date: Sat, 16 Feb 2002 15:09:01 +0100 (CET) Subject: [pups] PDP11-23 In-Reply-To: <000801c1b6e5$a9a03760$73e6f1c3@pieterprive> Message-ID: Hi, Pieter. > If anyone can help me with the following questions. We can always try. > Can i connect an windows/dos sytem to the pdp11-23 and run the program. Yes. Use any terminal emulator on the PC, and use it the same way as you are using some other terminal right now. > Is it possible to copy the program and run it on a Windows/Dos based machine. Not as such. However, there do exist PDP-11 emulators for the PC, which means you could copy the whole operating system, and everything else associated (I hope you don't have any special hardware though) it should be runnable. Look a e11 (http://www.dbit.com) for such a system. Another option is a PDP-11 system on a card that you put into your PC, made by Strobe Data (http://www.strobe.com). Johnny Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at update.uu.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From bill at cs.scranton.edu Sun Feb 17 01:46:22 2002 From: bill at cs.scranton.edu (Bill Gunshannon) Date: Sat, 16 Feb 2002 10:46:22 -0500 (EST) Subject: [pups] PDP11-23 In-Reply-To: Message-ID: <20020216104153.Y3512-100000@server2.cs.scranton.edu> On Sat, 16 Feb 2002, Johnny Billquist wrote: > > > Is it possible to copy the program and run it on a Windows/Dos based machine. > > Not as such. However, there do exist PDP-11 emulators for the PC, which > means you could copy the whole operating system, and everything else > associated (I hope you don't have any special hardware though) it should > be runnable. Look a e11 (http://www.dbit.com) for such a system. > Another option is a PDP-11 system on a card that you put into your PC, > made by Strobe Data (http://www.strobe.com). > Actually, I think he was thinking of the application rather than the whole system. Was there ever a DIBOL compiler for the PC?? Was there ever a DIBOL compiler for any non-DEC systems?? Would it be possible (and maybe even fun) to either write a DIBOL to C translater (like p2c or f2c) or even a DIBOL front end to GCC?? Would there be any interest in having DIBOL available again?? I think the above questions should easily show that even though I have the DIBOL manual and probably even have a copy of the compiler on a tape somewhere, I have never used or even looked at the language. I have, however, heard a lot of comments praising it. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill at cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include From cpg at aladdin.de Sat Feb 23 00:52:13 2002 From: cpg at aladdin.de (Christian Groessler) Date: 22 Feb 2002 15:52:13 +0100 Subject: [pups] missing space in 2.11_rp_unknown Message-ID: <87wux5zi02.fsf@panther.aladdin.de> Hi, I'm running above image with the p11 emulator, and the root partition is almost full. I tried to clean it up, but I cannot find where the space is used. df says: -------- # df Filesystem 1K-blocks Used Avail Capacity Mounted on root 7816 7030 786 10% / -------- but looking at files, I only see 2MB+ in use: -------- # du -s / 2702 -------- This persists over reboots, so it doesn't seem to be a large deleted file which is still in use. Where is the missing space? regards, chris From grog at lemis.com Sat Feb 23 11:29:31 2002 From: grog at lemis.com (Greg Lehey) Date: Sat, 23 Feb 2002 11:59:31 +1030 Subject: [pups] missing space in 2.11_rp_unknown In-Reply-To: <87wux5zi02.fsf@panther.aladdin.de> References: <87wux5zi02.fsf@panther.aladdin.de> Message-ID: <20020223115931.A16519@wantadilla.lemis.com> On Friday, 22 February 2002 at 15:52:13 +0100, Christian Groessler wrote: > Hi, > > I'm running above image with the p11 emulator, and the root partition > is almost full. > I tried to clean it up, but I cannot find where the space is used. > > df says: > > -------- > # df > Filesystem 1K-blocks Used Avail Capacity Mounted on > root 7816 7030 786 10% / > -------- > > but looking at files, I only see 2MB+ in use: > > -------- > # du -s / > 2702 > -------- > > This persists over reboots, so it doesn't seem to be a large deleted > file which is still in use. Have you tried running fsck? Greg -- Finger grog at lemis.com for PGP public key See complete headers for address and phone numbers From sms at 2BSD.COM Sat Feb 23 13:31:49 2002 From: sms at 2BSD.COM (Steven M. Schultz) Date: Fri, 22 Feb 2002 19:31:49 -0800 (PST) Subject: [pups] missing space in 2.11_rp_unknown Message-ID: <200202230331.g1N3Vn719597@moe.2bsd.com> Hi! > From: Christian Groessler > I'm running above image with the p11 emulator, and the root partition > is almost full. > > # df > Filesystem 1K-blocks Used Avail Capacity Mounted on > root 7816 7030 786 10% / > > but looking at files, I only see 2MB+ in use: > > # du -s / > 2702 > This persists over reboots, so it doesn't seem to be a large deleted > file which is still in use. It might be a corrupt freelist. If that is the case then running fsck will detect that fact and reclaim the space by rebuilding the freelist. > Where is the missing space? My guess is it's "missing" - that can happen if the system's shutdown (or the emulator terminated) prematurely. In that case the freelist metadata might not have been updated. I see Greg mentioned running fsck. That sounds like an excellent suggestion. Cheers, Steven Schultz sms at 2bsd.com From repro at nutechgroup.net Sun Feb 24 05:57:40 2002 From: repro at nutechgroup.net (Nutech) Date: Sun, 24 Feb 2002 01:27:40 +0530 Subject: [pups] PDP 11 Message-ID: <3C77F434.F25C3348@nutechgroup.net> I post this message with hope that someone out there can help me with a problem I have at hand. My company recently bought a preowned printing machine, which uses a PDP11/73 BA23 connected to a VT240 terminal to control the functions of the machine. Needless to say that we are unable to make the PDP run since we have no knowledge of the machine and have no one to look upto for guidance.. While we are able to power on the PDP, the VT240 is dead. Looking for help I came across your site and got the feeling that you might be able to help me out of my current deliema. While I have the original program disks, I have NO operating disks or knowledge of what OS is on the PDP. The printing machine is controlled by the PDP thru 4 serial ports (TT0 thru TT3), the machine has a total of 8 ports, 4 are left unused. PLEASE HELP. Regards, Shroff repro at nutechgroup.net From cpg at aladdin.de Mon Feb 25 21:57:21 2002 From: cpg at aladdin.de (Christian Groessler) Date: 25 Feb 2002 12:57:21 +0100 Subject: [pups] missing space in 2.11_rp_unknown Message-ID: <87heo5vkny.fsf@panther.aladdin.de> Hi, On 02/22/2002 07:31:49 PM PST "Steven M. Schultz" wrote: > >> From: Christian Groessler >> I'm running above image with the p11 emulator, and the root partition >> is almost full. >> >> # df >> Filesystem 1K-blocks Used Avail Capacity Mounted on >> root 7816 7030 786 10% / >> >> but looking at files, I only see 2MB+ in use: >> >> # du -s / >> 2702 > > I see Greg mentioned running fsck. That sounds like an excellent > suggestion. Yes, but it didn't help :-( What can this be? I tried something else, I copied the contents of the root fs elsewhere, newfs'd the root partition and copied the contents back. But now booting stops when it normally starts init, ------------- : unix Boot: bootdev=05010 bootcsr=0176700 2.11 BSD UNIX #1: Fri Feb 15 18:47:18 PST 2002 chris at pdp11:/usr/src/sys/PDP11CPG attaching qe0 csr 174440 qe0: DEC DEQNA addr 08:00:2b:07:82:6c attaching lo0 phys mem = 2097152 avail mem = 1647872 user mem = 307200 ------------- ... and here it hangs. Do I have to consider something else when I newfs the root partition? regards, chris From sms at 2BSD.COM Tue Feb 26 03:16:31 2002 From: sms at 2BSD.COM (Steven M. Schultz) Date: Mon, 25 Feb 2002 09:16:31 -0800 (PST) Subject: [pups] missing space in 2.11_rp_unknown Message-ID: <200202251716.g1PHGVT16246@moe.2bsd.com> Hi - > > I see Greg mentioned running fsck. That sounds like an excellent > > suggestion. > > Yes, but it didn't help :-( > What can this be? It might be necessary to use the '-s' option . "fsck -s" will unconditionally rebuild the freelist. > I tried something else, I copied the contents of the root fs > elsewhere, newfs'd the root partition and copied the contents back. Did you use dump+restor? > But now booting stops when it normally starts init, > Oh no! > ------------- > : unix > Boot: bootdev=05010 bootcsr=0176700 > > 2.11 BSD UNIX #1: Fri Feb 15 18:47:18 PST 2002 > chris at pdp11:/usr/src/sys/PDP11CPG > > attaching qe0 csr 174440 > qe0: DEC DEQNA addr 08:00:2b:07:82:6c > attaching lo0 > > phys mem = 2097152 > avail mem = 1647872 > user mem = 307200 > > ------------- > > ... and here it hangs. Do I have to consider something else when I > newfs the root partition? The boot block, /boot, /unix, /netnix and /etc/init, /bin/sh are intact since the system got as far as printing the memory numbers. After the memory stats the '/etc/autoconfig' process should be run ('init' runs it) and the device probes should take place. The only thing I can think of (and it's a wild guess) is that the "clock" isn't running - thru the boot process clock interrupts aren't used but when 'init' goes to run 'autoconfig' the system nees clock interrupts in order to drive the context switching. Either the clock isn't running or /etc/autoconfig got corrupted somehow in the copying. Steven Schultz sms at 2bsd.com From cpg at aladdin.de Tue Feb 26 21:56:34 2002 From: cpg at aladdin.de (Christian Groessler) Date: 26 Feb 2002 12:56:34 +0100 Subject: [pups] missing space in 2.11_rp_unknown Message-ID: <87oficpibx.fsf@panther.aladdin.de> Hi, On 02/25/2002 09:16:31 AM PST "Steven M. Schultz" wrote: > >Hi - > >> > I see Greg mentioned running fsck. That sounds like an excellent >> > suggestion. >> >> Yes, but it didn't help :-( > >> What can this be? > > It might be necessary to use the '-s' option . "fsck -s" will > unconditionally rebuild the freelist. This didn't work either. > >> I tried something else, I copied the contents of the root fs >> elsewhere, newfs'd the root partition and copied the contents back. > > Did you use dump+restor? No, tar. I tried again with dump and restor and now it works! Thanks for the hint! I seldomly use dump/restore. Now there's enough space in /: $ df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/xp0a 7816 2658 5158 04% / /dev/xp0g 151625 117599 34026 08% /usr $ Btw, the capacity values look a bit strange? regards, chris From sms at 2BSD.COM Wed Feb 27 09:29:07 2002 From: sms at 2BSD.COM (Steven M. Schultz) Date: Tue, 26 Feb 2002 15:29:07 -0800 (PST) Subject: [pups] missing space in 2.11_rp_unknown Message-ID: <200202262329.g1QNT7T07646@moe.2bsd.com> Hi! > From: Christian Groessler > > Did you use dump+restor? > > No, tar. I tried again with dump and restor and now it works! Thanks > for the hint! I seldomly use dump/restore. Ah ha! For moving filesystems dump+restor or 'afio' need to be used. Dump+restor also have the advantage of preserving the file flags (see chflags(2) and chflags(1)) - other utilities do not preserve that metadata. The other thing that dump+restor (or afio) handle correctly is the special files in /dev. 'tar' does not know how to archive files such as "/dev/rp0a". Mmmm, I wonder if the problems you were having were caused by /dev not being correctly populated. > Now there's enough space in /: > > $ df > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/xp0a 7816 2658 5158 04% / > /dev/xp0g 151625 117599 34026 08% /usr > $ > > Btw, the capacity values look a bit strange? Yes, they do look (more than a little bit) strange. On my system here (a P11 based emulated PDP-11 - I have a real 11/73 but it is only powered up when I'm actively testing): Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/xp0a 8228 3163 5065 38% / /dev/xp0h 155328 84188 71140 54% /usr What patchlevel did you mention the system was at? There were a lot of patches issued after the ' 2.11_rp_unknown' image was created. One thing, which probably will not make any difference, to try would be to recompile 'df' (and possibly 'libc') and see if the problem changes. Looks like it's a math error of some kind so either the compiler/libraries are broken or P11's having a problem doing arithmetic. Cheers, Steven Schultz sms at 2bsd.com From repro at nutechgroup.net Wed Feb 27 13:50:30 2002 From: repro at nutechgroup.net (Nutech) Date: Wed, 27 Feb 2002 09:20:30 +0530 Subject: [pups] Memory Error 46 on a PDP 11/73 Message-ID: <3C7C5786.5A3185F3@nutechgroup.net> Hello, I am getting the following error when I try to boot my PDP. The Card details for the CPU and the Memory Board are as under. Here are the details of the Various cards. Slot 1(ABCD) KDJ11-BB (M8190) Slot 2(ABCD) MSV11-QA(M7551) Slot 3 (AB) M3107 Slot 3 (CD) Blank Slot 4 (AB) Solna prinitng machine card Slot 4 (CD) BIT Scandiavia card Slot 5 (AB) Blank Slot 5 (CD) M7555 Can some one please guide what I can do besides replacing the old card with a new card. Regards, Shroff Testing in progress - Please wait 1 2 3 4 5 6 Error 46 Memory Error See troubleshooting documentation Error PC = 173242 PCR page = 15 Program listing address = 015242 R0 = 060000 R1 = 125252 R2 = 125652 R3 = 052525 R4 = 001000 R5 = 040000 R6 = 172300 Par3 = 034000 Expected data = 125252 Bad data = 125652 Address = 03400000 Command Description 1 Rerun test 2 Loop on test 3 Map memory and I/O page Type a command then press the RETURN key: 3 Memory Map Starting Ending Size in CSR CSR Bus Address address K Bytes address type type 00000000 - 03777776 1024 17772100 Parity Qbus Press the RETURN key when ready to continue I/O page Map Starting Ending Address address 17760440 - 17760456 17765000 - 17765776 CPU ROM or EEPROM 17772100 Memory CSR 17772150 - 17772152 17772200 - 17772276 Supervisor I and D PDR/PAR's 17772300 - 17772376 Kernel I and D PDR/PAR's 17772516 MMR3 17773000 - 17773776 CPU ROM 17777160 - 17777166 17777520 - 17777524 BCSR, PCR, BCR/BDR 17777546 Clock CSR 17777560 - 17777566 Console SLU 17777572 - 17777576 MMR0,1,2 17777600 - 17777676 User I and D PDR/PAR's 17777744 - 17777752 MSER, CCR, MREG, Hit/Miss 17777766 CPU Error 17777772 PIRQ Press the RETURN key when ready to continue I/O page Map Starting Ending Address address 17777776 PSW Press the RETURN key when ready to continue Error 46 Memory Error See troubleshooting documentation Error PC = 173242 PCR page = 15 Program listing address = 015242 R0 = 060000 R1 = 125252 R2 = 125652 R3 = 052525 R4 = 001000 R5 = 040000 R6 = 172300 Par3 = 034000 Expected data = 125252 Bad data = 125652 Address = 03400000 Command Description 1 Rerun test 2 Loop on test 3 Map memory and I/O page Type a command then press the RETURN key: From cpg at aladdin.de Thu Feb 28 07:35:53 2002 From: cpg at aladdin.de (Christian Groessler) Date: 27 Feb 2002 22:35:53 +0100 Subject: [pups] missing space in 2.11_rp_unknown Message-ID: <87ofiad2va.fsf@power.cnet.aladdin.de> Hi, On 02/26/2002 03:29:07 PM PST "Steven M. Schultz" wrote: > > Mmmm, I wonder if the problems you were having were caused by > /dev not being correctly populated. Maybe. I noticed they're missing and recreated them by hand. Perhaps I made a mistake there. >> $ df >> Filesystem 1K-blocks Used Avail Capacity Mounted on >> /dev/xp0a 7816 2658 5158 04% / >> /dev/xp0g 151625 117599 34026 08% /usr >> $ >> >> Btw, the capacity values look a bit strange? > > Yes, they do look (more than a little bit) strange. > > On my system here (a P11 based emulated PDP-11 - I have a real 11/73 > but it is only powered up when I'm actively testing): > >Filesystem 1K-blocks Used Avail Capacity Mounted on >/dev/xp0a 8228 3163 5065 38% / >/dev/xp0h 155328 84188 71140 54% /usr > > What patchlevel did you mention the system was at? There were a lot > of patches issued after the ' 2.11_rp_unknown' image was created. > One thing, which probably will not make any difference, to try would > be to recompile 'df' (and possibly 'libc') and see if the problem > changes. Looks like it's a math error of some kind so either > the compiler/libraries are broken or P11's having a problem doing > arithmetic. It's a problem of the p11 emulator I use. I got a patch off-list which fixed it. It was some signed/unsigned thing. Regarding the patchlevels, how do I find out which patchlevel my system is at? regards, chris From sms at 2BSD.COM Thu Feb 28 09:25:22 2002 From: sms at 2BSD.COM (Steven M. Schultz) Date: Wed, 27 Feb 2002 15:25:22 -0800 (PST) Subject: [pups] missing space in 2.11_rp_unknown Message-ID: <200202272325.g1RNPM825304@moe.2bsd.com> Hello again - > From: Christian Groessler > > Mmmm, I wonder if the problems you were having were caused by > > /dev not being correctly populated. > > Maybe. I noticed they're missing and recreated them by hand. Perhaps I > made a mistake there. It would be easy enough to do - or perhaps a critical one was left out. Filesystems without device nodes can be moved with a 'tar' pipeline but the root filesystem is special. > It's a problem of the p11 emulator I use. I got a patch off-list which > fixed it. It was some signed/unsigned thing. Ah ha! > Regarding the patchlevels, how do I find out which patchlevel my > system is at? Look at the /VERSION file. The first or second line will have the patchlevel. That file's updated by each patch. Cheers, Steven From frank at wortner.com Thu Feb 28 12:24:49 2002 From: frank at wortner.com (Frank Wortner) Date: Wed, 27 Feb 2002 21:24:49 -0500 Subject: [pups] missing space in 2.11_rp_unknown In-Reply-To: <200202272325.g1RNPM825304@moe.2bsd.com> Message-ID: FYI, here's the patch that fixes the "df" problem that Christian reported. If I recall correctly, it took me about a day to figure out that the problem wasn't in df, wasn't in the 2.11 BSD C library, but was in the p11 emulator. The fact that the same disk image booted by Bob Supnik's SIMH PDP/11 emulator produced correct "df" results was the big clue. Here's the fix for p11 (version 2.7). $ diff -c float.h* *** float.h Tue Oct 10 10:36:14 2000 --- float.h.orig Sat Mar 4 03:03:29 2000 *************** *** 442,448 **** # define CnvL(A,L) (void)((A) = F_int((L))) # define CnvF2L(S,L) (void)((L) = F_chop((S))) ! # define FrExp(A) ((signed)((A).e - EOFFS)) # define GetMant(P) (((P)->m & ~f_msb) << 1) # define GetExp(P) ((int)(P)->e - EOFFS + 1) --- 442,448 ---- # define CnvL(A,L) (void)((A) = F_int((L))) # define CnvF2L(S,L) (void)((L) = F_chop((S))) ! # define FrExp(A) ((A).e - EOFFS) # define GetMant(P) (((P)->m & ~f_msb) << 1) # define GetExp(P) ((int)(P)->e - EOFFS + 1) -- Frank "I don't hold with all this washing. This modern Behind-the-ears nonsense." * Eeyore, "Winnie the Pooh" From sven_dehmlow at web.de Fri Feb 1 02:09:13 2002 From: sven_dehmlow at web.de (Sven Dehmlow) Date: Thu, 31 Jan 2002 17:09:13 +0100 Subject: [TUHS] Re: Porting Unix v6 to i386 In-Reply-To: <20020131110042.F19170@apple.ukc.ac.uk> References: <20020130091842.A12653@apple.ukc.ac.uk> <200201310918.LAA20241@mole.nixu.fi> <20020131110042.F19170@apple.ukc.ac.uk> Message-ID: <02013117091301.00697@linux> On Thursday 31 January 2002 12:00, P.A.Osborne wrote: > On Thu, Jan 31, 2002 at 11:18:06AM +0200, Lauri Aarnio wrote: > > Have you considered using Tanenbaum's Minix as a reference ? > > Funnily enough - no. Which was a tad daft as I have a copy > of the original Tanenbaum book on a shelf about 2 feet above > the monitor.... :-) sheepish grin > Good than it will be easy for you to take a look into this book and to find out that Minix is a microkernel. You want to code a monolithic kernel. Any questions? ;-) [snip] Sven From Lauri.Aarnio at nixu.com Fri Feb 1 04:45:03 2002 From: Lauri.Aarnio at nixu.com (Lauri Aarnio) Date: Thu, 31 Jan 2002 20:45:03 +0200 Subject: [TUHS] Re: Porting Unix v6 to i386 In-Reply-To: Your message of "Thu, 31 Jan 2002 17:09:13 +0100." <02013117091301.00697@linux> Message-ID: <200201311845.UAA17935@mole.nixu.fi> In message <02013117091301.00697 at linux>, Sven Dehmlow writes: >On Thursday 31 January 2002 12:00, P.A.Osborne wrote: >> On Thu, Jan 31, 2002 at 11:18:06AM +0200, Lauri Aarnio wrote: >> > Have you considered using Tanenbaum's Minix as a reference ? >> >> Funnily enough - no. Which was a tad daft as I have a copy >> of the original Tanenbaum book on a shelf about 2 feet above >> the monitor.... :-) sheepish grin >> > >Good than it will be easy for you to take a look into this book and >to find out that Minix is a microkernel. You want to code a >monolithic kernel. It doesn't matter at all if it is a microkernel or not, if somebody just needs a reference implementation; How device drivers work or how the '286 memory management needs to be set up is practically the same; what matters is that Minix runs in 16-bit protected mode whereas Linux and *BSD don't. Lauri From bqt at update.uu.se Fri Feb 1 04:51:41 2002 From: bqt at update.uu.se (Johnny Billquist) Date: Thu, 31 Jan 2002 19:51:41 +0100 (CET) Subject: [TUHS] Re: Porting Unix v6 to i386 In-Reply-To: <20020131102649.B19170@apple.ukc.ac.uk> Message-ID: On Thu, 31 Jan 2002, P.A.Osborne wrote: > On Wed, Jan 30, 2002 at 08:50:31PM +0100, Johnny Billquist wrote: > > On Wednesday 30 January 2002 10:18, P.A.Osborne wrote: > > > Having had a rummage and a chat with acolleague here at > > > UKC - it seems that V6 will be easier than V7, partially because > > > of the Lions commentary - but mainly because 286 protected mode > > > gives a very similar handling on memory management as the PDP did. > > > > What a silly argument. > > V6 and V7 both run on the PDP-11, so the memory > > management hardware used by them both are the same. > > Having looked through the source of v6 and v7 the comments are shall > we say minimalistic to people who are not as familiar with the PDP > architecture as say Ritchie and Thompson - ie ME! Hence the Lions > commentary makes life a darn site easier. > > I am not disagreeing with the second point you have made. However the > point is that V7 is a development on from V6 and the memory management > is more complex and thus requires more work. I thought I only made one point, and that was that the argument for V6 being easier to port because "286 protected mode gives a very similar handling on memory management as the PDP did". Since V6 and V7 both run on the PDP-11 it can absolutely not be an argument for preferring V6 to V7. Thus I think it is a silly argument. The rest is purely speculative on my behalf, and I really don't want to debate wether V6 or V7 would be better to port. I have a proper PDP-11 at home, and in addition, I run RSX, not Unix on it. :-) Johnny Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at update.uu.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From mike at ducky.net Fri Feb 1 05:04:30 2002 From: mike at ducky.net (Mike Haertel) Date: Thu, 31 Jan 2002 11:04:30 -0800 (PST) Subject: [TUHS] Re: Porting Unix v6 to i386 In-Reply-To: <20020131102649.B19170@apple.ukc.ac.uk> Message-ID: <200201311904.g0VJ4UA41938@ducky.net> >Having looked through the source of v6 and v7 the comments are shall >we say minimalistic to people who are not as familiar with the PDP >architecture as say Ritchie and Thompson - ie ME! Hence the Lions >commentary makes life a darn site easier. > >I am not disagreeing with the second point you have made. However the >point is that V7 is a development on from V6 and the memory management >is more complex and thus requires more work. V6 is much more difficult to port. Reason: it had never been ported. By contrast V7 source code contains numerous cleanups that were made for the Interdata 8/32 port. (One of those cleanups included the deletion of the famous "You are not expected to understand this" comment in the kernel--because that C code for context switching could not be made to work on other architectures. Whereas you can port V7 context switch just by rewriting the supporting asm routines.) Another problem with V6 is that a significant number of the user level utility programs were still written in asm. E.g. cat, strip, sum, and even nroff. You can still use the Lions book pretty well as a reference for understanding the V7 kernel. The code may not be identical but the concepts are mostly the same. From grog at lemis.com Fri Feb 1 10:42:56 2002 From: grog at lemis.com (Greg Lehey) Date: Fri, 1 Feb 2002 11:12:56 +1030 Subject: [TUHS] Re: Porting Unix v6 to i386 In-Reply-To: <200201311845.UAA17935@mole.nixu.fi> References: <02013117091301.00697@linux> <200201311845.UAA17935@mole.nixu.fi> Message-ID: <20020201111256.A538@wantadilla.lemis.com> On Thursday, 31 January 2002 at 20:45:03 +0200, Lauri Aarnio wrote: > In message <02013117091301.00697 at linux>, Sven Dehmlow writes: >> On Thursday 31 January 2002 12:00, P.A.Osborne wrote: >>> On Thu, Jan 31, 2002 at 11:18:06AM +0200, Lauri Aarnio wrote: >>>> Have you considered using Tanenbaum's Minix as a reference ? >>> >>> Funnily enough - no. Which was a tad daft as I have a copy >>> of the original Tanenbaum book on a shelf about 2 feet above >>> the monitor.... :-) sheepish grin >>> >> >> Good than it will be easy for you to take a look into this book and >> to find out that Minix is a microkernel. You want to code a >> monolithic kernel. > > It doesn't matter at all if it is a microkernel or not, if somebody > just needs a reference implementation; How device drivers work or how > the '286 memory management needs to be set up is practically the same; > what matters is that Minix runs in 16-bit protected mode whereas > Linux and *BSD don't. To repeat what I said earlier: the hardware-dependent code isn't very interesting, it's the kernel interfaces. Minix is not UNIX; BSD is. You'll find it easier to adapt a BSD driver to the Sixth or Seventh Edition than you will a Minix or Linux driver. Greg -- Finger grog at lemis.com for PGP public key See complete headers for address and phone numbers From mirian at cosmic.com Mon Feb 4 01:21:54 2002 From: mirian at cosmic.com (Mirian Crzig Lennox) Date: Sun, 3 Feb 2002 15:21:54 +0000 (UTC) Subject: [TUHS] booting 4.3-Quasijarus on SIMH VAX Message-ID: I've managed to boot the latest 4.3-Quasijarus0a on Bob Supnik's SIMH VAX emulator. SIMH emulates a MicroVAX 3000, which is one of the currently supported configurations in 4.3-Quasijarus. The way I did it was: First I installed NetBSD 1.5.2/vax on the VAX emulator. I used this to label and newfs the root/usr diskimage for 4.3-Q (it is important to use the -O option to newfs so that NetBSD will create a 4.3-style filesystem. (In all cases, I used RA90 disk images, which are nice and spacious and which both netbsd and 4.3-Q seem to work well with.) Then I restored the root and usr filesystems from the 4.3-Q distribution onto these diskimages, and used the /usr/mdec/installboot command in NetBSD to install the bootblock onto the root diskimage. I created an fstab for it, and also commented out everything in rc* having to do with the network (there's no network device support in SIMH VAX yet). I also commented out all gettys listed in /etc/ttys except for console. Speaking of console, it's important to use something which is as close to a VT-100 as possible. I've been using rxvt, which is pretty good. It seems to be important to disable the RL controller ("set rl disabled" in SIMH) when booting the GENERIC kernel. Otherwise, you get a page fault and panic on boot. (I haven't tracked the cause of this down yet). The GENERIC kernel also expects there to be images on ra0, ra1 and ra2 (which are rq0, rq1 and rq1 in SIMH, respectively). I can get the system to come up in multiuser mode, and I can log in as root. Unfortunately, though, after a few seconds, the system locks up with uda0: lost interrupt uba0: reset uda0 uda0: DMA burst size set to 4 ra0: uda0, unit 0, size = 2376153 sectors Typing ^E to get to the SIMH prompt, and single-stepping the emulator shows it is stuck in the idle loop. At this point, nothing short of shutting down SIMH has any effect. Any thoughts on what might be going wrong? The complete log is included below: --Mirian KA655-B V5.3, VMB 2.7 Performing normal system tests. 40..39..38..37..36..35..34..33..32..31..30..29..28..27..26..25.. 24..23..22..21..20..19..18..17..16..15..14..13..12..11..10..09.. 08..07..06..05..04..03.. Tests completed. >>>boot dua0: (BOOT/R5:0 DUA0) 2.. -DUA0 1..0.. loading boot Boot : /vmunix 327204+103384+130352 start 0x23a8 4.3 BSD Quasijarus UNIX #0: Sat Oct 2 22:15:38 CDT 1999 msokolov at luthien:/usr/src/sys/GENERIC real mem = 67076096 SYSPTSIZE limits number of buffers to 18 avail mem = 65240064 using 18 buffers containing 147456 bytes of memory MicroVAX 3000, ucode rev 6 uda0 at uba0 csr 172150 vec 774, ipl 15 uda0: version 3 model 3 uda0: DMA burst size set to 4 ra0 at uda0 slave 0: mydisk, size = 2376153 sectors ra1 at uda0 slave 1: no disk label: ra90, size = 2376153 sectors ra2 at uda0 slave 2: no disk label: ra90, size = 2376153 sectors ra3 at uda0 slave 3: floppy dz0 at uba0 csr 160100 didn't interrupt dz1 at uba0 csr 160110 didn't interrupt dz2 at uba0 csr 160120 didn't interrupt dz3 at uba0 csr 160130 didn't interrupt Changing root device to ra0a WARNING: todr too small -- CHECK AND RESET THE DATE! Automatic reboot in progress... Sun Aug 19 18:07:26 CDT 2001 /dev/ra0a: 429 files, 5504 used, 26548 free (52 frags, 3312 blocks, 0.0% fragmentation) /dev/rra0d: 2588 files, 21064 used, 968769 free (785 frags, 120998 blocks, 0..0% fragmentation) Sun Aug 19 18:07:58 CDT 2001 checking quotas: done. starting system logger preserving editor files clearing /tmp standard daemons: update cron. starting local daemons:. Sun Aug 19 18:08:01 CDT 2001 4.3 BSD UNIX (kryluk) (console) login: root Last login: Sun Aug 19 17:52:53 on console 4.3 BSD Quasijarus UNIX #0: Sat Oct 2 22:15:38 CDT 1999 Welcome to UNIX! erase ^?, kill ^U, intr ^C # uda0: lost interrupt uba0: reset uda0 uda0: DMA burst size set to 4 ra0: uda0, unit 0, size = 2376153 sectors From P.A.Osborne at ukc.ac.uk Fri Feb 1 20:24:30 2002 From: P.A.Osborne at ukc.ac.uk (P.A.Osborne) Date: Fri, 1 Feb 2002 10:24:30 +0000 Subject: [TUHS] Re: Porting Unix v6 to i386 In-Reply-To: <200201311847.g0VIlHj41858@ducky.net>; from mike@ducky.net on Thu, Jan 31, 2002 at 10:47:17AM -0800 References: <20020131102843.C19170@apple.ukc.ac.uk> <200201311847.g0VIlHj41858@ducky.net> Message-ID: <20020201102430.C22403@apple.ukc.ac.uk> > >http://hp.openwatcom.org/ftp/zips/ for the binaries > >http://hp.openwatcom.org/ftp/docs/ for PDFs of the documentation > > Cool! Thanks. > Still, no source code => not much use for porting Unix, unless you > want to be limited to cross-compiling from DOS. (Making the Watcom > binaries run under v6 Unix seems very unlikely since they probably > use fancy 32-bit extenders that know all sorts of esoterica about > DOS memory management...) The reason I want the compiler is that it will generate standalone 16 bit code on a sensible platform. GCC doesnt produce 16 bit code as far as I am aware - so personally I thought it would be amusing (I must be mad) to use tools that run under DOS (well OS/2). > Someone else on the mailing list suggested using old versions of > Tanenbaum's Minix, which has a different set of compilers; again > the problem is, no compiler source code last time I looked at Minix. > > So far the only viable compiler suggestion seems to be the one > from Warner Losh who recommended bcc. (Or, port the PDP-11 compiler > yourself.) I think we are looking at this from different ends, let me try and explain: Initially we need to be able to compile the kernel/system so it runs, I feel that updating the code to ANSI C and using a modern compiler will do the job for that. Eventually it would be nice to be able to get v6-i86 (or whatever we call it) to boot itself and then be able to compile itself - at that point it becomes a complete project. It is however essentially two projects: 1. rewriting the OS so it boots as i86 2. (re)writing a compiler that will run native and be able to compile the OS on its own platform The second part is not essential by any means, but it could by the purists be considered the ultimate goal. Paul From P.A.Osborne at ukc.ac.uk Fri Feb 1 20:27:41 2002 From: P.A.Osborne at ukc.ac.uk (P.A.Osborne) Date: Fri, 1 Feb 2002 10:27:41 +0000 Subject: [TUHS] Re: Porting Unix v6 to i386 In-Reply-To: ; from bqt@update.uu.se on Thu, Jan 31, 2002 at 07:51:41PM +0100 References: <20020131102649.B19170@apple.ukc.ac.uk> Message-ID: <20020201102741.D22403@apple.ukc.ac.uk> On Thu, Jan 31, 2002 at 07:51:41PM +0100, Johnny Billquist wrote: > I thought I only made one point, and that was that the argument for V6 > being easier to port because "286 protected mode gives a very similar > handling on memory management as the PDP did". Rereading the mail - you did. Sorry for getting the wrong end of the stick. > Since V6 and V7 both run on the PDP-11 it can absolutely not be an > argument for preferring V6 to V7. > > Thus I think it is a silly argument. OK fair point - I respect your view. > The rest is purely speculative on my behalf, and I really don't want to > debate wether V6 or V7 would be better to port. > I have a proper PDP-11 at home, and in addition, I run RSX, not Unix on > it. :-) If I acquired a PDP-11 and wanted to take it home I suspect that the missus would not be too pleased. Hence the PDP emulator and a bizarre need to port to x86... Paul From P.A.Osborne at ukc.ac.uk Mon Feb 4 19:33:43 2002 From: P.A.Osborne at ukc.ac.uk (P.A.Osborne) Date: Mon, 4 Feb 2002 09:33:43 +0000 Subject: [TUHS] Re: Porting Unix v6 to i386 In-Reply-To: ; from bwc@borf.com on Fri, Feb 01, 2002 at 02:43:53PM -0500 References: Message-ID: <20020204093343.C18315@apple.ukc.ac.uk> On Fri, Feb 01, 2002 at 02:43:53PM -0500, bwc at borf.com wrote: > Regarding the few comments in Ken's kernel--I always found the great--you > can get the Lyons' commentary which may be another reason for doing Sixth. My thoughts exactly funnily enough. Pondering just this over the weekend has left me wondering whether MiniUnix would be a better initial place to start - as its essentially V6, but without memory management or pipes. Which as a starting point for the experiment may be an easier place to start. Thoughts anyone? Also as a sideline, I don't know how the list owner of this list feels about this discussion potentially swamping the list. If this is an issue or other readers of the list are sick and tired of the current ruminations please feel free to let me know and I will create a mailing list on the list manager here at UKC. That way those of us who are regarded as sad, mad or just plain losers can take our mutterings somewhere else. :-) Paul From wkt at minnie.tuhs.org Mon Feb 4 20:57:28 2002 From: wkt at minnie.tuhs.org (Warren Toomey) Date: Mon, 4 Feb 2002 20:57:28 +1000 (EST) Subject: [TUHS] Re: Porting Unix v6 to i386 In-Reply-To: <20020204093343.C18315@apple.ukc.ac.uk> from "P.A.Osborne" at "Feb 4, 2002 09:33:43 am" Message-ID: <200202041057.g14AvTs78831@minnie.tuhs.org> In article by P.A.Osborne: > [V6 is well described in the Lions Commentary] > My thoughts exactly funnily enough. Well, seeing as though Paul referred to me (see below), I'll throw my own $0.02 in. I'd recommend V7 for several reasons: - it's more portable - the flavour of C used is more modern - it's got more useful applications (yacc etc.) - you get the stdio library - one last thing, there were some awful race conditions and bogosities in V6 that just had to be fixed. See the `50 bugs' tape, and also Dennis' own admission about 6th Edition savu/retu at http://cm.bell-labs.com/cm/cs/who/dmr/odd.html > Pondering just this over the weekend has left me wondering whether > MiniUnix would be a better initial place to start - as its essentially > V6, but without memory management or pipes. Which as a starting point > for the experiment may be an easier place to start. You could port that in a short amount of time, and treat it as a warming-up exercise! > Also as a sideline, I don't know how the list owner of this list > feels about this discussion potentially swamping the list. I think the list needs some traffic :-) It might be worth setting up a list for the e-mails between co-developers, but also to have periodic status reports and questions sent to this list. > That way those of > us who are regarded as sad, mad or just plain losers can take our > mutterings somewhere else. Why do you think I set this list up in the first place ;-) ??! Cheers, Warren From P.A.Osborne at ukc.ac.uk Mon Feb 4 21:48:28 2002 From: P.A.Osborne at ukc.ac.uk (P.A.Osborne) Date: Mon, 4 Feb 2002 11:48:28 +0000 Subject: [TUHS] Re: Porting Unix v6 to i386 In-Reply-To: <200202041057.g14AvTs78831@minnie.tuhs.org>; from wkt@minnie.tuhs.org on Mon, Feb 04, 2002 at 08:57:28PM +1000 References: <20020204093343.C18315@apple.ukc.ac.uk> <200202041057.g14AvTs78831@minnie.tuhs.org> Message-ID: <20020204114828.F18315@apple.ukc.ac.uk> On Mon, Feb 04, 2002 at 08:57:28PM +1000, Warren Toomey wrote: > Well, seeing as though Paul referred to me (see below), I'll throw my > own $0.02 in. I'd recommend V7 for several reasons: > > - it's more portable > - the flavour of C used is more modern > - it's got more useful applications (yacc etc.) > - you get the stdio library > - one last thing, there were some awful race conditions and > bogosities in V6 that just had to be fixed. See the > `50 bugs' tape, and also Dennis' own admission about > 6th Edition savu/retu at > http://cm.bell-labs.com/cm/cs/who/dmr/odd.html Hmmm. I am starting (I have to admit) to lean towards V7 as my thoughts continue. I hadn't seen the "50 bugs" tape - although I believe I have a copy archived somewhere. Must take a gander at some point and mount it on the emulator. > > Pondering just this over the weekend has left me wondering whether > > MiniUnix would be a better initial place to start - as its essentially > > V6, but without memory management or pipes. Which as a starting point > > for the experiment may be an easier place to start. > > You could port that in a short amount of time, and treat it as a > warming-up exercise! Thats what I was thinking - it also alows a honing of very rusty skills, and also allows building of tools that will be needed on the way. Also I dont suppose that anyone has the tarred up source for MiniUnix they could mail me? (It just saves me from extracting it out of the tape/disk images the hard way). One thing I am undecided about though is this: Should the source be converted to from pre K&R C to ANSI C for the sake of updating the system to run on a newer architecture (though not much since the PC was released in 1980 and we only need 16bits). OR Should we attempt to provide a new compiler (or preparser) which will take the pre K&R C and just compile it as is? I have to admit the above comments are straight off the top of my head, and haven't been considered at any length and indeed should be (over several pints of ale). > > Also as a sideline, I don't know how the list owner of this list > > feels about this discussion potentially swamping the list. > > I think the list needs some traffic :-) It might be worth setting up > a list for the e-mails between co-developers, but also to have periodic > status reports and questions sent to this list. OK once we get to that stage (I am still reading up and checking out the different architectures at present - so me writing code isnt going to happen yet until I at least have been over the printed source with a red pen) which could be a while, I guess either I can run a list here at UKC or maybe Warren would like to put one up at Minnie? Regards Paul From MichaelDavidson at pacbell.net Tue Feb 5 08:12:27 2002 From: MichaelDavidson at pacbell.net (Michael Davidson) Date: Mon, 04 Feb 2002 14:12:27 -0800 Subject: [TUHS] Re: Porting Unix v6 to i386 References: <02013117091301.00697@linux> <200201311845.UAA17935@mole.nixu.fi> <20020201111256.A538@wantadilla.lemis.com> Message-ID: <3C5F074B.5080802@pacbell.net> Greg Lehey wrote: > >To repeat what I said earlier: the hardware-dependent code isn't very >interesting, it's the kernel interfaces. Minix is not UNIX; BSD is. >You'll find it easier to adapt a BSD driver to the Sixth or Seventh >Edition than you will a Minix or Linux driver. > The bits that are "interesting" or "useful" to any particular person are the bits which help to fill in the gaps in their knowledge and are therefore likely to be different for different people. I am inclined to think that *none* of the other operating systems that have been mentioned - Linux, Minix, BSD UNIX etc - are of much use *except* as a reference for how to do certain things with the hardware (and they probably aren't even very good for that purpose) UNIX has come a *long* way since V6 and V7, and a modern BSD device driver with support for disk partitioning schemes, bad block mapping and who-knows-what-else is a very different beast from the V6 rk11 driver. To me, at least, the "obvious" way to get a V6 or V7 disk driver working is to do exactly what almost everyone used to do when faced with this problem - you start with something like the rk11 driver, study it until you understand how it works (or at least think that you do ...) and then modify it to talk to your particular piece of hardware. From that perspective, what you *really* need is good documentation for the PC hardware that you are going to be dealing with - ie interrupt controller, dma controller, floppy controller, ide interface etc. From norman at nose.cs.utoronto.ca Tue Feb 5 08:23:31 2002 From: norman at nose.cs.utoronto.ca (norman at nose.cs.utoronto.ca) Date: Mon, 04 Feb 2002 17:23:31 -0500 Subject: [TUHS] Re: Porting Unix v6 to i386 Message-ID: <200202042224.IAA18805@guardian-ext.bond.edu.au> Greg Lehey: To repeat what I said earlier: the hardware-dependent code isn't very interesting, it's the kernel interfaces. Minix is not UNIX; BSD is. You'll find it easier to adapt a BSD driver to the Sixth or Seventh Edition than you will a Minix or Linux driver. It depends on approach, which depends in turn on intent. If the intent is to get a system up and running as quickly as possible, it would probably be best to shoehorn existing code into the existing old UNIX framework, and code from a current BSD system is probably easier to do that with than code from Minix (says someone who has looked at neither within living memory). If the intent is to learn about the innards of operating systems and how they interact with hardware, or about the specifics of old UNIXes or the OS aspects of Intel hardware, it is better to compare different descriptions of the hardware (whether abstract descriptions in books or pragmatic ones in code), write your own small test programs to be run on bare hardware or as special cases within some system that already runs there, and eventually write your own code or adopt code that you now understand thoroughly. Which of these you consider fun depends both on your goals and on your personal taste. Both are worthy of respect. In days long past, when I did a lot of work to make a research version of UNIX as robust as possible against hardware flaws (recover if possible, at least explain clearly what broke if not) and to port it to a few new VAXes of the time, I found the best hardware information to lie in the VAX/VMS source fiche. The UNIXes of the day tended either to crash on the slightest hardware error or to ignore the error and just misbehave until rebooted. Stealing code from them would have been easier, but it wouldn't have done what I wanted. Reading the VMS sources and treating them as a hardware reference manual did. Modern UNIXes doubtless do better, but the point is that different systems do different things with the hardware, and if your goal is understanding and not just function, you will gain more by looking in many places. An irrelevant but fun anecdote: it could be argued that the resulting code recovered too smoothly from errors. One day I discovered that one of our systems was running more slowly than usual, though it was otherwise OK; checking back on the paper console log, I discovered that several weeks earlier it had had a hard cache error, reported it and cheerfully turned off the bad half of the cache, and continued on its way. So I called Field Service and we scheduled a convenient time to run diagnostics--yes, the hardware really had failed--and replace the bad CPU board; but it would have been better to have noticed earlier. I watched the console logs more carefully after that. Norman Wilson Toronto ON From wkt at minnie.tuhs.org Tue Feb 5 16:21:57 2002 From: wkt at minnie.tuhs.org (Warren Toomey) Date: Tue, 5 Feb 2002 16:21:57 +1000 (EST) Subject: [TUHS] Browse Unix src: the Unix Tree Message-ID: <200202050621.g156LwK91534@minnie.tuhs.org> All, With the freeing up of the Unix source, not only can I open up the Unix Archive to anonymous downloads, but I can now make my Unix Tree web site available anonymously: http://minnie.tuhs.org/UnixTree/ Here is where you will find unpacked versions of Unix source code, and a means of comparing files between different versions. Cheers, Warren P.S Thanks to the many people who have set up mirrors of the Unix Archive. From P.A.Osborne at ukc.ac.uk Tue Feb 5 20:42:44 2002 From: P.A.Osborne at ukc.ac.uk (P.A.Osborne) Date: Tue, 5 Feb 2002 10:42:44 +0000 Subject: [TUHS] Re: Porting Unix v6 to i386 In-Reply-To: <3C5F074B.5080802@pacbell.net>; from MichaelDavidson@pacbell.net on Mon, Feb 04, 2002 at 02:12:27PM -0800 References: <02013117091301.00697@linux> <200201311845.UAA17935@mole.nixu.fi> <20020201111256.A538@wantadilla.lemis.com> <3C5F074B.5080802@pacbell.net> Message-ID: <20020205104244.C25428@apple.ukc.ac.uk> On Mon, Feb 04, 2002 at 02:12:27PM -0800, Michael Davidson wrote: > I am inclined to think that *none* of the other operating systems that > have been mentioned > - Linux, Minix, BSD UNIX etc - are of much use *except* as a reference > for how to do > certain things with the hardware (and they probably aren't even very > good for that purpose) I feel that Linux and *BSD are possibly overkill for reference as a device driver model. Mainly because they have evolved so far on from what Vx is and they were even in the earliest days. I DO feel however that the source of a current PC system could be a good example of how to talk to the floppy, keyboard etc etc at the lowest level ie performing the read, write etc etc. So because of its small size and the fact that it doesn't have hundreds of people editing the code then say MINIX could be very usefull as a "how did they read from the floppy drive"; NOT how did they do process scheduling. So for example taking the source for the RK driver from V6 rk.c: If we were say in a PC version to call the floppy drive RK (why not?), then the aim would surely be to rewrite the appropriate functions so they are specific to the PC floppy drive. > UNIX has come a *long* way since V6 and V7, and a modern BSD device > driver with > support for disk partitioning schemes, bad block mapping and > who-knows-what-else is a > very different beast from the V6 rk11 driver. Of course it is. Otherwise I would still be using a magnet to edit the hard disk the hard way. I don't think for one minute we should provide that level of sophistication. Instead we should aim at getting a "1970s version of Unix" running on a PC. So initially the teletype becomes the screen and the keyboard and the disk unit becomes say the floppy drive. Later things can be expanded to talk IDE/SCSI whatever - but at that point you are evolving the "1970s version of Unix" on a stage further - which at present is not what I (at least) consider a goal of any potential porting project to be. It becomes part of a wish list. At present I would be extremely happy with being able to put a 1.44MB floppy disk in a PC and watch the PC boot an early Unix, provide a shell and be able to use a few tools. I don't think that initially we should aim for any more than that. My apologies if I am raining on anyones parade or this mail has gone out of context to the one I am replying to, or is even turning into a rant. Sorry if I am irritating anyone. > To me, at least, the "obvious" way to get a V6 or V7 disk driver working > is to do exactly > what almost everyone used to do when faced with this problem - you start > with > something like the rk11 driver, study it until you understand how it > works (or at least > think that you do ...) and then modify it to talk to your particular > piece of hardware. Exactly. That way you waste less time mucking around. > From that perspective, what you *really* need is good documentation for > the PC > hardware that you are going to be dealing with - ie interrupt > controller, dma controller, > floppy controller, ide interface etc. The PC Indispensible Hardware Book ISBN: 0201596164 is dead good for this. A quick look at Amazon reveals that there is a new edition - which is going to cover hardware we are unlikely to use - so an earlier edition may be found fairly cheaply. Besides I am not forking out for another copy just yet - the wifes course books are crippling my bank account as it is. :-) Regards Paul From jss at subatomix.com Thu Feb 7 02:36:42 2002 From: jss at subatomix.com (Jeffrey S. Sharp) Date: Wed, 6 Feb 2002 10:36:42 -0600 (CST) Subject: [TUHS] Re: Porting Unix v6 to i386 In-Reply-To: <20020205104244.C25428@apple.ukc.ac.uk> Message-ID: <20020206102406.A44142-100000@kenny.subatomix.com> On Tue, 5 Feb 2002, P.A.Osborne wrote: > Instead we should aim at getting a "1970s version of Unix" running on a > PC. So initially the teletype becomes the screen and the keyboard and > the disk unit becomes say the floppy drive. > > Later things can be expanded to talk IDE/SCSI whatever - but at that > point you are evolving the "1970s version of Unix" on a stage further - Screen => console tty is obvious. But why do you insist on the floppy drive as the storage medium? The floppy drive subsystem has drives and a controller with a certain programatic interface. The IDE/SCSI subsystem has drives and a controller with a certain programatic interface. They're the same kind of thing. Why is one more guilty of evolving the 1970s version of UNXI? I think that a floppy might make a good RK03/05 (capacity differences aside), but why not implement some RP drives with hard drives of even zip drives? -- Jeffrey S. Sharp jss at subatomix.com From P.A.Osborne at ukc.ac.uk Thu Feb 7 20:23:13 2002 From: P.A.Osborne at ukc.ac.uk (P.A.Osborne) Date: Thu, 7 Feb 2002 10:23:13 +0000 Subject: [TUHS] Re: Porting Unix v6 to i386 In-Reply-To: <20020206102406.A44142-100000@kenny.subatomix.com>; from jss@subatomix.com on Wed, Feb 06, 2002 at 10:36:42AM -0600 References: <20020205104244.C25428@apple.ukc.ac.uk> <20020206102406.A44142-100000@kenny.subatomix.com> Message-ID: <20020207102313.D26210@apple.ukc.ac.uk> On Wed, Feb 06, 2002 at 10:36:42AM -0600, Jeffrey S. Sharp wrote: > > Instead we should aim at getting a "1970s version of Unix" running on a > > PC. So initially the teletype becomes the screen and the keyboard and > > the disk unit becomes say the floppy drive. > > > > Later things can be expanded to talk IDE/SCSI whatever - but at that > > point you are evolving the "1970s version of Unix" on a stage further - > > Screen => console tty is obvious. But why do you insist on the floppy > drive as the storage medium? I don't insist on it. It was just my reckoning to get things going, that a floppy as an RK would be enough. > The floppy drive subsystem has drives and a controller with a certain > programatic interface. The IDE/SCSI subsystem has drives and a controller > with a certain programatic interface. They're the same kind of thing. > Why is one more guilty of evolving the 1970s version of UNXI? Re-reading that last mail of mine, I see that my mind kind of meandered. So to be honest - I think you could well be right. > I think that a floppy might make a good RK03/05 (capacity differences > aside), but why not implement some RP drives with hard drives of even zip > drives? I don't see any particular reason not to do so. I was attempting to openly straighten my own thoughts out (perhaps thinking out loud is not the best plan) and suggest that initially an RK - floppy would be a start, and that RP - hard disk could be done later. Paul From Rahbynz1 at aol.com Tue Feb 12 04:31:50 2002 From: Rahbynz1 at aol.com (Rahbynz1 at aol.com) Date: Mon, 11 Feb 2002 13:31:50 EST Subject: [TUHS] Re: FW: FW: Cancer (DO NOT DELETE A WORD OF THIS) Message-ID: <12e.c4f9e0e.29996817@aol.com> Please read the following: http://urbanlegends.about.com/library/blamybruce.htm?terms=make+a+wish From jkunz at unixag-kl.fh-kl.de Thu Feb 14 08:10:38 2002 From: jkunz at unixag-kl.fh-kl.de (Jochen Kunz) Date: Wed, 13 Feb 2002 23:10:38 +0100 Subject: [TUHS] 4.4BSD-Lite binaries for SPARC and PMAX Message-ID: <20020213231038.A172997@krumm.unixag-kl.fh-kl.de> Hi. I plan to do a BSD exhibition at the VCFE. Main focus is 4.3BSD{,-Tahoe,-Reno} on VAXen. But I want to show 4.4BSD-Lite on HP300, SPARC and PMAX too. I have the 4.4BSD-Lite HP300 binaries, but nothing for SPARC and PMAX. Are there any binaries still around? I don't want to struggle with a SPARC and PMAX bootstrap... Ahh, and 4.2BSD-Reno for HP300 is missing too... -- tschüß, Jochen Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/ From agrier at poofygoof.com Fri Feb 15 08:30:50 2002 From: agrier at poofygoof.com (Aaron J. Grier) Date: Thu, 14 Feb 2002 14:30:50 -0800 Subject: [TUHS] Re: Porting Unix v6 to i386 In-Reply-To: ; from P.A.Osborne@ukc.ac.uk on Fri, Feb 01, 2002 at 10:24:30AM +0000 Message-ID: <20020214143050.J241@goldberry.poofy.goof.com> On Fri, Feb 01, 2002 at 10:24:30AM +0000, P.A.Osborne wrote: > The reason I want the compiler is that it will generate standalone 16 > bit code on a sensible platform. GCC doesnt produce 16 bit code as > far as I am aware - so personally I thought it would be amusing (I > must be mad) to use tools that run under DOS (well OS/2). support for PDP-11 was added to gcc a few months ago. I don't think it's been well tested, but support exists in current versions of binutils and gcc. http://pdp11.nocrew.org/ there's also support for the m68hc11/12 which are 16-bit. it seems like support for 80{,1,2}86 in gcc should be possible; it just hasn't been done yet. another compiler that might be worth looking at is SDCC http://sdcc.sourceforge.net/ which is currently targeted towards 8-bit MCUs. of course bootstrapping via the original K&R compiler would be the "classic" way to do it, though. ;) -- Aaron J. Grier | "Not your ordinary poofy goof." | agrier at poofygoof.com "[...] I generally haven't found IDM guys to be very good live acts, most of them just sit down at their laptop and tweak reaktor." -- Brandon Daniel From johnh at psych.usyd.edu.au Fri Feb 15 10:07:15 2002 From: johnh at psych.usyd.edu.au (John Holden) Date: Fri, 15 Feb 2002 11:07:15 +1100 (EST) Subject: [TUHS] Re: Porting Unix v6 to i386 Message-ID: <200202150007.LAA29610@psychwarp.psych.usyd.edu.au> Aaron J. Grier wrote :- > support for PDP-11 was added to gcc a few months ago. It's been around since 1991 as a patch, but it didn't keep up with the newer versions of gcc From peter.jeremy at alcatel.com.au Fri Feb 15 13:08:29 2002 From: peter.jeremy at alcatel.com.au (Peter Jeremy) Date: Fri, 15 Feb 2002 14:08:29 +1100 Subject: [TUHS] Re: Porting Unix v6 to i386 In-Reply-To: <20020214143050.J241@goldberry.poofy.goof.com>; from agrier@poofygoof.com on Thu, Feb 14, 2002 at 02:30:50PM -0800 References: <20020214143050.J241@goldberry.poofy.goof.com> Message-ID: <20020215140829.G78085@gsmx07.alcatel.com.au> On 2002-Feb-14 14:30:50 -0800, "Aaron J. Grier" wrote: >support for PDP-11 was added to gcc a few months ago. I don't think >it's been well tested, but support exists in current versions of >binutils and gcc. > >http://pdp11.nocrew.org/ > >there's also support for the m68hc11/12 which are 16-bit. This is only cross-compilation support. gcc was never designed to be hosted in a 16-bit environment. An i386 gcc is: text data bss dec hex filename 1660236 22836 97104 1780176 1b29d0 /usr/libexec/cc1 Even taking into account the savings with 16-bit int's and pointers, you won't get the data segment below 64k - and most of gcc's structures are dynamically allocated. >it seems like support for 80{,1,2}86 in gcc should be possible; it just >hasn't been done yet. Given that i386 is already supported, adding support for 16-bit x86 would be fairly easy. The only major work would be handling the 16-bit addressing modes. >another compiler that might be worth looking at is SDCC >http://sdcc.sourceforge.net/ which is currently targeted towards 8-bit >MCUs. Again, no x86 support and I don't believe the code generation is that good. >of course bootstrapping via the original K&R compiler would be the >"classic" way to do it, though. ;) The PDP-11 is orthogonal and so PCC doesn't have to worry about getting particular operands into particular registers. I suspect that supporting the i386's idiosyncracies would be non-trivial. Peter From lars at nocrew.org Fri Feb 15 18:08:03 2002 From: lars at nocrew.org (Lars Brinkhoff) Date: 15 Feb 2002 09:08:03 +0100 Subject: [TUHS] Re: Porting Unix v6 to i386 In-Reply-To: <20020214143050.J241@goldberry.poofy.goof.com> References: <20020214143050.J241@goldberry.poofy.goof.com> Message-ID: <85lmdvcgm4.fsf@junk.nocrew.org> "Aaron J. Grier" writes: > support for PDP-11 was added to gcc a few months ago. I don't think > it's been well tested, but support exists in current versions of > binutils and gcc. You are confusing gcc and binutils. PDP-11 support as added to binutils recently. However, it's not well tested, and is likely to need more work to be usable. John Holden writes: > > support for PDP-11 was added to gcc a few months ago. > It's been around since 1991 as a patch, but it didn't keep up with > the newer versions of gcc It's still there, and some people are looking after it from time to time, but it's probably too broken to be useful. However, there has been some interest in building a complete GNU cross tool chain for the PDP-11. -- Lars Brinkhoff http://lars.nocrew.org/ Linux, GCC, PDP-10, Brinkhoff Consulting http://www.brinkhoff.se/ HTTP programming From firebug at apk.net Mon Feb 18 15:30:18 2002 From: firebug at apk.net (Derrik Walker v2.0) Date: Mon, 18 Feb 2002 00:30:18 -0500 Subject: [TUHS] Legal ramifications putting certain things on my web site? Message-ID: <9829AFEA-2430-11D6-A883-003065C1AC88@apk.net> I've started porting some of the old UNIX programs to Mac OS X. I've got about 1/2 the games, that should be ok, but I also have other things like crypt and makekey. I'd like to make these available in binary form, but I don't want the men in black knocking at my door either... Any thoughts? On a side note, I simply can not believe how easy it is to compile this old code under Mac OS X. for some of it, it's proving easier than porting Linux code ( if you've only known how long I worked on linux's fortune, and the old one just compiled no fuss, no problems ). Also, if your wandering why ... that's easy, because I can. Thanks. - Derrik firebug at apk.net http://junior.apk.net/~firebug --------------------------------------------------------------------------------------------------- The number of UNIX installations has grown to 10, with more expected. -- The Unix Programmer's Manual, 2nd Edition, June 1972 From MichaelDavidson at pacbell.net Mon Feb 18 16:01:07 2002 From: MichaelDavidson at pacbell.net (Michael Davidson) Date: Sun, 17 Feb 2002 22:01:07 -0800 Subject: [TUHS] Legal ramifications putting certain things on my web site? References: <9829AFEA-2430-11D6-A883-003065C1AC88@apk.net> Message-ID: <3C7098A3.2C8B2220@pacbell.net> "Derrik Walker v2.0" wrote: > > I've started porting some of the old UNIX programs to Mac OS X. I've > got about 1/2 the games, that should be ok, but I also have other things > like crypt and makekey. I'd like to make these available in binary > form, but I don't want the men in black knocking at my door either... > > Any thoughts? > Assuming that you are in the US you might want to put some kind of blanket disclaimer on your web site - something like the one at: http://gatekeeper.dec.com/hypertext/info/export-controls.html which essentially says that it is the responsibility of people downloading stuff from your site to ensure that they comply with any and all export regulations. I am not a lawyer and have no idea whether this kind of statement actually gives you any real protection but obviously someone at DEC once thought that it did ... From wkt at minnie.tuhs.org Mon Feb 18 19:36:54 2002 From: wkt at minnie.tuhs.org (Warren Toomey) Date: Mon, 18 Feb 2002 19:36:54 +1000 (EST) Subject: [TUHS] Legal ramifications putting certain things on my web site? In-Reply-To: <9829AFEA-2430-11D6-A883-003065C1AC88@apk.net> from "Derrik Walker v2.0" at "Feb 18, 2002 00:30:18 am" Message-ID: <200202180936.g1I9ats43685@minnie.tuhs.org> In article by Derrik Walker v2.0: > I've started porting some of the old UNIX programs to Mac OS X. I've > got about 1/2 the games, that should be ok, but I also have other things > like crypt and makekey. I'd like to make these available in binary > form, but I don't want the men in black knocking at my door either... > > Any thoughts? > > On a side note, I simply can not believe how easy it is to compile this > old code under Mac OS X. for some of it, it's proving easier than > porting Linux code ( if you've only known how long I worked on linux's > fortune, and the old one just compiled no fuss, no problems ). > > Also, if your wandering why ... that's easy, because I can. > Thanks. > - Derrik Derrick, if it's code from 32V, 7th Edition or earlier, then you are covered by the new Caldera Ancient UNIX license, and you can release binaries and/or source. If it's code from any of the BSDs, then you are covered by a standard BSD license, except for the bits which Caldera can trace as belonging to them 8-) Cheers, Warren From casanndra2002 at yahoo.com Tue Feb 19 06:11:37 2002 From: casanndra2002 at yahoo.com (casanndra2002 at yahoo.com) Date: Mon, 18 Feb 2002 21:11:37 +0100 Subject: [TUHS] I N T E R N E T I N C O M E ! ! ! Message-ID: <200202182014.GAA07728@guardian-ext.bond.edu.au> An HTML attachment was scrubbed... URL: From rweather at zip.com.au Tue Feb 19 14:06:28 2002 From: rweather at zip.com.au (Rhys Weatherley) Date: Tue, 19 Feb 2002 14:06:28 +1000 Subject: [TUHS] v7 upgrade Message-ID: <3C71CF44.18D0BDA1@zip.com.au> Hi, I've been lurking here for a week or two, reading the archives on porting v7 to x86, etc. On a lark, I downloaded the v7 sources and started to "upgrade" them so the userland can build and run on top of modern OS kernels such as Linux. The bulk of libc is the same (warts and all), with the "sys" layer replaced with modern syscalls. Perhaps it is a bit "sacrilegious", but I believe it makes the code more accessible for experimentation, and it should solve the "how do we get a PDP-11 compiler" problem: we use the original hosted on top of a modern kernel as a cross-compiler. Check it out and let me know what you think. Most of the libraries have been upgraded, with a handful of the simpler command-line utilities. http://www.southern-storm.com.au/v7upgrade.html Cheers, Rhys. From wkt at minnie.tuhs.org Tue Feb 19 17:06:58 2002 From: wkt at minnie.tuhs.org (Warren Toomey) Date: Tue, 19 Feb 2002 17:06:58 +1000 (EST) Subject: [TUHS] v7 upgrade In-Reply-To: <3C71CF44.18D0BDA1@zip.com.au> from Rhys Weatherley at "Feb 19, 2002 02:06:28 pm" Message-ID: <200202190706.g1J76wG51094@minnie.tuhs.org> In article by Rhys Weatherley: > On a lark, I downloaded the v7 sources and started to > "upgrade" them so the userland can build and run on top > of modern OS kernels such as Linux. The bulk of libc > is the same (warts and all), with the "sys" layer replaced > with modern syscalls. > > Perhaps it is a bit "sacrilegious", but I believe it makes > the code more accessible for experimentation, and it > should solve the "how do we get a PDP-11 compiler" > problem: we use the original hosted on top of a modern > kernel as a cross-compiler. Hi Rhys, just looked at your page. I liked the comment: Using these libraries, it is possible to port and run the old v7 command-line utilities. Eventually, it should be possible to run the original PDP-11 toolchain as a cross-compiler and hence be able to build an original v7 system without needing to use a PDP-11 emulator to run the old binaries. Strangely enough, I took a slightly different tack than you did to obtain the same result. Have a look at Apout at ftp://minnie.tuhs.org/pub/PDP-11/Sims/Apout/README 8-) Warren From rweather at zip.com.au Tue Feb 19 18:01:02 2002 From: rweather at zip.com.au (Rhys Weatherley) Date: Tue, 19 Feb 2002 18:01:02 +1000 Subject: [TUHS] v7 upgrade References: <200202190706.g1J76wG51094@minnie.tuhs.org> Message-ID: <3C72063E.CA48D123@zip.com.au> Warren Toomey wrote: > Strangely enough, I took a slightly different tack than you did to obtain > the same result. Have a look at Apout at > ftp://minnie.tuhs.org/pub/PDP-11/Sims/Apout/README Nice. Both approaches have their uses. I'm interested in how upgrading the code will make it more accessible to people wishing to study OS design, by enabling it to compile natively for modern hardware. It's difficult to "fiddle" with the code when running via emulation. I forgot to mention in my previous message that I've also got the userland compiling with bcc (Bruce's C Compiler), outputting 8086 binaries. This should help those who want to port v7 to 8086. Besides, it's fun to mess with this old code. I'm quite impressed that there's been very few problems upgrading the userland to run on 32-bit CPU's. Cheers, Rhys. From mirian at cosmic.com Wed Feb 20 01:51:46 2002 From: mirian at cosmic.com (Mirian Crzig Lennox) Date: Tue, 19 Feb 2002 15:51:46 +0000 (UTC) Subject: [TUHS] v7 upgrade References: <3C71CF44.18D0BDA1@zip.com.au> Message-ID: On Tue, 19 Feb 2002 14:06:28 +1000, Rhys Weatherley wrote: > >I've been lurking here for a week or two, reading the >archives on porting v7 to x86, etc. > >Perhaps it is a bit "sacrilegious", but I believe it makes >the code more accessible for experimentation, and it >should solve the "how do we get a PDP-11 compiler" >problem: we use the original hosted on top of a modern >kernel as a cross-compiler. I don't believe it is sacrilegious at all. The triumph of UNIX has always been that it's the software that really matters, not the hardware. --Mirian From aek at spies.com Wed Feb 20 07:19:51 2002 From: aek at spies.com (Al Kossow) Date: Tue, 19 Feb 2002 13:19:51 -0800 Subject: [TUHS] v7 upgrade Message-ID: <200202192119.NAA21653@spies.com> There were ports of PCC to the 8086, Z8000, and 68000 done by MIT's Laboratory for Computer Science. This might be a more historically correct place to start. From wkt at minnie.tuhs.org Thu Feb 21 11:10:21 2002 From: wkt at minnie.tuhs.org (Warren Toomey) Date: Thu, 21 Feb 2002 11:10:21 +1000 (EST) Subject: [TUHS] 4.4BSD-Lite binaries for SPARC and PMAX In-Reply-To: <20020220193912.A195476@MissSophie.unixag-kl.fh-kl.de> from Jochen Kunz at "Feb 20, 2002 07:39:12 pm" Message-ID: <200202210110.g1L1AL367254@minnie.tuhs.org> > Warren, maybe you know a PUPS volunteer in the USA that has appropriate > equipment and experience to do this job? This would also reduce shipping > efforts and cost for Mr. McKusick. (And risk of damage of the tapes, as > it would avoid shipping across the "big pond".) I've just sent some mail to Tim Shoppa, asking if he would be willing to read the tapes for us. Cheers, Warren From shoppa at trailing-edge.com Thu Feb 21 12:03:19 2002 From: shoppa at trailing-edge.com (Tim Shoppa) Date: Wed, 20 Feb 2002 21:03:19 -0500 (EST) Subject: [TUHS] 4.4BSD-Lite binaries for SPARC and PMAX In-Reply-To: <200202210110.g1L1AL367254@minnie.tuhs.org> from "Warren Toomey" at Feb 21, 2002 11:10:21 AM Message-ID: <20020221020319.3720318336@mudd.trailing-edge.com> > > Warren, maybe you know a PUPS volunteer in the USA that has appropriate > > equipment and experience to do this job? This would also reduce shipping > > efforts and cost for Mr. McKusick. (And risk of damage of the tapes, as > > it would avoid shipping across the "big pond".) > > I've just sent some mail to Tim Shoppa, asking if he would be willing > to read the tapes for us. I'd be glad to help out. In in the Washington DC area. Although I have to admit I haven't been following the mailing list lately - what tapes have been found and where are they? I *think* I've got some 4.4-ish tapes for some other architectures already, but I don't think for PMAX or SPARC. Tim. From jkunz at unixag-kl.fh-kl.de Thu Feb 21 18:13:42 2002 From: jkunz at unixag-kl.fh-kl.de (Jochen Kunz) Date: Thu, 21 Feb 2002 09:13:42 +0100 Subject: [TUHS] 4.4BSD-Lite binaries for SPARC and PMAX In-Reply-To: <20020221020319.3720318336@mudd.trailing-edge.com>; from shoppa@trailing-edge.com on Thu, Feb 21, 2002 at 03:03:19 CET References: <200202210110.g1L1AL367254@minnie.tuhs.org> <20020221020319.3720318336@mudd.trailing-edge.com> Message-ID: <20020221091342.R195476@MissSophie.unixag-kl.fh-kl.de> On 2002.02.21 03:03 Tim Shoppa wrote: > Although I have to admit I haven't been following the mailing list > lately - what tapes have been found and where are they? This was a off list discussion with The High Priest of the Daemon, Mr. Kirk McKusick himself. He possibly still has the original 4.4BSD SPARC and PMAX distribution tapes. He is willing to give them to me to read them for transfering the contens into the TUHS archive. Unfortunately my 9 track tape does only 1600 / 3200 BPI and I assume the tapes are 6250 BPI... Also if someone in the USA can do the job it would reduce shipping cost and efforts for Mr. McKusick, because I am beyond the "big pond". > I *think* I've got some 4.4-ish tapes for some other architectures > already, but I don't think for PMAX or SPARC. In the archive is only 4.4BSD-ALPHA with hp300 binarys, so... [beging smile] -- tschüß, Jochen Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/ From jss.tuhs at subatomix.com Fri Feb 22 00:22:17 2002 From: jss.tuhs at subatomix.com (Jeffrey S. Sharp) Date: Thu, 21 Feb 2002 08:22:17 -0600 (CST) Subject: [TUHS] 4.4BSD-Lite binaries for SPARC and PMAX In-Reply-To: <20020221091342.R195476@MissSophie.unixag-kl.fh-kl.de> Message-ID: <20020221081508.G2203-100000@kenny.subatomix.com> On Thu, 21 Feb 2002, Jochen Kunz wrote: > Also if someone in the USA can do the job it would reduce shipping cost > and efforts for Mr. McKusick, because I am beyond the "big pond". Also, be aware that many shippers will not insure international shipments. If a UPS worker knows that the contents of a particular truck are not insured, how do you think he/she would treat them? Someone in the USA surely has an appropriate tape drive. With the list's permission, I'd like to ask the members of the classiccmp and SunRescue lists for help. To whom should I direct them? -- Jeffrey S. Sharp jss at subatomix.com From jkunz at unixag-kl.fh-kl.de Fri Feb 22 01:59:04 2002 From: jkunz at unixag-kl.fh-kl.de (Jochen Kunz) Date: Thu, 21 Feb 2002 16:59:04 +0100 Subject: [TUHS] 4.4BSD-Lite binaries for SPARC and PMAX In-Reply-To: <20020221081508.G2203-100000@kenny.subatomix.com>; from jss.tuhs@subatomix.com on Thu, Feb 21, 2002 at 08:22:17AM -0600 References: <20020221091342.R195476@MissSophie.unixag-kl.fh-kl.de> <20020221081508.G2203-100000@kenny.subatomix.com> Message-ID: <20020221165904.A24287@unixag-kl.fh-kl.de> On Thu, Feb 21, 2002 at 08:22:17AM -0600, Jeffrey S. Sharp wrote: > Also, be aware that many shippers will not insure international shipments. > If a UPS worker knows that the contents of a particular truck are not > insured, how do you think he/she would treat them? This is an other reason I thought about, but did not write it down... I am sure I can get a 6250 BPI 9 track tape here in Germany, possibly from a friend in my city, but then there is still the shipping problem... > Someone in the USA surely has an appropriate tape drive. With the list's > permission, I'd like to ask the members of the classiccmp and SunRescue > lists for help. To whom should I direct them? Tim Shoppa has already taken this job. Thanks to him and Mr. McKusick for donating their precious time to this project. :-) -- tschüß, Jochen Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/ From rweather at zip.com.au Wed Feb 27 14:39:46 2002 From: rweather at zip.com.au (Rhys Weatherley) Date: Wed, 27 Feb 2002 14:39:46 +1000 Subject: [TUHS] v7upgrade 0.0.2 Message-ID: <3C7C6312.B69744A0@zip.com.au> I've uploaded version 0.0.2 of "v7upgrade" to my Web site: http://www.southern-storm.com.au/v7upgrade.html It is now possible to run a stripped-down v7 userland environment on top of a Linux/i386 kernel, using the v7 Bourne shell. A good chunk of the "shellutils" programs have now been upgraded, including all of your usual favourites (cat, chmod, cp, date, dd, diff, echo, kill, ls, mkdir, mv, od, rm, rmdir, among others). Getting the Bourne shell to work on top of Linux was quite the adventure, to say the least. S.R. did some very naughty things in that code. :-) The code also compiles cleanly for the bcc/8086 target, although I don't yet have a v7 kernel to run it on yet. Cheers, Rhys. From leypold at informatik.uni-tuebingen.de Wed Feb 20 09:58:52 2002 From: leypold at informatik.uni-tuebingen.de (M E Leypold @ labnet) Date: Wed, 20 Feb 2002 00:58:52 +0100 Subject: [TUHS] v7 upgrade In-Reply-To: <200202192119.NAA21653@spies.com> References: <200202192119.NAA21653@spies.com> Message-ID: <15474.59068.85087.897739@hod.void.org> Al Kossow writes: > > There were ports of PCC to the 8086, Z8000, and 68000 done by > MIT's Laboratory for Computer Science. This might be a more > historically correct place to start. I alway wondered, wether the source of these ports is available somewhere. I bet it isn't. Regards -- Markus