Help!

Help!

[Broadway, Rusel]

Hi.

I have been given a Bull DSP 2/300 system. The machine is running B.O.S.
version 02.00.12. The machine boots and runs fine and I cal login as Root
and look around the system. The problem I have is that the B.O.S. operating
system is a Unix look-a-like and I can find no-one who actually knows
anything about the box. Most Unix commands work but, being a VMS guy, I
can't run the machine like my Digital MV 2's. Does anyone know anything
about these machines? I particularly want to have a bash at programming the
machine. It appears to have C (This should be fun. I've not touched C for 12
years!)

Also. I have two Digital Micro Vax 2's. The both have hardware problems in
that a) One machine has a system disk which will not come up to speed and b)
The other has a corrupted system_primitives.exe on VMS 5.5-H and so I can't
run either of them! Anyone know where I can get spares which are pre-loaded?

I really would appreciate any help or advice/ pointers etc that anyone can
give.

Rusel Broadway
Senior Systems Analyst

DDI: 01206-25-5745

********************** N O T I C E *********************************

This information transmitted is intended only for the person or entity
to which it is addressed and may contain confidential and/or privileged
material. Any review , retransmission, dissemination or other use of,
or taking of any action in reliance upon, this information by persons
or entities other than the intended recipient is prohibited.

If you received this error, please contact the sender and delete all
copies of the message.

This footnote also confirms that this email message has been swept for
the presence of computer viruses, however we cannot guarantee that this
message is free from such problems.

**********************************************************************

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id FAA17930
	for pups-liszt; Sun, 17 Oct 1999 05:02:44 +1000 (EST)
Received: from finch-post-12.mail.demon.net (finch-post-12.mail.demon.net [194.217.242.41])
	by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with ESMTP id FAA17926
	for <pups at minnie.cs.adfa.edu.au>; Sun, 17 Oct 1999 05:02:35 +1000 (EST)
Received: from simul8.demon.co.uk ([212.228.120.103])
	by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1)
	id 11cZ66-000Dz5-0C
	for pups at minnie.cs.adfa.edu.au; Sat, 16 Oct 1999 19:02:30 +0000
Message-ID: <3808CDC7.210BC969 at simul8.demon.co.uk>
Date: Sat, 16 Oct 1999 20:11:03 +0100
From: James Lothian <simul8@simul8.demon.co.uk>
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en,ja
MIME-Version: 1.0
To: pups at minnie.cs.adfa.edu.au
Subject: Re: vtserver
References: <199910141836.LAA21478 at moe.2bsd.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-pups at minnie.cs.adfa.edu.au
Precedence: bulk

Hmm.. I seem to remember, from when I was thinking about rolling my own 
11 OS a few years ago, that the /34 differs from most of the other
mid-range
11s in automatically restoring the CPU registers on a page fault. I
think I
picked this up from the differences table in the /04, /34 & /60 CPU
handbook.
(This was unfortunately no use at all to me, as I've got a /40 not a
/34.) 

Of course, that was a while ago and I might be wrong.

James

"Steven M. Schultz" wrote:
> 
> Hi -
> 
> > From: Wilko Bulte <wilko at yedi.iaf.nl>
> 
>         I will be doing some more research on this when I get home from
>         work tonight.
> 
> > I once had Ultrix-11 3.1 running on a dual RK05 11/34. What I'd call a
> > very minimal system ;-) But it ran
> 
>         That is because DEC put the extra effort into supporting non-split I/D
>         machines.  The "stock" V7 really wanted a 11/70.  In fact there was a
>         chapter in the back of one of the manuals/books detailing what it took
>         to get V7 running on an 11/40 (it was a non-trivial project).
> 
>         Several things conspire against V7 and later on 11/34 (or 35, 40, 60,
>         etc).  The two most notable ones are the limited address space,
>         everything (drivers, data structures, general kernel code) must fit
>         in 56kb instead of 120kb - (8kb reserved for the I/O page) and lack
>         of instruction restart on MMU faults.
> 
>         I'll take a look at the V7 layout later but my memory is that it
>         wanted an 11/70.
> 
>         Steven Schultz


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id FAA18139
	for pups-liszt; Sun, 17 Oct 1999 05:47:02 +1000 (EST)
