TUHS

tuhs@tuhs.org

47 participants
6502 discussions

FW: Missing pack from the UnixV6 distros based at the TUH site

by Gregg C Levine

Hello from Gregg C Levine normally with Jedi Knight Computers Forwarded from a posting on news:alt.sys.pdp-11 that I made. Rather then repost the entire message in perpetuity I decided to forward the whole business to this list. As I am still deciding the best way to make use of the whole file tree, without an actual machine living here, I decided to download everything to this one, and then wait. Gregg C Levine drwho8(a)att.net "How many floors does this TARDIS of yours have, anyway?" "Gregg C Levine" <drwho8(a)att.net> wrote in message news:<20020625121449.XOEM20423.mtiwmhc21.worldnet.att.net@who>... > Hello from Gregg C Levine > Has anyone actually found this to happen? The TUH ftp site, has on it, a > number of actual distributions for UNIX for the PDP-11. One of them was > assembled by Tim Shoppa from a discarded machine. They were > subsequently uploaded to that site. However on of the packs is missing. > It is this one, "xxdp_with_1123.rl02: XXDP+ on RL02 pack, bootable." > That is from the README file associated with the entire directory. > Everything else is there, that one is not. What did happen to it, I wonder. > Gregg C Levine drwho8(a)att.net > >

22 years, 11 months

Re: [pups] Real ZOO web site, welcome! ID<sxsvCplqqlh1wxkv1ruj>

by Warren Toomey

In article by Dave Horsfall: > On Mon, 24 Jun 2002, Randy Merkel wrote: > > Golly, I think we have a spammer ;) > Either he/she/it took the trouble to subscribe (few do), or the list > is wide open; if the latter, expect more crap. Open no more, and I have to approve subscriptions too :-) Warren

22 years, 11 months

RE: [pups] Real ZOO web site, welcome! ID<sxsvCplqqlh1wxkv1ruj>

by Randy Merkel

Golly, I think we have a spammer ;)

22 years, 11 months

[pups] Real ZOO web site, welcome! ID<sxsvCplqqlh1fv1dgid1r}1dx>

by Farmgirl10326

22 years, 11 months

[pups] Real ZOO web site, welcome! ID<sxsvCplqqlh1wxkv1ruj>

by Farmgirl28914

22 years, 11 months

[pups] Real ZOO web site, welcome! ID<sxsvCwxkv1ruj>

by Farmgirl28237

22 years, 11 months

Simh and networking, and any of the available 2.11BSD collections

by Gregg C Levine

Hello from Gregg C Levine I've just joined this list, so bear with me. I am developing applications that will be using the protcols covered in DECnet to access a running PDP-11 system. Actually it is running, but its a SimH program posing as a PDP-11/23. I have downloaded the boot images, especially the 2.11BSD system that is available, and booted it under the SimH simulator. Any suggestions as to how I take this one step further? This is running on both Windows, and Linux. But the DECnet programs were built on Slackware Linux. Gregg C Levine drwho8(a)worldnet.att.net "How many floors does this TARDIS of yours have, anyway?"

22 years, 11 months

[pups] bsd2.11 kernel compile

by joseph lang

I am building a PDP 11 from junked parts and have it mostly working. I'm now installing BSD 2.11 and have run into a problem i could use some help with. When compiling a new kernel (to include network) I get an error ld: too big for type 431 *** exit 2 I assume this error is due to one of the overlays being too large. (this is pointed out in the install docs) How do I figure out which overlay (or base) is the problem? The random module shuffle in the documents only has 10 million combinations and at 30 minutes to compile, well I'm not going to live that long. Is there a more scientific way to arrange the overlays? Am I missing something obvious? joe lang langj(a)bellsouth.net

22 years, 11 months

Re: [pups] bsd2.11 kernel compile

by Steven M. Schultz

