TUHS

tuhs@tuhs.org

28 participants
6556 discussions

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?"

23 years, 2 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

23 years, 2 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

23 years, 2 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.

23 years, 2 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

23 years, 2 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

23 years, 2 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

23 years, 2 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.

23 years, 2 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

23 years, 2 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, 2 months

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