Received: from moe.2bsd.com (0 at MOE.2BSD.COM [206.139.202.200])
	by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with ESMTP id FAA18135
	for <pups at minnie.cs.adfa.edu.au>; Sun, 17 Oct 1999 05:46:53 +1000 (EST)
Received: (from sms at localhost)
	by moe.2bsd.com (8.9.0/8.9.0) id MAA18843
	for pups at minnie.cs.adfa.edu.au; Sat, 16 Oct 1999 12:42:14 -0700 (PDT)
Date: Sat, 16 Oct 1999 12:42:14 -0700 (PDT)
From: "Steven M. Schultz" <sms@moe.2bsd.com>
Message-Id: <199910161942.MAA18843 at moe.2bsd.com>
To: pups at minnie.cs.adfa.edu.au
Subject: Re: vtserver
Sender: owner-pups at minnie.cs.adfa.edu.au
Precedence: bulk

Hi -

> From: James Lothian <simul8 at simul8.demon.co.uk>
> 
> Hmm.. I seem to remember, from when I was thinking about rolling my own 
> 11 OS a few years ago, that the /34 differs from most of the other
> mid-range 11s in automatically restoring the CPU registers on a page fault. I

	It's not the automatically restoring that is the problem - the /34, /40
	(/60, etc) lack the MMU registers that record by how much the cpu
	registers have incremented/decremented at the time an instruction has
	faulted. SSR1 and SSR2 located at 0177574 and 0177576 respectively.

	From the module which handles the instruction restart (mch_backup.s):