Hi! > From: "Chuck Dickman" <chd_1(a)nktelco.net> I see you beat me to the answer ;) > During the compile 'size' outputs a list of the sizes of the > overlays. Look at the output. For mine.... > > > How do I figure out which overlay (or base) is the problem? > > The base must be less than 7 8k pages or 57344(decimal) bytes. > Each overlay must be less than 8k bytes or 8192(decimal). > The network code is not overlayed, so you have 8 pages or the > full 64k. And you use "size" on the .o files to see how much each object file contributes to an overlay. With the exception of a few .o files which *must* be in the base segment (and these are identified in the Makefile) anything can go anywhere it will fit. The overlay switching is extremely efficient so don't worry about the 'affinity' of modules too much. Oh, it should be mentioned that it is not legal to have an empty (0 length) overlay except at the end - i.e. you can't have overlay 3 be 0 bytes if overlay 4 or higher has nonzero size. > To make it work, just get the sizes below the limits. The > optimal arrangement would be placing the code in such that > the overlay changes were minimized. So... move your system > disk drivers into base and change the configuration to > remove any hardware you don't actually have. With the exception of perhaps the tty driver for the specific serial devices present on the system it's not worth trying to pack things "optimally". The overhead of overlays is inhererent in the function prologue and epilogue - the only extra overhead of actually switching overlays is stuffing ~two words or so into the MMU registers. DO NOT remove anything from the actual OV lines in the makefile - just make sure you define/configure devices as not being present in the config file (by saying you have 0 of them). Then the .o files do not take up any space and can be segregated into unused overlays at the end (OV9 or 10 or so). Good Luck! Steven Schultz sms(a)2bsd.com

22 years, 11 months

Re: [TUHS] Re: Porting Unix v6 to i386

by Mike Haertel

>I'll upload it soon. Meanwhile, instead of a DOS C compiler, people >should be able Bruce Evans' bcc or C86 as the compiler, which would >eventually allow the system to compile itself. The source code to the Watcom compilers has also finally been released.

22 years, 11 months

RE: [TUHS] Re: Porting Unix v6 to i386

by Ian King

I think this would be a great addition to the archive! I'm glad I didn't throw out that old 286 motherboard yet. :-) -- Ian -----Original Message----- From: Warren Toomey [mailto:wkt@minnie.tuhs.org] Sent: Tuesday, June 04, 2002 4:35 PM To: Szigeti Szabolcs Cc: tuhs(a)minnie.tuhs.org Subject: Re: [TUHS] Re: Porting Unix v6 to i386 In article by Szigeti Szabolcs: > I don't know if i can now legally give out parts of the original code, > if anyone wants to experiment with it (some parts are pretty ugly, > because i intedned to rewrite it, but never did, and the parts of the > comments are in Hungarian), drop me an email (though i'm now doing my > MBA thesis, so might not answer immediatey). If there is interest, I > can summarize my experiences. Hi, yes it's now legal to distribute your code, as Caldera's license allows for distribution of changes, see http://www.tuhs.org/Archive/Caldera-license.pdf I'm the guy who runs the Unix Archive, so I'd be very happy to take a copy of your work and add it to the archive. Cheers, Warren _______________________________________________ TUHS mailing list TUHS(a)minnie.tuhs.org http://minnie.tuhs.org/mailman/listinfo/tuhs

22 years, 11 months

Re: Porting Unix v6 to i386

by John Chung

Where can I obtain the program nowadays? It is going to be fun playing it using my x86 machine. :) __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

22 years, 11 months

Re: Porting Unix v6 to i386

by Szigeti Szabolcs

Hi folks! I've just joined your mailing list, and while looking at the archives, i saw this discussion on porting V6 to Intel. Well, back in '92, in a university scinence students' competition, I ported v6 to intel286 in protected mode. (I got second place, the winner was a 3D animation prog, which is more spectacular, than a # prompt :-) I used Borland C to compile, with some extra mungling the assembly code ( i can't remember why). The hard part was to understand the protected mode, and to write the low level stuff. Other things, like filesystem, etc. compiled with hardly any modification. (Had to change =+ to =+, introduce long insted of int[2], etc.). It has floppy, ide, kbd, parallel, serial and vga drivers. It got to full multiuser operation, but there are bugs and stupid codings certainly. The C compiler, nroff, and some other parts were not ported. (Yes, I used Borland C to compile the programs, and a tool to convert it to a.out :-) I don't know if i can now legally give out parts of the original code, if anyone wants to experiment with it (some parts are pretty ugly, because i intedned to rewrite it, but never did, and the parts of the comments are in Hungarian), drop me an email (though i'm now doing my MBA thesis, so might not answer immediatey). If there is interest, I can summarize my experiences. I've not looked it since several years, so i might not remember every detail, but there are some interesting point, and it was great fun to do. Regards, Szabolcs Szigeti

22 years, 11 months

Ken Beer/NewYork/DBNA/DeuBa is out of the office.

by Ken Beer

