From mboxrd@z Thu Jan 1 00:00:00 1970 From: cdl@mpl.ucsd.edu (Carl Lowenstein) Date: Wed, 3 Feb 1999 12:37:53 -0800 (PST) Subject: MicroVAX I console port question. Message-ID: <199902032037.MAA03843@mpl.ucsd.edu> > From owner-pups at minnie.cs.adfa.edu.au Wed Feb 3 11:35 PST 1999 > Date: Wed, 3 Feb 1999 11:11:56 -0800 (PDT) > From: Brian D Chase > To: PUPS Mailing List > Subject: MicroVAX I console port question. > Mime-Version: 1.0 > > Off-topic, but maybe somewhat related to MicroPDP-11's... I've got a > MicroVAX I in a BA23 enclosure. I'm presently a bit thrown by the serial > console port. I'm used to the 9pin MicroVAX II ports. From what I've > been told, the DB25-M connector for the console requires a special serial > cable for connecting the MicroVAX I up to a terminal. A null modem cable > is not adequate. My MicroVax (I and only) handbook vintage 1984 says the cable is a "BC22D-10". VAX Systems and Options Catalog Oct 1984 describes the BC22D-10 as "A fully shielded null modem cable". Two DB25F connectors, 6 wires. The pins in use are 1,2,3,6,7,20. I would expect that "null modem" means (from one end to the other) connect 2-3, 3-2, 7-7, 6-20, 20-6. The implication is that the computer might need to see DTR asserted before it talks to the terminal. carl carl lowenstein marine physical lab u.c. san diego {decvax|ucbvax} !ucsd!mpl!cdl cdl at mpl.ucsd.edu clowenstein at ucsd.edu Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id IAA08853 for pups-liszt; Thu, 4 Feb 1999 08:25:02 +1100 (EST) Received: from europe.std.com (europe.std.com [199.172.62.20]) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id IAA08845 for ; Thu, 4 Feb 1999 08:24:45 +1100 (EST) Received: from world.std.com by europe.std.com (8.7.6/BZS-8-1.0) id QAA11267; Wed, 3 Feb 1999 16:24:36 -0500 (EST) Received: from localhost by world.std.com (TheWorld/Spike-2.0) id AA09409; Wed, 3 Feb 1999 13:24:36 -0800 Date: Wed, 3 Feb 1999 13:24:36 -0800 (PDT) From: Brian D Chase To: Carl Lowenstein Cc: pups at minnie.cs.adfa.oz.au Subject: Re: MicroVAX I console port question. In-Reply-To: <199902032037.MAA03843 at mpl.ucsd.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pups at minnie.cs.adfa.edu.au Precedence: bulk On Wed, 3 Feb 1999, Carl Lowenstein wrote: > My MicroVax (I and only) handbook vintage 1984 says the cable is a "BC22D-10". > > VAX Systems and Options Catalog Oct 1984 describes the BC22D-10 as > "A fully shielded null modem cable". Two DB25F connectors, 6 wires. > > The pins in use are 1,2,3,6,7,20. I would expect that "null modem" > means (from one end to the other) connect 2-3, 3-2, 7-7, 6-20, 20-6. > > The implication is that the computer might need to see DTR asserted > before it talks to the terminal. Or given that everything seems to be fine on my end null modem cable-wise, it's possible that something more serious is wrong with my MicroVAX I. Does your handbook list what a flashing "1" LED error code means? I'll double-check my cabling as well. -brian. --- Brian "JARAI" Chase | http://world.std.com/~bdc/ | VAXZilla LIVES!!! Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id GAA13300 for pups-liszt; Fri, 5 Feb 1999 06:08:49 +1100 (EST) Received: from Zeke.Update.UU.SE (IDENT:2026 at Zeke.Update.UU.SE [130.238.11.14]) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id GAA13295 for ; Fri, 5 Feb 1999 06:08:37 +1100 (EST) Received: from localhost (bqt at localhost) by Zeke.Update.UU.SE (8.8.8/8.8.8) with SMTP id UAA06615; Thu, 4 Feb 1999 20:07:58 +0100 Date: Thu, 4 Feb 1999 20:07:56 +0100 (MET) From: Johnny Billquist To: "Erin W. Corliss" cc: pups at minnie.cs.adfa.oz.au Subject: Re: Memory Management In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pups at minnie.cs.adfa.edu.au Precedence: bulk On Thu, 21 Jan 1999, Erin W. Corliss wrote: > The documentation that Warren gave me describes the memory management > scheme. It says that when the machine is first started, the memory > management unit is disabled -- anyone know how to enable it, and where the > segmentation registers are (I'm assuming they are in the 0160000-0177777 > range somewhere)? I haven't seen anyone answering this, so here I go... Reg. Addr. MMR0 777572 MMR1 777574 MMR2 777576 MMR3 772516 UIPAR 777640-777656 UDPAR 777660-777676 UIPDR 777600-777616 UDPDR 777620-777636 SIPAR 772240-772256 SDPAR 772260-772276 SIPDR 772200-772216 SDPDR 772220-772236 KIPAR 772340-772356 KDPAR 772360-772376 KIPDR 772300-772316 KDPDR 772320-772336 xy in xyP?R is: x: U - User S - Supervisor K - Kernel y: I - Instruction D - Data PAR is Page Address Register PDR is Page Description Register Okay, so for the layout of the registers... MMR0: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ! ! ! ! ! \-/ ! \---/ +-- Enable relocation ! ! ! ! ! ! ! ! ! +------ Page number ! ! ! ! ! ! ! ! +---------- Page address space I/D ! ! ! ! ! ! ! +------------- Page mode ! ! ! ! ! ! +---------------- Instruction completed ! ! ! ! ! +------------------ Maintenance mode ! ! ! ! +-------------------- Enable memory management trap ! ! ! +-------------------------- Trap-Memory management ! ! +---------------------------- Abort-Read only access violation ! +------------------------------ Abort-Page length error +-------------------------------- Abort-Non resident The page info is for when a trap/fault occurs, and tells in which page it occured.The rest should be pretty obvious. MMR1: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \-------/ \---/ \-------/ \---/ ! ! ! +---- Register number ! ! +------------ Amount changed (2 compl.) ! +-------------------- Register numbe +---------------------------- Amount changed (2 compl.) Low byte is written first, and this register tells how much registers have changed part way through an instruction, which needs to be undone to start the intruction again. MMR2: Virtual address of instruction where fault occured. MMR3: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ! ! +--- Enable user D space ! ! ! +----- Enable supervisor D space ! ! +------- Enable kernel D space ! +----------- Enable 22-bit mapping +------------- Enable unibus map If 22-bit mapping isn't enabled, the machine will be in 18-bit addressign when MMU is enabled. Unibus-mapping is something I'll skip for now. You need it for DMA on a 22-bit unibus machine only. Note that at the end of a MMU trap/abort, MMR0 bit 15-12 must be cleared for MMR1 and MMR2 to become active again. >From a virtual address (VA), you get to the physical address (PA) like this: APF=VA[15:13] DF=VA[12:0] PA=PAR(APF)*64+DF The PDR looks loke this: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \-----------/ ! ! ! \---/ ! ! ! ! +----- ACF ! ! ! +--------- ED ! ! +--------------- W ! +----------------- A +------------------------- PLF ACF - Access Control Field 000 - Non resident; abort on all accesses 001 - Read only; abort on write attempt, memory mgmt trap on read 010 - Read only; abort on write attempt 011 - Unused; abort on all accesses - reserved for future use 100 - Read/Write; memory mgmt trap upon completion of read or write 101 - Read/Write; memory mgmt trap upon completion of write 110 - Read/Write; no system trap/abort action 111 - Unused; abort on all accesses - reserved for future use A - Access to page has been made. W - Page has been written to since PAR/PDR was loaded ED - Expansion direction PLF - Page length field Now, have fun... Johnny Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at update.uu.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol