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@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(a)minnie.cs.adfa.edu.au>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(a)minnie.cs.adfa.edu.au; Sat, 16 Oct 1999 19:02:30 +0000 Message-ID: <3808CDC7.210BC969(a)simul8.demon.co.uk> Date: Sat, 16 Oct 1999 20:11:03 +0100 From: James Lothian <simul8(a)simul8.demon.co.uk> X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en,ja MIME-Version: 1.0 To: pups(a)minnie.cs.adfa.edu.au Subject: Re: vtserver References: <199910141836.LAA21478(a)moe.2bsd.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pups(a)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: Received: (from major@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(a)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(a)minnie.cs.adfa.edu.au>au>; Sun, 17 Oct 1999 05:46:53 +1000 (EST) Received: (from sms@localhost) by moe.2bsd.com (8.9.0/8.9.0) id MAA18843 for pups(a)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(a)moe.2bsd.com> Message-Id: <199910161942.MAA18843(a)moe.2bsd.com> To: pups(a)minnie.cs.adfa.edu.au Subject: Re: vtserver Sender: owner-pups(a)minnie.cs.adfa.edu.au Precedence: bulk Hi - 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(a)moe.2bsd.com Received: (from major@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(a)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(a)minnie.cs.adfa.edu.au>au>; Sun, 17 Oct 1999 06:08:01 +1000 (EST) Received: (from sms@localhost) by moe.2bsd.com (8.9.0/8.9.0) id NAA19063 for pups(a)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(a)moe.2bsd.com> Message-Id: <199910162007.NAA19063(a)moe.2bsd.com> To: pups(a)minnie.cs.adfa.edu.au Subject: Re: vtserver Sender: owner-pups(a)minnie.cs.adfa.edu.au Precedence: bulk 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(a)moe.2bsd.com