* 11/40 version of backup, for use with no SSR1 and SSR2.  Actually SSR1
* usually exists for all processors except the '34 and '40 but always
* reads as zero on those without separate I&D ...

	What is a dozen lines of code if those registers exist turns into
	over 300 lines and even then there is no guarantee (fortunately the
	C compiler does not generate the sequences that can not be handled)
	it will work.

	What's instruction restart used for?  The most common case is growing
	the stack.  The stack for a process starts out small and then kernel
	will automatically extend it downwards IF an instruction faults when
	accessing the stack area:


		sub	$N,sp
		mov	$xxx, XX(sp)
		mov	-(r4), X(sp)

	for dealing with local variables in a function.  The other case
	is when calling a function:

		mov	(r0)+, -(sp)
		mov	$xxx, -(sp)
		jsr	pc, function

	If the reference to (sp) is made and the instruction faults the
	kernel will determine if the current stack needs to be extended.  It
	will then restart the faulted instruction - but to do that it needs
	to know what other registers ('r0', 'r4', etc...) might have been
	already changed so that it can back out those changes before 
	restarting the instruction.

	In the case of the 11/44, 70, 73, etc there are MMU registers that
	will record the fact that "R0" or "r4" or whatever was changed by
	2 or not.  On the /34 and /40 that capability does not exist and
	the kernel can not _always_ guarantee things will work.  MOST of the
	time it will but...

	Interestingly enough there is a difference between the KDJ-11 (11/73)
	family and the other 11s which have the SSR1, and 2.   From the
	bug report and fix for 2.11BSD (update #150):

	"The problem  is that the KDJ-11 processes the double word store
        of the 'movfi' differently than the 11/44 or 11/70.  On other
        systems (such as the 11/44) the first word is stored successfully
        at 0175000 then the program faults when trying to access 0174776
        but SP is left at 0174776 with SSR1 (memory management
        status register 1) indicating that 'sp' was decremented by 4.  The
        kernel adjusts 'sp', grows the stack and restarts the instruction.
        The 'movfi' then completes successfully.

        On a KDJ-11 cpu the story is different.  The fault is generated
        as expected BUT 'SP' IS STILL 0175002!  The kernel sees that 'sp'
        is still within the "valid stack region" and DOES NOT grow the
        stack at all.   SSR1 indicates that no registers were modified
        so the kernel does no adjustment of 'sp'.  The instruction is
        NOT restarted and a SIGSEGV signal is sent to the program.

        The problem appears to be only when doing FP instructions, fixed point 
        operations do not experience any difficulty.  The instruction
        "cmp -(sp),-(sp)" for example is handled correctly."

	Steven Schultz
	sms at moe.2bsd.com

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id GAA18253
	for pups-liszt; Sun, 17 Oct 1999 06:08:29 +1000 (EST)
Received: from moe.2bsd.com (0 at MOE.2BSD.COM [206.139.202.200])
	by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with ESMTP id GAA18248
	for <pups at minnie.cs.adfa.edu.au>; Sun, 17 Oct 1999 06:08:01 +1000 (EST)
Received: (from sms at localhost)
	by moe.2bsd.com (8.9.0/8.9.0) id NAA19063
	for pups at minnie.cs.adfa.edu.au; Sat, 16 Oct 1999 13:07:04 -0700 (PDT)
Date: Sat, 16 Oct 1999 13:07:04 -0700 (PDT)
From: "Steven M. Schultz" <sms@moe.2bsd.com>
Message-Id: <199910162007.NAA19063 at moe.2bsd.com>
To: pups at minnie.cs.adfa.edu.au
Subject: Re: vtserver
Sender: owner-pups at minnie.cs.adfa.edu.au
Precedence: bulk

> From: Warren Toomey <wkt at cs.adfa.edu.au>
> > To: Kirk Davis <kbd at ndx.net>
> > Do you know of anyone that has used it on a /34? I've punched in the
> > bootstrap and ran it. It loads the boot file from my Linux system.
> > It appears to call it but it halts somewhere in the 70000-70040 region.
> > Nothing comes up on the console. Looks like the memory is over written 
> > with the same values over and over again in this area. Any thoughts?
> > 
> Sorry for the delay Kirk. It could be that the V7 bootstrap expects
> split I/D, or a different I/O mapping then what's provided on the /34.
> 
> I'll punt this to the PUPS mailing list. I have a suspicion that
> you won't be able to install V7, but you should be able to install V6
> or 2.9BSD instead.

	I _think_ I know what the problem is...

	While the /34 (and /40, etc) can run a stripped down V7 (the necessary
	mch.s code exists for example) the kernels that come with the 
	distribution are split I&D kernels.  /hptmunix, etc are all split I/D
	executables.   Thus you'll be able to toggle in the bootstrap and
	get /boot loaded but then fault when loading and/or trying to execute
	the kernel.

	As I recall the usual way to get Unix on to a /23, 34,etc was to
	have a 11/70 around to do the build on, then stage/create the media
	(usually an RL02 or similar) on the 70 and sneakernet the pack over
	to the /34.

	At least that is how it was done when we shoehorned V7 into an 11/23.
	Of course we "cheated" in that we had a fellow around who made the
	necessary changes to the assembler/compiler/linker to handle kernel
	overlays (preceeded the use of them in 2BSD by several years).  Thus
	we could run a larger kernel than a pure/stock V7.  It was an
	"interesting" experience running V7 on an 11/23 (maxed out with 248kb
	of memory which was fairly expensive at the time).   There was just
	enough memory left after the kernel was loaded for a couple user 
	processes.  Thus as the '#' prompt you would run "ls" the shell ('sh')
	would get swapped out, the 'ls' would run, and then 'sh' would get
	swapped back in.   Uh, slowed things down just a _little_ bit :-)

	Steven Schultz
	sms at moe.2bsd.com