I will be out of the office starting 05/25/2002 and will not return until 06/06/2002. I will respond to your message when I return. I will be on vacation. My manager, Venkat Jituri has my contact information. For Equity Research issues, contact Chris Fumai. -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

22 years, 12 months

Memorial Day in uts

by Bryan Cantrill

I recently discovered your excellent site (was pre-Lions src just recently made available?), which prompted me to send the following mail out to my colleagues in Solaris Kernel Development. (Apologies in advance if you find this annoying, superfluous or disrespectful -- I thought some might find it interesting, if stupid.) If there are other kernel implementors of AT&T-derived UNIX lurking here, it would be enlightening to know what a similar comparison yields on your baby. (It should go without saying that the implementation of each mentioned function has virtually no resemblance to its V3 forebear.) And of course, my burning question: has none of us changed "/* stat codes */" in proc.h?) ------8<--------------------- Subject: Memorial Day in uts To: kernel(a)eng.sun.com All, This Memorial Day, take a moment to remember the source code that has served in our kernel since its inception. To this end, wander by http://minnie.tuhs.org/UnixTree/, and pause for a moment to commemorate these brave functions from the 101st Tapeborne -- all of which have served continuously since August, 1973: bflush() falloc() newproc() sched() bread() getblk() nodev() signal() brelse() getf() nulldev() stty() bwrite() gtty() panic() suser() clock() issig() printf() swtch() closef() mmread() psig() timeout() core() mmwrite() psignal() ufalloc() Their compatriot structure fields include: av_back b_flags p_flag u_cdir av_forw b_forw p_ppid b_back c_arg (*) p_stat b_blkno c_func (*) p_wchan (*) c_func and c_arg are notable for having survived a bonwick scorched-earth rewrite of callouts circa 1997 -- unclear if this makes them eligible for the Purple Heart, or if they should be considered acquited war criminals. As for constants, B_DONE, B_ERROR, FREAD, FWRITE, and SSLEEP have all had the same numerical value since they enlisted in 1973. And a moment of silence is certainly due to this line in proc.h -- a line which has not changed so much as a character since 1973: /* stat codes */ And to the code ripped out in the line of duty, we say only: "We Have Not Forgotten." (Of course, we usually follow that up with "Never Again.") - Bryan ---------------------------------------------------------------------------- Bryan Cantrill, Solaris Kernel Development. bmc(a)eng.sun.com (650) 786-3652

22 years, 12 months

Re: [TUHS] Re: simh vax and 4.3-quasijarus

by msokolov＠ivan.Harhan.ORG

I wrote: > the uVAX unhalt is simply an RFI: on real hardware it knows that > this RFI is an unhalt and lights the RUN LED because the SSC chip compares > instruction fetch addresses against the halt range and detects the unhalt Of course I meant REI. I was mixing VAX and PowerPC in my head again... That's what happens when you try to work on too many architectures at the same time. MS

23 years

Re: [TUHS] Re: simh vax and 4.3-quasijarus

by msokolov＠ivan.Harhan.ORG

