In article by Sven Dehmlow:
> Hi Warren,
> I can't find the port [of V6 to the 286] in the archives.
> Am I'm too stupid to search or haven't you added it yet?
> Sven
My apologies, I had forgotten to import it. It's now available
at http://www.tuhs.org/Archive/Other/V6on286
with the mirror sites to follow soon.
Cheers,
Warren
Hi -
> From: Warren Toomey <wkt(a)minnie.tuhs.org>
> In article by Greg 'groggy' Lehey:
> > The big issue is address space. It's difficult enough shoehorning
> > 2.11BSD onto the PDP-11. It's well-nigh impossible to retrofit 32 bit
> > operating systems. But Steven M. Schulz will doubtless give you a
> More specifically, the issue is data space. Using overlays, you can
> have a process with more than 64Kbytes of instruction space on a PDP-11,
> but the maximum data space that a process can have is 64Kbytes.
>
> The kernel is in a similar situation, but with some PDP-11 models
> there is kernel mode and supervisor mode, giving you two separate
> 64Kbytes instruction + 64Kbytes data address spaces (and overlays
> to increase the I space).
>
> I can't see Linux fitting into 128K of data space, and GCC is definitely
> out of the question. Besides, 2.11BSD already looks pretty close to 4BSD :-)
Well said Warren.
The D (data) space is the most severe constraint on adding any new
feature to 2.11BSD. Besides, as Warren mentioned, most of 4.3BSD
as well as a few bits&pieces of 4.4 are already present.
A couple years ago I toyed with the idea of porting over the 4.4BSD
tty subsystem (it'd be real nice to have termios and 8bit clean
serial line handling). The 'struct tty' almost tripled in size! Even
doing major surgery and leaving out a couple less useful capabilities
the growth in 'struct tty' exceeded what is left available in 2.11's
kernel D space.
Oh, I should point out the limit for the kernel's D space is even lower
than the 64KB mentioned. Of that 64KB the I/O page has to, of course,
be mapped in at all times or the kernel wouldn't have access to the
memory management registers, device registers, and so on. Then
the kernel has to have access to 'struct u' (the per process context
area - part of the address space is also where the kernel stack is
kept). So, 64 - 8 - 8 = 48. The kernel has a total of 48KB of
data space to use.
There are a few "tricks" that are played. Some data structures are
allocated external to the kernel's D space. That data is mapped in
as needed. Slows things down of course since it does take a number
of instructions to save the current memory manangement status, change it
to access the external data, fetch the data, restore the mmu registers.
Things such as the 4.3BSD disc quota system were implemented this way.
There is at the present time an absolute maximum on the size of the
I (instruction/text) space of 56K + (15*8)KB or 176KB (base segment of
56KB and 15 overlays of 8KB each. At present, depending on how many
drivers and so on are configured, about 9 or 10 overlays are used to
build a 2.11 kernel. The actual limit of kernel size that can be
booted is a bit lower due to how the boot process functions - in order
to simplify the memory manangement during booting the boot code
relocates to 192KB. The sum of the kernel text plus initialized data
(but not the .bss segment) can not exceed 192KB or the boot code will
be overwritten. Another complicating factor comes from UMR (Unibus
Mapping Registers) handling - if the boot code ever runs above 256KB
then UMR handling would have to be done by the boot code on UNIBUS
machines (Qbus machines of course don't have this problem since they
don't have UMRs to contend with).
GCC (all of the GNU stuff actually) was written with, I believe,
"malloc aforethought" ;) It's outright hostile to 16 bit machines.
There might be a few bytes free to add a feature or two to 2.11BSD
but much more than that would mean a lot of work to come up with some
free D space for the data structures that would be needed.
Cheers,
Steven Schultz
sms(a)2bsd.com
Hello from Gregg C Levine
I've got a question for those of you, who work more in that field then I.Has
anyone successfully gotten, say, NetBSD, or anything along the lines of the
4.4 series to run on a PDP-11? Granted I don't think it would work there,
because of the way its hardware was constructed. Or for that matter, say
Linux? Since the Simh collection builds easily on Linux, I was thinking that
it would be relatively simple to do so.
Gregg C Levine drwho8(a)worldnet.att.net
"How many floors does this TARDIS of yours have, anyway?"
Hello from Gregg C Levine
The web site links, that contain the SCO location, now point to a site on
Caldera's site. I tried e-mailing someone via their contacts page, but so
far to no avail. Has anyone on the list had any favorable response,
regarding the ability to access their archives of the older versions of
UNIX? As always, I am interested in the versions of UNIX that are targeted
towards the PDP-11. Seriously though, has anyone actually gotten any
feedback from Caldera? Warren if you want to comment, please do so, and I'll
even accept a private one.
Gregg C Levine drwho8(a)worldnet.att.net
"How many floors does this TARDIS of yours have, anyway?"
Gregg C Levine:
>gotten the distribution to boot, using a version of Simh? A text file of
>commands to be fed to the Simh program would be a great help.
Here is a transcript:
PDP-11 simulator V2.9-10
sim> set rl0 rl02
sim> show rl0
RL0, 5242KW, not attached, write enabled, RL02
sim> att rl0 unix_v6.rl02
sim> show rl0
RL0, 5242KW, attached to unix_v6.rl02, write enabled, RL02
sim> boot rl0
!unix
unix v6 11/23
mem = 99 KW max = 63
#
Good Luck,
Wolfgang
Gregg C Levine:
>gotten the distribution to boot, using a version of Simh? A text file of
>commands to be fed to the Simh program would be a great help.
Here is a transcript:
PDP-11 simulator V2.9-10
sim> set rl0 rl02
sim> show rl0
RL0, 5242KW, not attached, write enabled, RL02
sim> att rl0 unix_v6.rl02
sim> show rl0
RL0, 5242KW, attached to unix_v6.rl02, write enabled, RL02
sim> boot rl0
!unix
unix v6 11/23
mem = 99 KW max = 63
#
Good Luck,
Wolfgang
Hello from Gregg C Levine
Thank you for your kind advice, Warren. However, I have tried most of the
other members of that directory, and yes, it does work. I am curious about
this one, because it appears to be decidely different then say an actual
distribution of V6. I am also looking at the ones that came from the
Research area.
Gregg C Levine drwho8(a)worldnet.att.net
"How many floors does this TARDIS of yours have, anyway?"
----- Original Message -----
From: "Warren Toomey" <wkt(a)minnie.tuhs.org>
To: "Gregg C Levine" <drwho8(a)worldnet.att.net>
Sent: Sunday, June 30, 2002 8:09 AM
Subject: Re: [TUHS] The Tim Shoppa distribution of V6
> In article by Gregg C Levine:
> > On the FTP site, is a a V6 distribution contributed by Tim Shoppa. It is
> > created for the PDP-11/23, and there is a good readme.txt file that
explains
> > the different images, and how they got there. However, has anyone
actually
> > gotten the distribution to boot, using a version of Simh? A text file of
> > commands to be fed to the Simh program would be a great help.
> > I have mine, built using the MingW compiler, and this is version 2.9-10.
> > Also, if anyone has gotten it to boot on real hardware, that would a be
a
> > great plus.
>
> Gregg, I'd first try the other V6 boot images found in:
>
> http://www.tuhs.org/Archive/PDP-11/Boot_Images
>
> e.g v6_rl02_unknown.gz
>
> to make sure that they will boot with the Supnik emulator.
> You might also find that the Supnik emulator can't emulate
> an 11/23. So I would also try the Ersatz emulator and set
> it's CPU to be a 23.
>
> In other words, try a known bootable image first, then
> try Ersatz-11 as an 11/23 on that same bootable image,
> and then try Tim Shoppa's image.
>
> Warren
>
Hello again from Gregg C Levine
On the FTP site, is a a V6 distribution contributed by Tim Shoppa. It is
created for the PDP-11/23, and there is a good readme.txt file that explains
the different images, and how they got there. However, has anyone actually
gotten the distribution to boot, using a version of Simh? A text file of
commands to be fed to the Simh program would be a great help.
I have mine, built using the MingW compiler, and this is version 2.9-10.
Also, if anyone has gotten it to boot on real hardware, that would a be a
great plus.
Gregg C Levine drwho8(a)worldnet.att.net
"How many floors does this TARDIS of yours have, anyway?"
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
>
>
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
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?"
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
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
>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.
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
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
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
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.
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
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
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
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