Rico Pajarola <rp(a)servium.ch> wrote: > At this point, I am at the simh prompt (">"). I think simh catches > the halt instruction and goes to the simh prompt when it encounters > one. I have a VAX 4000/300 at home (unfortunately it doesn't run > any of the older unixes), and when it halts, I get the >>> prompt > (differs from simh). The 4000/300 works like any other uVAX (VAX processor implemented in a single IC) in this respect: a halt is a special exception that works like regular VAX macrocode exceptions except that it saves the PC and the PSL in special IPRs rather than on the stack (so that it doesn't depend on a stack), vectors to the hardwired ROM address 20040000 rather than through SCB (so that it doesn't depend on SCB), and MAPEN is cleared (so that it goes to the physical address 20040000 in the ROM rather than whatever that address may be virtually). The CPU board firmware than displays the halt message and the >>> prompt as prescribed by the VAX Architecture (DEC STD 032-0). KA650/655 works exactly the same way. While I haven't played with simh and don't intend to in the near future (due to my general lack of interest in emulators), thus I don't claim to be right here, but from your session logs it appears that simh is not doing the above uVAX halt exception but instead it handles halts like an 11/780, by "physically" stopping all instruction execution. That is fine and dandy, the 11/780 way is certainly cooler, but the problem is it ain't a KA655 any more, and one should not expect the KA655 boot ROM to work right then (and IMAO it has no right to report the KA655 SID code either). > I am pretty sure that I have configured simh correctly, I verified > this by installing netbsd on the same setup, and it boots ok. When I took a cursory look at SIMH/VAX, which consisted only of glancing at its brief documentation, I read that the KA655 ROM image it comes with is not the real one but hacked to work with the poor emulator. This suggests to me that you are able to boot some OSes because Bob has gutted the (quite complicated) KA655 console and boot logic to the bare minimum he had emulated. I wouldn't be surprised if he hacked out the KA655 diagnostic executive almost entirely, so that on "power-up" one goes through an absolutely minimal init sequence without a single halt/unhalt cycle occuring (of which on a real KA655 several occur on every power-up during diagnostics), gets to the >>> prompt, and then when booting, runs VMB, unhalts once (the SIMH probably doesn't even know that it unhalts, as the uVAX unhalt is simply an RFI: on real hardware it knows that this RFI is an unhalt and lights the RUN LED because the SSC chip compares instruction fetch addresses against the halt range and detects the unhalt, but I doubt that SIMH emulates this), and then it all goes well (cross your fingers three times!) never goes through a proper KA655 halt/unhalt again. But if something goes wrong in the boot and VMB's error handler gets invoked, SIMH's very poor man's emulation is not prepared for it. > My only problem seems to be getting the bootblocks right. I have > heard that someone managed to install quasijarus0a on simh, so it > must be me somehow screwing the bootblocks. But the rub is that because of SIMH talking the KA655 talk but not walking the KA655 walk, you can't see what exactly is the problem with your bootblocks: VMB's error messages aren't displayed. MS

23 years

Re: [TUHS] simh vax and 4.3-quasijarus

by Rico Pajarola

is there anybody who has successfully installed 4.3-quasijarus on simh, who could tell me how to install the bootblocks (I am not completely sure that I got the disklabel right). The exact incantation of installboot and the output of disklabel would be very helpful. Rico Pajarola

23 years

Re: simh vax and 4.3-quasijarus

by Rico Pajarola

From: Gunther Schadow <gunther(a)aurora.regenstrief.org> >>> >>> 2.. >>>-DUA0 >>>HALT instruction, PC: 00000C1A (MOVL (R11),SP) > >this suspiciously looks as if the HALT is from SIMH not from the >VAX it simulates. There are two halt levels in SIMH, one being >the VAX halting and going into VAX console mode, the other being >SIMH halting. Are you absolutely sure that you have a proper >VAX console with SIMH? You should get normal VAX console >behavior, try a few commands and see whether you're on the right >page. At this point, I am at the simh prompt (">"). I think simh catches the halt instruction and goes to the simh prompt when it encounters one. I have a VAX 4000/300 at home (unfortunately it doesn't run any of the older unixes), and when it halts, I get the >>> prompt (differs from simh). >Also, be sure you have it all configured right, that you have >the right devices defined and properly associated with files >on the hosting OS etc. I am pretty sure that I have configured simh correctly, I verified this by installing netbsd on the same setup, and it boots ok. My only problem seems to be getting the bootblocks right. I have heard that someone managed to install quasijarus0a on simh, so it must be me somehow screwing the bootblocks. >> This seems like a simh problem, or, more probably since you can boot That Other >> OS successfully, a problem with your installation of 4.3BSD-Quasijarus0a masked >> by a simh problem. the problem is with the bootloader only, quasijarus0a runs well once booted using the netbsd bootloader. >I would agree. What other system can you boot on SIMH? only netbsd and quasijarus0a (I don't have any vms media). thanks for your help Rico Pajarola

23 years

Interview ASAP

by sadams＠resumeship.com

23 years

Re: [TUHS] simh vax and 4.3-quasijarus

by msokolov＠ivan.Harhan.ORG

Rico Pajarola <rp(a)servium.ch> wrote: > I installed 4.3-quasijarus on simh [...] > I have been unable to boot it directly from it's 'own' > filesystem. > > here's what I see, complete transcript at the end > > >>>boot dua0 > > (BOOT/R5:0 DUA0) > > > > > > > > 2.. > > -DUA0 > > HALT instruction, PC: 00000C1A (MOVL (R11),SP) My ability to help you here will be limited because you are using simh rather than a real VAX. The real KA655 console ROM does not issue halt messages like the above, its halt message have a different form (the one prescribed by DEC STD 032-0, VAX Architecture Standard). The last message above does not exist on any real VAX made by DEC. > that's obviously not what I want. I tried all combinations of > installboot and disklabel -B I can think of, both in netbsd and > quasijarus, and all lead to the same result. > > Can anybody tell me the exact incantations necessary to install > the bootblocks for quasijarus0a [...] This seems like a simh problem, or, more probably since you can boot That Other OS successfully, a problem with your installation of 4.3BSD-Quasijarus0a masked by a simh problem. You've got a halt inside VMB that happened after VMB had successfully opened the boot device but before it accepted a valid bootblock. What happens on a real KA655 is as follows: the console copies VMB from the EPROM to RAM and transfers control to it, which is accompanied by the display of 2.. on the console and on the CPU module LEDs. At that point the VAX is unhalted, i.e., the RUN indicator on the front panel lights up. VMB thus runs as user code and tries to perform the bootstrap. As VMB successfully opens the boot device using its built-in drivers, it displays the device name in VMS format on the console. Then if it finds and accepts a valid bootblock it displays 1.. on the console and on the CPU module LEDs. Finally it transfers control to the bootblock accompanied by 0.. display. If something goes wrong and VMB gives up, it prints its own error message on the console and then executes a HALT instruction to return to the console prompt. The HALT instruction halts the VAX (the RUN indicator on the front panel goes out) and invokes the console, which prints the halt message followed by the >>> prompt as prescribed by DEC STD 032-0. It looks like you are seeing VMB fail for some reason and halt, giving you the (not compliant with DEC STD 032-0) halt message from simh. However, you are not seeing VMB's error message which on a real KA655 will always appear before the halt message from the console. This is a simh problem, it obviously does not fully and properly emulate the real KA655 here. I cannot help you past this point as I only support real VAX hardware. There is probably something wrong with your bootblock as your emulated VAX's VMB is not accepting it while accepting the one on DUA1 from That Other OS, but your poor emulator prevents you from seeing what the problem is. > So far I have not been able to boot any other VAX operating system > from the TUHS archive, the netbsd bootloader cannot load ultrix32m, > 32v and 3bsd. I don't know / don't care much about That Other OS and its bootloader, but the format of the VAX unix/vmunix kernel image and its boot interface has remained absolutely unchanged from 32V through 4.3BSD-Quasijarus0a inclusive (but see below about VAX model support). DEC has extended the boot interface in Ultrix, but it's completely backward compatible: as the Ultrix bootloader starts the kernel with a calls instruction, it passes one argument (calls $1) whereas traditional Bell/Berkeley UNIX had zero (calls $0). A traditional kernel will simply ignore this argument, while the Ultrix kernels checks for its presence (thanks to the wonderful VAX architecture and its procedure call standard that allows a procedure to determine its argument count) and lives without it if it's absent. (That argument is a pointer to a structure with useful info, however, and I plan to adopt this extension in 4.3BSD-Quasijarus1.) > I have not yet had time to try any of the other 4.x > bsds, but I assume they'd have the same problem as quasijarus0a. 4.3BSD-Quasijarus0 was the first release to support KA650/655, so don't bother trying earlier ones. (Although you could try 4.3-Reno if that's what you like.) > I don't > have ultrix/vax media to do it right You can get the complete TK50 distribution (tape images) of Ultrix V4.00 for VAX on my FTP site ivan.Harhan.ORG in /pub/UNIX/thirdparty/Ultrix-32. I have full sources for it there too. > Ultrix 4.3 gives me: > > 466788+254256+177476+[36984+34990] total=0xecfa2 OK, so the kernel has been loaded successfully. > > machine check 82: vap 82000004 istate1 7c000c00 istate2 c070fe pc 80001c61 psl 41f0008 > > r0=8000000c, r1=8000167c, r2=0, r3=211bd0dd, r4=0, r5=dd274 > > panic: mchk Since Ultrix V4.3 perfectly supports the KA655 CPU, this again must be a case of simh misemulating it. My advice to you is to get a real VAX. MS P.S. You may want to subscribe to the Quasijarus mailing list, send a request to quasijarus-request(a)ifctfvax.Harhan.ORG.

23 years

simh vax and 4.3-quasijarus

by Rico Pajarola

I installed 4.3-quasijarus on simh, and I managed to boot indirectly by putting the kernel as /quasijarus0a in the netbsd root filesystem, and then booting it from the netbsd bootloader with 'boot quasijarus0a -a'. I have been unable to boot it directly from it's 'own' filesystem. here's what I see, complete transcript at the end > >>>boot dua0 > (BOOT/R5:0 DUA0) > > > > 2.. > -DUA0 > HALT instruction, PC: 00000C1A (MOVL (R11),SP) that's obviously not what I want. I tried all combinations of installboot and disklabel -B I can think of, both in netbsd and quasijarus, and all lead to the same result. Can anybody tell me the exact incantations necessary to install the bootblocks for quasijarus0a, or does anybody who has installed quasijarus0a have a session transcript? any idea what I might be doing wrong? So far I have not been able to boot any other VAX operating system from the TUHS archive, the netbsd bootloader cannot load ultrix32m, 32v and 3bsd. I have not yet had time to try any of the other 4.x bsds, but I assume they'd have the same problem as quasijarus0a. I have tried ultrix-4.3 (also from the netbsd bootloader, I don't have ultrix/vax media to do it right), but it does not work either. If anybody can help me with this, thanks in advance Rico Pajarola The following transcript shows how I boot it (first the way it fails, then the way it works): > VAX simulator V2.9-9 > sim> show c > VAX simulator configuration > > CPU, 32768KB > TLB, 2 units > TLB0, 8KW > TLB1, 8KW > ROM, 128KB > NVR, 1KB > SYSD, 2 units > SYSD0 > SYSD1 > QBA > TTI > TTO > CSI > CSO, not attached > CLK > PTR, address=20001F68-20001F6F, not attached > PTP, address=20001F68-20001F6F, not attached > LPT, address=20001F4C-20001F4F, not attached > RQ, address=20001468-2000146B, 4 units > RQ0, 159334KB, attached to 4.3-quasijarus0a.rd54.dsk, write enabled, RD54 > RQ1, 622932KB, attached to ../netbsd-vax/netbsd-vax.ra82.dsk, write enabled, RA82 > RQ2, 409KB, not attached, write enabled, RX50 > RQ3, 409KB, not attached, write enabled, RX50 > RL, disabled > TS, disabled > DZ, disabled > sim> boot cpu > > > 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 > HALT instruction, PC: 00000C1A (MOVL (R11),SP) > >>>boot dua1 > (BOOT/R5:0 DUA1) > > > > 2.. > -DUA1 > 1..0.. > > > >> NetBSD/vax boot [Aug 19 2001 05:57:49] << > >> Press any key to abort autoboot 3 > > boot quasijarus0a -a > 327204+103384+130352+[29436+24084] total=0x96220 > 4.3 BSD Quasijarus UNIX #0: Sat Oct 2 22:15:38 CDT 1999 > msokolov@luthien:/usr/src/sys/GENERIC > real mem = 33521664 > SYSPTSIZE limits number of buffers to 80 > avail mem = 31697920 > using 80 buffers containing 655360 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: RD54, size = 311200 sectors > ra1 at uda0 slave 1: vaxnetbsd, size = 1216665 sectors > ra2 at uda0 slave 2: floppy > ra3 at uda0 slave 3: floppy > lp0 at uba0 csr 177514 vec 200, ipl 14 > root device? ra0 > WARNING: clock gained 14 days -- CHECK AND RESET THE DATE! > erase ^?, kill ^U, intr ^C > # from this point on, it works as expected. Ultrix 4.3 gives me: > 466788+254256+177476+[36984+34990] total=0xecfa2 > machine check 82: vap 82000004 istate1 7c000c00 istate2 c070fe pc 80001c61 psl 41f0008 > r0=8000000c, r1=8000167c, r2=0, r3=211bd0dd, r4=0, r5=dd274 > panic: mchk > > dumping to dev ffffffff, offset 0 > dump machine check 80: vap 78302077 istate1 fb000c00 istate2 c070fd pc 8004eb57 psl 41f0000 > r0=78302073, r1=0, r2=0, r3=211bd0dd, r4=22, r5=80 > panic: mchk > > HALT instruction, PC: 8000165B (XFC)

23 years

Re: [pups] Re: GCC

by norman＠nose.cs.utoronto.ca

Jonathan Engdahl: Consider lcc, the Princeton C compiler. It's much smaller than gcc, and ANSI compliant. lcc's a good compiler; it has become cc in my own peculiar Ancient UNIX environment. But my environment is on VAXes, not PDP-11s; the lcc I use probably cannot be compiled to a core compiler binary of less than about 180KB, of which 136KB is text, and that is without any real code generators. (For those who know lcc: I am using a slightly-hacked-up lcc 3.6; the 180KB binary includes just the symbolic and null code generators, not the enormous one I ended up with for the VAX.) On the other hand, it is probably easier to split lcc into overlays or multiple passes to make it fit on a PDP-11 than to do the same to gcc; and lcc works fine as a cross-compiler. And it's a good solid ANSI compiler; enough so that it is a little annoying to use it on heritage code (it grumbles, correctly, if a function returns no value and wasn't declared void), and helpful or very painful (depending on your point of view) when used on really old code that is sleazy about mixing types of pointers in procedure arguments, or reusing one structure as part of another, or the like. I had an interesting time a few months ago getting an old version of tbl to compile cleanly and produce correct results under lcc; the program contained some ancient constructs that are truly remarkable to look back on, especially for those of us who started out programming that way and learned better the hard way ... If I were going to work with PDP-11s, I would probably use lcc as a cross-compiler myself, after writing or snitching a code generator of course. Norman Wilson

23 years

Re: [TUHS] ancient unix filesystems --- on current Unix implementations

by Chuck Dickman

Does anyone know how many of the V5, V6, V7, 2BSD, 2.11BSD, etc. filesystems are implemented in some current unix implementations, NetBSD, Linux, etc. Seems like that could be useful when playing with simh. -chuck

23 years

Re: ancient unix filesystems

by Stuart Norris

On Mon, 6 May 2002 tuhs-request(a)minnie.tuhs.org wrote: > From: Warren Toomey <wkt(a)minnie.tuhs.org> > > Sven, you might want to look at this: > http://minnie.tuhs.org/cgi-bin/pups.cgi?article=2170 > > From: Stuart Norris <norris(a)euler.mech.eng.usyd.edu.au> > > I have hacked together a version of a Unix 5th (and 6th) > Edition filesystem for Linux. It is read only, and was written for > Linux 2.0 on an x86 and so will require a little work to install on > other systems and newer kernels, but it is fun to be able to mount > old disk images. The source code is sitting on http://www.esc.auckland.ac.nz/People/Staff/Norris/src/u5e-0.2.tar.gz and the INTRO file contains a description of the filesystem. I don't think it works with current Linux kernels (I havn't touched it for a long while), so it might be easiest to start afresh using the minix filesystem module as a start. Briefly, the filesystem is like -- * Block size: 512 * General layout: Block 0 boot block Block 1 super block Blocks 2 -> isize-1 inodes Blocks isize -> fsize-1 data blocks * Byte ordering of "short" (16 bit entities) is little endian 0 1 * Byte ordering of "long" (32 bit entities) is PDP-11 2 3 0 1 * Inode on disk: "short" 0 means non-existent 1 root dir * Maximum number of hard links to a file: 256 * Super-block location: bytes 512-1023 * Super-block layout: unsigned short s_isize; /* size in blocks of I list */ unsigned short s_fsize; /* size in blocks of entire volume */ unsigned short s_nfree; /* number of in core free blocks (0-100) */ unsigned short s_free[100]; /* in core free blocks */ unsigned short s_ninode; /* number of in core I nodes (0-100) */ unsigned short s_inode[100];/* in core free I nodes */ char s_flock; /* lock during free list manipulation */ char s_ilock; /* lock during I list manipulation */ char s_fmod; /* super block modified flag */ char s_ronly; /* mounted read-only flag */ unsigned long s_time; /* current date of last update */ * Inode layout: unsigned short i_mode; /* access permissions */ unsigned char i_nlink; /* number of links to file */ unsigned char i_uid; /* owner */ unsigned char i_gid; /* group */ unsigned char i_size0; /* size of file */ unsigned short i_size1; unsigned short i_addr[8];/* address of blocks */ unsigned long i_atime; /* time of last access */ unsigned long i_mtime; /* time of last modification */ * Regular file data blocks are organized as if (010000 bit set) the file is large: i_addr[] contains indirect blocks else the file is small: * Inode size 32, 16 inodes per block * Directory entry on disk unsigned short inode; char name[14]; * Dir entry size 16, 32 dir entries per block * There are no symbolic links -- Stuart Norris s.norris(a)auckland.ac.nz Bioengineering Institute, University of Auckland hm: +(64 9) 307 0006 http://www.esc.auckland.ac.nz/People/Staff/Norris wk: +(64 9) 373 7599 x3055

23 years

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS