             <<< DISK$PUBLIC:[COVERT.DECUSERVE]MICRONOTE.NOTE;1 >>>
                              -< TOEM MicroNotes >-
================================================================================
Note 1.0                   MUL, DIV, ASH for Falcon(+)                 6 replies
JAWS::KAISER                                          7 lines  25-MAR-1985 09:13
--------------------------------------------------------------------------------
Welcome to the Micronotes Notesfile, public repository of Micronotes written by
the OEM Technical Support Group.  They are formatted for printing.

Micronotes are numbered, and each one is in the notesfile note with the same
number (except for Micronote 1, which is the reply to this note); so for the
sake of simplicity, please don't WRITE in this file.  Feel free to REPLY,
however.
================================================================================
Note 1.1                   MUL, DIV, ASH for Falcon(+)                    1 of 6
JAWS::KAISER                                        144 lines  25-MAR-1985 09:13
--------------------------------------------------------------------------------
      +---------------+					   +-----------------+
      | d i g i t a l |					   |  uNOTE # 001    |
      +---------------+					   +-----------------+


      +----------------------------------------------------+-----------------+
      | Title: MUL,DIV and ASH Instruction for the FALCON  | Date: 13-APR-84 |
      |			 and the FALCON-PLUS		   |		     |
      +----------------------------------------------------+-----------------+
      | Originator: Charlie Giorgetti			   | Page 1 of 4     |
      +----------------------------------------------------+-----------------+


      There  is no hardware support for the EIS, FIS, or FPP instruction sets.
      For FALCON SBC-11/21 applications that need the ability to  perform  the
      EIS  instructions MUL, DIV, and ASH, equivalent software routines can be
      substituted.  These callable routines  do	 not  do  any  form  of	 error
      checking.	  A  user should be aware that extensive use of these software
      routines	for  hardware  instructions  will  have	  impact   on	system
      performance.  These routines can be incorporated into an application and
      called as a subroutine.  The calling sequence for the subroutines can be
      set-up  in  a macro.  The following is a list of each of the subroutines
      and the macros that are used to set-up and call the software  MUL,  DIV,
      and ASH routines.

									Page 2


	The following macro and subroutine can be  used	 to  perform  the  MUL
      instruction in software:

	       .MACRO  SMUL    A,B,HI,LO

		MOV	A,-(SP)	    ; Push a multiplier onto the stack
		MOV	B,-(SP)	    ; Push the other multiplier as well
		JSR	PC,$MUL	    ; Call the MUL subroutine
		MOV	(SP)+,HI    ; Get the most significant part of
				      the result
		MOV	(SP)+,LO    ; Get the least significant part of
				      the result

	       .ENDM

	 $MUL:: MOV	R0,-(SP)    ; Save some work registers
		MOV	R1,-(SP)
		MOV	10(SP),R1   ; Obtain the value of A from the stack
		MOV	#21,-(SP)   ; Initialize the shift counter
		CLR	R0	    ; Initialize the high 16-bit accumulator
	   10$: ROR	R0	    ; Perform multiplication
		ROR	R1
		BCC	20$
		ADD	10(SP),R0
		CLC
	   20$: DEC	(SP)	    ; Bump the shift counter
		BNE	10$	    ; Not done ?
		TST	(SP)+	    ; Romove the counter from the stack
		MOV	R1,10(SP)   ; Save the low 16-bit value on the stack
		MOV	R0,6(SP)    ; Save the high 16-bit value on the stack
		MOV	(SP)+,R1    ; Restore the work registers
		MOV	(SP)+,R0
		RTS	PC	    ; Return

									Page 3


	The following macro and subroutine can be  used	 to  perform  the  DIV
      instruction in software:

		.MACRO	SDIV	DIVSOR,DIVHI,DIVLO,REM,QUO

		MOV	DIVSOR,-(SP); Push the divisor onto the stack
		MOV	DIVHI,-(SP) ; Push the upper 16-bits of the dividend
		MOV	DIVLO,-(SP) ; Push the lower 16-bits of the dividend
		JSR	PC,$DIV	    ; Call the DIV subroutine
		MOV	(SP)+,REM   ; Get the remainder
		MOV	(SP)+,QUO   ; Get the quotient

		.ENDM

	 $DIV:: MOV	R5,-(SP)    ; Get some work registers
		MOV	R4,-(SP)
		MOV	R3,-(SP)
		MOV	R0,-(SP)
		MOV	14.(SP),R3  ; Get the divisor from the stack
		MOV	12.(SP),R4  ; Get the high 16-bits of the dividend
		MOV	10.(SP),R5  ; as well as low 16-bits
		CLR	R0	    ; Clear an accumulator
		MOV	#32.,-(SP)  ; Shift counter
	    1$: ASL	R5	    ; Perform the division
		ROL	R4
		ROL	R0
		CMP	R0,R3
		BLO	2$
		SUB	R3,R0
		INC	R5
	    2$: DEC	(SP)
		BNE	1$	    ; Not done ?
		TST	(SP)+	    ; Remove the counter from the stack
		MOV	R0,12.(SP)  ; Store the remainder on the stack
		MOV	R5,14.(SP)  ; Store the quotient as well
		MOV	(SP)+,R0    ; Restore the work registers
		MOV	(SP)+,R3
		MOV	(SP)+,R4
		MOV	(SP)+,R5
		MOV	(SP)+,(SP)  ; Update the return PC
		RTS	PC	    ; Return

									Page 4


	The following macro and subroutine can be  used	 to  perform  the  ASH
      instruction in software:

		.MACRO	SASH	COUNT,VAL

		MOV	COUNT,-(SP) ; Push the shift count
		MOV	VAL,-(SP)   ; Push what is to be shifted
		JSR	PC,$ASH	    ; Call the ASH subroutine
		MOV	(SP)+,VAL   ; Get the results of the shift

		.ENDM

	$SASH:: MOV	R0,-(SP)    ; Get a couple of work registers
		MOV	R1,-(SP)
		MOV	6(SP),R0    ; R0 = value to be shifted
		MOV	8.(SP),R1   ; R1 = direction and shift count
		BIC	#^C<77>,R1
		BEQ	20$	    ; Get out if no shifting
		CMP	R1,#31.	    ; What direction is the shift
		BGT	10$	    ; go to the corection direction shift
	    5$: ASL	R0
		DEC	R1
		BNE	5$
		BR	20$
	   10$: NEG	R1
		BIC	#^C<77>,R1
	   11$: ASR	R0
		DEC	R1
		BNE	11$
	   20$: MOV	R0,8.(SP)   ; Store the shifted result on the stack
		MOV	(SP)+,R1    ; Restore the work registers
		MOV	(SP)+,R0
		MOV	(SP)+,(SP)  ; Update the return PC
		RTS	PC	    ; Return
================================================================================
Note 1.2                   MUL, DIV, ASH for Falcon(+)                    2 of 6
FURILO::JACKSON                                      13 lines   5-SEP-1985 13:50
--------------------------------------------------------------------------------
There is a small problem with this notesfile in that I don't want 
people to WRITE  notes in this file.  (there is good reason to this that
is mentioned in 1.0)  Anyway, there may be issues that the users of this
notesfile need to be concerned about, therefore I am creating a new 
notesfile for this purpose.

The notesfile is located at:

		krystl::sys$notes:micronote_questions.not

for those with pre-V4... KRYSTL::"SYS$NOTES:MICRONOTE_QUESTIONS.NOT"

-bill
================================================================================
Note 1.3                   MUL, DIV, ASH for Falcon(+)                    3 of 6
KRYSTL::SYSTEM                                       21 lines  10-JAN-1986 13:13
--------------------------------------------------------------------------------
This notefile will be converted to the new VAX Notes format on Saturday,
25 January.  This means that VNotes and Notes-11 users will be unable to
access the file after that date.  There is an effort underway to upgrade
Notes-11 so that it can access new-format files.  However, it is currently
unknown when this new Notes-11 will be available.

Also, VAX Notes requires VMS V4.2 (at least) to be installed on a system.
See the notefile CLT""::SYS$NOTES:NOTESUTIL.NOT for more information on
VAX Notes.  In particular, note 530 explains how to install it, and gives
the location of documentation.

VAX Notes is currently scheduled for external field text on 17 January.
At that point, the newest field-test version of VAX Notes will be made
available internally.  If the external field test is delayed, the
conversion of this file will be delayed also.

After the conversion, the old file will be write-locked.  The last note in
the old file will contain information on the converted file.

						Bill Jackson
						Keeper of Notes on KRYSTL
================================================================================
Note 1.4                   MUL, DIV, ASH for Falcon(+)                    4 of 6
PULSAR::SILVER                                       10 lines  12-JAN-1986 16:25
--------------------------------------------------------------------------------
Why????  Don't you want PDP users to be able to take advantage of your
work??

There are lots of sites around who use NOTES-11 on PDP systems, since they
don't have access to VMS systems.

Why not wait a bit longer until the new NOTES-11 is available?

- Craig Silver

================================================================================
Note 1.5                   MUL, DIV, ASH for Falcon(+)                    5 of 6
FURILO::JACKSON                                      12 lines  13-JAN-1986 08:34
--------------------------------------------------------------------------------
For the past few months, I've been running a batch job that checks for 
open notes files on this system.  (there are several).  Anyway, most of the
users are now accessing this file with VNOTES (you can tell by the process
name of the process that opens the file (either FAL or NOTES_XXXX_X))


Unfortunately, both notes systems are mutually exclusive.  I created another
files (MICRONOTE_QUESTIONS) a while ago for discussion of this very issue,
noone responded.

-bill jackson

================================================================================
Note 1.6                   MUL, DIV, ASH for Falcon(+)                    6 of 6
FURILO::JACKSON                                       8 lines  21-JAN-1986 11:57
--------------------------------------------------------------------------------
You may have noticed that the VNOTES server is not running on this machine.
 This is because we have installed VMS V4.2 on this system and have not
(or do not intend to) reinsall VNOTES on this system.

Notesfile conversion is taking place this saturday.......


-bill

================================================================================
Note 2.0                         Block Mode DMA                          1 reply
JAWS::KAISER                                        560 lines  25-MAR-1985 09:14
--------------------------------------------------------------------------------
      +---------------+					   +-----------------+
      | d i g i t a l |					   |  uNOTE # 002    |
      +---------------+					   +-----------------+


      +----------------------------------------------------+-----------------+
      | Title: Block Mode DMA				   | Date: 01-JUN-83 |
      +----------------------------------------------------+-----------------+
      | Originator: Scott Tincher and Mike Collins	   | Page 1 of 11    |
      +----------------------------------------------------+-----------------+


			   What is Block Mode DMA?
			   -----------------------

      Block Mode DMA is a method of data transfer which	 increases  throughput
      due  to  the  reduced handshaking necessary over the Q-bus.  In order to
      implement Block  Mode  DMA  both	the  master  and  slave	 devices  must
      understand  the  block  Mode  protocol.	If either device does not have
      Block Mode capability the transfers proceed via standard	DATI  or  DATO
      cycles.

		Conventional Direct Memory Access on the Q-bus
		----------------------------------------------

      Under conventional DMA operations, after a DMA  device  has  become  bus
      master, it begins the data transfers.  This is accomplished by gating an
      address onto the bus followed by the data being transferred to  or  from
      the  memory  device.   If	 more  than  one  transfer is performed by the
      temporary bus master, the address portion of the cycle must be  repeated
      for each data transfer.

		 Block Mode Direct Memory Access on the Q-bus
		 --------------------------------------------

      Under block Mode DMA operations an address cycle is followed by multiple
      word  transfers  to  sequential addresses.  Therefore data throughput is
      increased due to the elimination of the address portion of each transfer
      after the initial transfer.

      There are two types of block Mode	 transfer,  DATBI  (input)  and	 DATBO
      (output).	  An  overview	of  what occurs during each type of block Mode
      transfer is outlined in figures  1  (DATBI,  Block  Mode	input)	and  2
      (DATBO, block mode output).

      In the following discussion the signal prefix  T(Transmit)  indicates  a
      bus  driver  input  and  the  signal  prefix  R(Receive) indicates a bus
      receiver output.

									Page 2


			       DATBI Bus Cycle
			       ---------------

      Before a DATBI block mode transfer can occur the DMA bus	master	device
      must  request  control of the bus.  This occurs under conventional Q-bus
      protocol.

	o REQUEST BUS

	  The bus master device requests control of the bus  by	 asserting
	  TDMR.

	o GRANT BUS CONTROL

	  The bus arbitration logic in	the  CPU  asserts  the	DMA  grant
	  signal  TDMGO	 0  nsec minimum after TDMR is received and 0 nsec
	  minimum after RSACK negates (if a DMA device	was  previous  bus
	  master).

	o ACKNOWLEDGE BUS MASTERSHIP

	  The DMA bus master device asserts TSACK  0  nsec  minimum  after
	  receiving  RDMGI, 0 nsec minimum after the negation of RSYNC and
	  0 nsec minimum after the negation of RRPLY.  The DMA bus  master
	  device negates TDMR 0 nsec minimum after the assertion of TSACK.

	o TERMINATE GRANT SEQUENCE

	  The bus arbitration logic  in	 the  CPU  negates  TDMGO  0  nsec
	  minimum  after  receiving RSACK.  The bus arbitration logic will
	  also negate TDMGO if RDMR negates or if RSACK	 fails	to  assert
	  within 10 usec ('no SACK timeout').

	o EXECUTE A BLOCK MODE DATBI TRANSFER

	  o ADDRESS DEVICE MEMORY

	    a) The address is asserted by the bus master on TADDR<21:00>
	    along with the negation of TWTBT.

	    b) The bus master  asserts	TSYNC  150  nsec  minimum  after
	    gating the address onto the bus.

	  o DECODE ADDRESS

	    The	 appropriate  memory  device  recognizes  that	it  must
	    respond to the address on the bus.

	  o REQUEST DATA

	    a)	The  address  is  removed  by  the   bus   master   from
	    TADDR<21:00> 100 nsec minimum after the assertion of TSYNC.

	    b) The bus master asserts the first TDIN  100  nsec	 minimum
	    after asserting TSYNC.

									Page 3


	    c) The  bus	 master	 asserts  TBS7	50  nsec  maximum  after
	    asserting  TDIN  for  the first time.  TBS7 remains asserted
	    until 50 nsec maximum after the assertion of  TDIN	for  the
	    last time.	In each case, TBS7 can be asserted or negated as
	    soon as the conditions for asserting TDIN are met.

	    The assertion of TBS7 indicates the bus master is requesting
	    another read cycle after the current read cycle.

	  o SEND DATA

	    a) The bus slave asserts TRPLY 0  nsec  minimum  (8000  nsec
	    maximum to avoid a bus timeout) after receiving RDIN.

	    b) The bus slave asserts TREF concurrent with TRPLY if,  and
	    only if, it is a block mode device which can support another
	    RDIN after the current RDIN.

				     NOTE

		Block  mode  transfers	must  not  cross   16	word
		boundaries

	    c) The bus slave gates TDATA<15:00>	 onto  the  bus	 0  nsec
	    minimum  after receiving RDIN and 125 nsec maximum after the
	    assertion of TRPLY.

	  o TERMINATE INPUT TRANSFER

	    a) The bus master receives stable RDATA<15:00> from 200 nsec
	    maximum  after  receiving  RRPLY until 20 nsec minimum after
	    the negation of RDIN.  (The 20 nsec minimum represents total
	    minimum   receiver	 delays	  for  RDIN  at	 the  slave  and
	    RDATA<15:00> at the master.)

	  b)  The  bus	master	negates	 TDIN  200  nsec  minimum  after
	    receiving RRPLY.

	  o OPERATION COMPLETED

	    a)	The  bus  slave	 negates  TRPLY	 0  nsec  minimum  after
	    receiving the negation of RDIN.

	    b) If RBS7 and TREF are both asserted  when	 TRPLY	negates,
	    the	 bus  slave  prepares  for  another  DIN cycle.	 RBS7 is
	    stable from 125 nsec after RDIN is received until  150  nsec
	    after TRPLY negates.

	    c) If TBS7 and RREF were both asserted  when  TDIN	negated,
	    the bus master asserts TDIN 150 nsec minimum after receiving
	    the negation of RRPLY and continues with timing relationship
	    'SEND  DATA' above.	 RREF is stable from 75 nsec after RRPLY
	    asserts until 20 nsec minimum after TDIN  negates.	 (The  0
	    nsec  minimum  represents  total minimum receiver delays for
	    RDIN at the slave and RREF at the master.)

									Page 4


				     NOTE

		The bus master must limit itself to  not  more	than
		eight  transfers  unless  it  monitors	RDMR.  If it
		monitors RDMR, it may perform up to 16 transfers  as
		long  as  RDMR	is  not	 asserted  at the end of the
		seventh transfer.

	  o TERMINATE BUS CYCLE

	    a) If RBS7 and  TREF  were	not  both  asserted  when  TRPLY
	    negated,  the  bus slave removes TDATA<15:00> from the bus 0
	    nsec minimum and 100 nsec maximum after negating TRPLY.

	    b) If TBS7 and RREF were not both asserted when TDIN negated
	    the	  bus  master  negates	TSYNC  250  nsec  minimum  after
	    receiving the last assertion of RRPLY  and	0  nsec	 minimum
	    after the negation of that RRPLY.

	  o RELEASE THE BUS

	    a) The DMA bus master negates TSACK 0 nsec after negation of
	    the last RRPLY.

	    b) The DMA bus master negates TSYNC 300 nsec  maximum  after
	    it negates TSACK.

	    c) The DMA bus master must remove  RDATA<15:00>,  TBS7,  and
	    TWTBT from the bus 100 nsec maximum after clearing TSYNC.

	o RESUME PROCESSOR OPERATION The bus arbitration logic in the  CPU
	  enables  processor-generated	TSYNC  or  will	 issue another bus
	  grant (TDMGO) if RDMR is asserted.

									Page 5



			       Figure 1 - DATBI CYCLE
			       ----------------------

	      PROCESSOR		      I/O DEVICE	      MEMORY
	      ---------		      ----------	      ------

				   +- Request Bus
				   |  -----------
				   |  Assert TDMR
	      Grant Bus Control <--+
	      -----------------
	    . Near end of the current bus
	      cycle (RRPLY is negated) assert
	      TDMGO and inhibit new processor
	      generated TSYNC for the duration
	      of the DMA operation
			    |
			    |
			    +----> Acknowledge Bus Mastership
				   --------------------------
				   . Receive RDMGO
				   . Wait for negation of RSYNC and RRPLY
				   . Assert TSACK
			+--------- . Negate TDMR
			|
			V
	      Terminate Grant Sequence
	      ------------------------
	    . Negated RDMGO and wait for
	      DMA operation to be completed
		      |
		      |
		      +--> Execute a Block Mode DMA
			   ------------------------
			   (DATBI) Data Transfer
			   ---------------------
				      .
				      .
				      .
			    Address Device Memory
			    ---------------------
			      . Assert address on TADDR<21:00>
			      . Assert TSYNC
			      . Negate TWTBT -------+
						    |
						    +--->  Decode Address
							   --------------
							   . Store "Device
							     Selected" operation

									Page 6


				Figure 1 - DATBI CYCLE (continued)
				----------------------------------

	      PROCESSOR		      I/O DEVICE	      MEMORY
	      ---------		      ----------	      ------

			      +---->  Request Data
			      |	      ------------
			      |	    . Remove address from TADDR<21:00>
			      |	    . Assert TDIN
			      |	    . Assert TBS7 (request for an
			      |	      additional DIN cycle after
			      |	      the current one
			      |		     |
			      |		     +-----------> Send Data
			      |				   ---------
			      |				. Data on TDATA<15:00>
			      |				. Assert TRPLY
			      |				. Assert TREF (to
			      |				  indicates block
			      |				  mode capability)
			      |					|
			      |	      Terminate Input <---------+
			      |	      ---------------
			      |	      Transfer
			      |	      --------
			      |	    . Accept data and respond
			      |		by negating TDIN
			      |		      |
			      |		      +------> Operation Completed
			      |			       -------------------
			      |			     . Negate TRPLY
			      |				     |
			      |			       +-----------+
			      |		      yes      |    are	   |
			      +------------------------|RBS7 & TREF|
						       | Asserted  |
						       |     ?	   |
						       +-----------+
							     |	no
				 Terminate Bus Cycle  <------+
				 -------------------
				 and Release the Bus
				 -------------------
				    . Negate TSACK
				    . Negate TSYNC
				    . Remove TDAL, TBS7, and,
			      +-----  TWTBT from the Bus
			      |
			      V
		     Resume Processor Operation
		     --------------------------
		   . Enable processor generated TSYNC or
		     issue another grant if RDMR is asserted

									Page 7


			       DATBO Bus Cycle
			       ---------------

      DATBO Bus cycles Before a block mode transfer  can  occur	 the  DMA  bus
      master  device  must  request  control  of  the  bus.  This occurs under
      conventional Q-bus protocol.

	o REQUEST BUS The bus master device requests control of the bus by
	  asserting TDMR.

	o GRANT BUS CONTROL The bus arbitration logic in the  CPU  asserts
	  the DMA grant signal TDMGO 0 nsec minimum after RDMR is received
	  and 0 nsec minimum after TSACK negates  (if  a  DMA  device  was
	  previous bus master).

	o ACKNOWLEDGE BUS MASTERSHIP The DMA  bus  master  device  asserts
	  TSACK 0 nsec minimum after receiving RDMGI, 0 nsec minimum after
	  the negation of RSYNC and 0 nsec minimum after the  negation	of
	  RRPLY.   The	DMA  bus master device negates TDMR 0 nsec minimum
	  after the assertion of TSACK.

	o TERMINATE GRANT SEQUENCE The bus arbitration logic  in  the  CPU
	  negates  TDMGO  0  nsec  minimum after receiving RSACK.  The bus
	  arbitration logic will also negate TDMGO if RDMR negates  or	if
	  RSACK fails to assert within 10 usec ('no SACK timeout').

	o EXECUTE A BLOCK MODE DATBO TRANSFER

	  o ADDRESS DEVICE MEMORY

	    a) The address is asserted by the bus master on TADDR<21:00>
	    along with the assertion of TWTBT.

	    b) The bus master  asserts	TSYNC  150  nsec  minimum  after
	    gating the address onto the bus.

	  o DECODE ADDRESS The appropriate memory device recognizes that
	    it must respond to the address on the bus.

	  o SEND DATA

	    a) The bus master gates TDATA<15:00> along	with  TWTBT  100
	    nsec  minimum  after  the  assertion  of  TSYNC.   TWTBT  is
	    negated.

	    b) The bus master asserts the first TDOUT 100  nsec	 minimum
	    after gating TDATA<15:00>.

				     NOTE

		During DATBO cycles TBS7 is undefined

	  o RECEIVE DATA

	    a) The bus slave receives stable data on  RDATA<15:00>  from

									Page 8


	    25 nsec minimum before receiving RDOUT until 25 nsec minimum
	    after receiving the negation of RDOUT.

	    b)	The  bus  slave	 asserts  TRPLY	 0  nsec  minimum  after
	    receiving RDOUT.

	    c) The bus slave asserts TREF concurrent with TRPLY if,  and
	    only if, it is a block mode device which can support another
	    RDOUT after the current RDOUT.

				     NOTE

		Blockmode  transfers  must   not   cross   16	word
		boundaries

	  o TERMINATE OUTPUT TRANSFER The bus master negates  TDOUT  150
	    nsec minimum after receiving RRPLY.

	  o OPERATION COMPLETED

	    a)	The  bus  slave	 negates  TRPLY	 0  nsec  minimum  after
	    receiving the negation of RDOUT.

	    b) If RREF was asserted when TDOUT negated and  if	the  bus
	    master  wants to transfer another word, the bus master gates
	    the new data on TDATA<15:00> 100 nsec minimum after negating
	    TDOUT.   RREF  is  stable  from  75 nsec maximum after RRPLY
	    asserts until 20 nsec minimum after RDOUT negates.	(The  20
	    nsec minimum represents minimum receiver delays for RDOUT at
	    the slave and RREF at the master).

	    c) The bus master  asserts	TDOUT  100  nsec  minimum  after
	    gating  new	 data on TDATA<15:00> and 150 nsec minimum after
	    receiving the negation of RRPLY.  The cycle	 continues  with
	    the timing relationship in 'RECEIVE DATA' above.

				     NOTE

		The bus master must limit itself to  not  more	than
		eight  transfers  unless  it  monitors	RDMR.  If it
		monitors RDMR, it may perform up to 16 transfers  as
		long  as  RDMR	is  not	 asserted  at the end of the
		seventh transfer.

	  o TERMINATE BUS CYCLE

	    a) If RREF was not asserted when RRPLY negated or if the bus
	    master  has	 no  additional data to transfer, the bus master
	    removes data on TDATA<15:00> from the bus 100  nsec	 minimum
	    after negating TDOUT.

	    b) If RREF was not	asserted  when	TDOUT  negated	the  bus
	    master  negates  TSYNC  275 nsec minimum after receiving the
	    last RRPLY and 0 nsec minimum after the the negation of  the
	    last RRPLY.

									Page 9


	  o RELEASE THE BUS

	    a) The DMA bus master negates TSACK 0 nsec after negation of
	    the last RRPLY.

	    b) The DMA bus master negates TSYNC 300 nsec  maximum  after
	    it negates TSACK.

	    c) The DMA bus master must remove  TDATA,  TBS7,  and  TWTBT
	    from the bus 100 nsec maximum after clearing TSYNC.

	o RESUME PROCESSOR OPERATION The bus arbitration logic in the  CPU
	  enables  processor-generated	TSYNC  or  will	 issue another bus
	  grant (TDMGO) if RDMR is asserted.

								       Page 10



				    Figure 2 - DATBO CYCLE
				    ----------------------

	      PROCESSOR			      I/O DEVICE	      MEMORY
	      ---------			      ----------	      ------

					  +- Request Bus
					  |  -----------
					  |  . Assert TDMR
		   Grant Bus Control <----+
		   -----------------
	    . Near the end of the current bus
	      cycle (RRPLY is negated) assert
	      TDMGO and inhibit new processor
	      generated TSYNC for the duration
	      of the DMA operation.
			   |
			   |
			   +-------> Acknowledge Bus Mastership
				     --------------------------
				    . Receive RDMG
				    . Wait for negation of RSYNC and RRPLY
				    . Assert TSACK
			  +-------- . Negate TDMR
			  |
			  V
		  Terminate Grant Sequence
		  ------------------------
		. Negate TDMGO and wait for DMA
		  operation to be completed.
			  |
			  +---------> Execute A Block Mode DMA
				      -------------------------
				      (DATBO) Data Transfer
				      ---------------------
					       .
					       .
					       .
					Address Memory
					--------------
				   . Assert Address on TADDR<21:00>
				   . Assert TWTBT
				   . Assert TSYNC ------+
							|
							+-----> Decode Address
								--------------
							      . Address match
								selects device

								       Page 11


				  Figure 2 - DATBO CYCLE (continued)
				  ----------------------------------

	      PROCESSOR			      I/O DEVICE	      MEMORY
	      ---------			      ----------	      ------

				 +----> Send Data
				 |	---------
				 |    . Assert TDATA <15:00>
				 |    . Negate TWTBT
				 |    . Assert TDOUT ----+
				 |			 |
				 |			 +--> Receive Data
				 |			      ------------
				 |			    . Accept data and
				 |			      RWTBT
				 |			    . Assert TRPLY
				 |			    . Assert TREF
				 |			      (Indicates block
				 |			      mode capability)
				 |				     |
				 |				     |
				 |   Terminate Output Transfer <-----+
				 |   -------------------------
				 |
				 | . Negate TDOUT --+
				 |		    |
				 |		    +-->  Operation Completed
				 |			  -------------------
				 |			 . Negate TRPLY
				 |				  |
				 | +------------------+	     +----------+
			     yes | | Does Master      |	 yes | is RREF	|
				 +-| Wish to Transfer |<-----|Asserted ?|
				   | More Data ?      |	     +----------+
				   +------------------+		  |  no
					    |			  |
				  Terminate Bus Cycle and <-------+
				  -----------------------
				       Release the Bus
				       ---------------
				    . Negate TSACK
				    . Negate TSYNC
			     +----- . Remove TDAL, TDAL,TBS7, and TWTBT
			     |	      from the Bus
			     |
			     |
		 Resume Processor Operation
		 --------------------------
		. Enable processor generated TSYNC
		  (processor is bus master) or issue
		  another grant if RDMR is asserted
================================================================================
Note 2.1                         Block Mode DMA                           1 of 1
MOTHER::FRAZIER                                      12 lines   4-JUN-1985 14:48
--------------------------------------------------------------------------------
I'd like to point out a potential problem.

The MXV11-B has been promoted as a usable companion for the KDJ11-AA.
However the MXV11-B does NOT support "Block Mode" transfers.
The MXV11-B also must have a starting address within the first 265kb.
So now the ring buffer for the RQDX1/2 is in non-block mode memory.
The results are predictably disastrous.



							James


================================================================================
Note 3.0                      LSI-11/73 Bootstraps                    No replies
JAWS::KAISER                                        114 lines  25-MAR-1985 09:14
--------------------------------------------------------------------------------
      +---------------+					   +-----------------+
      | d i g i t a l |					   |  uNOTE # 003    |
      +---------------+					   +-----------------+


      +----------------------------------------------------+-----------------+
      | Title: Compatible Bootstraps for the LSI-11/73	   | Date: 28-NOV-83 |
      +----------------------------------------------------+-----------------+
      | Originator: Mike Collins			   | Page 1 of 2     |
      +----------------------------------------------------+-----------------+



      The LSI-11/73 (KDJ11-AA) is a high performance CPU for the Q-Bus.	 It is
      a	 CPU  only, which means that there is no boot capability on the module
      itself.  Therefore a boot module must  be	 selected  to  work  with  the
      LSI-11/73.

      This uNOTE will discuss the bootstrap modules which can be used with the
      11/73.

      There are 4 possible modules which can be used for bootstrap.
      They are : MXV11-BF w/MXV11-B2 boot ROMs
		 MRV11-D  w/MXV11-B2 boot ROMs
		 MXV11-AA or -AC w/MXV11-A2 boot ROMs
		 BDV11

      For an LSI-11/73 based system to be Field Serviceable the bootstrap code
      must  execute a cache memory diagnostic on power-up.  The only boot code
      which satisfies this requirement is found in  the	 MXV11-B2  boot	 ROMs.
      Therefore	 an  LSI-11/73 based, Field Serviceable system must use either
      the MXV11-BF w/MXV11-B2 ROMs or the MRV11-D w/MXV11-B2 ROMs.

					NOTE

	      The MXV11-B2 ROMs will not work on the MXV11-A module.

      MXV11-BF or MRV11-D w/MXV11-B2 ROMs
      -----------------------------------

      The MXV11-BF w/MXV11-B2 ROMs is the preferred choice since  this	module
      has  2  asynchronous  serial  lines  as  well as 128Kb of dynamic RAM in
      addition to the boot capability.	However, if your application does  not
      need  the	 extra	serial lines and RAM, an alternate choice would be the
      MRV11-D w/MXV11-B2 ROMs.

      The MXV11-B2 ROMs will boot the following devices :
		  RLO1 / RLO2 (DL)
		  RXO1 / RXO2 (DX,DY)
		  TU58 (DD)
		  TSV05 (MS)
		  MSCP type Devices e.g. RD51, RX50 (DU)
		  DECnet via DPV11, DLV11-E, DLV11-F, DUV11

								Page 2


					NOTE

	      The MXV11-BF  is	not  supported	by  RSTS  due  to  its
	      non-parity  memory.   An alternative configuration would
	      be to use the MRV11-D with the MXV11-B2 boot ROMs, and a
	      DLV11-J or other DLV11 serial line device.

      The remaining 2 boot modules do NOT  have	 the  necessary	 cache	memory
      diagnostic code to make an 11/73 based system Field Serviceable.

      Below is a list of all  of  the  KNOWN  WORKING  bootstraps  for	the  2
      remaining boot modules.

      MXV11-A w/MXV11-A2 ROMs
      -----------------------

      Working bootstraps : RLO1 / RLO2
			   RXO1 / RXO2
			   TU58 conventional boot
			   TU58 standalone boot

				      WARNING

	      If the MXV11-A is used in a 22 bit system	 the  on-board
	      RAM must be disabled.  Refer to uNOTE  106.

      BDV11
      -----

      Working bootstraps : RLO1 / RLO2
			   RXO2
			   RK05

				      WARNING

	      Disable the processor and	 memory	 tests	since  an  odd
	      address  trap  does  occur  in  each  of them.  See NOTE
	      below.  To disable the CPU test,	set  switch  E15-1  to
	      OFF.   To	 disable  the memory test, set switch E15-2 to
	      OFF.   (Refer  to	 the  Microcomputer   and   Interfaces
	      Handbook for complete configuration information.)

	      The 11/73 has an	on-board  Line	Time  Clock  Register,
	      therefore	 the BDV11 BEVNT switch E21-5 should be set to
	      the OPEN position.  This disables	 software  control  of
	      the  BEVNT  signal via the BDV11 LTC register and allows
	      software control	of  this  signal  via  the  11/73  LTC
	      register.

	      If the BDV11 is used in a 22 bit system, it must	be  CS
	      REV E or later or ECO M8012-ML0005 must be installed.


					NOTE

	      ODD ADDRESS TRAPS.  The 11/23  ignores  an  odd  address
	      reference whereas the KDJ11-A will trap to address 4.

================================================================================
Note 4.0                     LSI-11/73 Upgrade Paths                  No replies
JAWS::KAISER                                        300 lines  25-MAR-1985 09:15
--------------------------------------------------------------------------------
      +---------------+					   +-----------------+
      | d i g i t a l |					   |  uNOTE #004     |
      +---------------+					   +-----------------+


      +----------------------------------------------------+-----------------+
      | Title: LSI-11/73 Upgrade Paths			   | Date: 28-NOV-83 |
      +----------------------------------------------------+-----------------+
      | Originator: Mike Collins			   | Page 1 of 6     |
      +----------------------------------------------------+-----------------+



      With the announcement of the KDJ11-A CPU module, there will be  numerous
      questions	 regarding  configuring the module into a current system.  The
      purpose of this MicroNote	 is  to	 address  all  possible	 configuration
      upgrade paths (within reason).

      Generally a KDJ11-A will be installed as an upgrade to  a	 system	 built
      from components or DEC packaged system.

      In the case of a component upgrade it is	assumed	 the  processor	 is  a
      KDF11-A  and  the	 boot  mechanism  is an MXV11-A with the MXV11-A2 Boot
      ROMs.

      System upgrades fall into 2 categories:
	       1. KDF11-A based systems and
	       2. KDF11-B based systems (11/23+ and Micro/PDP-11)

      There are 3 issues which must be addressed when  considering  a  KDJ11-A
      upgrade.	They are:
	       1. The Boot mechanism
	       2. 18 or 22 bit system
	       3. Single or multiple box system


					NOTE

	      1.  In the following upgrade scenarios, the systems have
	      been  labeled  as	 being	Field  Serviceable  or not.  A
	      system which is Field Serviceable has a bootstrap	 which
	      meets  Field  Service  requirements.  The requirement is
	      that the bootstrap must execute an  11/73	 cache	memory
	      diagnostic  on power-up.	There is no guarantee that the
	      overall system will be Field Serviceable or that it will
	      be FCC compliant.

	      2.  Systems  using  CPU's	 other	than  the  KDF11-A  or
	      KDF11-B  (i.e.   11/03  systems)	are not considered for
	      upgrade.

      CAUTION:	It is recommended that the AC and DC  loading  for  the	 final
      configuration  be	 checked for conformance with the Q-Bus loading rules.
      It is also recommended to check for overloading on the +5 Volt  and  +12
      Volt Power Supplies.

								Page 2


      For each system upgrade the following parameters are listed for both the
      'Current' system and the 'Upgraded' system:
	       1. CPU
	       2. Boot Mechanism
	       3. System Size
	       4. Number of Boxes
	       5. Field Serviceable or not
	       6. Special Conditions


      COMPONENT UPGRADE PATHS:
      -----------------------

      1. Current System		      Upgrade 1
	 --------------		      ---------
	 KDF11-A		      KDJ11-A
	 MXV11-A		      MXV11-B/MRV11-D with MXV11-B2 Boot ROMs
	 18 Bit System		      18 Bit System
	 1 Box			      1 Box
				      Field Serviceable

				      Upgrade 2
				      ---------
				      KDJ11-A
				      MXV11-A
				      18 Bit System
				      1 Box
				      NOT Field Serviceable

      2. Current System		      Upgrade
	 --------------		      -------
	 KDF11-A		      See upgrades for category	 1
	 MXV11-A
	 18 Bit System
	 More than 1 box

      3. Current System		      Upgrade
	 --------------		      -------
	 KDF11-A		      See upgrades for category	 1
	 MXV11-A (Memory Disabled)
	 22 Bit System
	 1 Box

      4. Current System		      Upgrade
	 --------------		      -------
	 KDF11-A		      Not currently configureable with
	 MXV11-A (Memory Disabled)    DEC equipment.
	 22 Bit System
	 More than 1 box
	 This system is not currently configureable with DEC equipment.

								Page 3


      PDP 11/23A SYSTEM UPGRADE PATHS:
      -------------------------------

      5. Current System		      Upgrade 1
	 --------------		      ---------
	 KDF11-A		      KDJ11-A
	 BDV11			      MXV11-B/MRV11-D with MXV11-B2 Boot ROMs
	 18 Bit System		      18 Bit System
	 1 Box			      1 Box
				      Field Serviceable

				      Upgrade 2
				      ---------
				      KDJ11-A
				      BDV11
				      18 Bit System
				      1 Box
				      NOT Field Serviceable
				      Disable the Processor and Memory tests
				      and also the BEVNT register on the
				      BDV11.

				      Upgrade 3
				      ---------
				      KDJ11-A
				      MXV11-A (with MXV11-A2 boot ROMs)
				      18 Bit System
				      1 Box System
				      NOT Field Serviceable
				      Check AC loading since termination was
				      removed when the BDV11 was removed from
				      the system.

      6. Current System		      Upgrade 1
	 --------------		      ---------
	 KDF11-A		      KDJ11-A
	 BDV11			      MXV11-B/MRV11-D with MXV11-B2 Boot ROMs
	 18 Bit System		      18 Bit System
	 More than 1 Box	      More than 1 box
				      Field Serviceable
				      Use BCV1A and BCV1B expansion cables.

				      Upgrade 2
				      ---------
				      KDJ11-A
				      BDV11
				      18 Bit System
				      More than 1 Box
				      NOT Field Serviceable
				      Disable the Processor and Memory tests
				      and also the BEVNT register on the
				      BDV11.
				      Use BCV1B cable set between 1st and 2nd
				      box and the BCV1A cable set between the
				      2nd and 3rd box.	Note: If in a 3 box
				      system the expansion cable set lengths
				      must differ by 4 ft.

								Page 4


				      Upgrade 3
				      ---------
				      KDJ11-A
				      MXV11-A (with MXV11-A2 boot ROMs)
				      18 Bit System
				      More than 1 Box
				      NOT Field Serviceable
				      Use BCV1A and BCV1B expansion cables.

      7. Current System
	 --------------
	 KDF11-A
	 BDV11
	 22 Bit System
	 1 Box
	 Systems with this configuration were never shipped by DEC.


      PDP 11/23 PLUS SYSTEM UPGRADE PATHS:
      -----------------------------------

      8. Current System		      Upgrade 1
	 --------------		      ---------
	 KDF11-B		      KDJ11-A
	 Boot is on CPU		      MXV11-B/MRV11-D with MXV11-B2 Boot ROMs
	 22 Bit System		      22 Bit System
	 1 Box System		      1 Box
				      Field Serviceable

				      Upgrade 2
				      ---------
				      KDJ11-A
				      MXV11-A (with MXV11-A2 boot ROMs)
				      22 Bit System
				      1 Box
				      NOT Field Serviceable
				      Must disable RAM on MXV11-A.

				      Upgrade 3
				      ---------
				      KDJ11-A
				      BDV11
				      22 Bit System
				      1 Box System
				      NOT Field Serviceable
				      Must have BDV11 ECO M8012-ML005
				      installed.  Disable the Processor and
				      Memory tests and also the BEVNT register
				      on the BDV11.

								Page 5


      9. Current System		      Upgrade 1
	 --------------		      ---------
	 KDF11-B		      Not currently configureable with
	 Boot is on CPU		      DEC equipment.
	 22 Bit System
	 More than 1 Box

				      Upgrade 2
				      ---------
				      Not currently configureable with
				      DEC equipment.

				      Upgrade 3
				      ---------
				      Not currently configureable with
				      DEC equipment.


      MICRO/PDP-11 SYSTEM UPGRADE PATHS:
      ---------------------------------

      10. Current System	      Upgrade
	  --------------	      -------
	  Micro/PDP-11		      Same as 11/23+ rules, see category
	  KDF11-BE		       8, Upgrade 1.  Upgrades 2 and
	  Boot is on CPU	      3 are not recommended since the
	  22 Bit System		      MXV11-A and BDV11 cannot boot the
	  1 Box system		      5 1/4" media in the Micro/PDP-11.


      11. Current System	      Upgrade
	  --------------	      -------
	  Micro/PDP-11		      Same as 11/23+ rules, see upgrades
	  KDF11-BE		      for category  9.
	  Boot is on CPU
	  22 Bit System
	  More than 1 box


					NOTE

	      It is not	 currently  possible  to  expand  out  of  the
	      Micro/PDP-11 while maintaining FCC compliance.

	      11/23 PLUS and Micro/PDP-11 system upgrades will require
	      an  EXTRA	 backplane  slot  to accomodate the additional
	      boot module (i.e.	 MXV11-A,-B or BDV11).

								Page 6


      11/23-S SYSTEM UPGRADE SOLUTIONS:
      --------------------------------

      12. Current System	      Upgrade
	  --------------	      -------
	  KDF11-BA		      See upgrades for category	 5.
	  Boot is on CPU
	  18 Bit System
	  1 Box system

      13. Current System	      Upgrade
	  --------------	      -------
	  KDF11-BA		      See upgrades for category	 6.
	  Boot is on CPU
	  18 Bit system
	  More than 1 box


					NOTE

	      It is not	 currently  possible  to  expand  out  of  the
	      11/23-S while maintaining FCC compliance.

================================================================================
Note 5.0                     Q22 Compatible Options                   No replies
JAWS::KAISER                                        319 lines  25-MAR-1985 09:15
--------------------------------------------------------------------------------
      +---------------+					   +-----------------+
      | d i g i t a l |					   |  uNOTE # 005    |
      +---------------+					   +-----------------+


      +----------------------------------------------------+-----------------+
      | Title: Q22 Compatible Options			   | Date: 23-Apr-84 |
      +----------------------------------------------------+-----------------+
      | Originator: Charlie Giorgetti			   | Page 1 of 6     |
      +----------------------------------------------------+-----------------+


      This is a list of Q22 compatible options.	 A Q22	compatible  option  is
      defined  as  a  Q-bus  option  that  will work without restriction in an
      extended Q-bus system, that is a 22-bit Q-bus system.   This  list  also
      includes	options	 that are not compatible in Q22 systems and the reason
      for the restriction.

      The requirements for a device to be Q22 compatible are the following:

      1.  Processors, memories, and DMA devices must all be capable of	22-bit
      addressing.

      2.  Devices must use backplane pins BC1, BD1, BE1,  BF1  and  DC1,  DD1,
      DE1, DF1, for BDAL18-21 only.

      Processors, memories, or DMA devices which are  not  capable  of	22-bit
      addressing  may  generate or decode erroneous addresses if they are used
      in   systems   which   implement	 22-bit	  addressing.	 Memory	   and
      memory-addressing	 devices  which implement only 16 or 18-bit addressing
      may be used in a 22-bit backplane, but the size  of  the	system	memory
      must  be	restricted  to	the  address range of those devices (64 KB for
      systems with 16-bit devices and  256  KB	for  systems  with  an	18-bit
      devices).

      Any device which uses backplane pins BC1, BD1, BE1,  BF1	or  DC1,  DD1,
      DE1, DF1, for purposes other than BDAL18-21 is electrically incompatible
      with the 22-bit bus and may not be used without modification.

				      NOTE
	  Eighteen or sixteen bit DMA devices can potenitially work in
	  Q22  systems	by  buffering I/O in the 18- or 16-bit address
	  space.

      I.  Fully Compatible Options

      Options in this category meet both of the requirements  mentioned	 above
      and may be used in any Q-bus configuration.

      A. Processors

	KD32-A	   M7135/M7136	  MicroVAX I CPU Module

	KDF11-A	   M8186	  LSI-11/23 CPU
				  (Etch Rev. C or later)

								Page 2



	KDF11-B	   M8189	  LSI-11/23B CPU

	KDJ11-A	   M8192	  LSI-11/73 CPU

	KDJ11-B	   M8190	  MicroPDP-11/73 CPU

	KXT11-C	   M8377	  Q-bus Perpherial I/O Processor

	KMV11-A	   M7500	  Q-bus Perpherial Communication Processor

      B. Backplanes/Boxes

		      H9270-Q	  4 X 4 Q22/Q22 Backplane

		      H9281-QA	  2 X 4	 Q22 Dual-height Backplane
		      H9281-QB	  2 X 8	 Q22 Dual-height Backplane
		      H9281-QC	  2 X 12 Q22 Dual-height Backplane

		      H9275	  4 X 9 Q22/Q22 Backplane

	BA11-S	      H9276	  4 X 9 Q22/CD Backplane

	Micro/PDP-11  H9278	  4 X 3 Q22/CD and 4 X 5 Q22/Q22 Backplane

      C. Memory

	MCV11-D	   M8631	  CMOS Non-volatile Memory

	MSV11-L	   M8059	  MOS Memory (either 128 KB or 256 KB)

	MSV11-P	   M8067	  MOS Memory (either 256 KB or 512 KB)

	MSV11-Q	   M7551	  MOS Memory (1 MB)

	MXV11-B	   M7195	  Multifunction Module

	MRV11-D	   M8578	  PROM/ROM Module

      D. Options

	AAV11-C	   A6006	  D/A Converter

	ADV11-C	   A8000	  A/D Converter

	AXV11-C	   A0026	  D/A and A/D Combination Converter

	BDV11	   M8012	  Bootstrap, Terminator, Diagnostic
				  (CS Rev. E or later, ECO M8012-ML005
				   installed)

	DEQNA	   M7504	  Ethernet Controller

	DLV11	   M7940	  Asynchronous Serial Line Interface

								Page 3


	DLV11-E	   M8017	  Asynchronous Serial Line Interface

	DLV11-F	   M8028	  Asynchronous Serial Line Interface

	DLV11-J	   M8043	  Four Asynchronous Serial Line Interfaces
				  (CS Rev. E or later, ECO M8043-MR002
				   installed)

	DHV11	   M3104	  8-line Asynchronous EIA Multiplexer

	DMV11-AD   M8053-MA	  Synchronous Communications Interface

	DMV11-AF   M8064-MA	  Synchronous Communications Interface

	DPV11	   M8020	  Programmable Synchronous EIA Line

	DRV11	   M7941	  32 line Parallel Interface

	DRV11-J	   M8049	  64 line Parallel Interface

	DRV11-W	   M7651	  General Purpose DMA Interface (dual)

	DUV11	   M7951	  Programmable Synchronous EIA Line

	DZQ11	   M3106	  4-line Asynchronous EIA Multiplexer (dual)

	DZV11	   M7957	  4-line Asynchronous EIA Multiplexer (quad)

	FPF11	   M8188	  Floating Point Processor

	IBV11-A	   M7954	  IEEE Instrument Bus Interface

	IEQ11	   M8634	  DMA IEEE Instrument Bus Interface

	KLESI-QA   M7740	  LESI Bus Adaptor (RC25 Interface)

	KPV11-A	   M8016	  Power-fail and LTC Generator
				  (KPV11-B and -C are not compatible)

	KWV11-C	   A4002	  Programmable Real-time Clock

	LAV11	   M7949	  LA180 Line Printer Interface

	LPV11	   M8027	  LA180/LP05 Printer Interface

	RLV12	   M8061	  RL01/2 Controller

	RQDX1	   M8639	  Controller for 5.25" Floppy and Winchester

	RXV11	   M7946	  RX01 Floppy Disk Interface

	TQK25	   M7605	  Streaming Cartridge Tape Controller

	TSV05	   M7196	  Magnetic Tape Controller

								Page 4


      E. Bus Cable-Cards

		   M9404	  Cable Connector

		   M9404-YA	  Cable Connector with 240-Ohm Terminators

		   M9405	  Cable Connector

		   M9405-YA	  Cable Connector with 120-Ohm Terminators

      II.  Restricted Compatibility Options

      Options in this category do not meet one or both of the requirements for
      use in a 22-bit system.  These options are incompatible with some or all
      22-bit systems.

      A. Processors

	KDF11-A	   M8186	  LSI-11/23 CPU
				  (Prior to etch rev. C, 18-bit addressing only,
				   and use of BC1,BD1,BE1,BF1 for purposes other
				   than BDAL18-21)

	KD11-HA	   M7270	  LSI-11/2 CPU
				  (16-bit addressing only, and use of BC1,BD1,
				   BE1,BF1 for purposes other than BDAL18-21)

	KD11-F	   M7264	  LSI-11 CPU
				  (16-bit addressing only, and use of DC1,DB1,
				   DE1,DF1 for purposes other than BDAL18-21)

	KXT11-A	   M8063	  SBC-11/21 CPU
				  (16-bit addressing only)

      B. Backplanes/Boxes

	DDV11-B			  6 X 9 Backplane
				  (18-bit addressing only)

	BA11-M	   H9270	  4 X 4 Backplane
				  (18-bit addressing only)

	BA11-N	   H9273-A	  4 X 9 Backplane
				  (18-bit addressing only)

	BA11-VA	   H9281-A,B,C	  2 X n Dual-height Backplane n = 4, 8, and 12
				  BA11-VA used the H9281-A
				  (18-bit addressing only)

	VT103			  4 X 4 Backplane (part number: 54-14008)
				  (18-bit addressing only)

								Page 5


      C. Memories

	 MMV11-A   G653		  8 KB Core Memory
				  (16-bit addressing only, Q-bus required on C/D
				   backplane connectors)

	 MRV11-AA  M7942	  ROM Module
				  (16-bit addressing only)

	 MRV11-BA  M8021	  UV PROM-RAM
				  (16-bit addressing only)

	 MRV11-C   M8048	  PROM/ROM Module
				  (18-bit addressing only)

	 MSV11-B   M7944	  8 KB bus refreshed RAM
				  (16-bit addressing only)

	 MSV11-C   M7955	  32 KB RAM
				  (18-bit addressing only)

	 MSV11-D,E M8044/M8045	  8 KB, 16 KB, 32 KB, 64 KB RAM
				  (18-bit addressing only)

	 MXV11-A   M8047	  Multifunction Module
				  (18-bit addressing only on memory, the memory
				   can be disbales see uNte #106)
      D. Options

	 AAV11	   A6001	  D/A Converter
				  (Use of BC1 for purposes other than BDAL18)

	 ADV11	   A012		  A/D Converter
				  (Use of BC1 for purposes other than BDAL18)

	 BDV11	   M8012	  Bootstrap/Terminator
				  (CS Revision E or earlier 18 bits only)

	 DLV11-J   M8043	  Serial Line Interface
				   (CS Rev. E or earlier incompatible with
				    KDF11-A and KDF11-B)

	 DRV11-B   M7950	   General Purpose DMA Interface (quad)
				   (18-bit DMA only)

	 KPV11-B,C M8016-YB,YC	   Power-fail/line-time clock/terminator
				   (Termination for 18-bits only)

	 KUV11	   M8018	   Writable Control Store
				   (For use with KD11-F processor only)

	 KWV11-A   M7952	   Programmable real-time clock
				   (Use of BC1 for purposes other than BDAL18)

								Page 6


	 REV11	   M9400	   Terminator, DMA refresh, bootstrap
				   (Bootstrap for use with KD11-F and KD11-HA
				    processors only.
				    Termination for 18-bits only.
				    DMA refresh may be used in any system.)

	 RKV11-D   M7269	   RK05 Controller Interface
				   (16-bit DMA only)

	 RLV11	   M8013	   RL01,2 Controller
		   M8014	   (18-bit DMA only, use of BC1 and BD1 for
				    purposes other than BDAL18 and BDAL19)

	 RXV21	   M8029	   RX02 Floppy Disk Interface
				   (18-bit DMA only)

	 TEV11	   M9400-YB	   120-Ohm Bus Terminator
				   (Termination for 18-bits only)

	 VSV11	   M7064	   Graphics Display
				   (18-bit DMA only)

      E. Bus Cable-Cards

		   M9400-YD	   Cable Connector
				   (18-bit bus only)

		   M9400-YE	   Cable Connector with 240-Ohm Terminators
				   (18-bit bus only)

		   M9401	   Cable Connector
				   (18-bit bus only)

================================================================================
Note 6.0                  LSI-11/23 & 11/73 Differences               No replies
JAWS::KAISER                                        413 lines  25-MAR-1985 09:15
--------------------------------------------------------------------------------
      +---------------+					   +-----------------+
      | d i g i t a l |					   |  uNOTE # 006    |
      +---------------+					   +-----------------+


      +----------------------------------------------------+-----------------+
      | Title:		  Differences Between		   | Date: 23-APR-84 |
      |		      the LSI-11/73 and LSI-11/23	   |		     |
      +----------------------------------------------------+-----------------+
      | Originator: Mike Collins			   | Page 1 of 8     |
      +----------------------------------------------------+-----------------+



      This MicroNote identifies and discusses  the  differences	 between   the
      LSI-11/23	 (KDF11-AA) and the LSI-11/73 (KDJ11-AA).  The following table
      lists these differences.	Following the table are individual discussions
      on these differences.

      Some of these differences are discussed from the point  of  view	of  an
      11/23 to 11/73 upgrade.

      Table 1 LSI-11/73 versus LSI-11/23

      +--------------------------+-----------------------+---------------------+
      |	       FEATURE		 |	   11/73	 |	 11/23	       |
      +==========================+=======================+=====================+
      | Odd Address Traps	 |	    Yes		 |	   No	       |
      +--------------------------+-----------------------+---------------------+
      | Micro ODT		 |	   22 Bit	 |	  18 Bit       |
      +--------------------------+-----------------------+---------------------+
      | Illegal Halt		 |	  Traps to 4	 |     Traps to 10     |
      +--------------------------+-----------------------+---------------------+
      | Processor Modes		 |	      3		 |	    2	       |
      +--------------------------+-----------------------+---------------------+
      | I & D Space		 |	     Yes	 |	   No	       |
      +--------------------------+-----------------------+---------------------+
      | General Purpose Reg Sets |	      2		 |	    1	       |
      +--------------------------+-----------------------+---------------------+
      | Floating Point Inst. Set |	   Standard	 |	  Option       |
      +--------------------------+-----------------------+---------------------+
      | Line Time Clock Reg.	 |	     Yes	 |	    No	       |
      +--------------------------+-----------------------+---------------------+
      | On-board Cache Memory	 |	     Yes	 |	    No	       |
      +--------------------------+-----------------------+---------------------+
      | Pipelined Processing	 |	     Yes	 |	    No	       |
      +--------------------------+-----------------------+---------------------+
      | UBMap Signal on the Q-bus|	Not Available	 |	 Available     |
      +--------------------------+-----------------------+---------------------+
      | Additional Instructions	 |	CSM, TSTSET,	 |	    Not	       |
      |	       Available	 |	   WRTLCK	 |	 Available     |
      +--------------------------+-----------------------+---------------------+
								   cont'd

									Page 2


      Table 1 cont'd LSI-11/73 versus LSI-11/23

      +--------------------------+-----------------------+---------------------+
      |	       FEATURE		 |	   11/73	 |	 11/23	       |
      +==========================+=======================+=====================+
      |				 |			 |		       |
      |				 |  CPU Error Register	 +----+		       |
      |				 |  Memory System Error Reg   |		       |
      | Additional CPU Registers |  Cache Control Reg	      |	     Not       |
      |				 |  Hit/Miss Reg	      |	  Available    |
      |				 |  Program Interrupt Req Reg |		       |
      |				 |  Line Time Clock Reg	      |		       |
      |				 |  Maintenance Reg	 +----+		       |
      |				 |			 |		       |
      +--------------------------+-----------------------+---------------------+
      |				 |     A discussion of processor speed can     |
      |	   Processor Speed	 |   be found in the respective user guides    |
      |				 |			 |		       |
      |				 |    User Guide Part #	 |  User Guide Part #  |
      |				 |	 EK-KDJ1A-UG	 |     EK-KDF11-UG     |
      |				 |			 |		       |
      +--------------------------+-----------------------+---------------------+


			      ODD ADDRESS TRAPS

      The 11/73 processor will trap to 4 when it  encounters  an  odd  address
      reference.   i.e.	  whenever  an	address begins on an odd byte boundary
      (least significant bit = 1).  The 11/23 ignores odd  address  references
      and simply treats the LSB as a zero, effectively 'forcing' all addresses
      to begin on even byte  boundaries.   Odd	address	 traps	do  not	 occur
      frequently,  however  it is possible for code to run on an 11/23 and NOT
      run  on  an  11/73  because  of  them.   Fixes  for  these  errors   are
      straightforward.

		    MICRO ODT (Octal Debugging Technique)

      Both the 11/23 and the 11/73 implement  ODT  in  their  microcode.   The
      11/23 can use ODT to examine main memory locations from 0 to 256 Kbytes,
      but no further.  On the other hand, the 11/73 ODT can examine the full 4
      Mbyte  range  of	main memory.  When accessing addresses in the I/O page
      with an 11/73, a full 22 bit address must be specified.

	   Example: To look at the first instruction of the bootstrap code with
		    an 11/73 it is necessary to type:

		       @17773000/
		       or  @7777777777773000/

		       NOT @773000/	This is NOT enough because only
					18 bits have been specified.

									Page 3


				 ILLEGAL HALT

      The 11/23 and the	 11/73	respond	 differently  when  detecting  a  halt
      instruction  in  user or supervisor mode.	 The 11/23 traps to address 10
      whereas the 11/73 traps to address 4.  The 11/73 also sets  the  Illegal
      Halt Bit in the CPU ERROR Register to indicate an Illegal Halt occurred.

			       PROCESSOR MODES

      The 11/23 has two processor modes, KERNEL and USER.  The 11/73 has three
      KERNEL, SUPERVISOR and USER.

				I and D SPACE

      The concept of I and  D  space  is  used	in  mapping  information  into
      separate	physical memory segments, depending on whether the information
      is considered instructions (I) or data (D).  The use of I	 and  D	 space
      allows programs to exist in two virtual segments and effectively doubles
      the address available to the user from 64 Kbytes to 128 Kbytes.

      The 11/73 has the capability for I and D space whereas  the  11/23  does
      not.   To implement this feature, many more PAR/PDR pairs are necessary.
      The 11/73 has 48 PAR/PDR pairs, the 11/23 has only 16 PAR/PDR pairs.

			GENERAL PURPOSE REGISTER SETS

      The 11/23 and all previous LSI-11	 processors  have  1  set  of  general
      purpose  registers,  R0  thru  R7.   Some	 of these are used for special
      purposes.	 R7 is used as the program counter and R6 is used as the stack
      pointer.	Internal to the 11/23 are 2 registers used for stack pointers,
      one for each processor mode).  There are 5 additional registers R0  thru
      R5.

      The 11/73 has two sets of general purpose registers, listed in the table
      below.  Only eight are visible to the user at any given time.  There are
      two groups of six registers (R0 thru R5 and R0' thru  R5').   The	 group
      currently	 being used is selected by bit 11 in the Processor Status Word
      (PSW).  Only one stack pointer is visible to the user at	any  one  time
      and is determined by bits 14 and 15 in the PSW.

	 Register Number	      Designation
	      0			      R0      R0'
	      1			      R1      R1'
	      2			      R2      R2'
	      3			      R3      R3'
	      4			      R4      R4'
	      5			      R5      R5'
	     *6			      KSP     SSP    USP
	      7			      PC

		* KSP = Kernel Stack Pointer
		  SSP = Supervisor Stack Pointer
		  USP = User Stack Pointer

									Page 4


			FLOATING POINT INSTRUCTION SET

      Both the 11/23 and the 11/73 use the  FP11  Floating  Point  Instruction
      Set.   The  FP11	Instruction  Set is an option for the 11/23 (choice of
      either the KEF11 chip or the FPF11  floating  point  accelerator).   The
      FP11  instruction set is part of the J11 microprocessor microcode and is
      therefore a standard feature of the 11/73.

			   LINE TIME CLOCK REGISTER

      The original dual height 11/23 CPU does  not  have  an  LTC  (Line  Time
      Clock)  register	on  the	 board.	 In 11/23 based systems the BDV11 boot
      module contains the  LTC	reg.   In  order  to  enable  or  disable  LTC
      interrupts under software control, the 11/23 must write to this register
      over the Q-bus.


	      +---------+				   +---------+
	      |		|				   |	     |
	      |	 11/23	|				   |   LTC   |
	      |		|				   |   REG   |
	      |		|				   |	     |
	      |	   1	|				   |	     |
	      +--+   +--+				   +--+	  +--+
		 | 7 |					      |	  |
		 |   +----------------------------------------+	  +-------------
		 | 7 5 4 6		       Q-bus
		 +--------------------------------------------------------------

      The 11/73 has an LTC  register  on  the  CPU  board.   This  means  that
      whenever	the  11/73  wants  to  enable  or disable LTC interrupts under
      software control it writes to this on-board register.   The  address  of
      the  LTC	register (location 177546) is 'trapped' on the board and NEVER
      goes out onto the Q-bus.	When the 11/73 is used	in  a  system  with  a
      BDV11,  it  is recommended that software control over the LTC interrupts
      be disabled on the BDV11 (see uNOTE  114).

	      +---------+
	      |		|
	      |	 11/73	|
	      |		|
	      |		|
	      | 177546	|
	      +---------+
		 |   |
		 |   +----------------------------------------------------------
		 |			   Q-bus
		 +--------------------------------------------------------------

			    ON-BOARD CACHE MEMORY

      Cache memory systems are designed	 to  increase  CPU  performance.   The
      cache maintains copies of portions of main memory in very high-speed RAM
      and thus reduces access times significantly.

									Page 5


      The 11/73 is the first Q-bus  processor  to  implement  a	 cache	memory
      system.	The  cache  is	automatically  enabled	on  power-up  and  its
      operation is transparent to software.  However software  can  enable  or
      disable the cache by writing to the Cache Control Register (CCR).

      When the cache is enabled, any information fetched from main memory will
      be  'cached'  i.e.   placed  in the high-speed RAM.  Information fetched
      from an I/O device will NOT be 'cached' (i.e.  information fetched  from
      an address in the I/O page).


      CAUTION :	 Digital Equipment Corporation does not support a system which
      uses  shared  or	dual-ported  memory  on	 the Q-bus.  However there are
      applications  and	 non-DEC  add-on  hardware  which  do	support	  such
      configurations.  Consider the following:

      The system below uses an 11/73, has a certain amount of main  memory  as
      well  as	dual-ported  memory.   The  cache is enabled and the following
      sequence of events occur:

	  1.  The 11/73 reads a	 word  from  the  dual-ported  RAM  at
	  address  A  which  contains  the  value  X.	The  value  is
	  'cached'.
		  +---------+		  +---------+		  +---------+
		  |	    |		  |	    |		  |	    |
		  |  11/73  |		  |_________|		  | EXTERNAL|
		  |	    |	    +-----| A: X    | <-+	  | DEVICE  |
		  |	    |	    |	  |---------|	|	  |	    |
		  | A: X    |<------+	  |	    |	|	  |	    |
		  +---------+		  |	    |	|	  +---------+
					  |   RAM   |	|
					  |	    |	 Dual-Ported RAM
					  |	    |
					  +---------+

	  2. The external device writes a new value, Y, into location A.

		  +---------+		  +---------+		  +---------+
		  |	    |		  |	    |		  |	    |
		  |  11/73  |		  |_________|		  | EXTERNAL|
		  |	    |		  | A: Y    | <---------- | DEVICE  |
		  |	    |		  |---------|		  |	    |
		  | A: X    |		  |	    |		  |	    |
		  +---------+		  |	    |		  +---------+
					  |   RAM   |
					  |	    |
					  |	    |
					  +---------+
	  3.  The 11/73 references location A again, but finds that it
	  is  in  the  cache  and therefore uses the 'old' value of X.
	  But this is incorrect	 since	the  external  device  updated
	  location A with the new value Y.

      This anomaly can be corrected in a number of ways.

									Page 6


      A.  Put the dual ported RAM somewhere in the I/O page since any I/O page
      reference	 always	 bypasses  cache.  If the amount of dual-ported RAM is
      large this may not be practical.

      B.   The	memory	management  unit  contains  several  Page   Descriptor
      Registers	 (PDRs).   The	PDRs  contain  information  relative  to  page
      expansion, page length and access control.  Bit 15 of each  PDR  is  the
      Bypass Cache bit.	 If the PDR accessed during a relocation operation has
      this bit set the reference will go directly to  main  memory.   Hits  on
      reads  or	 writes	 will  result  in  invalidation	 of the accessed cache
      location.

      Enabling this bit in each PDR associated	with  the  dual-ported	memory
      will force these references to bypass cache.

      C.  Whenever the processor reads from the	 dual-ported  RAM,  add	 extra
      code which will simply turn off the cache prior to the read and turn the
      cache back on after the read is complete.	 Turning the cache on and  off
      can  be  done  by	 setting  the  appropriate  bits  in the Cache Control
      Register.

			     PIPELINED PROCESSING

      The 11/73 gets much of its performance by implementing  a	 prefetch  and
      predecode	  mechanism.   The  major  benefit  of	this  is  that	memory
      references are overlapped with  internal	operations  which  results  in
      faster   program	execution.   The  11/23	 does  not  implement  such  a
      mechanism.


      CAUTION  :   This	 implementation	 is  completely	 compatible  with  DEC
      hardware	and  software.	 However  there	 are  applications and non-DEC
      add-on hardware which may	 be  confused.	 Such  situations  are	easily
      corrected.


      The prefetch mechanism assumes sequential program flow;  one instruction
      immediately  follows  the	 next.	 Whenever  the	program	 flow  is  not
      sequential (i.e.	the PSW, CCR, PC or any memory management register  is
      written)	the  pipeline  is 'flushed'.  If a non-DEC device does its own
      'macro' memory management, the instruction flow may be confused.

      For example :

      A non-DEC device utilizes 2 ROM sets for boot code.  Both ROM  sets  map
      over  the	 same  addresses  but  only 1 set is enabled at any instant in
      time.  This is done via a ROM set enable CSR.  Assume the boot  code  in
      ROM  set	X is executing.	 Instruction X + 1 is a MOV instruction to the
      ROM enable CSR to transfer program control to ROM set Y.	The intent  of
      the  ROM	code  is for statement Y + 2 in ROM set 2 to be executed next.
      This will work OK with  an  11/23.   However  because  of	 the  prefetch
      mechanism	 of the 11/73, the 11/73 will execute instruction X + 2 of ROM
      set 1, NOT ROM set 2.

      This particular boot method effectively does its own memory mapping  and

									Page 7


      since  it	 is done at the 'macro' level and external to the J11 cpu, the
      pipeline is not 'flushed'.  A  simple  solution  is  to  include	a  NOP
      instruction  after  the instruction which updates the ROM enable CSR, or
      to use a branch instruction which effectively changes the PC and	causes
      the pipeline to be 'flushed'.


					      User Boot Device
	      +---------+	   +------------------------------------------+
	      |		|	   |	       ROM X		  ROM Y	      |
	      |	 11/73	|	   |	      +-------+		+-------+     |
	      |		|	   |  X	      |	      |	  Y	|	|     |
	      |		|	   |  X + 1   |	      |	  Y + 1 |	|     |
	      |		|	   |  X + 2   |	      |	  Y + 2 |	|     |
	      +---------+	   |  .	      |	      |	  .	|	|     |
				   |  .	      |	      |	  .	|	|     |
      Sequence of events :	   |  .	      |	      |	  .	|	|     |
      1. ROM X is enabled.	   |  X + n   |	      |	  Y + n |	|     |
				   |	      |	      |		|	|     |
      2. Instruction X + 1 enables |	      +-------+		+-------+     |
	 ROM Y.			   |  +----------------+		      |
				   |  | ROM Enable CSR |		      |
      3. Next instruction to be	   |  +----------------+		      |
	 executed is Y + 2.	   +------------------------------------------+

		      MAP SIGNAL ON THE Q-BUS (UBMAP L)

      The 11/23 outputs the signal UBMAP onto the Q-bus.  Some non-DEC	add-on
      equipment	 may use this signal for special purposes.  This signal is not
      defined by the Q-bus  specification  and	for  design  reasons  was  not
      included	on  the 11/73.	Therefore, the 11/73 may not work with non-DEC
      devices which expect to see this signal.

		      ADDITIONAL INSTRUCTIONS AVAILABLE

      These 3 instructions are part of the 11/73 instruction set but  are  NOT
      found in the 11/23:

		      CSM     Call to Supervisor Mode
		      TSTSET  Test Destination and Set Low Bit
		      WRTLCK  Read/Lock Destination Write/Unlock R0 into
			      Destination

									Page 8


		      ADDITIONAL CPU REGISTERS AVAILABLE

      The following CPU registers are part of the DCJ11 chip or implemented on
      the 11/73 module and are not found on the 11/23.

		      CPU Error Register
		      Memory System Error Register
		      Cache Control Register
		      Hit/Miss Register
		      Additional PAR/PDR's necessary to implement I & D Space
		      Program Interrupt Request Register
		      Line Time Clock Register (previously discussed)
		      Maintenance Register

			       PROCESSOR SPEED

      The 11/73 executes instructions significantly  faster  than  the	11/23.
      Software	which  bases  delays  on instruction loops may not work on the
      11/73 because the	 instructions,	and  therefore	the  delay  loop,  are
      completed	 much  faster  than  they  were	 when  executed	 on the 11/23.
      Software which uses this method of  implementing	delays	produces  code
      which  is	 not processor independent.  However instances do appear every
      so often and it is important to be aware of this possibility.

================================================================================
Note 7.0                      Falcon(+) Memory Maps                   No replies
JAWS::KAISER                                        691 lines  25-MAR-1985 09:16
--------------------------------------------------------------------------------
      +---------------+					   +-----------------+
      | d i g i t a l |					   |  uNOTE # 007    |
      +---------------+					   +-----------------+


      +----------------------------------------------------+-----------------+
      | Title: User Defined Memory Maps for the FALCON	   | Date: 01-May-84 |
      |			  and the FALCON+		   |		     |
      +----------------------------------------------------+-----------------+
      | Originator: Jack Toto				   | Page 1 of 12    |
      +----------------------------------------------------+-----------------+


      The memory maps on the Falcon, and Falcon Plus are defined by  the  FPLA
      (Field  Programmable  Logic  Array)  that	 is located on board in socket
      XE41.  This micronote explains how to redefine the existing maps.

      The equipment needed to custom build the FPLA is as follows:

      1. Signetics NS82S100N FPLA.
      2. Signetics NS82S100N FPLA worksheet.
      3. PROM programmer that supports Signetics NS82S100N FPLA.
      4. User written routine to convert binary into hex form,
	     needed for the PROM programmer.

      The Falcon or Falcon Plus can be configured to any one of four  standard
      memory  maps.   When  you custom build the memory map FPLA, you may keep
      this ability to select any one of four memory map schemes, however it is
      not nessecary to build in the four maps, you may build an FPLA with only
      one map for the Falcon.  Further the addresses of the SLUs and  Parallel
      I/O  Port	 can  be  be changed to some other addresses on the module, or
      they can be relocated off the module to some other  device  such	as  an
      MXV11-A/B, DLV11-J, DRV11-J, etc.

      The memory map is defined by:

      1. Selecting a range of addresses, for example addresses 077777 - 037777.
	 This includes selecting the addresses of the boards SLUs and PIO.
      2. Asserting or deasserting the bits which define that range.
      3. Defining which one of four memory maps the selected range of
	   addresses will respond.
      4. Selecting an enable bit (A7 -A0), which tells the T-11 where to
	 find that range of addresses: on the Q-bus, on board the Falcon Plus
	   in one of the two sockets, or in the local RAM.

      When mapping an FPLA to be used with the KXT11-A2 or KXT11-A5 ODT	 ROMs,
      you  must	 map  addresses 177600 - 177777 to the local RAM that comes on
      board the Falcon or Falcon Plus.	This space is used for a  scratch  pad
      area  by	Macro  ODT.   If  Macro	 ODT is not going to be used than this
      address range can be left to be selected by the user.  Beyond  this  all
      addresses and functions can be mapped off board.

      Below is an example of an FPLA worksheet that was	 completed  specifying
      one  map	(map 0) which maps all of memory to the Q-bus, and changes the
      address of SLU2 from 176540 - 176547, to 176500 - 176507.	  This	format
									Page 2


      is  simalar  to  the  Signetics  FPLA worksheet.	For each address range
      shown, the combination of bits set (H), cleared (L),  or	in  the	 don't
      care  state  (-)	define	that  range.   Further	each address range has
      associated with it an output enable bit (A) that identifies the location
      of the memory containing that range.  It is possible to define larger or
      smaller ranges then the ones shown here, if needed.  More	 examples  are
      provided in the Falcon Plus User's Guide Appendix H.


      THIS IS AN FPLA MAP FOR
      COMPANY: XYZ




			  I I I I I I I I I I I I I  I I  I

			  0 0 0 0 0 1 0 1 0 1 0 1 0  1 0  1
			  7 8 6 9 5 0 4 1 3 2 2 3 1  5 0  4   F F F F F F F
      --------------------------------------------------------------------------
      ADDRESS	      X	  1 1 1 1 1 1 0 0 0 0 0 0 0  0 0  0   7 6 5 4 3 2 1 0
      RANGE	      X	  5 4 3 2 1 0 9 8 7 6 5 4 3  2 1  0

      177600-177777  RAM  - - - H H H H H H - - - -  L L  H   A		      00
      177570-177577  QB	  - - - H H H H H L H H H H  L L  H		A     01
      177560-177567  DL0  - - - H H H H H L H H H L  L L  H	   A	      02
      177540-177557  QB	  - - - H H H H H L H H L -  L L  H		A     03
      177500-177537  QB	  - - - H H H H H L H L - -  L L  H		A     04
      177400-177477  QB	  - - - H H H H H L L - - -  L L  H		A     05
      177000-177377  QB	  - - - H H H H L - - - - -  L L  H		A     06
      176600-176777  QB	  - - - H H H L H H - - - -  L L  H		A     07
      176560-176577  QB	  - - - H H H L H L H H H -  L L  H		A     08
      176550-176557  QB	  - - - H H H L H L H H L H  L L  H		A     09
      176540-176547  QB	  - - - H H H L H L H H L L  L L  H		A     10
      176510-176537  QB	  - - - H H H L H L H L - H  L L  H		A     11
      176500-176507  DL1  - - - H H H L H L H L L L  L L  H		  A   12
      176400-176477  QB	  - - - H H H L H L L - - -  L L  H		A     13
      176300-176377  QB	  - - - H H H L L H H - - -  L L  H		A     14
      176240-176277  QB	  - - - H H H L L H L H - -  L L  H		A     15
      176220-176237  QB	  - - - H H H L L H L L H -  L L  H		A     16
      176210-176217  QB	  - - - H H H L L H L L L H  L L  H		A     17
      176200-176207  PIO  - - - H H H L L H L L L L  L L  H	    A	      18
      176000-176177  QB	  - - - H H H L L L - - - -  L L  H		A     19
      174000-175777  QB	  - - - H H L - - - - - - -  L L  H		A     20
      170000-173777  QB	  - - - H L - - - - - - - -  L L  H		A     21
      160000-167777  QB	  - - - L - - - - - - - - -  L L  H		A     22
      140000-157777  QB	  H H L - - - - - - - - - -  L L  L		A     23
      100000-137777  QB	  H L - - - - - - - - - - -  L L  L		A     24
      000000-077777  QB	  L - - - - - - - - - - - -  L L  L		A     25

							      7 6 5 4 3 2 1 0
									Page 3


      Once the address ranges have been coded, they need to be converted  into
      the  formatted file shown directly below.	 This file will be used as the
      input file to a program (see end of Micronote) that will output the FPLA
      terms  in	 a  format that is usable by the PROM Programmer itself.  When
      converting the above worksheet to FPLA terms, the	 following  should  be
      considered:


      1. The area at the beginning of the file may be used as a comment area
	 as long as the word "START" is not used in the comments. "START" is
	 the key word to begin the formatting process while the word "END" is
	 the key word used to signal the formatter that the processing must be
	 terminated. Both words MUST appear in capital letters.

      2. The layout of the map must be as follows:
								    -----
	 I15 I14 I13 I12 I11 I10 I09 I08 I07 I06 I05 I04 I03 I02 I01 I00 | TERM1
	 O7  O6	 O5  O4	 O3  O2	 O1  O0					 |
								    -----
								    -----
	 I15 I14 I13 I12 I11 I10 I09 I08 I07 I06 I05 I04 I03 I02 I01 I00 | TERM2
	 O7  O6	 O5  O4	 O3  O2	 O1  O0					 |
								     ----

	 Where I15 is input 15 on the FPLA ,I14 is input 14 on the PLA etc.
	 further O7 is output 7 on the FPLA and O6 is output 6 on the PLA.

      3. "-" indicates a "DON'T CARE ON THAT INPUT" AND * indicates a "DON'T
	 CARE ON THIS OUTPUT".

      The following is the formatted FPLA map for the worksheet	 shown	above.
      Notice  that  bus address bit 00 is translated to FPLA bit I14, that bus
      address 01 is translated to FPLA bit I00, that is, the bus address  bits
      are  not	directly  translated  to  the FPLA bits, however the worksheet
      activity (output) bits F7 - F0 translate directly to FPLA bits A7 - A0.

      START
      LH--HHH---HHH--L
      A*******
      LHHHHHH---HHLHHL
      *****A**
      LHHHHHH---HHLHLL
      **A*****
      LHLHHHH---HHLH-L
      *****A**
      LH-HHHH---HHLL-L
      *****A**
      LH-LHHH---HHL--L
      *****A**
      LH--LHH---HH---L
      *****A**
      LH--HHH---HLH--L
      *****A**
      LHHHHHH---HLLH-L
      *****A**
									Page 4


      LHLHHHH---HLLHHL
      *****A**
      LHLHHHH---HLLHLL
      *****A**
      LH-HHHH---HLLLHL
      *****A**
      LHLHHHH---HLLLLL
      ******A*
      LH-LHHH---HLL--L
      *****A**
      LH-HLHH---HLH--L
      *****A**
      LH-LLHH---HLHH-L
      *****A**
      LHHLLHH---HLHL-L
      *****A**
      LHLLLHH---HLHLHL
      *****A**
      LHLLLHH---HLHLLL
      ***A****
      LH--LHH---HLL--L
      *****A**
      LH---LH---H----L
      *****A**
      LH----H---L----L
      *****A**
      LH----L--------L
      *****A**
      LL-----HHL-----L
      *****A**
      LL-----LH------L
      *****A**
      LL------L------L
      *****A**



      Translation: The following is a translation of FPLA terms and FPLA
		   activity outputs, and the actual pin name on the FPAL chip.

      I15....D15 (02 on worksheet above) used for high order bit of map decode.
      I14....LBS7 (00 on worksheet above) asserted for all I/O page addresses.
      I13....AD04
      I12....AD06
      I11....AD08
      I10....AD10
      I09....AD12
      I08....AD14
      I07....AD15
      I06....AD13
      I05....AD11
      I04....AD09
      I03....AD07
      I02....AD05
      I01....AD03
									Page 5


      I00....DO (01 on worksheet above) used for the low order bit of map decode.

      A7.....F7 on worksheet above, used for local RAM enable.
      A6.....F6 on worksheet above, used for socket A enable.
      A5.....F5 on worksheet above, used for DL0 enable.
      A4.....F4 on worksheet above, used for PIO enable.
      A3.....F3 on worksheet above, not used.
      A2.....F2 on worksheet above, used for all Q-bus enables.
      A1.....F1 on worksheet above, used for DL1 enable.
      A0.....F0 on worksheet above, used for socket B enable.

      The output file shown below is an example of one that would be  loadable
      into a PROM Programmer in order to blast the FPLA chip.  An example of a
      program that will produce the formatted output file shown below  can  be
      found at the end of this micronote.

      START
      $A0000,  ( ADDRESS )
      FF       ( FIRST 8 BITS )
      $A100,   ( ADDRESS )
      FF
      00
      FD
      FB
      F1
      EF
      7E
      C1
      80
      7F
      00
      FF
      FF
      FF
      FF
      FF
      FF
      FF
      .
      .	       ( OTHER TERMS IN HEX BYTES )
      .
      .
      $A200    ( NEXT ADDRESS BOUNDARY )
      .
      .	       ( TERMS )
      .
      $A300    ( ADDRESS )
      .
      .	       ( TERMS )
      .
      $A400    ( ADRESSS )
      .
      .	       ( TERMS )
      .
      ETC.
									Page 6


      Once the FPLA is built, it is placed into socket XE41, the  memory  will
      be  configured  to  whatever  the FPLA terms look like.  The Falcon Plus
      needs to be strapped for a start address, a memory map  (1  of  4)  that
      matches  the  one	 called	 out  in the FPLA, and other user configurable
      options.

      FPLA FORMAT PROGRAM **********
      ==============================

      1 REM THIS PROGRAM IS FOR NORMAL PLA MAP INPUTS
      2 PRINT "INPUT DEVICE AND FILE NAME";H1$
      4 INPUT H1$
      5 OPEN H1$ FOR INPUT AS FILE #1
      7 PRINT "DO YOU WISH OUTPUT COMPARE FILE ON LINE PRINTER,DEVICE,BOTH OR NONE ? "
      8 PRINT "DEFAULT IS NONE (LP,DEV,B,N) ";N1$
      10 INPUT N1$
      12 IF N1$="LP" THEN  GO TO 30
      16 IF N1$="DEV" THEN  GO TO 36
      20 IF N1$="B" THEN  GO TO 42
      22 LET N$="N"
      23 LET K1$="N"
      24 GO TO 50
      30 OPEN "LP:" FOR OUTPUT AS FILE #2
      33 LET N$="Y"
      34 LET K1$="N"
      35 GO TO 50
      36 PRINT "WHAT IS DEVICE AND FILE NAME";U1$ \ INPUT U1$
      37 OPEN U1$ FOR OUTPUT AS FILE #3
      38 LET N$="N"
      39 LET K1$="Y"
      40 GO TO 50
      42 OPEN "LP:" FOR OUTPUT AS FILE #2
      45 LET N$="Y"
      46 PRINT "WHAT IS DEVICE AND FILE NAME";U1$ \ INPUT U1$
      47 OPEN U1$ FOR OUTPUT AS FILE #3
      48 LET K1$="Y"
      50 PRINT "WHAT DEVICE AND FILE NAME FOR OUTPUT PROM PROGRAMMER FILE";W$
      52 INPUT W$
      55 OPEN W$ FOR OUTPUT AS FILE #4
      60 LET Y1=1
      62 LET H1$=CHR$(2)
      64 LET H2$=CHR$(3)
      66 LET Z$=CHR$(10)+CHR$(13)
      68 LET L1$=" "
      70 INPUT #1,A$
      71 IF N$="N" THEN	 GO TO 73
      72 PRINT #2,A$
      73 IF K1$="N" THEN  GO TO 76
      74 PRINT #3,A$
      75 PRINT #4,A$
      76 IF A$="START" THEN  GO TO 80
      78 GO TO 70
      80 LET S1$="$A0000,"
      82 PRINT #4,H1$;S1$
      84 PRINT #4,"FF "
									Page 7


      86 LET S1$="$A100,"
      88 PRINT #4,S1$
      90 GO TO 92
      91 PRINT #4,S1$
      93 INPUT #1,I1$
      92 IF I1$="END" THEN  GO TO 120
      94 INPUT #1,O1$
      95 INPUT #1,I2$
      96 IF I2$="END" THEN  GO TO 130
      97 INPUT #1,O2$
      98 INPUT #1,I3$
      99  IF I3$="END" THEN  GO TO 140
      100 INPUT #1,O3$
      101 INPUT #1,I4$
      102 IF I4$="END" THEN  GO TO 150
      103 INPUT #1,O4$
      104 INPUT #1,I5$
      105 IF I5$="END" THEN  GO TO 160
      106 INPUT #1,O5$
      107 INPUT #1,I6$
      108 IF I6$="END" THEN  GO TO 170
      109 INPUT #1,O6$
      110 INPUT #1,I7$
      111 IF I7$="END" THEN  GO TO 180
      112 INPUT #1,O7$
      113 INPUT #1,I8$
      114 IF I8$="END" THEN  GO TO 190
      115 INPUT #1,O8$
      117 GO TO 200
      120 LET I1$="0000000000000000" \ LET O1$="AAAAAAAA"
      121 LET I2$="0000000000000000" \ LET O2$="AAAAAAAA"
      122 LET I3$="0000000000000000" \ LET O3$="AAAAAAAA"
      123 LET I4$="0000000000000000" \ LET O4$="AAAAAAAA"
      124 LET I5$="0000000000000000" \ LET O5$="AAAAAAAA"
      125 LET I6$="0000000000000000" \ LET O6$="AAAAAAAA"
      126 LET I7$="0000000000000000" \ LET O7$="AAAAAAAA"
      127 LET I8$="0000000000000000" \ LET O8$="AAAAAAAA"
      128 LET E1=1
      129 GO TO 200
      130 LET I2$="0000000000000000" \ LET O2$="AAAAAAAA"
      132 LET I3$="0000000000000000" \ LET O3$="AAAAAAAA"
      133 LET I4$="0000000000000000" \ LET O4$="AAAAAAAA"
      134 LET I5$="0000000000000000" \ LET O5$="AAAAAAAA"
      135 LET I6$="0000000000000000" \ LET O6$="AAAAAAAA"
      136 LET I7$="0000000000000000" \ LET O7$="AAAAAAAA"
      137 LET I8$="0000000000000000" \ LET O8$="AAAAAAAA"
      138 LET E1=1
      139 GO TO 200
      140 LET I3$="0000000000000000" \ LET O3$="AAAAAAAA"
      143 LET I4$="0000000000000000" \ LET O4$="AAAAAAAA"
      144 LET I5$="0000000000000000" \ LET O5$="AAAAAAAA"
      145 LET I6$="0000000000000000" \ LET O6$="AAAAAAAA"
      146 LET I7$="0000000000000000" \ LET O7$="AAAAAAAA"
      147 LET I8$="0000000000000000" \ LET O8$="AAAAAAAA"
      148 LET E1=1
									Page 8


      149 GO TO 200
      150 LET I4$="0000000000000000" \ LET O4$="AAAAAAAA"
      154 LET I5$="0000000000000000" \ LET O5$="AAAAAAAA"
      155 LET I6$="0000000000000000" \ LET O6$="AAAAAAAA"
      156 LET I7$="0000000000000000" \ LET O7$="AAAAAAAA"
      157 LET I8$="0000000000000000" \ LET O8$="AAAAAAAA"
      158 LET E1=1
      159 GO TO 200
      160 LET I5$="0000000000000000" \ LET O5$="AAAAAAAA"
      165 LET I6$="0000000000000000" \ LET O6$="AAAAAAAA"
      166 LET I7$="0000000000000000" \ LET O7$="AAAAAAAA"
      167 LET I8$="0000000000000000" \ LET O8$="AAAAAAAA"
      168 LET E1=1
      169 GO TO 200
      170 LET I6$="0000000000000000" \ LET O6$="AAAAAAAA"
      176 LET I7$="0000000000000000" \ LET O7$="AAAAAAAA"
      177 LET I8$="0000000000000000" \ LET O8$="AAAAAAAA"
      178 LET E1=1
      179 GO TO 200
      180 LET I7$="0000000000000000" \ LET O7$="AAAAAAAA"
      187 LET I8$="0000000000000000" \ LET O8$="AAAAAAAA"
      188 LET E1=1
      189 GO TO 200
      190 LET I8$="0000000000000000" \ LET O8$="AAAAAAAA"
      198 LET E1=1
      200 PRINT I1$,O1$,Z$,I2$,O2$,Z$,I3$,O3$,Z$,I4$,O4$
      210 PRINT I5$,O5$,Z$,I6$,O6$,Z$,I7$,O7$,Z$,I8$,O8$
      215 IF N$="N" THEN  GO TO 218
      216 PRINT #2,I1$,O1$,Z$,I2$,O2$,Z$,I3$,O3$,Z$,I4$,O4$
      217 PRINT #2,I5$,O5$,Z$,I6$,O6$,Z$,I7$,O7$,Z$,I8$,O8$
      218 IF K1$="N" THEN  GO TO 221
      219 PRINT #3,I1$,O1$,Z$,I2$,O2$,Z$,I3$,O3$,Z$,I4$,O4$
      220 PRINT #3,I5$,O5$,Z$,I6$,O6$,Z$,I7$,O7$,Z$,I8$,O8$
      221 LET X=16
      235 LET D1$=SEG$(I1$,X,X)
      240 IF D1$="H" GO TO 260
      245 IF D1$="L" GO TO 270
      250 IF D1$="-" GO TO 280
      252 IF D1$="0" GO TO 256
      255 GO TO 1340
      256 LET A(1,0)=1 \ LET A(1,1)=1
      257 GO TO 285
      260 LET A(1,0)=1 \ LET A(1,1)=0
      265 GO TO 285
      270 LET A(1,0)=0 \ LET A(1,1)=1
      275 GO TO 285
      280 LET A(1,0)=0 \ LET A(1,1)=0
      285 LET D2$=SEG$(I2$,X,X)
      290 IF D2$="H" GO TO 315
      300 IF D2$="L" GO TO 325
      305 IF D2$="-" GO TO 335
      306 IF D2$="0" GO TO 309
      307 GO TO 1340
      309 LET A(1,2)=1 \ LET A(1,3)=1
      310 GO TO 340
									Page 9


      315 LET A(1,2)=1 \ LET A(1,3)=0
      320 GO TO 340
      325 LET A(1,2)=0 \ LET A(1,3)=1
      330 GO TO 340
      335 LET A(1,2)=0 \ LET A(1,3)=0
      340 LET D3$=SEG$(I3$,X,X)
      345 IF D3$="H" GO TO 365
      350 IF D3$="L" GO TO 375
      355 IF D3$="-" GO TO 385
      357 IF D3$="0" GO TO 359
      358 GO TO 1340
      359 LET A(1,4)=1 \ LET A(1,5)=1
      360 GO TO 390
      365 LET A(1,4)=1 \ LET A(1,5)=0
      370 GO TO 390
      375 LET A(1,4)=0 \ LET A(1,5)=1
      380 GO TO 390
      385 LET A(1,4)=0 \ LET A(1,5)=0
      390 LET D4$=SEG$(I4$,X,X)
      400 IF D4$="H" GO TO 420
      405 IF D4$="L" GO TO 430
      410 IF D4$="-" GO TO 440
      412 IF D4$="0" GO TO 414
      413 GO TO 1340
      414 LET A(1,6)=1 \ LET A(1,7)=1
      415 GO TO 445
      420 LET A(1,6)=1 \ LET A(1,7)=0
      425 GO TO 445
      430 LET A(1,6)=0 \ LET A(1,7)=1
      435 GO TO 445
      440 LET A(1,6)=0 \ LET A(1,7)=0
      445 LET A8=A(1,0)*1+A(1,2)*2+A(1,4)*4+A(1,6)*8
      450 LET A9=A(1,1)*1+A(1,3)*2+A(1,5)*4+A(1,7)*8
      455 LET A8=15-A8 \ LET A9=15-A9
      460 LET D5$=SEG$(I5$,X,X)
      465 IF D5$="H" GO TO 485
      470 IF D5$="L" GO TO 495
      475 IF D5$="-" GO TO 505
      476 IF D5$="0" GO TO 479
      477 GO TO 1340
      479 LET B(1,0)=1 \ LET B(1,1)=1
      480 GO TO 510
      485 LET B(1,0)=1 \ LET B(1,1)=0
      490 GO TO 510
      495 LET B(1,0)=0 \ LET B(1,1)=1
      500 GO TO 510
      505 LET B(1,0)=0 \ LET B(1,1)=0
      510 LET D6$=SEG$(I6$,X,X)
      515 IF D6$="H" GO TO 535
      520 IF D6$="L" GO TO 545
      525 IF D6$="-" GO TO 555
      526 IF D6$="0" GO TO 529
      527 GO TO 1340
      529 LET B(1,2)=1 \ LET B(1,3)=1
      530 GO TO 560
								       Page 10


      535 LET B(1,2)=1 \ LET B(1,3)=0
      540 GO TO 560
      545 LET B(1,2)=0 \ LET B(1,3)=1
      550 GO TO 560
      555 LET B(1,2)=0 \ LET B(1,3)=0
      560 LET D7$=SEG$(I7$,X,X)
      565 IF D7$="H" GO TO 585
      570 IF D7$="L" GO TO 595
      575 IF D7$="-" GO TO 605
      576 IF D7$="0" GO TO 579
      577 GO TO 1340
      579 LET B(1,4)=1 \ LET B(1,5)=1
      580 GO TO 610
      585 LET B(1,4)=1 \ LET B(1,5)=0
      590 GO TO 610
      595 LET B(1,4)=0 \ LET B(1,5)=1
      600 GO TO 610
      605 LET B(1,4)=0 \ LET B(1,5)=0
      610 LET D8$=SEG$(I8$,X,X)
      615 IF D8$="H" GO TO 635
      620 IF D8$="L" GO TO 645
      625 IF D8$="-" GO TO 655
      626 IF D8$="0" GO TO 629
      627 GO TO 1340
      629 LET B(1,6)=1 \ LET B(1,7)=1
      630 GO TO 660
      635 LET B(1,6)=1 \ LET B(1,7)=0
      640 GO TO 660
      645 LET B(1,6)=0 \ LET B(1,7)=1
      650 GO TO 660
      655 LET B(1,6)=0 \ LET B(1,7)=0
      660 LET B8=B(1,0)*1+B(1,2)*2+B(1,4)*4+B(1,6)*8
      665 LET B9=B(1,1)*1+B(1,3)*2+B(1,5)*4+B(1,7)*8
      670 LET B8=15-B8 \ LET B9=15-B9
      675 IF B8<10 THEN LET P1=0
      680 IF B8<10 THEN	 GO TO 720
      685 IF B8=10 THEN LET B8$="A"
      690 IF B8=11 THEN LET B8$="B"
      695 IF B8=12 THEN LET B8$="C"
      700 IF B8=13 THEN LET B8$="D"
      705 IF B8=14 THEN LET B8$="E"
      710 IF B8=15 THEN LET B8$="F"
      715 LET P1=1
      720 IF A8<10 THEN LET P0=0
      725 IF A8<10 THEN	 GO TO 765
      730 IF A8=10 THEN LET A8$="A"
      735 IF A8=11 THEN LET A8$="B"
      740 IF A8=12 THEN LET A8$="C"
      745 IF A8=13 THEN LET A8$="D"
      750 IF A8=14 THEN LET A8$="E"
      755 IF A8=15 THEN LET A8$="F"
      760 LET P0=1
      765 IF P1=0 THEN	GO TO 780
      770 IF P0=0 THEN	GO TO 805
      775 GO TO 795
								       Page 11


      780 IF P0=1 THEN	GO TO 815
      785 PRINT #4,STR$(B8);STR$(A8);L1$
      790 GO TO 820
      795 PRINT #4,B8$;A8$;L1$
      800 GO TO 820
      805 PRINT #4,B8$;STR$(A8);L1$
      810 GO TO 820
      815 PRINT #4,STR$(B8);A8$;L1$
      820 IF B9<10 THEN LET P3=0
      825 IF B9<10 THEN	 GO TO 865
      830 IF B9=10 THEN LET B9$="A"
      835 IF B9=11 THEN LET B9$="B"
      840 IF B9=12 THEN LET B9$="C"
      845 IF B9=13 THEN LET B9$="D"
      850 IF B9=14 THEN LET B9$="E"
      855 IF B9=15 THEN LET B9$="F"
      860 LET P3=1
      865 IF A9<10 THEN LET P2=0
      870 IF A9<10 THEN	 GO TO 910
      875 IF A9=10 THEN LET A9$="A"
      880 IF A9=11 THEN LET A9$="B"
      885 IF A9=12 THEN LET A9$="C"
      890 IF A9=13 THEN LET A9$="D"
      895 IF A9=14 THEN LET A9$="E"
      900 IF A9=15 THEN LET A9$="F"
      905 LET P2=1
      910 IF P3=0 THEN	GO TO 925
      915 IF P2=0 THEN	GO TO 945
      920 GO TO 937
      925 IF P2=1 THEN	GO TO 955
      930 PRINT #4,STR$(B9);STR$(A9);L1$
      935 GO TO 960
      937 PRINT #4,B9$;A9$;L1$
      940 GO TO 960
      945 PRINT #4,B9$;STR$(A9);L1$
      950 GO TO 960
      955 PRINT #4,STR$(B9);A9$;L1$
      960 LET X=X-1
      965 IF X>0 THEN  GO TO 235
      970 LET Y=8
      975 LET C1$=SEG$(O1$,Y,Y)
      980 IF C1$="A" THEN LET A1=1
      985 IF C1$="*" THEN LET A1=0
      990 LET C2$=SEG$(O2$,Y,Y)
      995 IF C2$="A" THEN LET A2=1
      1000 IF C2$="*" THEN LET A2=0
      1005 LET C3$=SEG$(O3$,Y,Y)
      1010 IF C3$="A" THEN LET A3=1
      1015 IF C3$="*" THEN LET A3=0
      1020 LET C4$=SEG$(O4$,Y,Y)
      1025 IF C4$="A" THEN LET A4=1
      1030 IF C4$="*" THEN LET A4=0
      1035 LET C5$=SEG$(O5$,Y,Y)
      1040 IF C5$="A" THEN LET A5=1
      1045 IF C5$="*" THEN LET A5=0
								       Page 12

      1050 LET C6$=SEG$(O6$,Y,Y)
      1055 IF C6$="A" THEN LET A6=1
      1060 IF C6$="*" THEN LET A6=0
      1065 LET C7$=SEG$(O7$,Y,Y)
      1070 IF C7$="A" THEN LET A7=1
      1075 IF C7$="*" THEN LET A7=0
      1080 LET C8$=SEG$(O8$,Y,Y)
      1085 IF C8$="A" THEN LET F8=1
      1090 IF C8$="*" THEN LET F8=0
      1095 LET O9=(A1*1)+(A2*2)+(A3*4)+(A4*8)
      1100 LET P9=(A5*1)+(A6*2)+(A7*4)+(F8*8)
      1105 LET O9=15-O9 \ LET P9=15-P9
      1110 IF P9<10 THEN LET T1=0
      1115 IF P9<10 THEN  GO TO 1155
      1120 IF P9=10 THEN LET P9$="A"
      1125 IF P9=11 THEN LET P9$="B"
      1130 IF P9=12 THEN LET P9$="C"
      1135 IF P9=13 THEN LET P9$="D"
      1140 IF P9=14 THEN LET P9$="E"
      1145 IF P9=15 THEN LET P9$="F"
      1150 LET T1=1
      1155 IF O9<10 THEN LET T0=0
      1160 IF O9<10 THEN  GO TO 1200
      1165 IF O9=10 THEN LET O9$="A"
      1170 IF O9=11 THEN LET O9$="B"
      1175 IF O9=12 THEN LET O9$="C"
      1180 IF O9=13 THEN LET O9$="D"
      1185 IF O9=14 THEN LET O9$="E"
      1190 IF O9=15 THEN LET O9$="F"
      1195 LET T0=1
      1200 IF T1=0 THEN	 GO TO 1215
      1205 IF T0=0 THEN	 GO TO 1240
      1210 GO TO 1230
      1215 IF T0=1 THEN	 GO TO 1255
      1220 PRINT #4,STR$(P9);STR$(O9);L1$
      1225 GO TO 1260
      1230 PRINT #4,P9$;O9$;L1$
      1235 GO TO 1260
      1240 PRINT #4,P9$;STR$(O9);L1$
      1250 GO TO 1260
      1255 PRINT #4,STR$(P9);O9$;L1$
      1260 LET Y=Y-1
      1265 IF Y>0 THEN	GO TO 975
      1270 PRINT #4,Z$
      1275 LET Y1=Y1+1
      1280 IF Y1=2 THEN LET S1$="$A200,"
      1285 IF Y1=3 THEN LET S1$="$A300,"
      1290 IF Y1=4 THEN LET S1$="$A400,"
      1295 IF Y1=5 THEN LET S1$="$A500,"
      1300 IF Y1=6 THEN LET S1$="$A600,"
      1305 PRINT #4,Z$
      1310 IF Y1=7 THEN	 GO TO 1320
      1315 IF E1=0 THEN	 GO TO 91
      1320 PRINT #4,H2$
      1330 CLOSE
      1335 GO TO 1345
      1340 PRINT "INPUT LINE IN ERROR"
      1345 END

================================================================================
Note 8.0                   LSI-11/73 Memory Managment                 No replies
JAWS::KAISER                                        558 lines  25-MAR-1985 09:17
--------------------------------------------------------------------------------
      +---------------+					   +-----------------+
      | d i g i t a l |					   |  uNOTE # 008    |
      +---------------+					   +-----------------+


      +----------------------------------------------------+-----------------+
      | Title: Memory Management and the LSI-11/73	   | Date: 22-Jun-84 |
      +----------------------------------------------------+-----------------+
      | Originator: Dave Smith				   | Page 1 of 10    |
      +----------------------------------------------------+-----------------+


      This  micronote  explains	 memory	 management  as	 it  applies  to   the
      LSI-11/73.   It includes descriptions of what memory management is, what
      it does, and how it works.

      Simply  stated,  memory  management  is  a  method  of  mapping  virtual
      addresses	 to physical addresses.	 The virtual address space is the view
      of memory as seen by a process running.  The physical address  space  is
      the  actual  physical  memory  as	 seen by the entire system.  Since ALL
      memory references must be mapped, this translation is done  in  hardware
      by  using	 a  Memory  Management Unit (MMU).  Various schemes (dependent
      upon the architecture) have been developed to accomplish this, but  most
      memory management systems provide the following services:

		     1) Protection

		     2) Relocation

		     3) Segmentation


      The first two are of great importance in a multiprogramming system since
      memory  management  provides the mechanism for assigning memory areas to
      user programs and for preventing users from accessing  areas  that  have
      been  assigned  to  other	 users.	  This	protects  the operating system
      executive as well as users from accidental or  willful  memory  accesses
      outside  of a user's assigned memory.  Relocation is also important in a
      multiprogramming	environment  since  the	 executive  must  be  able  to
      relocate the user's program to a free area in physical memory.

      The LSI-11/73 Memory Management Unit provides the hardware for  complete
      memory  management  by  providing	 all  of  the  above  services.	 It is
      software compatible with the  larger  UNIBUS  PDP-11s  and  other	 Q-bus
      processors.   Since  the	LSI-11/73  has	the  PDP-11 architecture and a
      16-bit program counter, all  16-bit  addresses  access  a	 64Kb  virtual
      address space.  On the LSI-11/73 this addressing limitation can be eased
      by using separate sets of memory management registers  for  instructions
      (I-space)	 and  for  data	 (D-space).   By  utilizing separate I- and D-
      space, the address space	can  be	 segmented  into  two  64Kb  segments,
      effectively  doubling  the virtual address space.	 The LSI-11/73 and the
      Q-bus allow 4 Mb of memory to be referenced.  The MMU  is	 necessary  to
      provide  the  mapping  from  the	64Kb virtual address space to the 4 Mb
      physical address space.

								Page 2


      When the MMU is activated, a 16-bit virtual  address  is	mapped	to  an
      18-bit  or  22-bit  physical  address.   The MMU uses registers known as
      Active Page Registers (APRs).  An APR consists of two  16-bit  registers
      which are called the Page Address Register (PAR) and the Page Descriptor
      Register (PDR).  PARs are used in the actual address  translation	 while
      PDRs  contain  access  and  other	 information.	Since the LSI-11/73 is
      functionally equivalent to the PDP-11/70, it can operate in one of three
      modes:   Kernel,	Supervisor,  or	 User  and it can use I- and D- space.
      This means that the MMU must provide separate sets of registers for each
      mode  and	 within	 each  mode,  sets  of	registers  for I-space and for
      D-space.	A set of registers consists of eight pairs of PDRs  and	 PARs.
      Thus the LSI-11/73 MMU has a total of three sets of 32 16-bit registers.

      Mapping is always done in pages of 8Kb (4K words) in length or less.  In
      order  to	 map  the  largest possible virtual address space (64 Kb), the
      address space is divided into eight pages of 8Kb each.  One APR is  used
      for  each	 of  the  eight pages, numbered 0 to 7.	 The uppermost page in
      physical memory is called the I/O page and is usually mapped by a Kernel
      Mode APR since it is a privileged area.

				  PHYSICAL
				  ADDRESS
				   SPACE

			   4 Mb +----------+
				| I/O page | <--+
				+----------+	|
				|	   |	|
				+----------+	|
	  USER MODE	+-----> |  page 7  |	|	KERNEL MODE
			|	+----------+	|
	    APRs	|	|	   |	|	   APRs
			|	+----------+	|
			|	      .		|
			|	      .		|
	+----------+	|	+----------+	|	+----------+
	|   PAR7   |----+	|	   |	+-------|   PAR7   |
	+----------+		+----------+		+----------+
	|   PAR6   |		|	   |		|   PAR6   |
	+----------+		+----------+		+----------+
	|   PAR5   |	  +---> |	   |		|   PAR5   |
	+----------+	  |	+----------+		+----------+
	|   PAR4   |----+ |	|	   |	+-------|   PAR4   |
	+----------+	| |	+----------+	|	+----------+
	|   PAR3   |	| |	|	   |	|	|   PAR3   |
	+----------+	| |	+----------+	|	+----------+
	|   PAR2   |	| |	|	   | <--+	|   PAR2   |
	+----------+	| |	+----------+		+----------+
	|   PAR1   |	+-----> |	   |		|   PAR1   |
	+----------+	  |	+----------+		+----------+
	|   PAR0   |------+	|	   | <----------|   PAR0   |
	+----------+	      0 +----------+		+----------+


      The Page Address Register consists solely	 of  the  Page	Address	 Field

								Page 3


      (PAF).  If 22-bit addressing is enabled, then all 16 bits of the PAR are
      used as the PAF.	If only 18-bit addressing is desired then the 12 lower
      order  bits  are the PAF and the 4 higher order bits are unused.	It may
      be thought of as a base register containing  a  base  address  or	 as  a
      relocation register containing a relocation constant.

			PAGE ADDRESS REGISTER	(PAR)
		 15					       0
		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
		|	PAGE ADDRESS FIELD (PAF)		|
		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+


      The Page Descriptor Register contains  information  about	 access,  page
      length, and expansion direction:


			PAGE DESCRIPTOR REGISTER (PDR)

		 15 14		      08 07 06 05 04 03 02 01 00
		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
		|BC| PAGE LENGTH FIELD	| 0| W| 0| 0|ED| ACF | 0|
		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+


	PDR <15>	BC	(Bypass Cache)

			Set if memory accessing is wished to be
			without utilizing the cache.  Useful with
			dual-ported memories.

	PDR <08:14>	PLF	(Page Length Field)

			Specifies the authorized length of the page
			in 32 word (or 64 byte) groups.

			0	<-->	32 word page
			.
			.
			177 (8) <-->	4096 word page


	PDR <06>	W	(Written Into)

			Useful in determining whether or not a page can
			simply be erased or must be saved to be brought
			back into memory.

			0	<-->	Page has NOT been written into
			1	<-->	Page has been written into


	PDR <03>	ED	(Expansion Direction)

			0	<-->	Expands to higher addresses

								Page 4


					(Normally used)
			1	<-->	Expands to lower addresses
					(Can be used for stack segments)

	PDR <01:02>	ACF	(Access Control Field)

			00	<-->	Nonresident
			01	<-->	Resident - Read Only
			10	<-->	Not Used
			11	<-->	Resident - Read/Write

      The 16-bit virtual address is divided into three fields:


				VIRTUAL ADDRESS (VA)

		15    13 12			6 5	       0
		+-------+------------------------+-------------+
		|  APF	|	   BN		 |    DIB      |
		+-------+------------------------+-------------+
			<--------DISPLACEMENT FIELD (DF)------->


	o APF or Active Page Field
		These three bits determine which of the eight
		APRs are selected.

	o BN or Block Number
		The PAF determines an 8 Kb page in memory.
		The BN is that offset that is added to the base
		of the page determined by the PAF to obtain the
		block within the page to map.

	o DIB or Displacement In the Block
		Tells exactly which one of the 32 words is being
		mapped to.  The low order 6 bits (DIB) are never
		relocated.


	The BN and DIB fields are collectively referred to as the
	Displacement Field (DF).


      If the MMU is not activated  then	 16-bit	 virtual  addresses  are  also
      16-bit physical addresses and linearly map the 64Kb address space.  When
      the MMU is activated the	16-bit	virtual	 address  (VA)	is  no	longer
      interpreted  as a physical address Instead, the physical address (PA) is
      constructed using the VA	and  the  PAF  (Page  Address  Field)  of  the
      selected PAR.

      The translation of virtual addresses to  22-bit  physical	 addresses  is
      accomplished as follows:

	1) A set of registers is selected.  This is determined by
	   the space being referenced (Instructions or Data) and by

								Page 5


	   the mode bits of the Processor Status Word (PSW <15:14>).

	2) The APF field of the virtual address determines which of the
	   eight pairs in the selected set will be used for the mapping.

	3) The PAF of the selected register pair contains the starting
	   address of the currently active page as a block number.

	4) The block number from the virtual address and the block number
	   from the PAF are added together.  The block number from the PAF
	   is shifted left by six bits in order to perform this addition.
	   The result is the actual physical block number (bits <21:06>
	   of the physical address).

	5) The DIB of the virtual address is carried along unchanged as
	   bits <05:00> of the translated address.


			VIRTUAL TO PHYSICAL ADDRESS TRANSLATION

					16-BIT VIRTUAL ADDRESS
			     15						   0
			    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
			    |	APF  |	       BN	  |	 DIB	    |
			    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
				|		|			|
				|		|			|
			   +---------+		|			|
			   | Selects |		|			|
			   |   APR   |		+---------------+	|
			   +---------+				|	|
								|	|
								|	|
			PAGE ADDRESS REGISTER			|	|
	   15						 0	|	|
	  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+	|	|
	  |						  |	|	|
	  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+	|	|
				|				|	|
				|	      +-----+		|	|
				+------------>| ADD |<----------+	|
					      +-----+			|
						|			|
				+---------------+			|
				|					|
				|					|
	 21			|		       6   5		|  0
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+
	|	BLOCK NUMBER IN PHYSICAL MEMORY		| |	DIB	    |
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+

	<--------------- 22-BIT PHYSICAL ADDRESS (PA) ---------------------->

								Page 6


      There are four memory management registers  that	are  used  for	memory
      fault  recovery  and  abort and status information as well as control of
      the MMU.	They are called MMR0, MMR1, MMR2, and MMR3.

      Memory Management Register 0 (MMR0)  is  the  main  control  and	status
      register.


			MEMORY MANAGEMENT REGISTER 0 (MMR0)

		 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
		|  |  |	 | 0| 0| 0| 0| 0| 0|	 |  |	     |	|
		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+



	MMR0 <15>	NONRESIDENT ABORT

			Set if an attempt is made to access a page
			with an ACF of 0 or 2 or if the PSW indicates
			mode 2.


	MMR0 <14>	PAGE LENGTH ABORT

			Set if an attempt is made to access a location
			whose block number is outside the area authorized
			by the PLF of the PDR for that page.


	MMR0 <13>	READ ONLY ABORT

			Set if an attempt is made to write to a page with
			an ACF of 1 (Read Only).


	MMR0 <06:05>	PROCESSOR MODE

			Copy of the PSW <15:14> when abort occurred.


	MMR0 <04>	PAGE SPACE

			1	<-->	D-space
			0	<-->	I-space


	MMR0 <03:01>	PAGE NUMBER

			Page Number of page causing the abort.
			Copy of APF of virtual address.


	MMR0 <00>	ENABLE RELOCATION

								Page 7



			1	<-->	ALL addresses are relocated
					(MMU activated)
			0	<-->	NO addresses are relocated
					(MMU disabled)



      Memory Management Register 1 (MMR1) is  called  the  Instruction	Backup
      Register.	  It records any autoincrement or autodecrement of any general
      purpose register.	 The lower byte is used for source  operands  and  the
      destination   operand   may  be  in  either  byte,  dependent  upon  the
      instruction.


			MEMORY MANAGEMENT REGISTER 1 (MMR1)

		 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
		|	       |	|	       |	|
		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+


	MMR1 <15:11>	AMOUNT CHANGED (2's complement)

	MMR1 <10:08>	REGISTER NUMBER

	MMR1 <07:03>	AMOUNT CHANGED (2's complement)

	MMR1 <02:01>	REGISTER NUMBER


      Memory Management Register 2 (MMR2) is known as the Last Virtual Program
      Counter.	 It  is	 loaded	 with  the value of the Program Counter at the
      beginning of each instruction fetch and is  used	in  instruction	 fault
      recovery.

								Page 8


      Memory Management Register 3 (MMR3) is used to select 18-bit  or	22-bit
      address  mapping and is used to enable/disable the data space for any of
      the processor modes.


			MEMORY MANAGEMENT REGISTER 3 (MMR3)

		 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
		| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0|	 |  |  |	|
		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+


	MMR3 <05>	UNINTERPRETED

			May be set or cleared but is not interpreted.


	MMR3 <04>	ENABLE 22-BIT MAPPING

			1	<-->	Mapping is to 22-bit space.
			0	<-->	Mapping is to 18-bit space.


	MMR3 <03>	ENABLE CSM (Call Supervisor Mode) INSTRUCTION

			1	<-->	CSM is recognized.
			0	<-->	CSM is not recognized.


	MMR3 <02>	KERNEL DATA SPACE

			1	<-->	Enable data space mapping in
					Kernel Mode
			0	<-->	Disable data space mapping in
					Kernel Mode


	MMR3 <01>	SUPERVISOR DATA SPACE

			1	<-->	Enable data space mapping in
					Supervisor Mode
			0	<-->	Disable data space mapping in
					Supervisor Mode


	MMR3 <00>	USER DATA SPACE

			1	<-->	Enable data space mapping in
					User Mode
			0	<-->	Disable data space mapping in
					User Mode

								Page 9



      Summary:

      The LSI-11/73  Memory  Management	 Unit  provides	 a  powerful,  general
      purpose  tool for memory management.  It can be used to expand memory in
      a simple way and it can be used in a multiprogramming system to  provide
      all the services necessary for an efficient and secure environment.

      The following is a simple MACRO-11 program which illustrates the	method
      of  setting  up the registers and performing some mappings.  It writes a
      known value to an unmapped location and sets up the  MMU	registers  and
      turns  on	 the  unit.   It  then	writes another known value to the same
      virtual address which is now mapped.  Then it turns  the	MMU  off.   At
      this point the two known values are in different memory locations.


		.TITLE	MMU

	;
	;	Program to demonstrate setting up MMU registers
	;	and to illustrate the mapping that takes place
	;

		PSW	=	177776	; Processor Status Word
		MMR0	=	177572	; Memory Management Register 0
		PDR0	=	172300	; Page Descriptor Register 0
		PAR0	=	172340	; Page Address Register 0
		PAR1	=	172342	; Page Address Register 1
		PAR7	=	172356	; Page Address Register 7


	; INSURE THAT MMU IS NOT ACTIVATED

	START:: CLR	@#MMR0		; CLEAR MMR0


	; STORE A KNOWN VALUE (152152) IN UNMAPPED LOCATION 20000

		MOV	#152152,@#20000


	; SET PSW TO KERNEL MODE

		BIC	#140000,@#PSW


	; SET THE PARS SO THAT EACH PAGE MAPS TO ITSELF

		MOV	#PAR0,R5	; SET UP PAR POINTER
		MOV	#10,R4		; SET UP PAR COUNTER
		CLR	R3		; SET UP PAR OFFSET VALUE


	LOOP1:	MOV	R3,(R5)+	; SET EACH RELOCATION CONSTANT TO
					; MAP TO ITSELF

							       Page 10


		ADD	#200,R3		; UPDATE OFFSET
		SOB	R4,LOOP1	; DO ALL OF THEM


	; SET PAR1 TO MAP PAGE 1 TO PAGE 2

		MOV	#400,@#PAR1


	; SET PAR7 TO MAP THE I/O PAGE TO THE TOP OF MEMORY

		MOV	#7600,@#PAR7	; 172356 POINTS TO 760000

	;
	; SET UP THE PDRS
	;
	; 77406 (8) = 0 111 111 100 000 110 (2)
	;
	;	RESIDENT - READ/WRITE
	;	UPWARD EXPANDING
	;	NOT WRITTEN INTO
	;	8KB PAGE SIZE
	;	DON'T BYPASS CACHE
	;

		MOV	#PDR0,R5	; SET UP PDR POINTER
		MOV	#10,R4		; SET UP PDR COUNTER

	LOOP2:	MOV	#77406,(R5)+	; SET EACH PDR
		SOB	R4,LOOP2	; DO THEM ALL


	; ENABLE THE MMU

		INC	@#MMR0		; SET BIT 0 OF MMR0


	; WRITE A VALUE TO LOCATION 20000. THIS SHOULD BE MAPPED.

		MOV	#107010,@#20000 ; WRITE 107010 TO MAPPED 2000


	; DISABLE THE MMU

		DEC	@#MMR0		; CLEAR BIT 0 OF MMR0


	; AT THIS POINT IN THE PROGRAM, EXAMINING PHYSICAL
	; ADDRESS 20000 SHOWS THE VALUE OF 152152 WHICH WAS PLACED THERE
	; ADDRESS 40000 (WHICH 20000 MAPPED TO) HOLDS THE VALUE 107010

		HALT
		.END	START

================================================================================
Note 9.0                    LSI-11/73 Cache Concepts                  No replies
JAWS::KAISER                                        307 lines  25-MAR-1985 09:18
--------------------------------------------------------------------------------
      +---------------+					   +-----------------+
      | d i g i t a l |					   |  uNOTE # 009    |
      +---------------+					   +-----------------+


      +----------------------------------------------------+-----------------+
      | Title: Cache Concepts and the LSI-11/73		   | Date: 02-JUL-84 |
      +----------------------------------------------------+-----------------+
      | Originator: Charlie Giorgetti			   | Page 1 of 6     |
      +----------------------------------------------------+-----------------+


      The goal is to  introduce	 the  concept  of  cache  and  its  particular
      implementation  on  the  LSI-11/73  (KDJ11-A).   This  is not a detailed
      discussion of the different cache	 organizations	and  their  impact  on
      system performance.

			      What Is A Cache ?
			      -----------------

      The purpose of having a cache is to simulate a  system  having  a	 large
      amount of moderately fast memory.	 To do this the cache system relies on
      a small amount of very fast,  easily  accessed  memory  (the  cache),  a
      larger  amount of slower, less expensive memory (the backing store), and
      the statistics of program behavior.

      The goal is to store some of the data and its  associated	 addresses  in
      the  cache  and  all  of	the data at its usual addresses (including the
      currently cached data) in the backing store.  If it can be arranged that
      most  of	the  time  when the processor needs data it is located in fast
      memory, then the program will execute more quickly,  slowing  down  only
      occasionally  for	 main memory operations.  The placement of data in the
      cache should not be a concern to the programmer but is a consequence  of
      how the cache functions.

      Figure 1 is an example of a memory organization  showing	a  cache  with
      backing  store.	If  the	 data needed by the microprocessor (uP) can be
      found in the cache then it is accessed much faster due to the local data
      path  and faster cache memory than by having to access the backing store
      on the slower system bus.


				     +-----------+	 System Bus
	+------+  CPU Internal Buses |	System	 | For Memory and I/O Options
	|      |<-----------------+->|	 Bus	 |<-------------------------->
	|  uP  |		  |  | Interface |	      |
	|      |<----------+	  |  +-----------+	      |
	+------+ Fast Path |	  |		      +-------+---------+
		 to Cache  |	  |		      |			|
			 +-+------+--+		      |	 System Memory	|
			 |	     |		      | (Backing Store) |
			 |   Cache   |		      |			|
			 |	     |		      +-----------------+
			 +-----------+

		Figure 1 - An Example Memory System with Cache

									Page 2


      A cache memory system can only work if it can successfully predict  most
      of  the  time  what  memory  locations  the  program will require.  If a
      program accessed data from memory in a  completely  random  fashion,  it
      would  be impossible to predict what data would be needed next.  If this
      was the case a cache would operate no better then a conventional	memory
      system.

      Programs rarely generate random addresses.  In many cases the subsequent
      memory  address  referenced  is  often  very  near  the  current address
      accessed.	 This is the principle of program locality.  The next  address
      generated	 is in the neighborhood of the current address.	 This behavior
      helps makes cache systems feasible.

      The concept of program locality is not  always  adhered  to,  but	 is  a
      statement	 of how many programs behave.  Many programs execute code in a
      linear fashion or in loops with  predictable  results  in	 next  address
      generation.   Jumps  and context switching give the appearance of random
      address generation.  The ability to determine what word a	 program  will
      reference	 next is never completely successful and therefore the correct
      "guesses" are a statistical measure of the size and organization of  the
      cache, and the behavior of the program being executed.

      The measure of a cache performance is a statistical  evaluation  of  the
      number  of  memory  references  found  versus  not found in cache.  When
      memory is referenced and the address is found in the cache this is known
      as  a  hit.   When  it is not it is termed a miss.  Cache performance is
      usually stated in terms of the hit ratio or the miss ratio  where	 these
      are defined as:


					Number of Cache Hits
		      Hit Ratio =  ---------------------------------
				   Total Number of Memory References



		      Miss Ratio =  1 - Hit Ratio




		      The LSI-11/73 Cache Implementation
		      ----------------------------------

      The cache organization chosen must be one that can be implemented within
      the physical and cost constraints of the design.

      The LSI-11/73 implements a direct map cache.  A direct map  organization
      has a single unique cache location for a given address and this is where
      the associated data from backing store are maintained.   This  means  an
      access to cache requires one address comparison to determine if there is
      a hit.  The significance of this is that a small amount of circuitry  is
      required	to  perform  the comparison operation.	The LSI-11/73 has an 8
      KByte cache.  This means that there are 4096  unique  address  locations
      each of which stores two bytes of information.

									Page 3


      The cache not only maintains the data from backing  store	 but  it  also
      includes other information that is needed to determine if its content is
      valid.  These are	 parity	 detection  and	 valid	entry  checking.   The
      following	 diagram  shows	 the logical layout of the cache and what each
      field and its associated address in the cache is used for.


	  Binary Cache
	  Entry Address	   P   V      TAG	P1     B1      P0     B0
			 +---+---+-------------+---+----------+---+----------+
	   000000000000	 |   |	 |	       |   |	      |	  |	     |
			 +---+---+-------------+---+----------+---+----------+
	   000000000001	 |   |	 |	       |   |	      |	  |	     |
			 +---+---+-------------+---+----------+---+----------+
	   000000000010	 |   |	 |	       |   |	      |	  |	     |
			 +---+---+-------------+---+----------+---+----------+
		.				 .
		.				 .
		.				 .

			 +---+---+-------------+---+----------+---+----------+
	   111111111101	 |   |	 |	       |   |	      |	  |	     |
			 +---+---+-------------+---+----------+---+----------+
	   111111111110	 |   |	 |	       |   |	      |	  |	     |
			 +---+---+-------------+---+----------+---+----------+
	   111111111111	 |   |	 |	       |   |	      |	  |	     |
			 +---+---+-------------+---+----------+---+----------+

		      Figure 2 - LSI-11/73 Cache Layout


      The Cache Entry Address is the address of one of 4096 entries within the
      cache.   This  value  has a one-to-one relationship with a field in each
      address that is generated	 by  the  processor  (described	 in  the  next
      section on how the physical address accesses cache).

      Each field has the following meaning:

	  Tag (TAG) - This nine bit field  contains  information  that	is
	  compared  to the address label, described in the next section on
	  how the physical address  accesses  cache.   When  the  physical
	  address  is  generated, the address label is compared to the tag
	  field.  If there is a match it can be considered a hit  provided
	  that there is entry validation and no parity errors.

	  Cache Data (B0 and B1) - These two bytes  are	 the  actual  data
	  stored in cache.

	  Valid Bit (V) - The valid bit indicates whether the  information
	  in B0 and B1 is usable as data if a cache hit occurs.	 The valid
	  bit is set when the entry is allocated  during  a  cache  update
	  which occurs as a result of a miss.

	  Tag Parity Bit - (P) - Even  parity  calculated  for	the  value
	  stored in the tag field.

									Page 4


	  Parity Bits (P0 and P1) - P0 is even parity calculated  for  the
	  data	byte  B0 and P1 is odd parity calculated for the data byte
	  B1.

      When the processor generates a  physical	address,  the  on-board	 cache
      control  logic must determine if there is a hit by looking at the unique
      location in cache.  To determine	what  location	to  check,  the	 cache
      control logic considers each address generated as being made up of three
      unique parts.  The following are the three fields of  a  22-bit  address
      (in  an  unmapped	 or  18-bit environment the label field is six or four
      bits less respectfully):


       21 20 19 18 17 16 15 14 13    12 11 10 09 08 07 06 05 04 03 02 01    00
      +--+--+--+--+--+--+--+--+--+  +--+--+--+--+--+--+--+--+--+--+--+--+  +--+
      |	 |  |  |  |  |	|  |  |	 |  |  |  |  |	|  |  |	 |  |  |  |  |	|  |  |
      +--+--+--+--+--+--+--+--+--+  +--+--+--+--+--+--+--+--+--+--+--+--+  +--+

      |<-------- LABEL --------->|  |<-------------- INDEX ------------>|  BYTE
									  SELECT

    Figure 2 - Components of a 22-bit Address For Cache Address Selection

      Each field has the following meaning:

	  Index - This twelve bit field determines which one of	 the  4096
	  cache	 data  entries to compare with for a cache hit.	 The index
	  field is the displacement into the cache and corresponds to  the
	  Cache Entry Address.

	  Label - Once the location in the cache is selected, the nine bit
	  label	 field	is  compared  to the tag field stored in the cache
	  entry under consideration.  If the address  label  and  the  tag
	  field match, the valid bit is set, and there is no parity error,
	  then a hit has occurred.

	  Byte Select Bit - This bit determines if the reference is on	an
	  odd  or  even	 byte  boundary.  All Q-bus reads are word only so
	  this bit has no effect on a cache read.  Q-bus writes can access
	  either  words or bytes.  If there is a word write the cache will
	  be updated if there is a hit.	 If there is a miss  a	new  cache
	  entry	 will  be  made.  If there is a byte write, the cache will
	  only be updated if there is a hit.  A miss will not create a new
	  entry on a byte write.

      The LSI-11/73 direct map cache must update the backing store on a memory
      write.   The  LSI-11/73  uses  the  write	 through  method.   With  this
      technique, writes	 to  backing  store  occurs  concurrently  with	 cache
      writes.	The  result is that the backing store always contains the same
      data as the cache.

									Page 5


		       Features Of The LSI-11/73 Cache
		       -------------------------------

      The LSI-11/73 direct map cache has a number of features that  assist  in
      the  performance	of  the	 overall  system  in  addition	to  the	 speed
      enhancement as a result of faster memory access.	These features consist
      of the following:

			 o Q-bus DMA monitoring
			 o I/O page reference monitoring
			 o Memory management control of cache access
			 o Program control of cache parameters
			 o Statistical monitoring of cache performance

      The  LSI-11/73  cache  control  logic  monitors  the  Q-bus  during  DMA
      transactions.   When  an	address	 that  has its data stored in cache is
      accessed during DMA, the cache  and  backing  store  contents  might  no
      longer  be  the  same.   This  is	 an unacceptable situation.  The cache
      control logic invalidates a cache entry if the address  is  used	during
      DMA.   This  also	 includes  addresses  used during Q-bus Block Mode DMA
      transfers.

      Memory references to the I/O page are not	 cached	 since	that  data  is
      volatile, meaning its contents can change without a Q-bus access.	 Since
      the cache could end up with stale data, I/O references are not cached.

      There are situations for which using the cache to store information  for
      faster  access is not desirable.	An example is a device that resides in
      the I/O page, and is true in other instances as well.  One situation  is
      a	 device	 that  does  not  reside  in  the  I/O page but can change its
      contents without a bus reference, such as dual ported memory.

	   Another situation is partitioning and  tuning  an  application  for
      instruction  code execution versus data being manipulated.  In this case
      the instruction stream may execute many times over  for  different  data
      values.	Speed  enhancement  can	 be  obtained  if the instructions are
      cached while the data is not cached.  By forcing the data	 never	to  be
      cached it cannot replace instructions in the cache.

      The memory management unit (MMU) of the LSI-11/73	 can  assist  in  this
      situation.   Pages  of memory allocated for data can be marked to bypass
      the cache and therefore not effect instructions that  loop  many	times.
      The  cache  and  the  MMU work together to achieve the goal of increased
      system performance.

      The dynamics of cache operation are under program control through use of
      the  Cache Control Register (CCR), an LSI-11/73 on-board register.  This
      register can "turn" the cache on or off, force cache parity  errors  for
      diagnostic  testing,  and	 invalidate all cache entries.	The details of
      the CCR are described in the  KDJ11-A  CPU  Module  User's  Guide	 (part
      number EK-KDJ1A-UG-001).

      During  system  design  or  at  run-time	the  performance  enhancements
      provided	by  the	 cache	system can be monitored under program control.
      This is accomplished by using another LSI-11/73  on-board	 register  the

									Page 6


      Hit/Miss	Register  (HMR).   This	 register  tracks  the last six memory
      references and indicates if a hit or miss took place.   The  details  of
      the HMR are also described in the KDJ11-A CPU Module User's Guide.

				   Summary
				   -------

      Caches are a mechanism that can help improve overall system performance.
      The  dynamics  of a given cache are dictated by the organization and the
      behavior of the programs running on the machine.	The LSI-11/73 cache is
      designed	to  be	flexible  in  its  use,	 simple in implementation, and
      enhance application performance.

      More  detailed  discussions  on  how  caches  work   and	 other	 cache
      organizations  can  be  found in computer architecture texts that have a
      discussion of memory hierarchy.

================================================================================
Note 10.0                  MicroVAX I I/O Programming                 No replies
JAWS::KAISER                                        229 lines  25-MAR-1985 09:18
--------------------------------------------------------------------------------
      +---------------+					   +-----------------+
      | d i g i t a l |					   |  uNOTE # 010    |
      +---------------+					   +-----------------+


      +----------------------------------------------------+-----------------+
      | Title: MicroVAX I/O Programming			   | Date: 27-JUL-84 |
      +----------------------------------------------------+-----------------+
      | Originator: Peter Jonhson			   | Page 1 of 5     |
      +----------------------------------------------------+-----------------+



      The Qbus MicroVax implements the full Vax memory management, so  virtual
      addresses	 are  translated  to physical addresses - just as they are for
      the Vax minicomputers.  When memory management is	 enabled,  system  and
      process  space  virtual addresses are translated into physical addresses
      and sent onto the Qbus.  Normally,  the  programmmer  need  not  concern
      himself  with  this  translation	as  this  is completely handled by the
      operating system; however, when accessing locations  in  the  I/O	 space
      directly	the  programmer	 must  concern	himself with the mapping since
      specific information must be supplied by the programmer to  MicroVMS  in
      order  for  it to successfully map the user's virtual addresses into the
      I/O space.  The process of mapping  a  virtual  address  to  a  physical
      address  must start by determining the physical address that you wish to
      access.  In our case this means that we must calculate a	Qbus  MicroVax
      physical	address	 given that we know the address that the Qbus board is
      configured to.  In order to do this we must know a few key  facts	 about
      the Qbus MicroVax architecture.




	1) The Qbus MicroVax I/O space begins at physical 20000000 (hex)

	2) The I/O space of a Qbus MicroVax is largely empty containing
	   only Q22 bus I/O space which is 8K bytes long




      Given these two pieces of information we now know that the I/O space for
      the  Qbus	 MicroVax  starts  at  physical	 20000000 (hex) and extends to
      20001FFF (hex).  This I/O space directly corresponds to the configurable
      addresses	 on  Qbus  option  boards  160000-177777  (oct).   In order to
      convert any Qbus option address to a Qbus MicroVax  address  one	simply
      subtracts	 160000	 from  the boards configured address to get its offset
      into the I/O space and then add this value  to  the  base	 of  the  Qbus
      MicroVax I/O space.  For example, let us consider a board which has been
      configured to  166540.   In  order  to  calculate	 its  equivalent  Qbus
      MicroVax address we would do the following:

								Page 2




	1) Subtract off the I/O base address for this board (160000)

			166540 (oct)
		    -	160000 (oct)
		      ---------
			  6540 (oct) -->  D60 (hex)

	2) Add the board's address offset to the Qbus MicroVax I/O space
	   base address

			20000000 (hex)
		    +	     D60 (hex)
		      ----------
			20000D60 (hex)



	   This addition results in the physical address on the Qbus MicroVax
	   system that this board would answer to.


      Now we have calculated the physical address for the board	 in  the  Qbus
      MicroVax	environment.   This value, however, is in the raw state and is
      still not usable by the uVMS software to	perform	 virtual  to  physical
      address  translation.   In  order	 for  this address to be useful to the
      software it must now be converted from a	physical  address  to  a  page
      frame  number.   The  page  is  the  basic  unit	of  memory mapping and
      protection.  A page is 512 contiguous  byte  locations.	A  page	 frame
      number  (PFN)  is	 the  address  of the first byte of a page in physical
      memory.  This means that the lsb of a PFN has the resolution of  1  page
      or  512  bytes.  It is a simple matter now to convert a physical address
      to a PFN.	 Since the lsb of a PFN	 is  1	page  to  convert  a  physical
      address to PFN just shift right the physical address 9 bits, i.e.	 shift
      off the 9 least significant bits.


	physcial 20000D60 (hex)	 shift right 9 --> PFN 100006 (hex)

      The PFN value which we have calculated is sufficient to allow the system
      to  map  a  physcial  page of addresses into your virtual address space.
      The address of the Qbus option resides somewhere in the  page  which  we
      have  mapped.   It  is the responsibility of the programmer to correctly
      offset from the beginning of the page in order to access the board  i.e.
      the  programmer  must displace from the base of the mapped page with the
      correct virtual address  offset.	 To  determine	the  offset  from  the
      beginning	 of the mapped page look to bits 0-9 of the configured address
      of the Qbus option board - this is  the  offset.	 In  our  example  the
      offset would be:

								Page 3




			166540 (oct)
			   | |
			   \ /
			    |
			    --------  540   bits 9-0 are the offset

      This offset would be  used  by  the  programmer  to  access  the	device
      registers	 on  the board.	 Failure to use the offset will usually result
      in an attempt to access non-esxistent  locations	(analagous  to	memory
      time-outs) which will result in an access violation error being returned
      to the user.  A sample program follows which illustrates the  principles
      which  have  been	 discussed.   It uses the same board address discussed
      earlier so that one can see the code needed to  acutally	implement  the
      previous example.



      The following program illustrates, in  a	raw  fashion,  how  one	 might
      actually	access	the  I/O  space	 with  software.   It  is not meant to
      illustrate good or recommended programming practice but rather  to  show
      the mechanics of accessing the I/O space of a Qbus on MicroVax I.

								Page 4




	.title	map_io_space


	;This program will allow a user with suitable privilege to access
	;device registers in the I/O space of a uVax.  This example shows
	;code which is used to extract data from a DRV11 - a general purpose
	;parallel interface which resides in I/O space.	 It is sufficiently
	;general to allow the concept to be used in other situations where
	;access to the I/O space from a user process is desireable.


	;This portion of the program is responsible for creating the
	;virtual to physical mapping required to access registers in
	;the I/O space.	 For this example the device registers are assumed to
	;start at 166540.  In order for virtual to physical mapping to occur
	;the  user must calculate the physcial page frame that the device
	;registers overlap into.  (See accompanying text for how to do this)



	;Create and map section directive does the actual work of mapping.
	;In order for this system service to work correctly the
	;use must have PFNMAP privilege

	.entry	start,^m<>

	$crmpsc_s -
	inadr = maprange, -		;Input virtual address range
	retadr = actadr, -		;Virtual address range acutally
					;mapped
	pagcnt = #1, -			;Non zero required for page frame
					;section
	flags =#<sec$m_expreg!sec$m_pfnmap!sec$m_wrt>, -
	vbn = pfn_number		;Actual page frame of I/O space
					;page which contains device registers

	blbs	r0,continue		;check the return status of create
					;and map - if successful branch

	pushl	r0			;put status onto stack
	calls	#1,g^lib$stop		;tell him what happened and
					;stop program

								Page 5



	;At this point one page of virtual addresses in the user's process
	;space is now mapped into one page of the I/O space.  Now the user
	;can access device registers by using move instructions.
	;...... ** Please note that only certain instructions are allowed when
	;doing physical I/O to the bus.	 For example a MOVL instruction is
	;NOT legal to the I/O space.


	continue:

	movl	actadr, r6		;Get starting virtual address from


					;system service and put into R6
	addl	#^x160, r6		;Add the displacement into this page
					;to access the device registers

	;Access data from the parallel interface

	tstb	(r6)			;Test for data transfer request
	bgew	10$			;If no data exit
	movw	4(r6), data_in_buffer	;Data is present - store it


	10$:
	$exit_s -			;exit gracefully
	code = #1



	;data for program ......

	maprange:	.long	^x400
			.long	^x800

	control_status	.word	0
	data_in_buffer	.word	0

	actadr:		.blkl	2		;holds returned virtual
						; address range
	pfn_number:	.long	^x100006	;actual pfn of I/O page to
						;be mapped

	.end	start

================================================================================
Note 11.0                LSI-11/73 Advanced Memory Mgmt               No replies
JAWS::KAISER                                        557 lines  25-MAR-1985 09:19
--------------------------------------------------------------------------------
     +---------------+					  +-----------------+
     | d i g i t a l |					  |  uNOTE # 011    |
     +---------------+					  +-----------------+


     +----------------------------------------------------+-----------------+
     | Title: LSI-11/73 ADVANCED MEMORY MANAGEMENT	  | Date: 04-Sep-84 |
     +----------------------------------------------------+-----------------+
     | Originator: Art Bigler				  | Page 1 of 11    |
     +----------------------------------------------------+-----------------+



     This  micronote  examines	the  advanced  memory	management   features
     available	on  the	 DCJ11	based  LSI-11/73  series processors (KDJ11-A,
     KDJ11-B).	 These	features  include  the	 standard   virtual   address
     relocation	 within	 the  physical	address space and the kernel and user
     execution modes, all of which are currently available as options on  the
     mid-range LSI-11/23 (KDF11-A, KDF11-B) processors.	 In addition to these
     features, the DCJ11 based processors also provide instruction  and	 data
     space  (I/D  space) memory management and the supervisor execution mode.
     The following discussion is intended to further clarify these  features.
     For  information pertaining to address relocation the reader is referred
     to micronote 008, MEMORY MANAGEMENT AND THE LSI-11/73.


     1.0	INSTRUCTION/DATA SPACE MEMORY MANAGEMENT

     I/D space memory management is utilized in the DCJ11 based processors IN
     ADDITION  TO  the	relocation  of	virtual addresses within the physical
     address space.  This provides the	ability	 to  place  multiple  program
     images  in physical memory while at the same time providing an increased
     virtual address space of 128 kb or 64 kw  by  mapping  instructions  and
     data to separate areas of physical memory.	 The means by which I/D space
     memory management is attained involves both  hardware  and	 software  as
     described in the following paragraphs.


     1.1	I/D SPACE HARDWARE

     The hardware required to implement I/D space  addressing  is  integrated
     into  the	memory	management  unit  and  is standard on all DCJ11 based
     processors.  This includes the following:

	   1.	Eight  (8)  additional	active	page  registers	 (APR's)  per
	       execution  mode	(more  about  execution	 modes later).	These
	       APR's are used to map to the data space when I/D space  memory
	       management is enabled.

	   1.  Additional  control  and	 status	 bits  in  memory  management
	       registers  0  and 3 (MMR0, MMR3) which are used to control the
	       enabling and disabling of data space addressing.	  INSTRUCTION
	       SPACE ADDRESSING IS ALWAYS ENABLED.

     1.1.1	ACTIVE PAGE REGISTERS

									  Page 2


     The hardware provides a total of sixteen (16) APR's per execution	mode,
     eight   (8)  instruction  space  registers	 and  eight  (8)  data	space
     registers.	 THE APR's are further divided into page descriptor registers
     (PDR's)  and  page	 address  registers (PAR's) as described in micronote
     008.  The physical addresses for these registers are  contained  in  the
     I/O page and are as follows:



		+-------+---------------+---------------+-------+
		|  MODE |     PAR's	|     PDR's	|  PAGE |
		+-------+---------------+---------------+-------+
		|	|    17772340	|    17772300	|   0	|
		+	+---------------+---------------+-------+
		|	|    17772342	|    17772302	|   1	|
		+	+---------------+---------------+-------+
		|	|    17772344	|    17772304	|   2	|
		+	+---------------+---------------+-------+
		| KERNEL|    17772346	|    17772306	|   3	|
		+   I	+---------------+---------------+-------+
		| SPACE |    17772350	|    17772310	|   4	|
		+	+---------------+---------------+-------+
		|	|    17772352	|    17772312	|   5	|
		+	+---------------+---------------+-------+
		|	|    17772354	|    17772314	|   6	|
		+	+---------------+---------------+-------+
		|	|    17772356	|    17772316	|   7	|
		+-------+---------------+---------------+-------+
		|	|    17772360	|    17772320	|   0	|
		+	+---------------+---------------+-------+
		|	|    17772362	|    17772322	|   1	|
		+	+---------------+---------------+-------+
		|	|    17772364	|    17772324	|   2	|
		+	+---------------+---------------+-------+
		| KERNEL|    17772366	|    17772326	|   3	|
		+   D	+---------------+---------------+-------+
		| SPACE |    17772370	|    17772330	|   4	|
		+	+---------------+---------------+-------+
		|	|    17772372	|    17772332	|   5	|
		+	+---------------+---------------+-------+
		|	|    17772374	|    17772334	|   6	|
		+	+---------------+---------------+-------+
		|	|    17772376	|    17772336	|   7	|
		+-------+---------------+---------------+-------+


				     TABLE 1a
				KERNEL MODE APR'S

									  Page 3


		+-------+---------------+---------------+-------+
		|  MODE |     PAR's	|     PDR's	|  PAGE |
		+-------+---------------+---------------+-------+
		|	|    17772240	|    17772200	|   0	|
		+	+---------------+---------------+-------+
		|	|    17772242	|    17772202	|   1	|
		+	+---------------+---------------+-------+
		|	|    17772244	|    17772204	|   2	|
		+	+---------------+---------------+-------+
		| SPVSR |    17772246	|    17772206	|   3	|
		+   I	+---------------+---------------+-------+
		| SPACE |    17772250	|    17772210	|   4	|
		+	+---------------+---------------+-------+
		|	|    17772252	|    17772212	|   5	|
		+	+---------------+---------------+-------+
		|	|    17772254	|    17772214	|   6	|
		+	+---------------+---------------+-------+
		|	|    17772256	|    17772216	|   7	|
		+-------+---------------+---------------+-------+
		|	|    17772260	|    17772220	|   0	|
		+	+---------------+---------------+-------+
		|	|    17772262	|    17772222	|   1	|
		+	+---------------+---------------+-------+
		|	|    17772264	|    17772224	|   2	|
		+	+---------------+---------------+-------+
		| SPVSR |    17772266	|    17772226	|   3	|
		+   D	+---------------+---------------+-------+
		| SPACE |    17772270	|    17772230	|   4	|
		+	+---------------+---------------+-------+
		|	|    17772272	|    17772232	|   5	|
		+	+---------------+---------------+-------+
		|	|    17772274	|    17772234	|   6	|
		+	+---------------+---------------+-------+
		|	|    17772276	|    17772236	|   7	|
		+-------+---------------+---------------+-------+


				     TABLE 1b
			      SUPERVISOR MODE APR'S

									  Page 4


		+-------+---------------+---------------+-------+
		|  MODE |     PAR's	|     PDR's	|  PAGE |
		+-------+---------------+---------------+-------+
		|	|    17777640	|    17777600	|   0	|
		+	+---------------+---------------+-------+
		|	|    17777642	|    17777602	|   1	|
		+	+---------------+---------------+-------+
		|	|    17777644	|    17777604	|   2	|
		+	+---------------+---------------+-------+
		|  USER |    17777646	|    17777606	|   3	|
		+   I	+---------------+---------------+-------+
		| SPACE |    17777650	|    17777610	|   4	|
		+	+---------------+---------------+-------+
		|	|    17777652	|    17777612	|   5	|
		+	+---------------+---------------+-------+
		|	|    17777654	|    17777614	|   6	|
		+	+---------------+---------------+-------+
		|	|    17777656	|    17777616	|   7	|
		+-------+---------------+---------------+-------+
		|	|    17777660	|    17777620	|   0	|
		+	+---------------+---------------+-------+
		|	|    17777662	|    17777622	|   1	|
		+	+---------------+---------------+-------+
		|	|    17777664	|    17777624	|   2	|
		+	+---------------+---------------+-------+
		|  USER |    17777666	|    17777626	|   3	|
		+   D	+---------------+---------------+-------+
		| SPACE |    17777670	|    17777630	|   4	|
		+	+---------------+---------------+-------+
		|	|    17777672	|    17777632	|   5	|
		+	+---------------+---------------+-------+
		|	|    17777674	|    17777634	|   6	|
		+	+---------------+---------------+-------+
		|	|    17777676	|    17777636	|   7	|
		+-------+---------------+---------------+-------+


				     TABLE 1c
				 USER MODE APR'S


     1.1.2	MEMORY MANAGEMENT REGISTER 0

     Memory  management	 register  0  (MMR0)  contains	control	 and   status
     information  for  the  memory  management	unit (MMU).  This register is
     discussed completely in micronote 008, to	which  the  reader  is	again
     refferred	for  information  on  those  functions which are not directly
     applicable to I/D space and supervisor mode.

     MMR0 contains three (3) status bits which are used in the implementation
     of	 I/D  space  memory addressing.	 These bits, 04 through 06, yield MMU
     status  information  whenever  a  MMU  abort  occurs  and	are  used  in
     conjunction  with	MMR0  bits 01 through 03 and 13 through 15 to provide
     complete execution mode and I/D space status for the  page	 causing  the
     abort.  See figure 1.

									  Page 5


     Bit 04, the page address space status bit, indicates the  address	space
     associated	 with  the  aborted  page  and	is equal to a zero (0) for an
     instruction space page and a one (1) for a data space page whenever  I/D
     space  addressing	is  enabled.   If I/D space addressing is not enabled
     this bit always reflects a zero (0).

     Bits 05 and 06, the processor mode status bits, indicate  the  processor
     execution	mode  associated with the page causing the abort.  These bits
     are coded as follows:

		 BIT
		06 05		EXECUTION MODE
		-----		--------------

		 0  0		KERNEL

		 0  1		SUPERVISOR

		 1  0		ILLEGAL (causes an abort with bit 15 set)

		 1  1		USER

     For more information on MMU aborts see micronote 008.

									  Page 6


			    MMR0    ADDRESS: 17777572

	  1   1	  1   1	  1   1	  0   0	  0   0	  0   0	  0   0	  0   0
	  5   4	  3   2	  1   0	  9   8	  7   6	  5   4	  3   2	  1   0
	+===+---+---+---+===+===+===+---+---+---+===+===+===+---+---+---+
	|   |	|   | 0 | 0 | 0 | 0 | 0 | 0 |	    |	|	    |	|
	+===+---+---+---+===+===+===+---+---+---+===+===+===+---+---+---+
	 |_| |_| |_|			     |_____| |_| |_________| |_|
	  |   |	  |				|     |	      |	      |
	  |   |	  |____ABORT READ-ONLY	      PAGE    |	    PAGE      |
	  |   |		ACCESS VIOLATION      MODE    |	    NUMBER    |
	  |   |					      |		      |
	  |   |________ABORT PAGE LENGTH ERROR	    PAGE	  ENABLE
	  |					   ADDRESS    RELOCATION
	  |____________ABORT NON-RESIDENT	   SPACE (I/D)



	BIT #		DESCRIPTION
	-----		-----------

	<15>	-	ABORT READ-ONLY ACCESS VIOLATION (R ONLY)
	<14>	-	ABORT PAGE LENGTH ERROR (R ONLY)
	<13>	-	ABORT NON-RESIDENT (R ONLY)
	<12:07> -	NOT USED (R ONLY)
	<06:05> -	PAGE MODE (R ONLY)
	<04>	-	PAGE ADDRESS SPACE (I/D) (R ONLY)
	<03:01> -	PAGE NUMBER (R ONLY)
	<00>	-	ENABLE RELOCATION (R/W)


				     FIGURE 1
		       MEMORY MANAGEMENT REGISTER 0 (MMR0)


     1.1.3	MEMORY MANAGEMENT REGISTER 3

     Memory  management	 register  3  (MMR3)  contains	control	 and   status
     information  for  data space addressing, 22 bit mapping, and the call to
     supervisor mode  (CSM)  instruction.   This  register,  once  again,  is
     discussed in detail in micronote 008.

     MMR3  contains  three  (3)	 control  bits	which	are   used   in	  the
     implementation  of	 I/D  space  addressing.   These bits, 00 through 02,
     individually enable data space addressing	for  each  of  the  execution
     modes.   Bit  00 enables data space addressing for the USER mode, bit 01
     enables it for SUPERVISOR mode, and bit 02 enables it for	KERNEL	mode.
     The  desired bits are set to a one (1) whenever data space addressing is
     desired.  MMR3 is cleared during  power-up,  console  restart,  and  the
     execution of the RESET instruction.  See figure 2.

									  Page 7


			MMR3 REGISTER	 ADDRESS: 17772516

	  1   1	  1   1	  1   1	  0   0	  0   0	  0   0	  0   0	  0   0
	  5   4	  3   2	  1   0	  9   8	  7   6	  5   4	  3   2	  1   0
	+===+---+---+---+===+===+===+---+---+---+===+===+===+---+---+---+
	| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |   |	|   |	MODE	|
	+===+---+---+---+===+===+===+---+---+---+===+===+===+---+---+---+
						 |_| |_| |_| |_| |_| |_|
						  |   |	  |   |	  |   |
			UNINTERPRETED_____________|   |	  |   |	  |   |
						      |	  |   |	  |   |
			ENABLE 22 BIT MAPPING_________|	  |   |	  |   |
							  |   |	  |   |
			ENABLE CSM INSTRUCTION____________|   |	  |   |
							      |	  |   |
			KERNEL________________________________|	  |   |
								  |   |
			SUPERVISOR________________________________|   |
								      |
			USER__________________________________________|


	BIT #		DESCRIPTION
	-----		-----------

	<15:06> -	NOT USED (R ONLY)
	<05>	-	UNINTERPRETED (R/W)
	<04>	-	ENABLE 22 BIT MAPPING (R/W)
	<03>	-	ENABLE CSM INSTRUCTION (R/W)
	<02>	-	KERNEL DATA SPACE (R/W)
	<01>	-	SUPERVISOR DATA SPACE (R/W)
	<00>	-	USER DATA SPACE (R/W)


				     FIGURE 2
			   MEMORY MANAGEMENT REGISTER 3



     1.1.4	I/D SPACE ADDRESS MAPPING

     When I/D space addressing has been enabled the MMU hardware performs the
     address  mapping  (IN  ADDITION TO ADDRESS RELOCATION WHICH IS PERFORMED
     USING THE APPROPRIATE SET OF APR'S) as follows:

	   1.  The current instruction is ALWAYS fetched from the instruction
	       space.

	   2.  The operands are mapped according to table 2.

									  Page 8


		+---------------+---------------+---------------+-------+
		| OPERAND	| REGISTER	| TYPE		| I OR D|
		| ADDRESSING	| USED		| OF		| SPACE |
		| MODE		|		| ADDRESSING	| USED	|
		+---------------+---------------+---------------+-------+
		| 000		| ANY		| REGISTER	| I	|
		+---------------+---------------+---------------+-------+
		| 001		| ANY		| REGISTER	| D	|
		|		|		| DEFERRED	|	|
		+---------------+---------------+---------------+-------+
		| 010		| 0 THROUGH 6	| AUTOINCREMENT | D	|
		|		|		|		|	|
		|		| 7		| IMMEDIATE	| I	|
		+---------------+---------------+---------------+-------+
		| 011		| 0 THROUGH 6	| AUTOINCREMENT | D (A) |
		|		|		| DEFERRED	| D (D) |
		|		|		|		|	|
		|		| 7		| ABSOLUTE	| I (A) |
		|		|		|		| D (D) |
		+---------------+---------------+---------------+-------+
		| 100		| 0 THROUGH 6	| AUTODECREMENT | D	|
		|		|		|		|	|
		|		| 7		| DO NOT USE !! |	|
		+---------------+---------------+---------------+-------+
		| 101		| 0 THROUGH 6	| AUTODECREMENT | D (A) |
		|		|		| DEFERRED	| D (D) |
		|		|		|		|	|
		|		| 7		| DO NOT USE !! |	|
		+---------------+---------------+---------------+-------+
		| 110		| ANY		| INDEX		| I (A) |
		|		|		|		| D (D) |
		+---------------+---------------+---------------+-------+
		| 111		| ANY		| INDEX		| I (A) |
		|		|		| DEFERRED	| D (A) |
		|		|		|		| D (D) |
		+---------------+---------------+---------------+-------+

			(A) = INDIRECT OR INDEX ADDRESS
			(D) = DATA


				     TABLE 2
		    OPERAND ADDRESSING WITH DATA SPACE ENABLED



     All address mapping is performed using the I space APR's when data space
     addressing is not enabled.

     The most difficult example showing data space addressing  is  the	index
     deferred type of addressing.

	       CLR	@1000(R3)

	   1.  The instruction is  fetched  from  the  instruction  space  at

									  Page 9


	       location PC.

	   2.  The base address 1000 is fetched from the instruction space at
	       location	 PC+2.	 The index in R3 is added to the base address
	       forming the address of the indirect address.

	   3.  The indirect address is fetched from the data space using  the
	       address calculated in step 2.

	   4.  The data is fetched from the  data  space  using	 the  address
	       calculated in step 3.


     1.2	I/D SPACE SOFTWARE

     At the present time I/D space addressing is supported by two (2) Digital
     supplied operating systems, RSX-11M-PLUS and ULTRIX-11.

     RSX-11M-PLUS  provides  linking  of  tasks	 which	utilize	  I/D	space
     addressing	 via  the  task	 builder (TKB) utility.	 Those programs which
     include the data PSECTs in their object files may be  task	 built	using
     the  /ID  switch.	 It should be noted that the task may not make use of
     the entire 32kw data space because RSX-11M-PLUS requires that the	stack
     and  the  task  header  be placed in data space.  Other restrictions may
     apply, consult the task builder manual for further information.

     When using I/D space with	other  operating  systems  or  in  standalone
     programs,	the  user  must	 do all the mapping within the program.	 This
     implies that the mapping of the operating system must be attended to  by
     the user program if operating system features are to be utilized.

     To make use of data space addressing the program must:

	   1.  Separate the instruction space  from  the  data	space.	 (ie.
	       create different regions in memory for instructions and data)

	   2.  Load the instruction space  and	data  space  APR's  with  the
	       appropriate relocation information.

	   3.  Enable I/D space mapping by setting the	MMR3  bit  associated
	       with the execution mode under which the program will run.

     The following restrictions apply to I/D space programs:

	   1.  The instruction space can only contain instructions, immediate
	       operands,  absolute  addresses,	and  index  words.   This  is
	       reflected in table 2.

	   2.  The stack page must be mapped into both instruction  and	 data
	       space  if  the MARK instruction is used because it is executed
	       off the stack.

	   3.	Instruction  space-only	 pages	cannot	 contain   subroutine
	       parameters  which are data.  This precludes the mapping of any
	       pages containing standard PDP-11	 calling  sequences  entirely

									 Page 10


	       into an instruction space page.

	   4.  The trap catcher technique of putting .+2 in the	 trap  vector
	       followed	 by  a	halt must be mapped into both instruction and
	       data space.

     For further information on I/D space addressing under  RSX-11M-PLUS  and
     ULTRIX-11 consult the appropriate documentation set.



     2.0	SUPERVISOR MODE

     The DCJ11 based processors provide three (3) execution  modes:   KERNEL,
     SUPERVISOR,  and  USER.   They  provide  for various forms of memory and
     processor protection and permit additional features to be implemented in
     multiprogramming  environments.   Each  mode  has its own set of mapping
     registers.

     KERNEL mode is the most privileged of the modes, allowing the  execution
     of	 any instruction and the modification of any area in memory including
     the I/O page.

     USER mode prohibits the execution of  privileged  instructions  such  as
     HALT  and	RESET and the modification of areas in memory that the KERNEL
     program does not provide access to.

     SUPERVISOR mode has the same privileges as USER mode with its own set of
     mapping   registers,   thus   providing  another  level  of  protection.
     SUPERVISOR mode is intended for use in  the  mapping  and	execution  of
     programs  to  be  shared  by users while still providing protection from
     them.  Examples of this are command line processors which	are  required
     for  use  by all users on a system, while necessitating write protection
     from them.

     The execution mode is controlled by the state of bits 14 and 15  in  the
     processor status word (PSW).  These bits are changed by the execution of
     traps and interrupts, pushing and popping of old PSW's to and  from  the
     stack, and, when in KERNEL mode, the direct manipulation by the program.
     Bits 12 and 13 reflect the execution mode which  existed  prior  to  the
     event which placed the processor in the current mode.  See figure 3.

     The current and previous mode PSW bits are coded as follows:

		 BIT
		15 14
		13 12		EXECUTION MODE
		-----		--------------

		 0  0		KERNEL
		 0  1		SUPERVISOR
		 1  0		ILLEGAL
		 1  1		USER

									 Page 11


		 PROCESSOR STATUS WORD (PSW)	ADDRESS: 17777776

	  1   1	  1   1	  1   1	  0   0	  0   0	  0   0	  0   0	  0   0
	  5   4	  3   2	  1   0	  9   8	  7   6	  5   4	  3   2	  1   0
	+===+---+---+---+===+===+===+---+---+---+===+===+===+---+---+---+
	|	|	|   | 0 | 0 |	|	    | T | N | Z | V | C |
	+===+---+---+---+===+===+===+---+---+---+===+===+===+---+---+---+
	 |_____| |_____| |_|	     |_| |_________| |_| |_____________|
	    |	    |	  |	      |	      |	      |		|
	 CURRENT PREVIOUS |	      |	   PRIORITY   |	    CONDITION
	   MODE	   MODE	  |	      |	    LEVEL     |	      CODES
			  |	      |		      |
			  |	      |		      |
			 GPR	  SUSPENDED	    TRACE
			GROUP	 INFORMATION	     BIT


	BIT #		DESCRIPTION
	-----		-----------

	<15:14> -	CURRENT MODE (R/W)
	<13:12> -	PREVIOUS MODE (R/W)
	<11>	-	GENERAL PURPOSE REGISTER SET (R/W)
	<10:09> -	NOT USED (R ONLY)
	<08>	-	SUSPENDED INFORMATION (R/W)
	<07:05> -	PROCESSOR PRIORITY LEVEL (R/W)
	<04>	-	TRACE BIT (R/W)
	<03>	-	NEGATIVE CONDITION CODE (R/W)
	<02>	-	ZERO CONDITION CODE (R/W)
	<01>	-	OVERFLOW CONDITION CODE (R/W)
	<00>	-	CARRY CONDITION CODE (R/W)


				     FIGURE 3
			      PROCESSOR STATUS WORD

================================================================================
Note 12.0                       DMA on the Q-bus                      No replies
JAWS::KAISER                                        174 lines  25-MAR-1985 09:20
--------------------------------------------------------------------------------
      +---------------+					   +-----------------+
      | d i g i t a l |					   |  uNOTE # 012    |
      +---------------+					   +-----------------+


      +----------------------------------------------------+-----------------+
      | Title:	DMA on The Q-bus			   | Date: 06-SEP-84 |
      +----------------------------------------------------+-----------------+
      | Originator:  Jack Toto				   | Page 1 of 4     |
      +----------------------------------------------------+-----------------+



      This Micronote explains the various types of DMA on the  Q-bus;	Single
      Cycle Mode, Burst Mode and Block Mode.


	    SINGLE CYCLE MODE:
	    ------------------

      Single cycle mode DMA like all DMA on the Q-bus requires	that  the  DMA
      device gain control of the bus through an arbitration cycle.  During the
      arbitration cycle the DMA device becomes bus master by first asserting a
      DMA  request  (BDMR).   When  the	 arbiter  acknowledges this request it
      issues a DMA grant (BDMGO).  In the event that there is  more  than  one
      DMA  device  in  the  backplane  the  grant signal is daisy chained from
      device to device.	 Eventually the device that  issued  the  DMA  request
      will  latch  the	grant  signal and take control of the bus, and proceed
      with the DMA transfer.

      Once becoming bus master the device asserts BSACK and is allowed	to  do
      one  word	 tranfer to or from memory, during which time the CPU is idle.
      Certain processors such as the KDJ11-B have a cache memory with dual tag
      store which allows it to process data while DMA transfers are occurring.
      Regardless of which processor type is used only one transfer is  allowed
      in  single cycle mode.  If the device must perform additional transfers,
      it must go through the bus arbitration cycle again.


			    _______________		 _______________
	  SACK	___________/		   \____________/		\_____

	  BDAL	__________/    ADRS/DATA    \___________/   ADRS/DATA	 \_____
					 1			      2



      In single cycle mode, the theoretical transfer rate across the Q-bus  is
      1.66  Mbytes/sec	(833Kw/sec)  A device such as the DRV11-B or the newer
      22-bit compatible DRV11-W can transfer data at a rate of 250KW/sec while
      in single cycle mode.
									Page 2





	    BURST MODE:
	    -----------

      Burst mode DMA can be performed by certain devices such as the  DRV11-B.
      Once  the	 DMA  controller  becomes  bus master (through the arbitration
      routine described in the single cycle section and it has asserted BSACK,
      the  DMA	tranfers  can  begin.	Each  data  word that is transfered is
      accompanied by an address that the data word is targeted for.  In	 burst
      mode  loading  an	 octal value into the 16 bit word count register (WCR)
      allows for that number of words (64Kb max) to be	transfered  under  one
      sack.   This  differs  from single mode, in that the word count register
      can be loaded with the same value, but each single  word	transfer  will
      require a new arbitraion cycle, i.e in order to transfer 64Kb of data it
      would require 65,536 arbitration cycles.



			________________________________________________
	      SACK ____/						\____


	      BDAL ____/ADRS/DATA ADRS/DATA ADRS/DATA................(N)\____

			  N := word count;



      The theoretical transfer rate across the Q-bus in burst mode remains  at
      1.66 Mbytes/sec, however a device such as the DRV11-B operating in burst
      mode can transfer data at a rate twice that of a	DRV11-B	 operating  in
      single  mode,  or 500Kw/sec.  In burst mode the DMA bus master maintains
      control of the bus until it has transferred all of  the  required	 data.
      Burst mode has the advantage of moving large blocks of memory across the
      bus with no delay.  The caution here is that no other device  (including
      the  CPU)	 has access to the bus during that time.  This can have severe
      impact on system performance.


	    DMA COMPROMISE:
	    --------------


      Since Single Cycle Mode requires a rearbitration for every data transfer
      and  Burst  Mode	can adverseley impact system performance in some cases
      DIGITAL EQUIPMENT CORP.  has made	 some  compromises  with  certain  DMA
      controllers.   Most  DIGITAL  devices  will  do  a  limited  Burst  Mode
      operation.  These controllers (for example  the  RXV21  and  RLV12)  are
      allowed  up  to do four words of data tranfer.  Each word of transfer is
      preceeded on the bus by an address that the data word is	targeted  for.
      This  allows data to move across the bus with a minimum of rearbitraton.
      However, when a group of four transfers is  finished,  the  DMA  devices
      must  again  go  through	the  arbitration cycle in order to allow other
									Page 3


      devices the opportunity to use the bus.  If no other  bus	 requests  are
      pending  at  a  higher priority, then bus mastership will be returned to
      the device for the next set of data transfers.



				______________________________________
	      SACK  ___________/				      \_______

	      BDAL  ___________/ADRS/DATA ADRS/DATA ARDS/DATA ADRS/DATA\_______
				1	  2	    3	      4




	    BLOCK MODE:
	    ----------

      For increased throughput, Block Mode DMA may be implemented on a	device
      for  use	with  memories that support this type of transfer.  Block Mode
      DMA devices are only block mode when operating.  They may not operate as
      a	 Single	 or  Burst  Mode device.  They may, however, appear to operate
      like a single mode device if they are only doing a single word transfer,
      and  they will always look like a Single Cycle Mode DMA device when used
      with non-Block Mode memory.


      Once a Block Mode device has arbitrated for the bus, the starting memory
      address  is  asserted,  then data for that address, followed by data for
      consecuetive addresses.  By eliminating the assertion of the address for
      each  data  word,	 the  transfer rate is almost doubled.	The DMA device
      should monitor the BDMR line.  If the line is  not  asserted  after  the
      seventh transfer than the device can continue.  This allows a maximum of
      16 data transfers for one abitration cylce.  If the  BDMR	 line  is  not
      monitored	 by  the  DMA device than a maximum data tranfer of 8 words is
      allowed after completing one bus	arbitration  cycle.   Block  Mode  DMA
      transactions can be described as two types, a DATBI (block mode data in)
      and DATBO (block mode data out).	Both of these cycles are explained  in
      depth  in	 the  Micronote's.   When  reading  the	 appropriate micronote
      special attention should be paid to the use of  BREF  and	 BBS7  signals
      when performing a DATBO.


		      ___________________________________________
	      SACK___/						 \___

	      BDAL___/ADRS/DATA/.........DEPENDS ON STATE OF BDMR\___
			    (1)		  * (7)		     (16)
					  |
		  ___			  |
	      BDMR   \____________________*_______________________/\/\/



      Block Mode devices such as the DEQNA, RQDX1 and the MSV11-P memories can
									Page 4


      transfer	data  across  the bus at rates that approach twice that of DMA
      devices in Burst Mode.  The actual rate is  dependent  upon  the	device
      itself.	The  technical	manuals	 for  each  of these devices should be
      checked for actual performance figures.

================================================================================
Note 13.0                 MicroPower Run-time Perform.                No replies
JAWS::KAISER                                        254 lines  25-MAR-1985 09:20
--------------------------------------------------------------------------------
	+---------------+				     +-----------------+
	| d i g i t a l |				     |	uNOTE # 013    |
	+---------------+				     +-----------------+


	+----------------------------------------------------+-----------------+
	| Title: Run-time System Performance Evaluation	     | Date: 09-Oct-84 |
	|	    Using MicroPower/Pascal V 1.5	     |		       |
	+----------------------------------------------------+-----------------+
	| Originator: Herbert Maehner			     | Page 1 of 5     |
	+----------------------------------------------------+-----------------+



       In real-time programming, the performance of the	 run-time  system  and
       the compiler together govern the overall power of the application.  The
       performance of the  MicroPower/Pascal  compiler	has  been  extensively
       discussed by R.Billig/R.Cronk [1].

       The performance of  the	run-time  executive  of	 MicroPower/Pascal  is
       measured	 in  this  MicroNote using different LSI-11 CPU-boards and the
       KXT11-CA I/O processor.	 Data  was  obtained  using  MicroPower/Pascal
       version 1.5.

			       Test Conditions
			       ---------------

       Results obtained through a lab experiment are only as  precise  as  the
       test  environment  and  may  only  be  referenced giving the exact test
       conditions.

       The goal was to measure the elapsed time of a given primitive execution
       on  the Pascal process level, i.e.  how long it takes to call/execute a
       kernel primitive from a Pascal program.

       Generally, the following procedure was used to obtain the elapsed time,
       where  in  some	cases more than one output bit has been used to obtain
       the desired pulse-width.

		    WHILE Condition = TRUE DO
		    BEGIN
		      Out_port.bit0 := TRUE;

			{ here call/execute given primitive }

		      Out_port.bit0 := FALSE;
		    END;

       The whole test was done in a loop as long as the	 condition  was	 true.
       Here,  Condition	 is  a	boolean variable, which is set FALSE by a high
       priorty process waiting on a terminal input (READLN).

       The Outport.bit0 is bit0 of a parallel device.  The parallel device was
       either a DRV11 (using LSI 11/23 and LSI 11/73) or the on-board parallel
       device (using the FALCON plus SBC 11/21 and KXT11-CA).

									Page 2


       The bit0 pulse is used as the input to an oscilloscope  which  has  the
       capabilities  to	 measure and display time differences and frequencies.
       The elapsed  time  required  to	execute	 the  various  primitives  was
       obtained.   In  addition	 to the primitive requests some math-functions
       times were obtained.  The results are shown in Table 1 at the  of  this
       MicroNote.

			  Interrupt-Test Conditions
			  -------------------------

       A Pascal-program with  an  embedded  interrupt  service	routine	 needs
       DRIVER  privileges  in  a  mapped environment.  The test program either
       connects to a "normal" ISR or to a prio7 ISR.  The program  executed  a
       simple loop like:

		       WHILE TRUE DO
		       BEGIN
			Out_port.Bit1 := TRUE;
			Out_port.Bit1 := FALSE;
		       END;


       The Outport is the parallel device of the type mentioned	 above.	  This
       is  used	 to monitor process execution behavior.	 Testing the interrupt
       response time, we used a	 square	 wave  generator  which	 triggered  an
       interrupt on that parallel device.  The ISR was coded as

		    .ENABL  GBL		    ; Enable global symbols
		    .MCALL  MACDF$,PURE$    ; Set-up pure/impure area
		    .MCALL  IMPUR$

		    .GLOBL  INPORT,OUTPRT   ; port A,B of PPI

		    MACDF$		    ; MACDF$ must be called before the
		    PURE$		    ; two assembly directives

		    .DSABL AMA

	    PPIINT::
		    BISB    #1,@#OUTPRT	    ; set bit 0 output port   -------
		    MOVB    @#INPORT,@#Temp ; dummy read	       | ISR time
		    MOVB    @#INPORT,@#Temp ; dummy read	       | measured
		    BICB    #1,@#OUTPRT	    ; set bit 0 output port   -------
		    RTS	    PC		    ; normal ISR return
		    RTS	    R4		    ; prio 7 ISR return

		    IMPUR$
	    TEMP:   .WORD 0		    ; reserve one word
		    .END


       Depending upon the ISR-type either the RTS PC or the  RTS  R4  must  be
       used  to	 exit  the  ISR.   The	first  MACRO-statement	within the ISR
       signaled bit0 of the parallel port.  The resulting  interrupt  dispatch
       time  was defined as the pulse width given by the square wave generator

									Page 3


       edge and the signaled output port.   This  includes  the	 hardware  ISR
       dispatch	 time  as well.	 The ISR execution time was given by the pulse
       width indicated within  ISR  source  above.   Again,  all  pulses  were
       measured	 using	an  oscilloscope.   The	 maximum  interrupt  rate  was
       determined by increasing the square frequency (which in turn  increases
       the outpt square wave of the ISR) until the system lost interrupts.

       Using  CONNECT  SEMAPHORE  the  interrupt  performance  was   similarly
       measured.   In  this  case  only	 a  dynamic process was waiting on the
       semaphore to be signaled.  The results are shown in table 2.






	    References

	    1. Rich Billig and Randy Cronk, A System/Architecture Approach to
	       Microcomputer Benchmarking, DIGITAL Equipment Corporation,
	       Sept. 1982, EZ-12053-03/82

	    2. MicroPower/Pascal Newsletter, Volume 1, No. 1, March 1984, p. 23,
	       DIGITAL Equipment Corporation, Order Number AV-B067A-TK

									Page 4


	    +---------------+-----------+-----------+-----------+------+------+
	    |		    | LSI-11/23 | LSI-11/23 |		|      |      |
	    | Operation	    |  w/o FPU	|  w/ FPU   | LSI-11/73 | SBC  | KXT11|
	    |		    |  u     m	|  u	 m  |  u     m	|11/21+|  -CA |
	    +---------------+-----------+-----------+-----------+------+------+
	    |Process	    |		|	    |		|      |      |
	    |	  creation  | 3.1  5.48 | 3.56 5.93 | 1.84 2.64 | 3.96 | 2.71 |
	    |	  deletion  | 2.4  4.19 | 2.55 4.35 | 1.14 1.92 | 2.96 | 2.06 |
	    +---------------+-----------+-----------+-----------+------+------+
	    |Schedule +	    |		|	    |		|      |      |
	    | Context Switch| 0.56 0.97 | 0.82 1.27 | 0.38 0.57 | 0.69 | 0.49 |
	    +---------------+-----------+-----------+-----------+------+------+
	    | Ring_buffer   |		|	    |		|      |      |
	    |  1 character  |		|	    |		|      |      |
	    |		get | 0.55 0.96 | 0.55 0.99 | 0.27 0.42 | 0.67 | 0.47 |
	    |		put | 0.50 0.93 | 0.51 0.95 | 0.25 0.39 | 0.63 | 0.43 |
	    |  2 characters |		|	    |		|      |      |
	    |		get | 0.61 1.05 | 0.61 1.05 | 0.29 0.43 | 0.72 | 0.51 |
	    |		put | 0.58 1.01 | 0.58 1.02 | 0.28 0.42 | 0.70 | 0.49 |
	    |  4 characters |		|	    |		|      |      |
	    |		get | 0.73 1.20 | 0.73 1.18 | 0.36 0.50 | 0.88 | 0.62 |
	    |		put | 0.71 1.17 | 0.71 1.15 | 0.35 0.49 | 0.86 | 0.60 |
	    | Signal Semaphr|		|	    |		|      |      |
	    |  by descriptor| 0.35 0.64 | 0.35 0.65 | 0.16 0.25 | 0.44 | 0.30 |
	    |  by name	    | 0.61 0.93 | 0.61 0.94 | 0.27 0.37 | 0.75 | 0.52 |
	    |  fast named   | 0.36 0.65 | 0.36 0.66 | 0.17 0.29 | 0.44 | 0.30 |
	    +---------------+-----------+-----------+-----------+------+------+
	    | Get_status    | 0.42 0.84 | 0.42 0.85 | 0.20 0.33 | 0.50 | 0.35 |
	    +---------------+-----------+-----------+-----------+------+------+
	    | Send + Receive|		|	    |		|      |      |
	    |	(by value)  |		|	    |		|      |      |
	    |	  -  1 Byte | 1.17 2.18 | 1.18 2.20 | 0.59 0.89 | 1.45 | 1.01 |
	    |	  - 34 Bytes| 1.46 2.50 | 1.46 2.51 | 0.73 1.11 | 1.79 | 1.24 |
	    | Send + Receive|		|	    |		|      |      |
	    | (by reference)|		|	    |		|      |      |
	    |	 -  10 Bytes| 1.26 2.28 | 1.26 2.31 | 0.67 0.96 | 1.54 | 1.08 |
	    |	 - 100 Bytes| 1.59 2.64 | 1.59 2.67 | 0.84 1.14 | 1.94 | 1.35 |
	    |	 - 500 Bytes| 3.09 4.32 | 3.09 4.35 | 1.74 2.11 | 3.78 | 2.63 |
	    +---------------+-----------+-----------+-----------+------+------+
	    | TAN	    | 6.84 7.74 | 1.64 1.68 | 0.35 0.36 | 9.00 | 6.24 |
	    +---------------+-----------+-----------+-----------+------+------+
	    | SIN	    | 5.13 5.82 | 1.75 1.78 | 0.33 0.34 | 6.80 | 4.69 |
	    +---------------+-----------+-----------+-----------+------+------+
	    | COS	    | 6.19 7.00 | 1.94 1.98 | 0.39 0.39 | 8.15 | 5.64 |
	    +---------------+-----------+-----------+-----------+------+------+
	    | EXP	    | 5.04 5.69 | 1.45 1.48 | 0.32 0.33 | 6.55 | 4.59 |
	    +---------------+-----------+-----------+-----------+------+------+
	    | LN	    | 5.34 6.01 | 1.27 1.31 | 0.28 0.29 | 6.95 | 4.86 |
	    +---------------+-----------+-----------+-----------+------+------+

		 Table 1: MicroPower/Pascal V1.5 Runtime System (millisec)

									Page 5


				    Notes for Table 1
				    -----------------
			  o  u = without MMU  and m = with MMU
			  o  FPU = with floating point unit  (KEF11)
			  o  Send/Receive without context-switch
			  o  SBC-11/21+ using on-board memory only


	     +------------------------+-----------+-----------+-------+-------+
	     | Operation	      | LSI-11/23 | LSI-11/73 |	 SBC  | KXT11 |
	     |			      |	 u	m |  u	    m | 11/21+|	 -CA  |
	     +------------------------+-----------+-----------+-------+-------+
	     |	ISR:		      |		  |	      |	      |	      |
	     |			      |		  |	      |	      |	      |
	     | Interrupt dispatch-    |		  |	      |	      |	      |
	     |	time (usec)	      | 62     91 | 42	   54 |	  81  |	  61  |
	     |			      |		  |	      |	      |	      |
	     | ISR execution	      |		  |	      |	      |	      |
	     |	 time (usec)	      | 20     23 |   13.4    |	  21  |	  16  |
	     |			      |		  |	      |	      |	      |
	     | Maximal interrupt-     |		  |	      |	      |	      |
	     |	 frequency (kHz)      | 7.0   5.1 | 12.9 10.9 |	 4.8  |	 7.5  |
	     +------------------------+-----------+-----------+-------+-------+
	     |	PRIO7 ISR:	      |		  |	      |	      |	      |
	     |			      |		  |	      |	      |	      |
	     | Interrupt dispatch-    |		  |	      |	      |	      |
	     |	time (usec)	      | 28.5   60 | 22	   38 |	  32  |	  28  |
	     |			      |		  |	      |	      |	      |
	     | ISR execution	      |		  |	      |	      |	      |
	     |	 time (usec)	      | 20     24 |   13.4    |	  21  |	  16  |
	     |			      |		  |	      |	      |	      |
	     | Maximal interrupt-     |		  |	      |	      |	      |
	     |	 frequency (kHz)      | 17.8  9.3 | 26	   16 |	 12.8 |	 16.5 |
	     +------------------------+-----------+-----------+-------+-------+
	     | CONNECT_SEMAPHORE: (one process waiting on that semaphore)     |
	     |								      |
	     | Interrupt dispatch +   |		  |	      |	      |	      |
	     |	 context-switch time  |		  |	      |	      |	      |
	     |	  (msec)	      | 0.88 1.36 | 0.49 0.63 |	 1.15 |	 0.82 |
	     |			      |		  |	      |	      |	      |
	     | Maximal interrupt-     |		  |	      |	      |	      |
	     |	   frequency (kHz)    | 0.67 0.39 | 1.20 0.83 |	 0.41 |	 0.75 |
	     +------------------------+-----------+-----------+-------+-------+

			      Table 2: Interrupt Performance

				     Note for Table 2
				     ----------------
		 Additionally, the system had to service the  clock  interrupt
		 at a rate of 50 Hz without the clock driver implemented, i.e.
		 the interrupt dispatcher discarded the interrupt.  The	 clock
		 interrupt was enabled because realistically most systems have
		 the clock enabled.

================================================================================
Note 14.0                 Fortran Routines from VAXELN                No replies
JAWS::KAISER                                        203 lines  25-MAR-1985 09:20
--------------------------------------------------------------------------------
      +---------------+					   +-----------------+
      | d i g i t a l |					   |  uNOTE # 014    |
      +---------------+					   +-----------------+


      +----------------------------------------------------+-----------------+
      | Title:	    Using Fortran Routines In A		   | Date: 16-Oct-84 |
      |		     VAXELN-Pascal Environment		   |		     |
      +----------------------------------------------------+-----------------+
      | Originator:  Herbert F. Maehner			   | Page 1 of 4     |
      +----------------------------------------------------+-----------------+


      This Micronote discusses the VAXELN interface to	VAX-11	Fortran.   The
      following topics are covered are discussed:

	   1.  The VAX-11 Procedure Calling Standard

	   2.  Establishing a COMMON-data area between a  VAXELN  program
	   and Fortran routines

		      VAXELN Procedure Calling Standard
		      ---------------------------------

      VAXELN Pascal (EPascal)  does  conform  to  the  VAX  Procedure  Calling
      Standard.	  The standard allows for three methods of parameter passing :
      value, reference, and descriptor, and requires that values be no	longer
      than  a  longword.   EPascal  does not explicitly support descriptors as
      parameters, and other languages may not treat conformant	parameters  as
      EPascal does, but EPascal does nothing to violate the calling standard.

      All routines can be described according to the conventions described  in
      the  summary  of run-time library entry points [1].  There are principle
      differences in passing parameters in Pascal and Fortran:

      In Pascal, you may pass parameters as

       - values, e.g PROCEDURE Pass_it (What: INTEGER);

	   i.e.	 the value of the  parameter  will  be	copied	into  the
	   procedure's	stack  frame  with no implications for the source
	   variable.  This is termed pass by value.

      or as

       - variable, e.g. PROCEDURE Pass_it (VAR What: INTEGER);

	   i.e.	 the parameter will be referenced  through  its	 address.
	   An  assignment  to  the  parameter  within  the procedure will
	   directly affect the source variable.	 This is termed	 pass  by
	   reference.

									Page 2



      In Fortran, you pass parameters as

       - values, e.g. SUBROUTINE Passit( What)
		      INTEGER*4 What

	   i.e.	 with no implications for the source.  It uses	a  common
	   data	 area  to  pass	 variables to the main program.	 The main
	   difference to Pascal is, that Fortran uses pass by  reference,
	   although it is actually a value.

      Calling  a  Fortran  routine  with  parameter  passing  from  a	Pascal
      environment,  you	 have  to  declare the parameters as VAR parameters in
      Pascal ( Figure 1 and Figure 2).


			       COMMON Data Area
			       ----------------

      As mentioned before, Fortran uses a COMMON data area to  pass  variables
      from  procedures	to the main part of the program.  In VAX-11 Pascal the
      [COMMON] attribute enables the  linker  to  establish  the  common  data
      section.	VAXELN- Pascal has no such attribute and wouldn't overlay data
      sections for common areas.  To overcome this restriction	you  must  use
      the  [EXTERNAL]  attribute  in  VAXELN-Pascal to declare the prospective
      data as externally declared and use a MACRO-32 declaration to assign the
      Fortran common part to the "global" data area (Figure 3).





	 References:

	 1. VMS RUN TIME LIBRARY USER'S GUIDE (Summary of Run Time
					       Library Entry Points)

	 2. VAXELN Encyclopedia, Procedures and Functions,

	 3. VMS MACRO Language Reference Manual

									Page 3


	  +--------------------------------------------------------------------+
	  |  MODULE Fortran_TO_Pascal;					       |
	  |								       |
	  |  { This module is a simple example on, how to use Fortran	       |
	  |    routines in VAXELN.  }					       |
	  |								       |
	  |  CONST							       |
	  |    Max = 50;						       |
	  |								       |
	  |  TYPE							       |
	  |    Array_type = ARRAY[1..Max] OF INTEGER;			       |
	  |								       |
	  |  VAR							       |
	  |    AA: [EXTERNAL] Array_type;				       |
	  |								       |
	  |  PROCEDURE Valaccess (VAR What:INTEGER); EXTERNAL;		       |
	  |								       |
	  |  FUNCTION Double_it (VAR What: INTEGER):INTEGER; EXTERNAL;	       |
	  |								       |
	  |  PROGRAM FORTEST(INPUT,OUTPUT);				       |
	  |								       |
	  |  VAR							       |
	  |    What,I,J,K:  INTEGER;					       |
	  |    Twenty: [READONLY] INTEGER:=20;				       |
	  |								       |
	  |  BEGIN							       |
	  |    WRITELN('Program start ');				       |
	  |    FOR I:=1 TO Max DO AA[I] := 0; { initialize array }	       |
	  |    Valaccess(Twenty);	 { call Fortran routine Valaccess }    |
	  |    FOR I:=21 TO Max DO					       |
	  |    BEGIN							       |
	  |	 What := I;						       |
	  |	 AA[I] := Double_it(What);     { use Fortran Function to       |
	  |    END;				     double array value }      |
	  |								       |
	  |    {  formated output to screen  }				       |
	  |								       |
	  |    K := 1;							       |
	  |    FOR I:=1 TO 10 DO					       |
	  |    BEGIN							       |
	  |	 FOR J:=1 TO 5 DO					       |
	  |	 BEGIN							       |
	  |	   WRITE(AA[K]:4,'  ');					       |
	  |	   K := K+1						       |
	  |	 END;							       |
	  |	 WRITELN;						       |
	  |    END;							       |
	  |  END;							       |
	  |  END; { end of module Fortran_to_Pascal }			       |
	  |								       |
	  +--------------------------------------------------------------------+
		    Figure 1 : VAXELN main program module

									Page 4



	  +--------------------------------------------------------------------+
	  | C								       |
	  | C Fortran SUBROUTINE TO SET THE INDEXED ARRAY VALUE		       |
	  | C THE MAXIMAL INDEX IS PASSED AS A PARAMETER		       |
	  | C								       |
	  |	 SUBROUTINE VALACCESS(WHAT)				       |
	  |	 IMPLICIT INTEGER*4 (A-Z)				       |
	  | C								       |
	  |	 COMMON	 /XX$AA/ AA(50)					       |
	  | C								       |
	  | C								       |
	  |	 DO 10 I=1,What						       |
	  |	 AA(I) =  What-I					       |
	  | 10	 CONTINUE						       |
	  | C								       |
	  |	 RETURN							       |
	  | C								       |
	  |	 END							       |
	  | C								       |
	  | C								       |
	  | C								       |
	  | C INTEGER FUNCTION TO DOUBLE THE VALUE PASSED AS A PARAMETER       |
	  | C								       |
	  |	 INTEGER FUNCTION DOUBLE_IT(WHAT)			       |
	  |	 IMPLICIT INTEGER*4 (A-Z)				       |
	  |	 DOUBLE_IT = WHAT + WHAT				       |
	  |	 RETURN							       |
	  | C								       |
	  |	 END							       |
	  |								       |
	  +--------------------------------------------------------------------+
		   Figure 2: External Fortran routines used

	  +--------------------------------------------------------------------+
	  | ;								       |
	  | ; definition file for common array AA to be accessed by Fortran    |
	  | ; subroutine VALACCESS					       |
	  | ; the P-section name XX$AA must be the same as the one used in the |
	  | ; Fortran routine						       |
	  | ;								       |
	  |	 .TITLE COMDAT						       |
	  |	 .PSECT XX$AA,LONG,PIC,USR,OVR,REL,GBL,SHR,NOEXE,RD,WRT,NOVEC  |
	  | AA:: .LONG 50						       |
	  |	 .END							       |
	  |								       |
	  +--------------------------------------------------------------------+
	 Figure 3: MACRO definition module to define the common array

================================================================================
Note 15.0                   Q-bus Hardware Bootstraps                 No replies
JAWS::KAISER                                        194 lines  25-MAR-1985 09:21
--------------------------------------------------------------------------------
      +---------------+					   +-----------------+
      | d i g i t a l |					   |  uNOTE # 015    |
      +---------------+					   +-----------------+


      +----------------------------------------------------+-----------------+
      | Title: Q-Bus Hardware Bootstraps		   | Date: 16-Oct-84 |
      +----------------------------------------------------+-----------------+
      | Originator: Dave Smith				   | Page 1 of 4     |
      +----------------------------------------------------+-----------------+


      The purpose of this micronote is to  provide  a  comprehensive  list  of
      Q-Bus hardware bootstraps and the devices they support.

      The tables on the next two pages are organized as follows.  There	 is  a
      row  for	each  of the currently supported bootable devices.  There is a
      column for each hardware bootstrap.  The columns span  both  pages.   In
      the  heading  for	 each bootstrap will be found any ordering information
      and/or references to notes which follow  the  tables.   When  two	 order
      numbers  are  given, both must be ordered since the boot code is divided
      into high byte and low byte ROMs.


      The bootstrap devices listed are:



	+============+======================================================+
	|	     |							    |
	|    BOOT    |			DESCRIPTION			    |
	|   DEVICE   |							    |
	|	     |							    |
	+============+======================================================+
	| BDV11	     | Bus Terminator, Bootstrap & Diagnostic ROM	    |
	|	     |	 used primarily with older LSI-11 configurations    |
	+------------+------------------------------------------------------+
	| MXV11-A2   | Bootstrap ROM set designed for MXV11-A board	    |
	+------------+------------------------------------------------------+
	| MXV11-B2   | Bootstrap ROM set designed for MXV11-BF & MRV11-D    |
	+------------+------------------------------------------------------+
	| KDF11-BA   | Bootstrap ROM on board PDP-11/23+ systems	    |
	+------------+------------------------------------------------------+
	| KDF11-BE   | Bootstrap ROM on board MicroPDP-11/23 systems	    |
	+------------+------------------------------------------------------+
	| KDF11-BF   | New Bootstrap ROM for PDP-11/23+ and MicroPDP-11/23  |
	+------------+------------------------------------------------------+
	| KXT11-A2   | Bootstrap ROM on board Falcon			    |
	+------------+------------------------------------------------------+
	| KXT11-A5   | Bootstrap ROM on board Falcon-Plus		    |
	+------------+------------------------------------------------------+
	| KDJ11-B    | Bootstrap ROM on board MicroPDP-11/73 CPU	    |
	+------------+------------------------------------------------------+
	| uVAX I     | Bootstrap ROM on board MicroVAX I CPU		    |
	+============+======================================================+

								Page 2



			BOOTSTRAP DEVICE SUPPORT

	+==========+==========+==========+==========+==========+==========+
	|  DEVICE  |  BDV11   | MXV11-A2 | MXV11-B2 | KDF11-BA | KDF11-BE |
	|	   |	      |		 |	    |	       |	  |
	|	   |  Rev A   |		 |see Note 2| part no  | part no. |
	|	   |	      |		 |	    |  23-339E2|  23-157E4|
	|	   |see Note 1|		 |	    |  23-340E2|  23-158E4|
	+==========+==========+==========+==========+==========+==========+
	|  RX01	   |	X     |	    X	 |     X    |	  X    |     X	  |
	+----------+----------+----------+----------+----------+----------+
	|  RX02	   |	X     |	    X	 |     X    |	  X    |     X	  |
	+----------+----------+----------+----------+----------+----------+
	|  TU58	   |see Note 1|	    X	 |     X    |	  X    |     X	  |
	+----------+----------+----------+----------+----------+----------+
	|  RL01/2  |	X     |	    X	 |     X    |	  X    |     X	  |
	+----------+----------+----------+----------+----------+----------+
	|  MRV11-C |	      |	    X	 |	    |	  X    |	  |
	+----------+----------+----------+----------+----------+----------+
	|  MRV11-D |	      |		 |	    |	       |	  |
	+----------+----------+----------+----------+----------+----------+
	|  RK05	   |	X     |	    X	 |	    |	       |	  |
	+----------+----------+----------+----------+----------+----------+
	|  RX50	   |	      |		 |     X    |	       |     X	  |
	+----------+----------+----------+----------+----------+----------+
	|  RD51	   |	      |		 |     X    |	       |     X	  |
	+----------+----------+----------+----------+----------+----------+
	|  RD52	   |	      |		 |	    |	       |	  |
	+----------+----------+----------+----------+----------+----------+
	|  TSV05   |	      |		 |     X    |	       |	  |
	+----------+----------+----------+----------+----------+----------+
	|  TK25	   |	      |		 |	    |	       |	  |
	+----------+----------+----------+----------+----------+----------+
	|  RC25	   |	      |		 |	    |	       |	  |
	+----------+----------+----------+----------+----------+----------+
	|  DEQNA   |	      |		 |	    |	       |	  |
	+----------+----------+----------+----------+----------+----------+
	|  DLV11-E |	X     |		 |     X    |	  X    |	  |
	+----------+----------+----------+----------+----------+----------+
	|  DLV11-F |	X     |		 |     X    |	  X    |	  |
	+----------+----------+----------+----------+----------+----------+
	|  DUV11   |	X     |		 |     X    |	  X    |	  |
	+----------+----------+----------+----------+----------+----------+
	|  DPV11   |	      |		 |     X    |	       |	  |
	+==========+==========+==========+==========+==========+==========+

								Page 3



			BOOTSTRAP DEVICE SUPPORT

	+==========+==========+==========+==========+==========+==========+
	|  DEVICE  | KDF11-BF | KXT11-A2 | KXT11-A5 | KDJ11-B  |  uVAX I  |
	|	   |	      |		 |	    |	       |	  |
	|	   | part no  |		 |	    |available |available |
	|	   |  23-183E4|		 |	    |  on CPU  |  on CPU  |
	|	   |  23-184E4|		 |	    |board only|board only|
	+==========+==========+==========+==========+==========+==========+
	|  RX01	   |	X     |	    X	 |     X    |	  X    |	  |
	+----------+----------+----------+----------+----------+----------+
	|  RX02	   |	X     |	    X	 |     X    |	  X    |	  |
	+----------+----------+----------+----------+----------+----------+
	|  TU58	   |	X     |	    X	 |     X    |	  X    |	  |
	+----------+----------+----------+----------+----------+----------+
	|  RL01/2  |	X     |		 |     X    |	  X    |	  |
	+----------+----------+----------+----------+----------+----------+
	|  MRV11-C |	      |		 |	    |	       |	  |
	+----------+----------+----------+----------+----------+----------+
	|  MRV11-D |	      |		 |	    |	       |     X	  |
	+----------+----------+----------+----------+----------+----------+
	|  RK05	   |	      |		 |	    |	  X    |	  |
	+----------+----------+----------+----------+----------+----------+
	|  RX50	   |	 X    |		 |     X    |	  X    |     X	  |
	+----------+----------+----------+----------+----------+----------+
	|  RD51	   |	 X    |		 |     X    |	  X    |     X	  |
	+----------+----------+----------+----------+----------+----------+
	|  RD52	   |	 X    |		 |	    |	  X    |     X	  |
	+----------+----------+----------+----------+----------+----------+
	|  TSV05   |	 X    |		 |	    |	       |	  |
	+----------+----------+----------+----------+----------+----------+
	|  TK25	   |	 X    |		 |	    |	  X    |	  |
	+----------+----------+----------+----------+----------+----------+
	|  RC25	   |	 X    |		 |	    |See note 3|See note 3|
	+----------+----------+----------+----------+----------+----------+
	|  DEQNA   |	 X    |		 |	    |	  X    |     X	  |
	+----------+----------+----------+----------+----------+----------+
	|  DLV11-E |	      |		 |	    |	  X    |	  |
	+----------+----------+----------+----------+----------+----------+
	|  DLV11-F |	      |		 |	    |	  X    |	  |
	+----------+----------+----------+----------+----------+----------+
	|  DUV11   |	      |		 |	    |	  X    |	  |
	+----------+----------+----------+----------+----------+----------+
	|  DPV11   |	      |		 |	    |	       |	  |
	+==========+==========+==========+==========+==========+==========+

								Page 4



			NOTES:
			------

	(1)	The information in the BDV11 column refers to the Rev A
		chips.	There were also Rev O chips and an additional TU58
		chip that can be added to the board:

		Rev O:

			Part numbers 23-010E2, 23-011E2

			Does NOT support:
				DLV11-F, RX02 as bootable devices


		TU58 ROM:

			Part number 23-126F3

			Inserted into socket XE40.  Other ROM must be
			Rev A.	Allows use of the TU58 DECtape II as
			a bootable device.


	(2)	The MXV11-B2 Bootstrap ROMs can be used with the MXV11-BF
		multifunction module as well as the MRV11-D ROM module.
		It will not work with the MXV11-A module.



	(3)	The RC25 adapter board must be configured at the the DEC
		standard base address for the first MSCP controller
		(772150).  Other MSCP controllers may also reside but
		may not be booted.

================================================================================
Note 16.0                  KXT11-CA Development Tools                 No replies
JAWS::KAISER                                        388 lines  25-MAR-1985 09:21
--------------------------------------------------------------------------------
     +---------------+					  +-----------------+
     | d i g i t a l |					  |  uNOTE # 016    |
     +---------------+					  +-----------------+


     +----------------------------------------------------+-----------------+
     | Title:  KXT11-CA Software Development Tools	  | Date: 16-OCT-84 |
     +----------------------------------------------------+-----------------+
     | Originator: Scott Tincher			  | Page 1 of 7	    |
     +----------------------------------------------------+-----------------+


     The KXT11-CA is a single board computer (SBC) which executes the PDP-11
     instruction set.  It may be utilized as a stand-alone SBC or interfaced
     to	 the  Q-bus  as	 a  peripheral	processor  or  as an intelligent I/O
     processor	 (IOP).	 This  article	will  describe	the  software  tools
     available to develop applications in either the stand-alone mode or the
     IOP mode.

     The KXT11-CA features:

	     o	T11  Microprocessor  which  implements the PDP-11
		instruction set

	     o	32K bytes of on-board static RAM

	     o	Two  28-pin  sockets  for  up  to  16K	bytes  of
		additional RAM or 32K bytes of ROM

	     o	Three serial line units:

		 o  One asynchronous DL compatible line (RS232)
		 o  One	 synch/asynch  line  with  modem  control
		    (RS449)
		 o  One	 synch/asynch  with  data and timing only
		    (RS449)

	     o	20 programmable parallel I/O lines

	     o	Three 16-bit programmable interval timers

	     o	2-channel DMA controller

	     o	Q-bus interface

	     o	Four diagnostic LEDs

     The  Q-bus	 interface  of	the KXT11-CA allows up to 14 KXT11-CAs to be
     added  to	a  traditional Q-bus system.  As a slave device the KXT11-CA
     offloads the arbiter CPU's processing activities by providing real-time
     I/O data buffering, preprocessing, and high speed communications.

     The  KXT11-CA  is	especially  suited  for	 applications  with critical
     interrupt latency requirements or applications that must service a high
     frequency	of  interrupts.	   The	KXT11-CA  may  also  be	 used  as  a
     computational  engine in applications where it is possible to partition
     the application to run in parallel.


								      Page 2

     The   software   development  environment	for  systems  which  utilize
     KXT11-CAs	is  slightly  different	 from  that of the traditional Q-bus
     system.	The  system programmer must develop application programs for
     each  KXT11-CA in	the system in addition to the application code which
     runs  on  the  arbiter  CPU.   Different software application tools are
     available	for  the  arbiter and "onboard" environments.  (When used in
     stand-alone mode only the onboard environment need be considered.)


     THE ARBITER ENVIRONMENT

     The  arbiter  system  may	run  under  any	 of  the following operating
     systems:

	     o	MicroPower/Pascal

	     o	RT-11

	     o	RSX-11M

	     o	RSX-11M-PLUS

     Each  of  these  operating	 systems  offers  a  device  handler for the
     two-port  RAM  of	the  KXT11-CA  as  well	 as  a	utility	 for loading
     application   programs   across   the  Q-bus  into	 the  KXT11-CA.	   A
     MicroPower/Pascal	application  may  be  coded  in Pascal and MACRO-11.
     RT-11 and RSX-11 applications will be coded in MACRO-11 or a high level
     language,	such  as  FORTRAN,  which  is  capable of issuing programmed
     requests (RT-11) or QIO directives (RSX-11).


     USING A MICROPOWER/PASCAL ARBITER SYSTEM

     If	 the  arbiter  system  controlling  the	 application is running in a
     MicroPower/Pascal	environment  there  are	 KXT11-CA specific functions
     available to aid in program development.  The first component is the KX
     device  handler.	 This handler provides the arbiter-side interface to
     the  two-port  RAM	 of  the KXT11-CA.  The KX handler supports up to 14
     KXT11-CAs	on the Q-bus.  Two functions are supplied which simplify the
     interface	between	 the  application program and the KX handler.  These
     functions are:

	     o	KX_write_data:	  Transfer  data  from an arbiter
		buffer	 to  a	KXT11-CA  process  and	return	a
		completion-status value.

	     o	KX_read_data:	 Transfer  data	 from  a KXT11-CA
		process	  to  an  arbiter  buffer  and	return	a
		completion-status value.

     MicroPower/Pascal	 also	provides   a   function	 which	transfers  a
     MicroPower/Pascal	.MIM  file  from  the  arbiter	to a KXT11-CA.	This
     function,	KXT_LOAD, reads a .MIM file from the arbiter and initiates a
     DMA  transfer using the DTC of the KXT11-CA to transfer the file to the
     KXT11-CA's	 local	memory.	 This procedure may be called at any time by
     the  arbiter's  application program - not necessarily at system startup
     time.


								      Page 3

     MicroPower/Pascal	also  supplies the symbolic debugger PASDBG.  PASDBG
     supplies the following features:

	     o	A  set	of  debugger commands and qualifiers that
		allow for control of an executing program.

	     o	Access	to  the	 symbol	 table	generated  by the
		Pascal	 compiler,   providing	symbolic  (Pascal
		language) referencing and variable access.

	     o	Access	 to   process	control	  variables   and
		structures.

	     o	Control	 of  an application system not configured
		for terminal I/O.

	     o	A  method  for	user  control  after an execution
		error.

	     o	A method for loading a program on the application
		system	 while	 PASDBG	 is  running  on  a  host
		computer.



     USING AN RT-11 OR RSX-11 ARBITER SYSTEM

     If the arbiter system controlling the application is running in a RT-11
     or	 RSX-11	 environment there are tool kits available to aid in program
     development.   They are the KXT11-C/RT-11 Peripheral Processor Tool Kit
     (QJV51) and the KXT11-C/RSX-11 Peripheral Processor Tool Kit (QJV52).

     There  are	 two  major components in each of these tool kits.  They are
     the KX device handler and the KUI utility program.

     The  KX  device handler manipulates the two-port RAM of the KXT11-CA so
     that  it  appears	to  be a standard Q-bus I/O device.  The KUI utility
     program  allows  programs to be loaded into a peripheral processor from
     the arbiter, performs debugging operations, starts execution of KXT11-C
     programs, and initiates KXT11-CA selftests.


     The  KX  handler  supplied	 with the RT-11 tool kit supports up to four
     KXT11-CAs	where each KXT11-CA appears as two logical units.  More than
     four  KXT11-CAs  may  be supported by editing, renaming, and rebuilding
     the KX handler.

     The  following  RT-11  programmed	requests  are  supported  by  the KX
     handler:

	     o	.OPEN	-  associates  a  user-specified  channel
		number	 with	a  logical  unit  number  of  the
		KXT11-CA.

	     o	.CLOSE	-  frees  a previously opened channel for
		use with another device or file.


								      Page 4

	     o	.READ	-   transfers	data  from  a  peripheral
		processor  to an arbiter buffer.  (.READ, .READW,
		.READC)

	     o	.WRITE - transfers data from an arbiter buffer to
		a   peripheral	 processor.    (.WRITE,	 .WRITEW,
		.WRITEC).


     The  KX  handler  supplied	 with  the RSX-11 tool kit supports up to 14
     KXT11-CAs.	 The  KX handler assigns a unit number for each data channel
     in	 each  KXT11-CA	 two-port  RAM.	 This handler supplies the following
     RSX-11 I/O requests:

	     o	IO.RVB	-  Read	 a virtual block of data from the
		device unit unit specified in the macro call.

	     o	IO.WVB	-  Write  a  virtual  block  of data to a
		physical device unit.

	     o	IO.ATT	- Attach a physical device to the control
		of the task which issued the request.

	     o	IO.DET	-  Detach  a  physical	device	from  the
		control of the task which issued the request.


     Included  in  the	RT-11 and RSX-11 tool kits is the KUI (KXT11-CA User
     Interface) utility program.  The KUI program has several commands which
     supply the following functions:

	     o	@  - Process commands from the specified indirect
		command file.

	     o	CLOSE  -  Close	 the  file  specified  in the LOG
		command.

	     o	EXECUTE	 -  Start  a  program  on  the	specified
		KXT11-CA.

	     o	EXIT  -	 Exit  the  KUI utility and return to the
		operating system.

	     o	LOAD  -	 Load  a  program from the arbiter's mass
		storage	 to  arbiter  memory.  Then perform a DMA
		operation  to transfer the image to the specified
		peripheral  processor's	 memory.  KUI under RT-11
		supports  the  transfer	 of  .SAV, .LDA, and .MIM
		files.	KUI under RSX-11 supports the transfer of
		.TSK and .MIM files.

	     o	LOG  -	Record	all commands, status information,
		and  messages during this terminal session in the
		specified file.	 The CLOSE command terminates the
		logging session.


								      Page 5

	     o	ODT  -	Executes  the octal debugging tool (ODT).
		This  tool  allows  the arbiter system to examine
		and  modify  the contents of registers and memory
		local  to  a  KXT11-CA.	  ODT may also be used to
		start or halt a program.

	     o	REINIT	-  Reinitialize	 the specified peripheral
		processor and reboot it's application.

	     o	RESUME	-  Causes  a  SUSPENDed	 command  file to
		continue execution.

	     o	SELFTEST   -   Causes  one  or	more  of  several
		diagnostic programs to execute.

	     o	SET  -	Specifies  a  peripheral processor as the
		target for subsequent commands.

	     o	SHOW  -	 Displays  information about the state of
		the peripheral processor.

	     o	SUSPEND	 -  Used  in  an indirect command file to
		halt  execution	 of the file.  The RESUME command
		can return control to the command file.

	     o	TRAP  -	 performs a trap emulation so that a trap
		handling routine can be tested.



     THE ONBOARD PROGRAMMING ENVIRONMENT

     The KXT11-CA may be programmed in either MACRO-11 or MicroPower/Pascal.
     MicroPower/Pascal	provides  the ability to program the onboard devices
     in	 a  high-level	language,  Pascal.   In particular MicroPower/Pascal
     provides the following device handlers:

	     o	DD:    This handler supports the TU58 tape drive.
		It allows the TU58 to be interfaced to any of the
		asynchronous I/O channels.

	     o	KK:    This  handler manipulates the two-port RAM
		from  the  KXT11-CA  side  in the KX/KK protocol.
		This  protocol	allows	the  KK	 handler  to pass
		variable length messages to the arbiter system by
		emulating  a traditional Q-bus slave device.  Two
		functions   are	  supplied   which  simplify  the
		interface  between  the	 user's	 application code
		and the KK handler.  These functions are:

		 o  KK_read_data:  transfer data from the arbiter
		    to	 a   KXT11-CA	buffer	 and   return	a
		    completion-status value.

		 o  KK_write_data:  transfer data from a KXT11-CA
		    buffer   to	  the	arbiter	  and	return	a
		    completion-status value.


								      Page 6

	     o	QD:    This  handler supports the two-channel DMA
		transfer   controller  (DTC).	 The  QD  handler
		enables	 the  DTC  to  move  data  from source to
		destination  without  the  aid	of  the CPU.  One
		location, source or destination, must be local to
		the KXT11-CA.  The QD handler may be used for the
		following functions:

		 o  Transfer data to and from Q-bus memory.

		 o  Transfer data to and from local memory.

		 o  Search for data.

		 o  Transfer to and from local I/O devices.

		 o  Access the Q-bus I/O page.

		 o  Assure access to a DMA Channel.

	     o	XL:   Supports asynchronous communications on the
		three  serial  ports  of the KXT11-CA.	The first
		port is a standard DL device.  The second port is
		channel	 A  of	the  multiprotocol  chip.    This
		channel	 is  supported	with full modem controls.
		The  third port is channel B of the multiprotocol
		chip.	 This  channel	is supported as though it
		were a standard DL device.    All  three channels
		may be operated simultaneously.

	     o	XS:   Supports synchronous operation of channel A
		of  the multiprotocol chip.  The handler provides
		the    following    bit-oriented    communication
		procedures:

		 o  Synchronization  (Flag detection)

		 o  Transparency  (Bit stuffing)

		 o  Invalid frame detection

		 o  Frame abortion detection

		 o  Frame	 check	     sequence	    (FCS)
		    checking/calculation

	     The  handler can be used by user-written software as
	     a	component  in  performing  bit-oriented protocols
	     such as X.25, HDLC, SDLC, and others.

	     o	YK:  Supports the parallel I/O port and the three
		counter-timers.	     The   handler  provides  the
		functions  of  read,  write, pattern recognition,
		DMA   read,   DMA   write,   counter-timer   set,
		counter-timer	read,  and  counter-timer  clear.
		Typical parallel port operations are:


								      Page 7
		 o  Transferring  a  series  of	 bytes	or  words
		    through a port with handshake protocol.

		 o  Setting or reading the bits of external state
		    lines.

		 o  Generating a time base to software.

		 o  Generating a waveform for external output.

		 o  Counting pulses from an external input.

     These  MicroPower/Pascal  device  handlers	 do  not  support all of the
     functions	of the onboard devices of the KXT11-CA.	 For this reason, or
     because  of  preference, the application code for the KXT11-CA may also
     be written in MACRO-11.



     RELATED DOCUMENTS

     For  further  information	pertaining to the KXT11-CA and it's software
     development tools please reference the following materials:

     KXT11-CA Single-Board Computer User's Guide	     EK-KXTCA-UG

     KXT11-C Peripheral Processor Software User's Guide	     AA-Y615A-TK

================================================================================
Note 17.0                     LSI-11/23 ECO History                      1 reply
JAWS::KAISER                                        365 lines  25-MAR-1985 09:22
--------------------------------------------------------------------------------
      +---------------+					   +-----------------+
      | d i g i t a l |					   |  uNOTE # 017    |
      +---------------+					   +-----------------+


      +----------------------------------------------------+-----------------+
      | Title: LSI 11/23 ECO History			   | Date: 19-NOV-84 |
      +----------------------------------------------------+-----------------+
      | Originator: Bob Hessinger			   | Page 1 of 8     |
      +----------------------------------------------------+-----------------+





      This micronote documents the  ECO	 and  etch  revision  history  of  the
      KDF11-A  (LSI  11/23)  module.  A quick verify has been included so that
      the status of a module may be determined by a visual check.


      For the M8186, the revision  identifier  is  a  two  field  alphanumeric
      designation stamped on the reverse side of the module handle.  The first
      field indicates the etch	revision.   The	 second	 field	indicates  the
      modifications to this etch.


      Hardware revision notation :

				    A 0
	      Identifies etch level	Identifies modifications


      The M8186 began as hardware revision "A0", as  shown  above.   That  is,
      etch  revision  "A"  with	 no  modifications  or	rework.	 As ECO's were
      released calling for rework, the hardware revision level was updated  to
      "A1",  then  "A2",  etc.	Periodically new etch revisions were released,
      incorporating previous modifications.   When  these  occurred  the  etch
      revision	field  was updated from "A" to "C", and later from "C" to "D".
      For the M8186, no etch revision "B" was released.

									Page 2


      The hardware revision history of the M8186 is shown below:

			    Release	 A0
					 |
			    Rework	 A1
			    ECO #1	 |
					 |
			    Rework	 A2
			    ECO #2	 |
					 |
      NOTE: All modules	    Rework	 A3
      shipped are at	    ECO #3	 |
      rev A3 or greater			 |
					 |
      NOTE : New etch	    Relayout	 +---- C0
      rev C created.  No    ECO #4	 |     |
      rev B boards were			 |     |
      built				 |     |
			    Rework	 A4    C0  NOTE: Rev C etch incorporates
			    ECO #5	 |     |	 changes for ECO #5
					 |     |
			    Rework	 A5    C1
			    ECO #6	 |     |
					 |     |
			    Rework	 A6    C2
			    ECO #7	 |     |
					 |     |
			    Rework	 A6    C2  NOTE: This was a documen-
			    ECO #8	 |     |	 tation change only
					 |     |
			    Rework	 A7    C3
			    ECO #9	 |     |
					 |     |
			    Rework and	 A8    C4 --- D0
			    Relayout	 |     |      |
			    ECO #10	 |     |      |
					 |     |      |
			    Rework	 A8    C4     D0  NOTE: This was a
			    ECO #11				documentation
								change only

									Page 3


      Jumper Functions on Etch Revision "A", "C" and "D" Modules

      +----------+------------------------------------------------------------+
      |	 Jumper	 |   Function	 |	   Description		 |  Shipped   |
      +----------+---------------+-------------------------------+------------+
      |	   W1	 |  Master Clock |  In = Enabled, do not remove	 |    In      |
      +----------+---------------+-------------------------------+------------+
      |	   W2,W3 |  DEC Reserved |  Factory configured, do not	 |    W2=Out  |
      |		 |		 |  change (see note 1)		 |    W3=In   |
      +----------+---------------+-------------------------------+------------+
      |	   W4	 |  BEVENT	 |  Out = Enabled		 |    In      |
      +----------+---------------+-------------------------------+------------+
      |	   W5,W6 | Power-up Mode |  Mode	       W5   W6	 |    Mode 1  |
      |		 |		 |  0 - PC=24,PS=26    Out  Out	 |    W5=In   |
      |		 |		 |  1 - Console ODT    In   Out	 |    W6=Out  |
      |		 |		 |  2 - Bootstrap      Out  In	 |	      |
      |		 |		 |  3 - Reserved       In   In	 |	      |
      +----------+---------------+-------------------------------+------------+
      |	   W7	 |  Halt/Trap	 |  In = Trap to 10 on Halt	 |    Out     |
      |		 |  Option	 |  Out = Enter Console ODT	 |	      |
      |		 |		 |	  on Halt		 |	      |
      +----------+---------------+-------------------------------+------------+
      |	   W8	 |  Bootstrap	 |  In = Boot to 17773000	 |    In      |
      |		 |  Address	 |  Out = Bootstrap address	 |	      |
      |		 |		 |  specified by jumpers W9-W15	 |	      |
      +----------+---------------+-------------------------------+------------+
      |	 W9-W15	 | User Bootstrap|  W9-W15 correspond to address |    In      |
      |		 |  Address	 |  bits 9-15 respectively.	 |	      |
      |		 |		 |  In = logic 1, Out = logic 0	 |	      |
      +----------+---------------+-------------------------------+------------+
      |	 W16,W17 |  DEC Reserved |  Factory configured, do not	 |    In      |
      |		 |		 |  change			 |	      |
      +----------+---------------+-------------------------------+------------+
      |		   Etch A only						      |
      +----------+---------------+-------------------------------+------------+
      |	  W18	 |  DEC Reserved |  Factory configured, do not	 |    In      |
      |		 |		 |  change			 |	      |
      +----------+---------------+-------------------------------+------------+
      |	  W19	 |Wake-up Circuit|  Out = enabled		 |     In     |
      |		 |		 |  This jumper is a red wire	 |	      |
      |		 |		 |  across diode D1		 |	      |
      +----------+---------------+-------------------------------+------------+
      |		   Etch C and D only					      |
      +----------+---------------+-------------------------------+------------+
      |	  W18	 |Wake-up Circuit|  Out = enabled		 |     In     |
      |		 |		 |  This jumper is a red wire	 |	      |
      |		 |		 |  across diode D1		 |	      |
      +----------+---------------+-------------------------------+------------+

      note 1 : W3 on etch A modules consists of a jumper from E2 pin 5 to
	       E2 pin 15.

									Page 4


		   +-------------------------------------------------------+
		   |							   |
		   |							   |
		   |							   |
		   |		     W18 ---				   |
		   |							   |
		   |							   |
		   |		      D1 ---				   |
		   |		      (W19 - see text)			   |
		   |							   |
		   |							   |
		   |							   |
		   |							   |
		   |				   W17 ---		   |
		   | +----+ +----+ +----+ +----+			   |
		   | |	  | |	 | |	| |    |			   |
		   | |	  | |	 | |	| |    |	    W1 |	   |
		   | |	  | |	 | |	| |    |	       |	   |
		   | |	  | |	 | |	| |    |			   |
		   | |	  | |	 | |	| |    | W16 |			   |
		   | |	  | |	 | |	| |    |     |			   |
		   | +----+ +----+ +----+ +----+			   |
		   |							   |
		   |		    W15	 ---		      W2 ---	   |
		   |		    W14	 ---				   |
		   |		    W13	 ---				   |
		   |		    W12	 ---				   |
		   |		    W11	 ---				   |
		   |		    W10	 ---				   |
		   |		    W9	 ---				   |
		   |		    W8	 ---				   |
		   |		    W6	 ---				   |
		   |		    W7	 ---				   |
		   |		    W6	 ---				   |
		   |		    W5	 ---	   W4 ---		   |
		   |							   |
		   |							   |
		   |							   |
		   |							   |
		   |							   |
		   |							   |
		   |				+-+			   |
		   ++			    +---+ |			  ++
		    |			    |	  |			  |
		    +-----------------------+	  +-----------------------+

				 KDF11-A REV A Jumper Layout

									Page 5


		   +-------------------------------------------------------+
		   |							   |
		   |							   |
		   |							   |
		   |							   |
		   |							   |
		   |							   |
		   |							   |
		   |		      D1 ---				   |
		   |		      (W18 - see text)			   |
		   |							   |
		   |							   |
		   |							   |
		   |							   |
		   | +----+ +----+ +----+ +----+			   |
		   | |	  | |	 | |	| |    |			   |
		   | |	  | |	 | |	| |    |		W1 ---	   |
		   | |	  | |	 | |	| |    |			   |
		   | |	  | |	 | |	| |    |			   |
		   | |	  | |	 | |	| |    |			   |
		   | |	  | |	 | |	| |    |			   |
		   | +----+ +----+ +----+ +----+			   |
		   |							   |
		   |		    W15	 ---				   |
		   |		    W14	 ---				   |
		   |		    W13	 ---				   |
		   |		    W12	 ---				   |
		   |		    W11	 ---				   |
		   |		    W10	 ---				   |
		   |		    W9	 ---				   |
		   |		    W8	 ---				   |
		   |		    W6	 ---				   |
		   |		    W7	 ---	 W4 ---		 W3 ---	   |
		   |		    W6	 ---				   |
		   |		    W5	 ---			 W2 ---	   |
		   |							   |
		   |							   |
		   |							   |
		   |							   |
		   |	 W16 ---					   |
		   |	 W17 ---					   |
		   |							   |
		   |				+-+			   |
		   ++			    +---+ |			  ++
		    |			    |	  |			  |
		    +-----------------------+	  +-----------------------+

				 KDF11-A REV C Jumper Layout

									Page 6


		   +-------------------------------------------------------+
		   |							   |
		   |							   |
		   |							   |
		   |							   |
		   |							   |
		   |							   |
		   |							   |
		   |							   |
		   |		      W18 |				   |
		   |			  |				   |
		   |							   |
		   |							   |
		   |							   |
		   |							   |
		   | +----+ +----+ +----+ +----+			   |
		   | |	  | |	 | |	| |    |			   |
		   | |	  | |	 | |	| |    |		W1 ---	   |
		   | |	  | |	 | |	| |    |			   |
		   | |	  | |	 | |	| |    |			   |
		   | |	  | |	 | |	| |    |			   |
		   | |	  | |	 | |	| |    |			   |
		   | +----+ +----+ +----+ +----+			   |
		   |							   |
		   |		    W15	 ---				   |
		   |		    W14	 ---				   |
		   |		    W13	 ---				   |
		   |		    W12	 ---				   |
		   |		    W11	 ---				   |
		   |		    W10	 ---				   |
		   |		    W9	 ---				   |
		   |		    W8	 ---				   |
		   |		    W6	 ---				   |
		   |		    W7	 ---	 W4 ---		 W3 ---	   |
		   |		    W6	 ---				   |
		   |		    W5	 ---			 W2 ---	   |
		   |							   |
		   |							   |
		   |							   |
		   |							   |
		   |							   |
		   |	 W16 ---					   |
		   |	 W17 ---					   |
		   |				+-+			   |
		   ++			    +---+ |			  ++
		    |			    |	  |			  |
		    +-----------------------+	  +-----------------------+

				 KDF11-A REV D Jumper Layout

									Page 7


      The following table details the ECO's issued since the  M8186  began  to
      ship  to	the field.  These ECO's are coded "M8186-ML0XX", where "XX" is
      the ECO number shown below :

      ECO #	Problem					   Quick Verify
      --------------------------------------------------------------------------
       04     Too many wires and etch cuts, new etch	   Module handle will be
	      needed.  Note that the jumper locations	   stamped "Cn" where
	      change for etch Revision C.		   "n" indicates
	      Note also that etch A boards bring only	   modifications
	      18 bits of addressing from the MMU to the
	      Q-BUS, while etch C boards bring all 22
	      bits of addressing from the MMU to the
	      Q-BUS.

       05     I/O page addressing scheme differs from	   Check for etch cut
	      LSI-11/2 processor.			   to pins 16 and 18
							   (rev A boards only)

       06     The internal wake-up circuit defeats the	   Red jumper wire is
	      power sequencing provided by standard	   installed in parallel
	      DEC power supplies.			   with D1.

       07     CTL/DAT hybrid (57-00000-00) and MMU IC	   CTL/DAT should be
	      (21-15542-00) were not compatible with	   57-00000-01 or higher
	      KEF11-AA floating point option.  The FP	   and MMU should be
	      registers in the MMU were inaccessible,	   21-15542-01 or higher
	      and the CTL/DAT data path caused		   for floating point
	      intermittent errors in floating point	   compatibility.
	      instructions.				   Coordinate with EC0
							   M8186-ML009

       08     MMU (21-15542-01) was included as part of	   Some modules may or
	      the M8186 module.	 This documentation	   not have MMUs,
	      change removes the MMU and makes it an	   depending on the
	      option which is ordered separately.	   options ordered.

									Page 8


      ECO #	Problem					   Quick Verify
      -------------------------------------------------------------------------
       09     1) No jumper table in print set (doc only)   1) Table added
	      2) Crystal oscillator may short to adjacent  2) Manufacturing
		 components				      includes nylon
							      spacer
	      3) Possibility of worst case MMU timing	   3) Module will have
		 violations.  Change configuration	      W2 removed and W3
		 of W2 and W3 to adjust timing.	 This	      in.  On rev A
		 ECO must be installed :		      modules W3 is a
		 A) When ECO m8186-ML007 is installed	      wire from E2 pin
		 B) When the KEF11 or FPF11 is installed      5 to E2 pin 15.
		 C) When one of the F-11 chips is replaced
		 D) Whenever unexplained system crashes
		    occur

       10     1) Heavily loaded systems lock up during	   1) Rev A and Rev C
		 worst case timing between DMA and	      modules will have
		 interrupt arbitration.	 Symptoms	      wires on E2 pins
		 usually occur with DMA options not	      2 and 4.	Rework
		 manufactured by DEC.			      included in Rev D.
	      2) Too many wires and etch cuts, new etch	   2) Module handle will
		 needed.  Note W18 now uses jumper posts.     be stamped "Dn"
							      where n indicates
							      modifications.

       11     Documentation updated.			   Documentation only.
================================================================================
Note 17.1                     LSI-11/23 ECO History                       1 of 1
BRS01::BRUSCHE                                        5 lines   9-MAY-1985 02:24
--------------------------------------------------------------------------------
Please note that in all tree jumper layout drawings there is a 
redundant "W6". The top ones are those that should be disregarded.

	Johan.


================================================================================
Note 18.0                   KXT11-CA DMA Programming                  No replies
JAWS::KAISER                                       1117 lines  25-MAR-1985 09:22
--------------------------------------------------------------------------------
      +---------------+					   +-----------------+
      | d i g i t a l |					   |  uNOTE # 018    |
      +---------------+					   +-----------------+


      +----------------------------------------------------+-----------------+
      | Title:	Programming the KXT11-CA DMA controller	   | Date: 28-DEC-84 |
      +----------------------------------------------------+-----------------+
      | Originator: Scott Tincher			   | Page 1 of 22    |
      +----------------------------------------------------+-----------------+


      The  KXT11-CA  intelligent   I/O	 processor   contains	several	  user
      programmable devices.  One of these devices is a DMA transfer controller
      (DTC).  This article will describe the features of the DTC  and  provide
      some  programming	 examples.   This  article  is	intended  for  use  by
      individuals interested in programming the DTC using  MACRO-11.   DIGITAL
      supplies	 a   DTC   device   driver   for   those   programmers	 using
      MicroPower/Pascal.  A working knowledge of MACRO-11 and of the  KXT11-CA
      is assumed.


      FEATURES/CAPABILITIES

      The DTC is addressable by	 the  local  T-11  microprocessor  as  an  I/O
      device.	It  is	capable of performing DMA transfers between any of the
      following addresses:

		   1)  A 16-bit local address to a 16-bit local address

		   2)  A 16-bit local address to a 22-bit global address

		   3)  A 22-bit global address to a 16-bit local address

		   4)  A 22-bit global address to a 22-bit global address

		   5)  To/From channel A of the multiprotocol SLU

		   6)  To/From the PIO chip

      Word, high byte, and low byte transfers  are  supported  locally.	  Only
      word transfers are supported across the Q-bus.

      The operations of the DTC are controlled by several internal  registers.
      It  was  designed with the capabilty of loading these registers directly
      from memory thereby minimizing  the  amount  of  processor  intervention
      necessary	 to  perform  a DMA transaction.  The area of memory where the
      parameters for the DTC are stored is referred to	as  the	 chain	table.
      The  local  microprocessor need only load the address of the chain table
      into the DTC and give a "start" command to initiate a DMA transfer.

      DMA transactions may be initiated locally by the T11 or by  the  arbiter
      CPU.   If the transfer is initiated by the arbiter the command words and
      transfer parameters are placed in the command registers of the  two-port
      RAM  file.   The	local CPU will then initiate the DMA transaction using
      the parameters supplied by the arbiter.

								Page 2


      The DTC consists of  two	identical  channels.   DMA  transfers  may  be
      interleaved  between  these  two channels or interleaved between the DTC
      and the T-11.  It is also possible to select a "hog  mode"  that	allows
      the DMA transfer to run to completion without interruption.

      The DTC supports three  types  of	 operations:   Transfer,  Search,  and
      Transfer-and-Search.  As the name implies, Transfer operations move data
      from a source to a destination.  Search  operations  read	 data  from  a
      source  and  compare  the data to the pattern register.  A mask register
      allows the user to declare "don't care" bits.   The  Transfer-and-Search
      operation	 combines  the	features of the Transfer and Search functions.
      In this type of operation data  is  transferred  between	a  source  and
      destination  until  the  data  transferred  meets	 the  match  condition
      specified in the Channel Mode register.

      The DTC is capable  of  performing  multiple  DMA	 transactions  without
      processor	  intervention.	   This	 can  be  accomplished	in  two	 ways:
      base-to-current reloading or chaining.  Base-to-current reloading allows
      the  DTC	to  reload  a portion of its registers before initiating a DMA
      transfer.	 The reload operation occurs  between  internal	 registers  so
      there  are  no  memory access related delays.  This type of operation is
      only practical in applications where data	 is  continuously  transferred
      between  the  same  addresses.   Chaining	 allows	 all of the applicable
      registers of the DTC to be reloaded from a new chain  table.   Therefore
      this is a slower but more flexible alternative.

      Upon completion of a DMA transfer the DTC may perform any combination of
      the   following	options:    Interrupt  the  local  processor,  perform
      base-to-current reloading, or perform  a	chain  reload.	 It  may  also
      choose to take no action.



      DTC REGISTERS

      Among the internal registers of the DTC are  two	chip-level  registers,
      the  Master  Mode	 register  and	the Command register.  These registers
      control both channels of the DTC.	 In addition, each channel of the  DTC
      is  controlled  by  several  channel-level  registers.   For the sake of
      completeness a brief description of these	 registers  will  be  included
      here.   For  a  detailed	description refer to the KXT11-CA Single Board
      Computer User's Guide (EK-KXTCA-UG-001).

      CHIP-LEVEL REGISTERS

      Master Mode Register

      The Master Mode register controls the chip-level interfaces.  It is used
      to:

		- Enable/disable the DTC
		- Select DTC/CPU interleaving
		- Enable/disable asynch operation
		- Enable/disable counter/timer interrupt request
		- Enable/disable interrupt save vector

								Page 3


      Command Register

      The command register is used to issue commands to the DTC channels  such
      as:  Reset, Start Chain, etc.


      CHANNEL-LEVEL REGISTERS

      (Each of the following registers is present in each channel of the DTC)


      Current Address Registers A and B (CARA, CARB)

      CARA and CARB consist of two words, the segment/tag and the offset.  The
      segment/tag is used to indicate:

		- Address bits <21:16> of the source (or destination)

		- If the source (or destination) resides on the Q-bus

		- Whether the source (or destination) address should be
		  incremented, decremented, or held constant

		- Whether wait states should be included

	   The offset is used to indicate:

		- Address bits <15:00>


      Base Address Registers A and B (BARA, BARB)

      BARA and BARB are identical to CARA and CARB.  They are used  to	reload
      CARA  and	 CARB  if  base-to-current  reloading  is selected after a DMA
      operation has terminated.


      Current Operation Count Register (COPC)

      This 16-bit register is used to specify the number of words  (or	bytes)
      to  be  transferred  during  a DMA operation.  The maximum word count is
      obtained by programming this register with a zero.


      Base Operation Count Register (BOPC)

      This register is identical to the COPC register.	It is used  to	reload
      the COPC register when base-to-current reloading is selected.


      Pattern and Mask Registers

      The  Pattern  and	 Mask	registers   are	  used	 during	  Search   and
      Transfer-and-Search  operations.	 The  contents of the Pattern register
      are compared to the read data to generate a "match" condition.  The Mask
      register is used to generate "don't care" bits.  Setting a bit to '1' in
      the Mask register specifies that the bit always matches.

								Page 4


      Status Register

      The status register is a 16-bit read-only	 register  which  returns  the
      status of the following fields:  Interrupts status, DTC status, Hardware
      interface status, and Completion status.


      Interrupt Vector and Interrupt Save Registers

      The Interrupt Vector register contains the vector that is output	during
      an  interrupt  acknowledge cycle.	 When an interrupt occurs the contents
      of the Interrupt Vector register and a part of the Status	 register  are
      stored  in  the Interrupt Save register.	This allows a new vector to be
      loaded during chaining so that a new  DMA	 operation  can	 be  performed
      before an interrupt acknowledge cycle occurs.


      Channel Mode Register

      The Channel Mode register consists of two words, channel mode  high  and
      channel mode low.	 Channel mode low is used to indicate:

		- The operation type (transfer, search,
		  transfer-and-search,bytes,words)

		- Whether CARA (or CARB) defines the source (or destination)

		- Transfer type (single, hog mode, interleaved)

		- Completion options (interrupt CPU, base-to-current reload,
		  chain reload)

	   Channel mode high is used to:

		- indicate match conditions

		- mask the hardware requests for DMA operations

		- cause the channel to request the bus for a DMA operation


      Chain Address Register

      The chain address register consists of two words,	 the  segment/tag  and
      the  offset.   This  register  is	 used to point to the reload word, the
      first word in a chain table.  The segment/tag is used to indicate:

		- Whether the reload word resides in Q-bus memory

		- Whether the reload word resides in the Q-bus I/O page

		- Address bits <21:16>

	   The offset is used to indicate:

		- Address bits <15:00>

								Page 5


      PROGRAMMING THE DTC

      Programming the DTC consists of three phases:  Chip Initialization, Data
      Transfer	(or  Search),  and  Termination.   This section will provide a
      general description of these phases.


      CHIP INITIALIZATION

      The Reset instruction is used to place the DTC  in  a  known  state.   A
      reset  will  clear  the CIE, IP, SIP and WFB bits and set the CA and NAC
      bits in the Channel Status registers.  The  Master  Mode	register  will
      also  be	cleared.   Before  a  DMA operation is initiated the local CPU
      loads the Master Mode register and the Chain  Address  register  of  the
      appropriate  channel  of	the  DTC.  The DTC fetchs any other parameters
      that are necessary from a table located in system memory referred to  as
      the  chain  table.   This	 minimizes  the	 amount	 of  CPU  intervention
      necessary to perform a DMA operation.  The  relationship	of  the	 Chain
      Address register to the chain table is shown in Figure 1.


						     System
      +---------------+			     |	     Memory	 |
      |		      |			     |			 |
      |		      |			     |-------------------|
      |	     DTC      |		 +---------->|	  Reload Word	 |
      |	 Channel 0/1  |		 |	     |-------------------|
      |		      |		 |	     |			 |
      |		      |		 |	     |	      DTC	 |
      |		      |		 |	     |	    Register	 |
      |	 +---------+  |		 |	     |	      Data	 |
      |	 |  Chain  |  |		 |	     |			 |
      |	 | Address |--|----------+	     |- - - - - - - - - -|
      |	 |   Reg.  |  |			+----| New Chain Address |
      |	 +---------+  |			|    |-------------------|
      +---------------+			|    |			 |
					|    |			 |
					|    |			 |
					|    |			 |
					|    |-------------------|
					+--->|	  Reload Word	 |
					     |-------------------|
					     |			 |
					     |	      DTC	 |
					     |	    Register	 |
					     |	      Data	 |
					     |			 |
					     |-------------------|
					     |			 |

			- Figure 1 -

								Page 6


      The first word in the chain table is the reload word.  The  reload  word
      is  used to specify which registers are to be loaded for the pending DMA
      operation.  Bits <9:0> of the reload word correspond to the registers of
      the DTC as shown in figure 2.  Bits <15:10> are not used.


				  Reload Word

	 +---------------------------------------------------------------+
	 | x | x | x | x | x | x | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
	 +---------------------------------------------------------------+
				   ^   ^   ^   ^   ^   ^   ^   ^   ^   ^
				   |   |   |   |   |   |   |   |   |   |
      Current ARA -----------------+   |   |   |   |   |   |   |   |   |
      Current ARB ---------------------+   |   |   |   |   |   |   |   |
      Current Op-Count --------------------+   |   |   |   |   |   |   |
      Base ARA --------------------------------+   |   |   |   |   |   |
      Base ARB ------------------------------------+   |   |   |   |   |
      Base Op-Count -----------------------------------+   |   |   |   |
      Pattern and Mask ------------------------------------+   |   |   |
      Interrupt Vector ----------------------------------------+   |   |
      Channel Mode ------------------------------------------------+   |
      Chain Address ---------------------------------------------------+
				 -  Figure 2 -


      Therefore if a bit in the reload word  is	 set  then  the	 corresponding
      register	is  to	be  reloaded  from  the chain table.  Since all of the
      registers are not applicable to each DMA operation the chain  table  may
      be of variable length.  ( i.e.  The pattern and mask registers would not
      be used in DMA operations that do	 not  search  the  data.)  It  is  NOT
      correct  to  select  a register in the reload word and subsequently load
      that register with a dummy argument such as  zero.   The	following  are
      examples	of  the	 relationship  between	the  reload word and the chain
      table.


	 |			   9   8   7   6   5   4   3   2   1   0 |
	 |---------------------------------------------------------------|
	 | x | x | x | x | x | x | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 1 | 0 |
	 |---------------------------------------------------------------|
	 |		      Current ARA  Segment/Tag			 |
	 |---------------------------------------------------------------|
	 |			Current ARA  Offset			 |
	 |---------------------------------------------------------------|
	 |		      Current ARB  Segment/Tag			 |
	 |---------------------------------------------------------------|
	 |			Current ARB  Offset			 |
	 |---------------------------------------------------------------|
	 |			  Current Op-Count			 |
	 |---------------------------------------------------------------|
	 |			 Channel Mode High			 |
	 |---------------------------------------------------------------|
	 |			  Channel Mode Low			 |
	 |---------------------------------------------------------------|
	 |								 |

								Page 7


	 |			   9   8   7   6   5   4   3   2   1   0 |
	 |---------------------------------------------------------------|
	 | x | x | x | x | x | x | 1 | 0 | 1 | 0 | 0 | 0 | 1 | 0 | 1 | 1 |
	 |---------------------------------------------------------------|
	 |		      Current ARA  Segment/Tag			 |
	 |---------------------------------------------------------------|
	 |			Current ARA  Offset			 |
	 |---------------------------------------------------------------|
	 |			  Current Op-Count			 |
	 |---------------------------------------------------------------|
	 |			  Pattern Register			 |
	 |---------------------------------------------------------------|
	 |			   Mask Register			 |
	 |---------------------------------------------------------------|
	 |			 Channel Mode High			 |
	 |---------------------------------------------------------------|
	 |			  Channel Mode Low			 |
	 |---------------------------------------------------------------|
	 |		     Chain Address Segment/Tag			 |
	 |---------------------------------------------------------------|
	 |			Chain Address Offset			 |
	 |---------------------------------------------------------------|
	 |								 |


      The DTC has been properly initialized once the chain table(s) have  been
      created  and the Master Mode register and Chain Address Register for the
      selected channel have been loaded.


      DATA TRANSFER

      The  DTC	may  perform  a	 DMA  operation	 once  it  has	been  properly
      initialized.   A DMA operation may be initiated in one of four ways:  by
      software request, by hardware request, by loading a set software request
      bit  in the Channel Mode register during chaining, or as the result of a
      command from the arbiter.

      Software Request:	 The local CPU may initiate a DMA operation by writing
      a	 'software request' command followed by a 'start chain' command to the
      Command register.	 The 'software	request'  command  sets	 the  software
      request  bit  in the channel's Mode register.  If either the SIP (second
      interrupt pending) bit or the NAC (no auto-reload or chain) bit  is  set
      in  the channel's status register the DMA operation will not begin.  The
      SIP  bit	will  be  cleared  when	 the  channel  receives	 an  interrupt
      acknowledge.   The  NAC  bit will be cleared when the channel receives a
      'start chain' command.  The 'start  chain'  command  initiates  the  DMA
      operation	 after	the  registers of the selected channel are loaded from
      the chain table.	The 'start chain' command is ignored if the SIP bit or
      the  CA (Chain Abort) bit are set in the channel's status register.  The
      SIP bit was described above.  The CA bit is cleared when	the  channel's
      chain address register is reloaded.

      Hardware Request:	 DMA operations may be started by applying a 'low'  on
      the channel's DREQ input.	 No details about this type of request will be
      provided since they fall beyond the scope of this note.

								Page 8


      Starting After Chaining:	If the software request bit of	the  channel's
      Mode register is loaded during chaining the channel will perform the DMA
      operation at the end of chaining.

      Arbiter Request:	The arbiter may interrupt the local CPU to  request  a
      DMA  operation.	This is accomplished by passing parameters to load the
      chain address register of channel 0 via the two-port RAM.	  The  arbiter
      loads  register  2  of  the  TPR	with  the  offset of the chain address
      register and register 3 of the TPR with the  segment/tag	of  the	 chain
      address  register.   The	DMA operation is then initiated by setting the
      DMA Load bit (bit 1) in the TPR command register	(register  0).	 Error
      conditions will be returned in TPR register 1.


      Information in the channel's Mode register determines what type  of  DMA
      operation	 will be performed.  The Channel Mode register consists of two
      words, Channel Mode High and Channel Mode Low.

      Bits <3:0> of the Channel Mode Low  register  select  the	 type  of  DMA
      operation.  These bits determine whether the data should be transferred,
      searched, or transferred-and-searched.  Bit 4 is the flip	 bit.	It  is
      used  to	determine  which set of current address registers (CARA, CARB)
      points to the source.

      Bits <6:5> determine the transfer type.  The types of DTC transfers are:
      single  transfer,	 demand dedicated with bus hold, demand dedicated with
      bus release, and channel-to-channel demand interleave.  Single  transfer
      is  used	with  devices  which  transfer data at irregular intervals.  A
      single DMA transaction will occur each time a 'software request' command
      is issued or the DREQ input is asserted.	Demand dedicated with bus hold
      is a software hog mode.  This mode allows the DMA transaction to run  to
      completion  as  long  as there is a valid op count and the DREQ input is
      asserted.	 If the DREQ input is not  asserted  no	 DMA  operations  will
      occur  but  the  channel will retain bus control.	 Demand dedicated with
      bus release is similar to demand dedicated with bus hold in that	a  DMA
      transaction  is  allowed	to  run to completion if DREQ is asserted.  If
      DREQ is not asserted the DTC must release the bus	 thus  allowing	 other
      devices	to   obtain   the   bus.    The	  operation   performed	 by  a
      channel-to-channel demand interleave request depends on the state of bit
      2 in the Master Mode register.  If MM bit 2 is clear then control may be
      passed between each channel of the DTC without the need to  release  the
      bus.   If MM bit 2 is set then the DTC must share the bus with the local
      processor.  The DTC will release the bus and then	 re-request  it	 after
      every DMA iteration.

      Bits <1:0> of the Channel Mode High register are used to	determine  the
      type of match control in Search and Transfer-and-Search operations.  The
      DTC is capable of	 generating  a	termination  condition	based  on  'No
      Match', 'Word Match', and 'Byte Match'.

      Bit <4> of the Channel Mode High register causes the channel to  request
      the  bus	and  perform  transfers	 when it is set by a 'Software Request
      Command' or a chain reload.

								Page 9


      TERMINATION OPTIONS

      Bits <15:7> of the Channel Mode Low  register  control  the  termination
      options.	A DTC operation may be terminated in a number of ways.	If the
      Current Operation Count Register goes to zero then a Terminal Count (TC)
      termination  is generated.  External logic may assert the End Of Process
      (EOP) input of the DTC to generate an EOP termination at any  time.   In
      addition,	 during	 a  Search  or	Transfer-and-Search  operation a match
      condition may occur which generates a MC termination.  Bits <15:7> allow
      the  DTC	to  perform  a	chain  reload, a base-to-current reload, or to
      interrupt the local processor if a TC, EOP, or MC termination  condition
      is  encountered.	 If  bits <15:7> are cleared then no special action is
      initiated when a TC, EOP, or MC condition is encountered.


      EXAMPLES

      The following example programs were developed  on	 a  PDP-11/23+	system
      with 256KB of memory using the RT-11 (version 5.1) operating system with
      the KXT11-C  Peripheral  Processor  Software  Toolkit.   These  examples
      assume  the  programmer  is  familiar  with  MACRO-11  and  the  KXT11-C
      Peripheral Processor Toolkit.

							       Page 10


	.TITLE EXAM1.MAC

	; This program transfers data from local KXT11-C addresses to other
	; local KXT11-C addresses.  This program should be compiled and linked
	; on the development system and then downloaded into the KXT11-C using
	; the KXT11-C Software Toolkit.	 Once the program has been compiled
	; and linked use the following KUI commands to execute it and verify
	; its successfullness.
	;
	; .KUI
	; KUI>SET n		! Where n is the appropriate KXT11-C
	; KUI>LOAD EXAM1
	; KUI>ODT		! Use KUI ODT to verify that the destination
	;      .		  addresses are cleared
	;      .
	; ODT>^C
	; KUI>EXECUTE		! Execute EXAM1
	; KUI>ODT		! Use KUI ODT to verify that the transfer was
	;      .		  successful
	;      .
	; ODT>^C
	; KUI>EXIT
	;

	; SET UP REGISTER ASSIGNMENTS

	MMREG	=	174470	; MASTER MODE REGISTER
	CMDREG	=	174454	; COMMAND REGISTER
	CASTF0	=	174446	; CHANNEL 0 CHAIN ADDRESS SEGMENT/TAG FIELD
	CAOF0	=	174442	; CHANNEL 0 CHAIN ADDRESS OFFSET FIELD


	START:	MOVB #130,MMREG	   ; LOAD MASTER MODE REG TO DISABLE DTC

		CLRB CMDREG	   ; RESET THE DTC

		MOV  #0,CASTF0	   ; LOAD THE CHAIN ADDRESS REGISTER SEG/TAG
		MOV  #RELOAD,CAOF0 ; LOAD THE CHAIN ADDRESS REGISTER OFFSET

		MOVB #131,MMREG	   ; LOAD MASTER MODE REG TO ENABLE DTC

		MOVB #102,CMDREG   ; SET SOFTWARE REQUEST CHANNEL 0

		MOVB #240,CMDREG   ; START CHAIN CHANNEL 0

		BR	.	   ; STAY HERE WHILE THE USER VERIFIES
				   ; THAT THE PROGRAM WAS SUCCESSFUL

	; CHAIN LOAD REGION

	RELOAD: .WORD 001602	   ; RELOAD WORD <Select CARA,CARB,COPC,CM>

		.WORD	000000	   ; CURRENT ADDRESS REGISTER A SEG/TAG
		.WORD	SOURCE	   ; CURRENT ADDRESS REGISTER A OFFSET
				   ; <This local address is the source>

							       Page 11



		.WORD	000000	 ; CURRENT ADDRESS REGISTER B SEG/TAG
		.WORD	DESTNT	 ; CURRENT ADDRESS REGISTER B OFFSET
				 ; <This local address is the destination>

		.WORD	000013.	 ; CURRENT OPERATION COUNT <Transfer 13 words>

		.WORD	000000	 ; CHANNEL MODE REGISTER HIGH
		.WORD	000040	 ; CHANNEL MODE REGISTER LOW
				 ; <No match conditions, do nothing upon
				   completion,
				 ; transfer type = Demand Dedicated w/Bus
				    Hold,
				 ;  CARA = source, word transfers>

	SOURCE: .WORD	1,2,3,4,5,6,7,6,5,4,3,2,1

	DESTNT: .BLKW	13.

		.END START

							       Page 12


	.TITLE EXAM2.MAC

	; This program transfers data from local KXT11-C addresses to
	; global Q-bus addresses. This program should be compiled and linked
	; on the development system and then downloaded into the KXT11-C using
	; the KXT11-C Software Toolkit.	 Once the program has been compiled
	; and linked use the following commands to execute it and verify its
	; successfullness.
	;
	; <HALT the development machine so that locations may be examined
	;  with Q-bus ODT>
	; @600000/xxxxxx  ! Examine the destination locations and clear
	;	   .	      them if necessary
	;	   .
	; @600030/xxxxxx
	; @P		  ! Use the 'P' command to return to the system prompt
	;
	; .KUI
	; KUI>SET n	  ! Where n is the appropriate KXT11-C
	; KUI>LOAD EXAM2
	; KUI>EXECUTE
	; KUI>EXIT
	;
	; <HALT the development machine so that locations may be examined
	;  with Q-bus ODT>
	; @600000/xxxxxx  ! Examine the destination locations to verify the
	;	   .	    success of the transfer
	;	   .
	; @600030/xxxxxx
	;
	; SET UP REGISTER ASSIGNMENTS

	MMREG	=	174470	   ; MASTER MODE REGISTER
	CMDREG	=	174454	   ; COMMAND REGISTER
	CASTF0	=	174446	   ; CHANNEL 0 CHAIN ADDRESS SEGMENT/TAG FIELD
	CAOF0	=	174442	   ; CHANNEL 0 CHAIN ADDRESS OFFSET FIELD


	START:	MOVB  #130,MMREG   ; LOAD MASTER MODE REG TO DISABLE DTC

		CLRB  CMDREG	   ; RESET THE DTC

		MOV  #0,CASTF0	   ; LOAD THE CHAIN ADDRESS REGISTER SEG/TAG
		MOV  #RELOAD,CAOF0 ; LOAD THE CHAIN ADDRESS REGISTER OFFSET

		MOVB #131,MMREG	   ; LOAD MASTER MODE REG TO ENABLE DTC

		MOVB #102,CMDREG   ; SET SOFTWARE REQUEST CHANNEL 0

		MOVB #240,CMDREG   ; START CHAIN CHANNEL 0

		BR   .		   ; STAY HERE WHILE THE USER VERIFIES THAT
				   ; THE PROGRAM WAS SUCCESSFUL

							       Page 13


	; CHAIN LOAD REGION

      RELOAD: .WORD 001602 ; RELOAD WORD <Select CARA,CARB,COPC,CM>

	      .WORD 000000 ; CURRENT ADDRESS REGISTER A SEG/TAG
	      .WORD SOURCE ; CURRENT ADDRESS REGISTER A OFFSET
			   ; <This local address is the source>

	      .WORD 101400 ; CURRENT ADDRESS REGISTER B SEG/TAG
	      .WORD 00000  ; CURRENT ADDRESS REGISTER B OFFSET
			   ; <This global Q-bus address is the destination>
			   ; <This corresponds to address 600000 on the Q-bus>
			   ; <The DTC uses physical addresses only>

	     .WORD 000013. ; CURRENT OPERATION COUNT <Transfer 13 words>

	     .WORD 000000  ; CHANNEL MODE REGISTER HIGH
	     .WORD 000040  ; CHANNEL MODE REGISTER LOW
			   ; <No match conditions, do nothing upon completion,
			   ;  transfer type = Demand Dedicated w/Bus Hold,
			   ;  CARA = source, word transfers>

     SOURCE: .WORD   1,2,3,4,5,6,7,6,5,4,3,2,1

	     .END START

							       Page 14



	.TITLE EXAM3.MAC

	; This program transfers data from global Q-bus addresses to local
	; KXT11-C addresses.  This program should be compiled and linked on
	; the development system and then downloaded into the KXT11-C using
	; the KXT11-C Software Toolkit.	 Once the program has been compiled
	; and linked use the following commands to execute it and verify its
	; successfullness.
	;
	; <Use Q-bus ODT to deposit values in locations 600000(8)-->600030(8).
	;  These values will be the source for this operation>
	;
	; @600000/000001  ! Deposit source values
	;	   .
	;	   .
	; @600030/000001
	; @P		  ! Use the 'P' command to return to the system prompt
	;
	; .KUI
	; KUI>SET n	  ! Where n is the appropriate KXT11-C
	; KUI>LOAD EXAM3
	; KUI>EXECUTE
	; KUI>ODT	  ! Use KUI ODT to examine the destination locations
	;		  to verify the transfer was successful
	; ODT> .
	;      .
	;      .
	; ODT>^C
	; KUI>EXIT
	;
	; SET UP REGISTER ASSIGNMENTS

	MMREG	=	174470	   ; MASTER MODE REGISTER
	CMDREG	=	174454	   ; COMMAND REGISTER
	CASTF0	=	174446	   ; CHANNEL 0 CHAIN ADDRESS SEGMENT/TAG FIELD
	CAOF0	=	174442	   ; CHANNEL 0 CHAIN ADDRESS OFFSET FIELD


	START:	MOVB #130,MMREG	   ; LOAD MASTER MODE REG TO DISABLE DTC

		CLRB CMDREG	   ; RESET THE DTC

		MOV  #0,CASTF0	   ; LOAD THE CHAIN ADDRESS REGISTER SEG/TAG
		MOV  #RELOAD,CAOF0 ; LOAD THE CHAIN ADDRESS REGISTER OFFSET

		MOVB #131,MMREG	   ; LOAD MASTER MODE REG TO ENABLE DTC

		MOVB #102,CMDREG   ; SET SOFTWARE REQUEST CHANNEL 0

		MOVB #240,CMDREG   ; START CHAIN CHANNEL 0

		BR   .		   ; STAY HERE WHILE THE USER VERIFIES THAT
				   ; THE PROGRAM WAS SUCCESSFUL

							       Page 15


	; CHAIN LOAD REGION

	RELOAD: .WORD 001602  ; RELOAD WORD <Select CARA,CARB,COPC,CM>

		.WORD 000000  ; CURRENT ADDRESS REGISTER A SEG/TAG
		.WORD DESTNT  ; CURRENT ADDRESS REGISTER A OFFSET
			      ; <This local address is the destination>

		.WORD 101400  ; CURRENT ADDRESS REGISTER B SEG/TAG
		.WORD 000000  ; CURRENT ADDRESS REGISTER B OFFSET
			      ; <This global Q-bus address is the source>
			      ; <This corresponds to address 600000 on
				the Q-bus>
			      ; <The DTC uses physical addresses only>

		.WORD 000013. ; CURRENT OPERATION COUNT <Transfer 13 words>

		.WORD 000000  ; CHANNEL MODE REGISTER HIGH
		.WORD 000060  ; CHANNEL MODE REGISTER LOW
			      ; <No match conditions, do nothing upon
				completion,
			      ;	 transfer type = Demand Dedicated w/Bus Hold,
			      ;	 CARB = source, word transfers>
			      ; <Notice how similar this reload table is to
			      ; the one in EXAM2.  By utilizing the flip bit
			      ; in the CM Reg Low no further changes were
			      ; necessary to use this table in this example>

	DESTNT: .BLKW	13.

		.END START

							       Page 16


	.TITLE EXAM4.MAC

	; This program transfers data from global Q-bus addresses to other
	; global Q-bus addresses.  This program should be compiled and linked
	; on the development system and then downloaded into the KXT11-C using
	; the KXT11-C Software Toolkit.	 Once the program has been compiled
	; and linked use the following commands to execute it and verify its
	; successfullness.
	;
	; <Use Q-bus ODT to deposit values in locations 600000(8)-->600030(8).
	;  These values will be the source for this operation>
	;
	; @600000/000001  ! Deposit source values
	;	   .
	;	   .
	; @600030/000001
	; @P		  ! Use the 'P' command to return to the system prompt
	;
	; .KUI
	; KUI>SET n	  ! Where n is the appropriate KXT11-C
	; KUI>LOAD EXAM4
	; KUI>EXECUTE
	; KUI>EXIT
	;
	; <Use Q-bus ODT to examine the destination locations to verify that
	;  the operation was sucessful>
	; @610000/xxxxxx
	;	  .
	;	  .
	; @610030/xxxxxx
	; @P		  ! Return to system prompt

	; SET UP REGISTER ASSIGNMENTS

	MMREG	=	174470	   ; MASTER MODE REGISTER
	CMDREG	=	174454	   ; COMMAND REGISTER
	CASTF0	=	174446	   ; CHANNEL 0 CHAIN ADDRESS SEGMENT/TAG FIELD
	CAOF0	=	174442	   ; CHANNEL 0 CHAIN ADDRESS OFFSET FIELD


	 START: MOVB #130,MMREG	   ; LOAD MASTER MODE REG TO DISABLE DTC

		CLRB CMDREG	   ; RESET THE DTC

		MOV  #0,CASTF0	   ; LOAD THE CHAIN ADDRESS REGISTER SEG/TAG
		MOV  #RELOAD,CAOF0 ; LOAD THE CHAIN ADDRESS REGISTER OFFSET

		MOVB #131,MMREG	   ; LOAD MASTER MODE REG TO ENABLE DTC

		MOVB #102,CMDREG   ; SET SOFTWARE REQUEST CHANNEL 0

		MOVB #240,CMDREG   ; START CHAIN CHANNEL 0

		BR   .		   ; STAY HERE WHILE THE USER VERIFIES THAT
				   ; THE PROGRAM WAS SUCCESSFUL

							       Page 17


	 ; CHAIN LOAD REGION

	 RELOAD:.WORD 001602  ; RELOAD WORD <Select CARA,CARB,COPC,CM>

		.WORD 101400  ; CURRENT ADDRESS REGISTER A SEG/TAG
		.WORD 000000  ; CURRENT ADDRESS REGISTER A OFFSET
			      ; <This global Q-bus address is the source>
			      ; <This corresponds to Q-bus address 600000(8)>

		.WORD 101400  ; CURRENT ADDRESS REGISTER B SEG/TAG
		.WORD 010000  ; CURRENT ADDRESS REGISTER B OFFSET
			      ; <This global Q-bus address is the destination>
			      ; <This corresponds to Q-bus address 610000(8)>

		.WORD 000013. ; CURRENT OPERATION COUNT <Transfer 13 words>

		.WORD 000000  ; CHANNEL MODE REGISTER HIGH
		.WORD 000040  ; CHANNEL MODE REGISTER LOW
			      ; <No match conditions, do nothing upon
				completion,
			      ;	 transfer type = Demand Dedicated w/Bus Hold,
			      ;	 CARA = source, word transfers>

		.END START

							       Page 18


	.TITLE EXAM5.MAC

	; This program demonstrates how chaining is implemented using the
	; DTC.	A local to local transfer will be initiated under program
	; control.  Then, using the chaining feature of the DTC, a local to
	; global transfer will be performed followed by a global to global
	; transfer and finally a global to local transfer.  The following
	; diagram illustrates these transfers.
	;
	;
	;	KXT11-C Memory			Q-bus Memory
	;
	;	--------------			------------
	;   +---|	     |			|	   |
	;   |	|	     |			|	   |
	;   |	|	     |			|	   |
	;   |	|------------|	Transfer #2	|----------|
	;   +-->|	     | ---------------> |	   |---+
	;	|------------|			|----------|   |
	;	|	     |			|	   |   | Transfer #3
	;	|------------|	Transfer #4	|----------|   |
	;	|	     | <--------------- |	   |<--+
	;	|------------|			|----------|
	;
	; This program should be compiled and linked on the development system
	; and then downloaded into the KXT11-C using the KXT11-C Software
	; Toolkit.  Once the program has been compiled and linked use the
	; following commands to execute it and verify its successfullness.
	;
	; <Use Q-bus ODT to clear the memory locations 600000(8) --> 600030(8)
	;  and 6100000(8) --> 610030(8) before executing the program>
	;
	; .KUI
	; KUI>SET n	   ! Where n is the appropriate KXT11-C
	; KUI>LOAD EXAM5
	; KUI>EXECUTE
	; KUI>ODT	   ! Use KUI ODT to verify that the destination
	; ODT> .	     contents are accurate
	; ODT> .
	; ODT>^C
	; KUI>EXIT
	;
	; <Use Q-bus ODT to examine the contents of the intermediate
	;  destinations to verify their accuracy>

	; SET UP REGISTER ASSIGNMENTS

	MMREG	=	174470	; MASTER MODE REGISTER
	CMDREG	=	174454	; COMMAND REGISTER
	CASTF0	=	174446	; CHANNEL 0 CHAIN ADDRESS SEGMENT/TAG FIELD
	CAOF0	=	174442	; CHANNEL 0 CHAIN ADDRESS OFFSET FIELD

	START:	MOVB #130,MMREG ; LOAD MASTER MODE REG TO DISABLE DTC

		CLRB CMDREG	; RESET THE DTC

							       Page 19


		MOV  #0,CASTF0	  ; LOAD THE CHAIN ADDRESS REGISTER SEG/TAG
		MOV  #LOAD1,CAOF0 ; LOAD THE CHAIN ADDRESS REGISTER OFFSET

		MOVB #131,MMREG	  ; LOAD MASTER MODE REG TO ENABLE DTC

		MOVB #102,CMDREG  ; SET SOFTWARE REQUEST CHANNEL 0

		MOVB #240,CMDREG  ; START CHAIN CHANNEL 0

		BR   .		  ; STAY HERE WHILE THE USER VERIFIES THAT
				  ; THE PROGRAM WAS SUCCESSFUL

	 ; CHAIN LOAD REGION

	 LOAD1: .WORD 001603   ; RELOAD WORD <Select CARA,CARB,COPC,CM,CA>

		.WORD 000000   ; CURRENT ADDRESS REGISTER A SEG/TAG
		.WORD AREA1    ; CURRENT ADDRESS REGISTER A OFFSET
			       ; <This local address is the source of
			       ; transfer #1>

		.WORD 000000   ; CURRENT ADDRESS REGISTER B SEG/TAG
		.WORD AREA2    ; CURRENT ADDRESS REGISTER B OFFSET
			       ; <This local address is the destination of
			       ;  transfer #1>

		.WORD 000013.  ; CURRENT OPERATION COUNT <Transfer 13 words>

		.WORD 000000   ; CHANNEL MODE REGISTER HIGH
		.WORD 100040   ; CHANNEL MODE REGISTER LOW
			       ; <No match conditions, chain reload upon
			       ; completion, transfer type = Demand Dedicated
			       ; w/Bus Hold, CARA = source, word transfers>
		.WORD 000000   ; CHAIN ADDRESS REGISTER SEG/TAG
		.WORD LOAD2    ; CHAIN ADDRESS REGISTER OFFSET
			       ; <This address points to the new chain table>

	LOAD2 : .WORD 001603   ; RELOAD WORD <Select CARA,CARB,COPC,CM,CA>

		.WORD 000000   ; CURRENT ADDRESS REGISTER A SEG/TAG
		.WORD AREA2    ; CURRENT ADDRESS REGISTER A OFFSET
			       ; <This local address is the source of
			       ; transfer #2>

		.WORD 101400   ; CURRENT ADDRESS REGISTER B SEG/TAG
		.WORD 000000   ; CURRENT ADDRESS REGISTER B OFFSET
			       ; <This global address is the destination of
			       ;  transfer #2 - 600000(8)>

		.WORD 000013.  ; CURRENT OPERATION COUNT <Transfer 13 words>


		.WORD 000000   ; CHANNEL MODE REGISTER HIGH
		.WORD 100040   ; CHANNEL MODE REGISTER LOW
			       ; <No match conditions, chain reload upon
			       ; completion, transfer type = Demand Dedicated
			       ; w/Bus Hold, CARA = source, word transfers>

							       Page 20



		.WORD 000000   ; CHAIN ADDRESS REGISTER SEG/TAG
		.WORD LOAD3    ; CHAIN ADDRESS REGISTER OFFSET
			       ; <This address points to the new chain table>

	LOAD3 : .WORD 001603   ; RELOAD WORD <Select CARA,CARB,COPC,CM,CA>

		.WORD 101400   ; CURRENT ADDRESS REGISTER A SEG/TAG
		.WORD 000000   ; CURRENT ADDRESS REGISTER A OFFSET
			       ; <This global address is the source of
				 transfer #3>
			       ;  <600000(8)>

		.WORD 101400   ; CURRENT ADDRESS REGISTER B SEG/TAG
		.WORD 010000   ; CURRENT ADDRESS REGISTER B OFFSET
			       ; <This global address is the destination of
			       ;  transfer #3 - 610000(8)>

		.WORD 000013.  ; CURRENT OPERATION COUNT <Transfer 13 words>

		.WORD 000000   ; CHANNEL MODE REGISTER HIGH
		.WORD 100040   ; CHANNEL MODE REGISTER LOW
			       ; <No match conditions, chain reload upon
			       ; completion, transfer type = Demand Dedicated
			       ; w/Bus Hold,
			       ;  CARA = source, word transfers>

		.WORD 000000   ; CHAIN ADDRESS REGISTER SEG/TAG
		.WORD LOAD4    ; CHAIN ADDRESS REGISTER OFFSET
			       ; <This address points to the new chain table>

	LOAD4 : .WORD 001602   ; RELOAD WORD <Select CARA,CARB,COPC,CM>

		.WORD 101400   ; CURRENT ADDRESS REGISTER A SEG/TAG
		.WORD 010000   ; CURRENT ADDRESS REGISTER A OFFSET
			       ; <This global address is the source of
			       ; transfer #4>
			       ;  <610000(8)>

		.WORD 000000   ; CURRENT ADDRESS REGISTER B SEG/TAG
		.WORD AREA3    ; CURRENT ADDRESS REGISTER B OFFSET
			       ; <This local address is the destination of
			       ;  transfer #4>

		.WORD 000013.  ; CURRENT OPERATION COUNT <Transfer 13 words>

		.WORD 000000   ; CHANNEL MODE REGISTER HIGH
		.WORD 000040   ; CHANNEL MODE REGISTER LOW
			       ; <No match conditions, do nothing upon
			       ; completion, transfer type = Demand Dedicated
			       ; w/Bus Hold,   CARA = source, word transfers>

	AREA1 : .WORD	1,2,3,4,5,6,7,6,5,4,3,2,1
	AREA2 : .BLKW	13.
	AREA3 : .BLKW	13.

		.END START

							       Page 21


	.TITLE	EXAM6.MAC

	; This program demonstrates how to initiate a DTC operation from the
	; arbiter CPU.	This program will tranfer a block of data from Q-bus
	; memory to KXT11-C memory.  All of the information necessary for the
	; transfer will reside in Q-bus memory (chain table, source data)
	; This program should be compiled, linked, and run on the arbiter
	; development system.  After the program executes use the following
	; KUI commands to verify the transfer
	;
	; .KUI
	; KUI>SET n	    ! Where n is the appropriate KXT11-C
	; KUI>ODT
	; ODT>5000/xxxxxx   ! Examine locations 5000 --> 5030 to verify that
	;	.		  the data was transfered correctly
	;	.
	; ODT>5030/xxxxxx
	; ODT>^C
	; KUI>EXIT
	;
	; Two-port RAM register definitions

	TPR0=160100

	TPR2=160104
	TPR3=160106

	.MCALL	.EXIT

	START: MOV #100000,TPR3 ; Place Chain Address Reg Seg/Tag in TPR3
	       MOV #LOAD,TPR2	; Place Chain Address Reg Offset in TPR2

	; *  NOTE!!  *
	;
	; The KXT11-C User's Guide contains an error which instructs the
	; programmer to place the CA register Seg/Tag in TPR2 and the CA
	; register Offset in TPR3.  This information is reversed and is
	; correct as stated above.

	BIS	#2,TPR0 ; Issue DMA Load command to the command register

	.EXIT

	 LOAD  : .WORD	001602	; RELOAD WORD <Select CARA,CARB,COPC,CM>

	.WORD	100000	; CARA SEG/TAG <Select Q-bus address as source>
	.WORD	SOURCE	; CARA OFFSET

	.WORD	000000	;CARB SEG/TAG <Select KXT address 5000 as destination>
	.WORD	005000	;CARB OFFSET

	.WORD	000013. ; COPC <Op-count = 13 words>

	.WORD	000000	; CM High
	.WORD	000040	; CM Low <select no termination options, software
			;	  hog-mode, CARA = source, word transfers>

							       Page 22


	 SOURCE: .WORD	1,2,3,4,5,6,7,6,5,4,3,2,1

		 .END	START











	   RELATED DOCUMENTS

	   For further information concerning the KXT11-CA and the DTC please
	   consult the following sources:

	   KXT11-CA Single-Board Computer User's Guide	    EK-KXTCA-UG-001
	   AmZ8016 DMA Transfer Controller User's Guide	    01924C


	   For further information concerning the KXT11-CA Peripheral Processor
	   Software Toolkit please consult:

	   KXT11-C Peripheral Processor Software User's Guide	  AA-Y615A-TK
	   KXT11-CA Software Toolkit/RT Reference Manual	  AA-AU63A-TC
	   KXT11-CA Software Toolkit/RSX Reference Manual	  AA-AU64A-TC

================================================================================
Note 19.0                 Disabling RAM on the MXV11-BF               No replies
JAWS::KAISER                                        132 lines  25-MAR-1985 09:24
--------------------------------------------------------------------------------
      +---------------+					   +-----------------+
      | d i g i t a l |					   |  uNOTE # 019    |
      +---------------+					   +-----------------+


      +----------------------------------------------------+-----------------+
      | Title: Disabling RAM on the MXV11-BF		   | Date: 10-JAN-85 |
      +----------------------------------------------------+-----------------+
      | Originator: Mike Collins			   | Page 1 of 3     |
      +----------------------------------------------------+-----------------+


      This uNOTE describes how to disable the on-board memory of the  MXV11-BF
      multifunction  module.   There  is also a comparison of features between
      the MXV11-BF (with RAM disabled) and the combination of the MRV11-D  and
      DLV11-J modules.

      DISABLING RAM ON THE MXV11-BF MODULE



				      WARNING!

	  The procedure outlined below	for  disabling	the  RAM  requires
	  physical changes to the circuit board.  Implementing this change
	  will void the warranty of the MXV11-BF as well  as  voiding  any
	  field service contract for the board.


      The procedure requires cutting one etch and adding one wire.

      PROCEDURE (see figure below)

	   1. The etch cut can be achieved two ways.

	      Cut and bend up pin 13 of chip E17.

			   OR

	      On side 2 of module (the non-component side), cut etch
	      which connects E17 pin 13 to E26 pin 2.

	   2. Add wire between E17 pin 13 and E17 pin 14 (+5 Volts).

	   3. The on-board RAM is now disabled.
									Page 2


				MXV11-BF (M7195)


	       |						   |
	       |						   |
	       |						   |
	       |			       Pin 1		   |
	       |			       |		   |
	       |			       | Pin 14		   |
	       |			       | |		   |
	       |			       | |		   |
	       |			       | |		   |
	       |			   +-+ V V     +-+	   |
	       |	    Pin 1 ---> +-+ | | +-+ +-+ | | +-+ +-+ |
	       |		       | | | | | | | | | | | | | | |
	       |	    E26 -----> | | | | | | | | | | | | | | |
	       |		       | | | | | | | | | | | | | | |
	       |		       +-+ | | +-+ +-+ | | | | | | |
	       |			   +-+	^      +-+ | | | | |
	       |				|	   +-+ +-+ |
	       +-+			  +-+	|		   |
		 |		      +---+ |	|		 +-+
		 |		      |	    |  E17		 |
		 |		      |	    |			 |
		 +--------------------+	    +--------------------+


      COMPARISON OF THE MXV11-BF VERSUS THE COMBINATION OF MRV11-D AND DLV11-J

      The following table lists several features common to both	 the  MXV11-BF
      with the RAM disabled and the MRV11-D / DLV11-J combination.

      FEATURE	      MXV11-BF w/o RAM	      MRV11-D and DLV11-J

      RAM	      None		      None

      Boot ROMs	      MXV11-B2		      MXV11-B2

      SLU's	      2 DLARTs		      4 UARTs
		      4 baud rates	      9 baud rates
		      No format options	      Many format options
		      (Start, stop bits, parity, # of bits, etc.)

      Miscellaneous   4 Red LED's	      14 unused ROM/RAM sockets
      features	      1 Green LED

      Cabinet kit     Currently N/A	      Available

      +5 V	      3.4A		      2.6A

      Heat diss.      16.65W		      16W
									Page 3


      FEATURE	      MXV11-BF w/o RAM	      MRV11-D and DLV11-J

      Slots	      1 dual		      2 duals

      AC loads	      2.3		      4.0

      DC loads	      0.5		      1.5

      +12 V	      0.1A		      0.25A

      When comparing the features on page 2, the  MRV11-D/DLV11-J  combination
      works  out better than the MXV11-BF.  All of the features on page 3 show
      the advantages of the MXV11-BF.

      The MXV11-BF is the best choice in situations where backplane space  and
      loading  is  a  primary  concern.	  In  terms of backplane space, if the
      number of slots available is limited, the MXV11-BF is  preferable	 since
      it  takes	 up  one  dual	slot  whereas  the MRV11-D/DLV11-J combination
      requires two dual slots.

      In a large system where AC loading may be a concern, the	MXV11-BF  also
      has an advantage over the MRV11-D/DLV11-J combination.  The number of AC
      loads the MXV11-BF presents to the bus  is  fewer	 than  the  two	 board
      combination.

      The most attractive use for the MXV11-BF is in a	minimal	 yet  powerful
      two-board system i.e.  KDJ11-A and the MXV11-BF.	The advantages of such
      a system are the size or form factor  (only  two	dual  height  modules)
      128Kb  of	 RAM,  2  serial  lines,  bootstrap  capability	 and  the high
      performance 11/73 CPU.

================================================================================
Note 20.0                    MXV11-A, -B Differences                  No replies
JAWS::KAISER                                         84 lines  25-MAR-1985 09:24
--------------------------------------------------------------------------------
      +---------------+					   +-----------------+
      | d i g i t a l |					   |  uNOTE # 020    |
      +---------------+					   +-----------------+


      +----------------------------------------------------+-----------------+
      | Title: Differences between the MXV11-A and MXV11-B | Date: 10-JAN-85 |
      +----------------------------------------------------+-----------------+
      | Originator: Dave Smith				   | Page 1 of 2     |
      +----------------------------------------------------+-----------------+


      This MicroNote illustrates the features to consider when upgrading  from
      MXV11-AA/-AC  to MXV11-BF multifunction boards or when choosing one in a
      new configuration.

      +-----------------------------------+----------------------------------+
      |					  |				     |
      |		MXV11-A			  |		MXV11-BF	     |
      |					  |				     |
      +-----------------------------------+----------------------------------+
      |					  |				     |
      | o Dual height form factor	  | o Dual height form factor	     |
      |					  |				     |
      | o 18-bit compatible only	  | o 18 or 22-bit compatible	     |
      |					  |				     |
      | o 2 SLU's (DLV11-J type)	  | o 2 SLU's (DLARTs)		     |
      |					  |				     |
      | o RAM:				  | o RAM:			     |
      |	   8 KB non-parity (MXV11-AA)	  |    128 KB non-parity	     |
      |	   32 KB non-parity (MXV11-AC)	  |				     |
      |					  |				     |
      | o ROM: 2 sockets (24-pin)	  | o ROM: 2 sockets (28-pin)	     |
      |	   (for MXV11-A2 boot ROMS	  |    (for MXV11-B2 boot ROMS	     |
      |	   - cannot use MXV11-B2 ROMS)	  |	- cannot use MXV11-A2 ROMS)  |
      |					  |				     |
      +-----------------------------------+----------------------------------+


      Notes:

      The MXV11-B2 Boot ROMs are required for an LSI-11/73 based system to  be
      maintained under a DEC Field Service contract because these ROMs contain
      cache diagnostics.

      For a comprehensive list of Bootstraps  and  device  support,  refer  to
      MicroNote	 15, entitled "Q-bus Hardware Bootstraps"

      Since the ROM sockets on these  boards  may  be  used  for  user-written
      application  code	 as well as boot code, it is important to note what is
      different on the two boards.  Besides the	 sockets  being	 of  different
      size,  the ROM on the two boards has another difference.	The ROM on the
      MXV11-BF is window mapped and may be used under application  control  to
      address  up  to  8  KB.	The  MXV11-A ROM is direct mapped and can only
      address 256 bytes.  Thus, an upgrade would require new ROMs and possible

								Page 2


      application recoding.

      For more detailed	 information  concerning  MXV11-BF  issues,  refer  to
      MicroNote 19.

      For more detailed information concerning MXV11-A issues,	refer  to  the
      archived MicroNotes listed in appendix A.


      Summary:

      When upgrading from the MXV11-A to the MXV11-BF or choosing the MXV11-BF
      over the MXV11-A, three important features are obtained:


      1) 22-bit compatibility - allows use in large memory systems
	 (The MXV11-BF memory can only be configured to start in the
	  lower 512 KB.	 It does, however, decode all 22 lines of
	  address which makes it usable in systems with up to 4 MB.)

      2) More memory (although its non-parity feature creates some software
	 support issues if used with RSX or RSTS)

      3) Support for boot ROMs that will boot MSCP devices such as the RX50
	 and RD51 and will provide cache diagnostics for the LSI-11/73.

================================================================================
Note 21.0                   MicroVAX I Floating Point                 No replies
JAWS::KAISER                                        106 lines  25-MAR-1985 09:24
--------------------------------------------------------------------------------
      +---------------+					   +-----------------+
      | d i g i t a l |					   |  uNOTE # 021    |
      +---------------+					   +-----------------+


      +----------------------------------------------------+-----------------+
      | Title: Floating Point Considerations on MicroVAX I | Date: 10-Jan-85 |
      +----------------------------------------------------+-----------------+
      | Originator: Christopher DeMers			   | Page 1 of 2     |
      +----------------------------------------------------+-----------------+


      The MicroVAX architecture implements a subset of VAX data	 types.	  Four
      that  are	 part  of  the	VAX  architecture but not part of the MicroVAX
      architecture are the D_floating, F_floating, G_floating  and  H_floating
      data  types.   Floating point instructions that use these data types are
      likewise not part of the architecture.

      The MicroVAX I system implements	a  proper  superset  of	 the  MicroVAX
      architecture;   that  is, MicroVAX I uses the MicroVAX architecture, but
      implements a few items that are not defined  as  part  of	 the  MicroVAX
      architecture.   Even though the architecture specifies emulation support
      for floating point,  the	following  data	 types	and  instructions  are
      supported in the MicroVAX I microcode:

		- F_float
		- D_float
		- G_float

      The F_float data type and instructions are standard on the  MicroVAX  I.
      In  addition,  the  user	may  specify  EITHER D_float or G_float as the
      double precision instruction  set.   The	decision  to  use  D_float  or
      G_float depends on the application.

      Both D_float and	G_float	 are  double  precision	 floating  point  data
      types/instructions.  D_float is compatible with the PDP-11 format and is
      the double precision  floating  point  default  for  many	 of  Digital's
      compilers	 including FORTRAN, PL/I, BASIC and Pascal.  Therefore, if the
      application has been compiled, say, on a VAX-11/780,  with  the  default
      (D_float)	 and is not to be re-compiled before being run on the MicroVAX
      I, then choose the D_float option.  The compilers mentioned above have a
      switch  that allows the generation of G_float instructions.  If you wish
      to choose the G_float option for your MicroVAX I, the program  needs  to
      be re-compiled with the G_float switch set.

      If Macro programs use a specific data type such  as  G_float,  then  the
      MicroVAX	I  will	 need to have the G_float option unless the program is
      modified so that the floating point instructions match the option chosen
      for the MicroVAX I.
									Page 2


      Note that even though a  program	uses  one  type	 of  double  precision
      floating	point  and  the	 MicroVAX  I  has  the other as an option, the
      program will run.	 A feature of the MicroVAX architecture	 is  that  all
      instructions  are	 executed.  The floating point instructions not chosen
      as a microcode option are emulated  in  software.	  An  instruction/data
      type mismatch could result in severe performance degradation.

      Another reason for choosing one double precision format over another  is
      the  size and accuracy of the data.  Both formats are 64 bits long.  The
      D_float range is 2.9E-37	to  1.7E38.   This  type  gives	 approximately
      sixteen  decimal digits precision.  G_float "steals" three bits from the
      fraction to give the exponent a larger  range.   The  G_float  range  is
      .56E-308	to  .9E308  and	 gives	approximately  fifteen	decimal digits
      precision.  The range of the number  is  increased  significantly	 while
      only reducing the precision by one decimal digit.

      H_float, the only other floating data type in the VAX  architecture,  is
      128  bits	 long  with  a	range  of  close to 10E5000 and a precision of
      thirty-three decimal digits.  H_float is not implemented as part of  the
      MicroVAX architecture.  It is, however, emulated in software.



			  Data Type Representations



				 F_Floating

			   15	      7 6	 0
			  +------------+----------+
			  |S| Exponent | Fraction |
			  +------------+----------+
			  |	  Fraction	  |
			  +-----------------------+
			   31			16




	       D_Floating				G_Floating


       15	  7 6	     0			 15	    4 3	       0
      +------------+----------+			+------------+----------+
      |S| Exponent | Fraction |			|S| Exponent | Fraction |
      +------------+----------+			+------------+----------+
      |	      Fraction	      |			|	Fraction	|
      +-----------------------+			+-----------------------+
      |	      Fraction	      |			|	Fraction	|
      +-----------------------+			+-----------------------+
      |	      Fraction	      |			|	Fraction	|
      +-----------------------+			+-----------------------+
       63		    48			 63		      48

================================================================================
Note 22.0                 MicroVAX I and II differences               No replies
FURILO::JACKSON                                     626 lines  19-AUG-1985 11:29
--------------------------------------------------------------------------------






      +---------------+                                    +-----------------+
      | d i g i t a l |                                    |  uNOTE # 022    |
      +---------------+                                    +-----------------+

                                                                         
      +----------------------------------------------------+-----------------+
      | Title: Differences between the MicroVAX I and the  | Date: 28-APR-85 |
      |                    MicroVAX II CPUs                |                 |
      +----------------------------------------------------+-----------------+
      | Originator: Mike Collins                           | Page 1 of 11    |
      +----------------------------------------------------+-----------------+


      This  MicroNote  identifies  the  differences  between  the  MicroVAX  I
      processor  and  the  MicroVAX  II processor.  The term 'MicroVAX 630' is
      sometimes used in this and other documentation when referring to the CPU
      module  of  the MicroVAX II system.  Table 1 below contains a summary of
      these differences and following the table are  detailed  discussions  of
      each.

      Table 1 - MicroVAX II versus the MicroVAX I

      +-----------------------------+--------------------+-------------------+
      |        FEATURE              |    MicroVAX II     |    MicroVAX I     |
      +-----------------------------+--------------------+-------------------+
      | CPU Technology              |   MicroVAX 78032   |    Custom VLSI    |
      +-----------------------------+--------------------+-------------------+
      | Memory System               |    Local Memory    | Uses Q-bus Memory |
      |                             |       System       |                   |
      +-----------------------------+--------------------+-------------------+
      | Floating Point              |   MicroVAX 78132   |     Microcode     |
      +-----------------------------+--------------------+-------------------+
      | Q-bus I/O Map               |        YES         |         NO        |
      +-----------------------------+--------------------+-------------------+
      | Addressable Physical Memory |     16 MBytes      |      4 MBytes     |
      +-----------------------------+--------------------+-------------------+
      | On-Board Memory             |    256KB or 1MB    |        None       |
      +-----------------------------+--------------------+-------------------+
      | Performance                 |         See Performance Section        |
      +-----------------------------+--------------------+-------------------+
      | Console Serial Line         |        YES         |        YES        |
      +-----------------------------+--------------------+-------------------+
      | Boot & Diagnostic ROMs      |        YES         |        YES        |
      +-----------------------------+--------------------+-------------------+
      | Form Factor                 |       1 Quad       |      2 Quads      |
      +-----------------------------+--------------------+-------------------+
      | Configuration Set via       |     Cabinet Kit    |   Cabinet Kit &   |
      |                             |                    | On-board Switches |
      +-----------------------------+--------------------+-------------------+
      | RQDX Controller Type        |        RQDX2       |   RQDX1 or RQDX2  |
      +-----------------------------+--------------------+-------------------+

                                                                Page 2


      Table 1 - MicroVAX II versus the MicroVAX I (cont'd)

      +-----------------------------+--------------------+-------------------+
      | TOY Clock w/ Battery Backup |        YES         |         NO        |
      +-----------------------------+--------------------+-------------------+
      | Multicomputing Hooks        |        YES         |         NO        |
      +-----------------------------+--------------------+-------------------+
      | Instruction Set Differences |            See MicroNote #24           |
      +-----------------------------+--------------------+-------------------+
      | Power Requirements          |   +5V - 6.2 Amps   |   +5V - 14 Amps   |
      |                             |  +12V - 0.14 Amps  |  +12V - 0.5 Amps  |
      +-----------------------------+--------------------+-------------------+
      | AC Loads                    |        2.7         |         2         |
      +-----------------------------+--------------------+-------------------+
      | DC Loads                    |         1          |         1         |
      +-----------------------------+--------------------+-------------------+
      | Termination                 |      240 Ohms      |      240 Ohms     |
      +----------------------------------------------------------------------+


      The MicroVAX II is both faster and smaller than  the  MicroVAX  I.   Two
      major   features   of   the   MicroVAX  II  are  responsible  for  these
      enhancements:  the MicroVAX 78032 microprocessor and the memory system.


                                   CPU TECHNOLOGY
                                   --------------
      The technologies used to design the two processors are different.   This
      is why the MicroVAX II CPU is half the size and three times the speed of
      the MicroVAX I.

      The MicroVAX I CPU was designed using a custom VLSI chip,  several  ROMs
      and off-the-shelf parts to implement the ALU, memory management unit and
      the microcode.  In contrast, these same features are implemented in  the
      MicroVAX 78032 microprocessor.  The MicroVAX 78032 is the first VAX on a
      chip.  Two custom gate arrays were also designed to reduce the  size  of
      the  MicroVAX II CPU to one quad module:  the Q-bus interface gate array
      and the MicroVAX 78032 interface gate array.


                                   MEMORY SYSTEM
                                   -------------
      The significant  difference  in  performance  is  due  in  part  to  the
      different  memory  systems  used by the two processors.  The MicroVAX II
      memory system uses a high speed interconnect between the MicroVAX  78032
      microprocessor  and  RAM.   The  MicroVAX I uses standard Q-bus memories
      which are not as fast but are also less expensive and usable by both the
      MicroVAX  I  and other 16-bit processors (such as the MicroPDP-11).  The
      MicroVAX I also uses a cache memory scheme.

      The  MicroVAX  II  CPU  communicates  to  memory  over  a  local  memory
      interconnect.   This  was done to increase the performance of the system
      in two ways.  First, the local memory system provides a fast  connection
      between  the  processor  and  memory  (400  nsec read and write cycles).
      Second, since memory fetches occur over the  local  memory  system,  the

                                                                Page 3


      Q-bus  is now a dedicated I/O bus.  The diagrams below contrast previous
      Q-bus processors and the MicroVAX II.

      The local memory system allows for 2 expansion memory boards.  (See next
      section on Addressable Physical Memory)

      Configuration Used by Previous Q-bus Processors:
      This approach is used by  most  Q-bus  processors  such  as  the  11/23,
      LSI-11/73  and  the  MicroVAX I.  In this design, the Q-bus bandwidth is
      shared by the processor and I/O devices when accessing memory.

              +---------+           +---------+           +---------+
              |         |           |         |           |         |
              |Processor|           | Memory  |           |   I/O   |
              |         |           |         |           |  Device |
              |         |           |         |           |         |
              |         |           |         |           |         |
              +---------+           +---------+           +---------+
                   |                     |                     |
                   |                     |                     |
             ---------------------------------------------------------
                                       Q-bus
             ---------------------------------------------------------
       
             Figure 1 - Memory Design Used by Previous Q-bus Processors


      MicroVAX II Design:
      The MicroVAX II uses a local memory system for  all  memory  references,
      allowing  the  Q-bus to be a dedicated I/O bus.  The local memory system
      is implemented using the  C-D  interconnect  of  the  backplane  and  an
      over-the-top  cable.  The memory system has a bandwidth of 10 MBytes/sec
      which will support the MicroVAX 78032  microprocessor  running  at  full
      speed  (approx.   6  MB/sec)  with simultaneous Q-bus DMA transfers (3.3
      MB/sec).

                     10 MBytes/sec
             +---------------------------+ <-- Over-the-Top Cable
             |     +---------------+     |
             |     |               | <---|---- C-D Interconnect in Backplane
           +---------+           +---------+           +---------+
           |         |           |         |           |         |
           |Processor|           |Expansion|           |   I/O   |
           |         |           |  Memory |           |  Device |
           | 6 MB/sec|           |(max. of |           |         |
           |         |           |    2)   |           |         |
           +---------+           +---------+           +---------+
                |                                           |
                |                                           |
           ---------------------------------------------------------
                             Q-bus (3.3 MBytes/sec)
           ---------------------------------------------------------
                         Q-bus is a dedicated I/O bus

                     Figure 2 - MicroVAX II Memory Design

                                                                Page 4


                                   FLOATING POINT
                                   --------------
      The MicroVAX architecture specifies that the floating point  instruction
      set  need  not  be  implemented in the hardware of a MicroVAX processor.
      For those processors that fall into this category, there is an  emulator
      in  the  software  which  guarantees  that  the  instructions  are still
      executable.  However the  MicroVAX  architecture  does  not  restrict  a
      MicroVAX  design  from having floating point instructions implemented in
      hardware.

      This is what was done on the MicroVAX I.  The MicroVAX I does  have  the
      F_floating  and D_floating or the F_floating and G_floating instructions
      in microcode.  (see MicroNote   21  "Floating  Point  Considerations  on
      MicroVAX I")

      The MicroVAX II uses the MicroVAX 78132 floating point unit to implement
      floating  point  instructions.  It is a high performance coprocessor for
      the MicroVAX 78032 and eliminates the  need  to  emulate  floating-point
      instructions in software.

      The MicroVAX 78132 handles the F_floating (single precision), D_floating
      (double-precision)  and the G_floating (extended range double-precision)
      floating point data types and instructions.  The  FPU  also  accelerates
      the execution of integer multiply and divide operations.

      The H_floating instructions are emulated in both the MicroVAX I and  the
      MicroVAX II.


                         Q-bus I/O MAP (SCATTER/GATHER MAP)
                         ----------------------------------
      The concept of a scatter/gather map has been used on  the  large  UNIBUS
      VAXes  since  the  VAX 11/780.  The same concept is used on the MicroVAX
      II.  Simply stated, the scatter/gather mechanism maps addresses from one
      bus  to  another  bus.   This  mapping  is necessary because the address
      length is not the same for the two buses.

      The term 'scatter/gather'  is  a  description  of  what  operations  are
      performed through the scatter/gather map.  A VAX with mapping enabled is
      a virtual machine and manages  data  in  512-byte  pages  which  may  be
      discontiguous  in  physical  memory.  When a DMA write operation occurs,
      pages of data may be 'scattered' into physical  memory.   During  a  DMA
      read operation from memory to an I/O device, such as a disk, these pages
      of data must be 'gathered' from throughout memory and transferred to the
      device.

      The MicroVAX I does not require a Q-bus I/O map.  Since all I/O  devices
      and  memory  share  the  same  bus,  the  Q-bus, there is no mismatch in
      address lengths and no I/O map is necessary.  Reading and  writing  data
      to  and  from memory in 512 byte pages becomes the responsibility of the
      I/O device or the system software.

      In the case of the MicroVAX II CPU, the scatter/gather map provides  the
      mapping  mechanism  to  allow  DMA  devices on the Q-bus, with a 4 MByte
      physical address range, to gain access to all  of  main  memory  on  the

                                                                Page 5


      local memory system, a 16 MByte physical address range.

      Figure 3 below illustrates the mapping process.

      The high order 13 bits of the Q-bus address select one of  8192  mapping
      registers.  Each register translates an address for a range covering one
      page of 512 bytes; thus the mapping registers  cover  the  entire  Q-bus
      address space of 4MB.

      The lower 15 bits of the mapping  register  will  have  been  previously
      loaded  with the correct information, which when appended to the lower 9
      bits of the Q-bus address selects the appropriate byte in main memory.

      The high order 15 bits of the physical address select which page in main
      memory  has the correct address and the low order 9 bits select the byte
      within a page.

                                   9 8        0
                        +----------------------+           Q-bus I/O Map
      Q-bus Address     | 13 bits   |          |           8K Mapping Registers
                        +----------------------+           +---------------+
                              |     |          |           |               |
                              +--------------------------> |---------------|
                                    |          |    +----- |               |
                                                    |      |---------------| 
                                    |          |    |      |               | 
      Selected Mapping Register                     |      |               |
                                    |          |    |      |               |
       31          15 14           0                |      |               |
      +-----------------------------+          |    |      +---------------+
      |V|            |    15 bits   | <-------------+
      +-----------------------------+
                     |              |          |

                     |              |          |
                                                              Local Memory 
                     |              |          |
                                                           +---------------+
      Physical Addr. +-------------------------+           |               |
      in local       |         24 bits         |           |               |
      memory         +-------------------------+           |               | 
                                  |                        |               |
                                  |                        |---------------|
                                  +----------------------> |               |
                                                           |---------------|
                                                           |               |
                                                           |               |
                                                           |               |
                                                           |               |
                                                           +---------------+

                 Figure 3 - Q-bus to Private Memory Mapping Process

                                                                Page 6


                            ADDRESSABLE PHYSICAL MEMORY
                            ---------------------------
      The total  amount  of  addressable  physical  memory  for  each  CPU  is
      different because of the memory system designs.

      The MicroVAX  I  uses  standard  Q-bus  memories  for  main  memory  and
      therefore  has  a  lower physical addressing limit than the MicroVAX II.
      This limit is constrained by the number of address lines on  the  Q-bus.
      There  are  22  address lines on the Q-bus, limiting maximum memory to 4
      MB.

      The MicroVAX II uses a 24 bit address when accessing  the  local  memory
      system.   Therefore  the  maximum  amount  of  addressable  memory is 16
      MBytes.

      When the system is first available, 9 Mbytes will be the maximum because
      the 16 MByte total depends on the availability of 1 Mbit RAM parts.  The
      9 MByte total includes a MicroVAX II CPU  (KA630-AA)  which  includes  1
      MByte on-board plus two 4 MByte expansion modules.

      The memory module capacities are listed in the table 3 below.

      Table 3 - Expansion Memory Options

      +----------+---------------+---------------+
      |  MEMORY  |  MEMORY SIZE  |  FORM FACTOR  |
      +----------+---------------+---------------+
      | MS630-AA |    1 Mbyte    |      Dual     |
      +----------+---------------+---------------+
      | MS630-BA |    2 Mbytes   |      Quad     |
      +----------+---------------+---------------+
      | MS630-BB |    4 Mbytes   |      Quad     |
      +----------+---------------+---------------+


                                    PERFORMANCE
                                    -----------
      The relative performance between the processors is of course application
      dependent.   However,  as  a  general rule of thumb, the MicroVAX II CPU
      will be approximately 3 times faster than the MicroVAX I.   The  results
      of  standard,  compute bound floating point benchmarks indicate that the
      MicroVAX II (with the MicroVAX 78132 FPU) will run 4 to 6.6 times faster
      than the MicroVAX I.


                                CONSOLE SERIAL LINE
                                -------------------
      The MicroVAX II and the MicroVAX I processors both  have  one  dedicated
      serial line for the console terminal.  There are two differences between
      the two serial line units.  First, the number of selectable  baud  rates
      is different.  The possible baud rates are listed in table 4.

                                                                Page 7


      Table 4 - Baud Rate Selections

      +--------------+------------+
      | MicroVAX II  | MicroVAX I |
      +--------------+------------+
      |      300     |     300    |
      |      600     |    1200    |
      |     1200     |    9600    |
      |     2400     |   19200    |
      |     4800     |            |
      |     9600     |            |
      |    19200     |            |
      |    38400     |            |
      +--------------+------------+

      Second, the console device connector on the patch panel for the MicroVAX
      I  is  an  RS232  25-pin D-subminiature connector.  The connector on the
      MicroVAX II patch panel is a 9-pin  D-subminiature  connector.   Because
      the  connectors  are different, different cables will be used to connect
      to the console terminal.
                                    FORM FACTOR
                                    -----------
      All of the features and functions  of  the  MicroVAX  II  processor  are
      contained  on  one  quad module.  The MicroVAX I processor is made up of
      two quad modules, a data path module ('DAP'), and  a  memory  controller
      ('MCT').   The  two  modules  of the MicroVAX I communicate over the C-D
      backplane interconnect and an over-the-top ribbon cable.


                              BOOT AND DIAGNOSTIC ROMs
                              ------------------------
      Both processors have boot/diagnostic ROMs.  The ROMs on the  MicroVAX  I
      are  NOT  the  same as those on the MicroVAX II CPU, therefore there are
      differences in their operation.

      Both ROMs perform the following functions :
           Initialize the machine into a known state.
           Perform diagnostic tests.
           Allow for the automatic restart or bootstrap of the system following 
           a processor halt or initial power-up.
           Provide bootstrap capability from a variety of devices.
           Provide the VAX console command language.

      Perform diagnostic tests.
      When either machine is powered on, their respective diagnostic tests are
      executed.

      Microverify is the  name  given  to  the  diagnostics  executed  by  the
      MicroVAX  I  system.  There are three LEDs on the DAP module and a seven
      segment display on the patch panel which will isolate the problem to one
      of  the  two CPU modules.  Error codes are defined in table 10-1 on page
      10-4 of the MicroVAX I Owner's Manual.

      A similar function is performed by the MicroVAX II CPU diagnostics.   As
      each  test  is run, a code is displayed on the processor LEDs, the patch

                                                                Page 8


      panel and the console terminal.  These codes count down  in  hexadecimal
      from  F  to  0.   There  are potentially 16 steps which may be executed,
      therefore the MicroVAX 630 has 4 LEDs.  The definitions for these  codes
      may  be  found  in  the  MicroVAX  630  CPU  Module  User's  Guide  (P/N
      CK-KA630-UG).

      Power-up modes.
      A major  difference  between  the  two  processors  is  what  occurs  at
      power-up.  The MicroVAX I will either attempt to do a restart, bootstrap
      or halt and enter console mode (the appropriate option is  selected  via
      two switches on the DAP module).

      The MicroVAX II can also be configured  to  try  a  restart,  perform  a
      bootstrap  or halt.  Before it attempts these options however, it does a
      language inquiry.  All console messages may be output in one  of  eleven
      different  languages;  one  must be selected.  There are options such as
      defaulting to English or defaulting to the language which  was  selected
      previously for unassisted bootstrap or always prompting for the language
      at power-up.  These options are described in the MicroVAX 630 CPU Module
      User's Guide.
      Bootstrap Devices.
      The list of devices which each  processor  can  boot  from  is  slightly
      different.  Table 5 lists the supported boot devices for each processor.
      The devices are listed in the order by which they are  searched  by  the
      processor.

      Table 5 - Bootstrap Devices

      +----------------+------------+
      |  MicroVAX II   | MicroVAX I |
      +----------------+------------+
      | RQDX, KDA50 or | RQDX       |
      | RC25           |            |
      |                |            |
      | TK50           |            |
      |                |            |
      | MRV11-D        | MRV11-D    |
      |                |            |
      | DEQNA          | DEQNA      |
      +----------------+------------+

      VAX Console Command Language.
      Both processors implement the VAX console command language in their boot
      ROMs.   Most  of  the  frequently  used commands are implemented by both
      machines.  However, there are a few commands which are only  implemented
      by one or the other.  Table 6 lists the commands and indicates which are
      available on each processor.

                                                                Page 9


      Table 6 - VAX Console Commands

      +-------------+--------------+------------+
      |   COMMAND   | MicroVAX II  | MicroVAX I |
      +-------------+--------------+------------+
      | BREAK       |       X      |      X     |
      | INITIALIZE  |       X      |      X     |
      | START       |       X      |      X     |
      | CONTINUE    |       X      |      X     |
      | HALT        |       X      |      X     |
      | BOOT        |       X      |      X     |
      | UNJAM       |       X      |      X     |
      | EXAMINE     |       X      |      X     |
      | DEPOSIT     |       X      |      X     |
      | X           |       X      |      X     |
      | FIND        |       X      |            |
      | REPEAT      |       X      |            |
      | TEST        |       X      |      X     |
      | ! (Comment) |       X      |            |
      | N (Next)    |              |      X     |
      | CTRL/U      |       X      |      X     |
      | CTRL/S      |       X      |            |
      | CTRL/Q      |       X      |            |
      | CTRL/O      |       X      |            |
      | CTRL/R      |       X      |            |
      | CTRL/C      |       X      |            |
      +-------------+--------------+------------+ 


                                   CONFIGURATION
                                   -------------
      Both CPUs  have  a  cabinet  kit  through  which  certain  features  are
      configured.   However  the  cabinet kits are different.  The cabinet kit
      for the MicroVAX I will not work with  the  MicroVAX  II  CPU  and  vice
      versa.

      In addition to the cabinet kit are eight switches on one of the MicroVAX
      I  CPU  boards  used  for setting such functions as the recovery action,
      break detect enable and the baud rate selection.  The  cabinet  kit  for
      the  MicroVAX  I is a set of two cables and a patch panel insert for FCC
      system integration.  It performs three functions:

           1. Console terminal connector 
           2. Baud rate rotary switch
           3. Two digit LED display

      The MicroVAX II CPU has no switches or jumpers  on  the  module  itself.
      All  options are set via the patch panel insert of the cabinet kit or an
      optional configuration card used in place of the cabinet kit.  The patch
      panel insert has the following functions :

           1. Halt enable switch
           2. Power-Up mode rotary switch
           3. Baud rate rotary switch
           4. Hexadecimal display

                                                               Page 10


           5. Console terminal connector
           6. Batteries for battery backup

      For MicroVAX II applications which do not need the cabinet kit,  Digital
      designed  a  special  configuration  card.  This card allows the user to
      configure the same functions as the cabinet kit but it is  much  smaller
      and requires no cables.  The configuration card is 1.5" x 2.5" and plugs
      into two connectors on the CPU module.  Simple DIP switches are used  to
      select the appropriate functions.


                       TIME-OF-YEAR CLOCK WITH BATTERY BACKUP
                       --------------------------------------
      The MicroVAX I does not have the capability for  keeping  time  after  a
      system  power-down  or  power  failure.  Each time the system is brought
      back up the time must be reentered  manually  (This  limitation  can  be
      bypassed  under  MicroVMS  for  example,  but  the  system  time will be
      incorrect until set at a later time).

      The MicroVAX II has the capability for a battery backed up  time-of-year
      (TOY)  clock.   A  low-power  TOY  clock  chip was designed onto the CPU
      module.  After a system power-down the chip keeps track of  the  correct
      time  and the system can reboot without needing an operator to enter the
      time and date.

      During normal operation the system keeps track of time using a  10  msec
      interval  timer internal to the MicroVAX 78032.  When power is lost this
      interval timer will stop  but  the  TOY  clock  chip  will  continue  to
      operate.  The TOY clock chip has a resolution of 1 second.

      The batteries for the time-of-year clock chip are located on  the  patch
      panel insert of the cabinet kit.

      The battery backup capability is not present if a system  is  using  the
      configuration  card instead of the cabinet kit in order to configure the
      system.  However there are pins on the configuration card which  can  be
      used  to  connect external batteries to provide the same capability.  It
      is the user's responsibility to provide the batteries  and  cabling  for
      battery backup when using the configuration card.


                                RQDX CONTROLLER TYPE
                                --------------------
      Initial MicroVAX I systems use the RQDX1 disk controller  for  the  RX50
      floppy  disks  and the RD51 / RD52 winchester disks.  This controller is
      required to be the last module in a system  because  it  does  not  pass
      interrupt acknowledge (IACK) nor the DMA grant (BDMG) signals to options
      which come after it in the backplane.

      The RQDX2 disk controller was designed to work with and is shipped  with
      initial  MicroVAX II systems.  The RQDX2 will also work with other Q-bus
      processors such as the MicroVAX I and MicroPDP-11/73.

      IMPORTANT!  The RQDX1 is incompatible with the MicroVAX II CPU therefore
      the two should never be configured into the same system.

                                                               Page 11


                                MULTICOMPUTING HOOKS
                                --------------------
      The MicroVAX II CPU has  been  designed  to  allow  a  maximum  of  four
      processors  to  coexist  in  the  same  system.  There will always be an
      arbiter and up to 3 auxiliaries.  This feature is NOT supported  by  any
      Digital  operating  system  and  is not an off-the-shelf multiprocessing
      solution.  For more information on the specifics of  the  multicomputing
      feature,  reference MicroNote #26 and the MicroVAX 630 CPU Module User's
      Guide.


                            INSTRUCTION SET DIFFERENCES
                            ---------------------------
      The  MicroVAX  architecture  specifies  which   instructions   must   be
      implemented  in the hardware/microcode, all other instructions will then
      be emulated in software.  Depending on the particular  instruction,  the
      emulation  is either entirely in software or in software with a hardware
      assist.  Any specific MicroVAX implementation  will  meet  this  minimum
      requirement but may choose to include in its microcode some instructions
      which would otherwise be emulated.  MicroNote #24 contains a table which
      lists  all of the instructions in the VAX architecture and indicates for
      each MicroVAX processor  whether  or  not  the  instruction  is  in  the
      hardware or emulated.


               POWER REQUIREMENTS, AC LOADS, DC LOADS AND TERMINATION
               ------------------------------------------------------
      Table  7  below  summarizes  the  pertinent  information  necessary   to
      configure one of these processors into a system.

      Since the MicroVAX II CPU is only one quad module it is  not  surprising
      that   the   amount  of  current  drawn  from  the  +5  volt  supply  is
      substantially less than that required by the MicroVAX I CPU.

      Table 7 - Specifications

      +---------------------+-------------+------------+
      |    SPECIFICATION    | MicroVAX II | MicroVAX I |
      +---------------------+-------------+------------+
      | Power Requirements  |             |            |
      |   +5 Volt (amps)    |     6.2     |    14.0    |
      |   +12 Volt (amps)   |     0.14    |     0.5    |
      +---------------------+-------------+------------+
      | AC loads            |     2.7     |      2     |
      +---------------------+-------------+------------+
      | DC loads            |     1.0     |      1     |
      +---------------------+-------------+------------+
      | Termination (ohms)  |     240     |     240    |
      +---------------------+-------------+------------+

================================================================================
Note 23.0                    MicroVAX I->II upgrades                  No replies
FURILO::JACKSON                                     248 lines  19-AUG-1985 11:31
--------------------------------------------------------------------------------






      +---------------+                                    +-----------------+
      | d i g i t a l |                                    |  uNOTE # 023    |
      +---------------+                                    +-----------------+

                                                                         
      +----------------------------------------------------+-----------------+
      | Title: MicroVAX I to MicroVAX II Upgrade Issues    | Date: 28-APR-85 |
      +----------------------------------------------------+-----------------+
      | Originator: Mike Collins                           | Page 1 of 5     |
      +----------------------------------------------------+-----------------+


      This MicroNote  describes  the  hardware  issues  in  upgrading  from  a
      MicroVAX I to a MicroVAX II.

      The Add-On and  Upgrades  group  within  Digital  Equipment  Corporation
      announced  a  formal  upgrade  kit  at  the  time  of  the  MicroVAX  II
      announcement.  For more information about this program contact  a  local
      DEC  sales  representative.   This MicroNote is intended for those users
      who wish understand the issues in an upgrade.

      Reference MicroNote #22 for a detailed description  of  the  differences
      between the processors of the MicroVAX I and MicroVAX II systems.

      Upgrading a MicroVAX I to a MicroVAX II is straightforward  because  the
      two  systems  share  many  common  components.   First  of  all the BA23
      enclosure is used by both systems, this includes  the  backplane,  power
      supply,  control  panel,  and  I/O patch panel.  The 5 1/4" disk devices
      used on a MicroVAX I are also compatible with the  MicroVAX  II.   Since
      I/O  devices  for  both  machines  are  Q-bus  devices they are directly
      compatible with the new processor.  The  upgrade  process  does  however
      involve  replacing the processor, the memory, the 5 1/4" disk controller
      and the  processor  cabinet  kit.   Each  of  these  upgrade  issues  is
      addressed in detail.

      An upgrade example is shown at the end of this MicroNote.

      THE PROCESSOR UPGRADE:
      The MicroVAX I CPU is made up of two quad modules, the memory controller
      ('MCT') and the data path ('DAP').  These two modules occupy slots 1 and
      2 in the backplane.  Both of these modules are replaced  with  a  single
      quad  module,  the  MicroVAX II CPU which must be placed in slot 1.  The
      MicroVAX II CPU module includes 1 MB of memory and  the  MicroVAX  78132
      floating  point  unit.   Slot 2 previously used by the MicroVAX I is now
      available for expansion memory or other options.


      THE MEMORY UPGRADE:
      The memory system designed  for  the  MicroVAX  II  is  unique  to  that
      processor,  therefore  the Q-bus memories used in the MicroVAX I must be
      removed and replaced by the new type.

                                                                Page 2


      If the MicroVAX I being upgraded has only 1 MB of main memory  then  the
      processor  and  memory  can  both  be  replaced with the MicroVAX II CPU
      module.  Additional memory  may  be  added  to  a  MicroVAX  II  CPU  if
      necessary.   Besides  the  1  MB of on-board memory, the MicroVAX II CPU
      will support a maximum of 2 memory expansion boards.   These  additional
      boards  must  be placed immediately after the processor in slots 2 and 3
      of the backplane.  The memory modules communicate with the CPU over  the
      C-D interconnect of the backplane and an over-the-top cable.  A cable is
      shipped with each memory module.

      Figure 1 is an example of  how  the  processor  and  memory  boards  are
      configured into a system.  If the dual height memory expansion module is
      used (MS630-AA) it must be placed in the C-D side of the backplane.  The
      memory  modules  may  be  placed in any order in slots 2 and 3.  Table 2
      lists the memory expansion options.

                                      WARNING

              Both the MicroVAX II  CPU  and  MS630  memory  expansion
              modules  must  be placed in backplane slots with the C-D
              interconnect.  Damage may result if  these  modules  are
              placed  in backplanes with Q-bus signals on both the A/B
              and C/D sides.


      Table 2 - MS630 Memory Expansion Modules

      +----------+---------------+---------------+
      |  MEMORY  |  MEMORY SIZE  |  FORM FACTOR  |
      +----------+---------------+---------------+
      | MS630-AA |    1 Mbyte    |      Dual     |
      +----------+---------------+---------------+
      | MS630-BA |    2 Mbytes   |      Quad     |
      +----------+---------------+---------------+
      | MS630-BB |    4 Mbytes   |      Quad     |
      +----------+---------------+---------------+

        Figure 1 - Processor and Memory Configuration
           +-------------------------------------+
           | +---------------------------------+ |
         1 | |  MicroVAX II CPU   ==========   | | 
           | +---------------------|      |----+ |
           +-----------------------|      |------+
           | +---------------------|      |----+ |
         2 | |  MS630-B           ==========   | | 
           | +---------------------|      |----+ |
           +-----------------------|      |<--------Memory Expansion 
           |                 +-----|      |----+ |       Cable
         3 |    MS630-AA---->|    ==========   | | 
           |                 +-----------------+ |
           +-------------------------------------+
         4 |                                     |
         . |    Additional slots                 |
         . |                                     |
         8 |                                     |
           +-------------------------------------+

                                                                Page 3


      THE RQDX DISK CONTROLLER UPGRADE:
      The RQDX1 5 1/4" disk controller used in  MicroVAX  I  systems  must  be
      removed  and  replaced  with  the  RQDX2  controller.   This  upgrade is
      necessary because the RQDX2 provides features not available on the RQDX1
      and because the RQDX1 is incompatible with the MicroVAX II.

      The RQDX1 does not pass the interrupt acknowledge (IACK)  or  DMA  grant
      signal  (DMGO)  to  other  modules  which may be located after it in the
      backplane.  Therefore it must always be the last  module  in  a  system.
      This  restriction  has been removed with the RQDX2, which does pass both
      of those signals.

      Both RQDX modules are capable of controlling 4 logical  units.   However
      the  RQDX1  can only control a maximum of 2 fixed winchesters (RD5n type
      drives).  Therefore the largest amount of storage that can be  connected
      to  an  RQDX1  would be a combination of 2 RD5n type drives and an RX50,
      which counts as two logical units because it actually handles two  400KB
      floppies.   The  RQDX2 also controls 4 logical units but it knows how to
      control any combination of RDs and RX50s.  Therefore the maximum  amount
      of  storage  that  can  be connected to an RQDX2 would be four RD5n type
      drives.

      The RQDX1 is compatible with RX50 floppies (800KB), RD51 (11MB) and RD52
      (31MB)  disk  drives.   The RQDX2 is compatible with those drives but is
      also capable of controlling RD53 (71MB) drives.


      THE CABINET KIT UPGRADE:
      The MicroVAX I  cabinet  kit  is  incompatible  with  the  MicroVAX  II,
      therefore  the  cabinet  kit  used in the MicroVAX II, BA23 based system
      must be used.  The part number is CK-KA630-AB.

      Both cabinet kits have one serial line connector in order to communicate
      with  the  VAX  console  device.   The  MicroVAX  I cabinet kit uses the
      standard  25-pin,  D-subminiature  RS232  connector.   The  MicroVAX  II
      cabinet  kit  uses  a  different  type  of  connector.   It  is  a 9-pin
      D-subminiature connector and will therefore require  a  different  cable
      from  the  patch  panel to the console device.  The appropriate cable is
      part number BCC08.


      OPERATING SYSTEM UPGRADE:
      Once the hardware has been upgraded it is also  necessary  to  have  the
      appropriate system software which will support the MicroVAX II.  Table 3
      lists the initial versions of  MicroVMS,  ULTRIX-32m  and  VAXELN  which
      support the MicroVAX II.

      Table 3 - System Software Support

      +-----------------+----------------------------------+
      | System Software | Version with MicroVAX II Support |
      +-----------------+----------------------------------+
      | MicroVMS        |         V4.1m or later           |
      | ULTRIX-32m      |         V1.1  or later           |
      | VAXELN          |         V2.0  or later           |
      +-----------------+----------------------------------+

                                                                Page 4


      Many software layered products support the  MicroVAX  II.   Consult  the
      appropriate  Software Product Description (SPD) to verify if the current
      version of the layered product is supported.


      UPGRADE EXAMPLE:
      The following example illustrates the  changes  made  to  a  MicroVAX  I
      system  to  upgrade  it to a MicroVAX II system.  The diagrams represent
      the modules placed in the BA23 backplane.

      Both systems have a CPU, 2MB of  memory,  a  DHV11  8-line  asynchronous
      multiplexer,  a  DEQNA  Ethernet  controller  and  an  RQDX  5 1/4" disk
      controller.

             MicroVAX I System                         MicroVAX II System

          +---------------------+                   +---------------------+
        1 | KD32 CPU - MCT      |                 1 |       KA630-AA      |
          +---------------------+                   +----------+----------+    
        2 | KD32 CPU - DAP      |                 2 |   DEQNA  | MS630-AA |
          +---------------------+                   +----------+----------+
        3 |    MSV11-QA (1MB)   |                 3 |        RQDX2        |
          +---------------------+                   +---------------------+
        4 |    MSV11-QA (1MB)   |                 4 |        DHV11        |
          +---------------------+                   +---------------------+
        5 |        DHV11        |                 5 |                     |
          +----------+----------+                   +---------------------+
        6 |   DEQNA  |   G7272  |                 6 |                     |
          +----------+----------+                   +---------------------+
        7 |        RQDX1        |                 7 |                     |
          +---------------------+                   +---------------------+
        8 |                     |                 8 |                     |
          +---------------------+                   +---------------------+

      Comments:

      The 2 modules of the MicroVAX I CPU  and  the  two  quad  memory  boards
      (MSV11-QAs) were replaced by the KA630-AA and one MS630-AA.

      The DHV11 and DEQNA are compatible with both processors, therefore  they
      were not replaced and remained in the system.

      The RQDX1 controller is incompatible with the MicroVAX II, therefore  it
      is  replaced with the RQDX2.  Any 5 1/4" disk (RX50, RD51 and RD52) used
      on the MicroVAX I is compatible with the RQDX2 on the MicroVAX II.

      The RQDX1 controller must occupy the last slot in a system.   The  RQDX2
      controller  is  located  before  the  DHV11  in  the  upgraded system to
      emphasize the point that it is not required to be the last module in the
      system.

      The MicroVAX I system required a G7272 grant continuity card in  slot  6
      in  order  to  make the system work properly.  This was not necessary in
      the upgraded MicroVAX II system because there was an  empty  dual-height
      slot  next  to  the  MS630-AA memory module.  This illustrates the point

                                                                Page 5


      that the dual height slot next to an MS630-AA is a valid Q-bus slot  and
      can be occupied by any compatible, dual-height option.

      The cabinet kits for the two systems are not shown in the diagrams,  but
      the  one used for the MicroVAX I must be replaced by the cabinet kit for
      the MicroVAX II, part number CK-KA630-AB.  The serial  line  cable  from
      the  patch  panel  to  the  terminal must also change.  The cable of the
      MicroVAX I system must be replaced by a BCC08 cable.

================================================================================
Note 24.0                 MicroVAX instr set difference               No replies
FURILO::JACKSON                                     578 lines  19-AUG-1985 11:32
--------------------------------------------------------------------------------






      +---------------+                                    +-----------------+
      | d i g i t a l |                                    |  uNOTE # 024    |
      +---------------+                                    +-----------------+

                                                                         
      +----------------------------------------------------+-----------------+
      | Title: MicroVAX Instruction Set Differences        | Date: 28-APR-85 |
      +----------------------------------------------------+-----------------+
      | Originator: Mike Collins                           | Page 1 of 10    |
      +----------------------------------------------------+-----------------+


      The MicroVAX architecture specifies that the full  VAX  instruction  set
      need  not  be  implemented in the hardware of a MicroVAX processor.  For
      those processors that fall into  this  category,  there  is  a  software
      emulator which guarantees that the instructions are still executable.

      This MicroNote lists all of the instructions of the VAX architecture and
      for each MicroVAX processor indicates which instructions are implemented
      in hardware/microcode, those  that  are  emulated  and  those  that  are
      present in a floating point unit.

      The  instructions  are  listed  in  alphabetical  order  by  instruction
      mnemonic.   The  following  designations  are  used to indicate where an
      instruction will be executed.

      CPU   - Instructions marked with 'CPU' are implemented in the hardware of
              the particular MicroVAX processor.

      EMA   - Instructions marked with 'EMA' are emulated with microcode assist.

      E     - Instructions marked with an 'E' are emulated entirely in software.

      Processor specific designations:
      MicroVAX II
      FPU   - Instructions marked with 'FPU' are implemented in the hardware 
              only if an external floating point unit is present, otherwise they
              are emulated.

      MicroVAX I
      Hx    - Instructions marked with 'H', 'HF', 'HD' or 'HG' are implemented 
              in hardware even though the MicroVAX architecture specifies that 
              these instructions are emulated.

              There are two versions of  the  MicroVAX  I,  one  with  F_  and
              D_floating  and the other with F_ and G_floating instructions in
              microcode.  There are no MicroVAX I processors  with  all  3  of
              these  floating  point  instruction  types in the hardware.  The
              F_floating instructions are identified by 'HF',  the  D_floating
              by 'HD' and the G_floating by 'HG'.

                                                                Page 2


              Reference  MicroNote  #21,  'Floating  Point  Considerations  on
              MicroVAX I'.

      The  following  table  lists  statistics  about  the   distribution   of
      instructions   based   on  where  they  are  executed.   There  are  304
      instructions in the VAX instruction set.

      Table 1 - MicroVAX Instruction Distribution

      +-------------------------+--------------+------------+-------------+
      |       Description       |   MicroVAX   | MicroVAX I | MicroVAX II |
      |                         | Architecture |            |             |
      +-------------------------+--------------+------------+-------------+
      |   Percentage executed   |     57.6     |    74.3    |    57.6     |
      |         in CPU          |              |            |             |
      +-------------------------+--------------+------------+-------------+
      |   Percentage executed   |      N/A     |     N/A    |    23.0     |
      |         in FPU          |              |            |             |
      +-------------------------+--------------+------------+-------------+
      |   Percentage emulated   |      8.9     |     7.3    |     8.9     |
      |  with microcode assist  |              |            |             |
      +-------------------------+--------------+------------+-------------+
      |   Percentage emulated   |     33.5     |    18.4    |    10.5     |
      |   entirely in software  |              |            |             |
      +-------------------------+--------------+------------+-------------+


      Table 2 - Instruction Set Differences

      Mnemonic         Description              MicroVAX    MicroVAXI MicroVAXII
                                              Architecture

      ACBB      Add compare and branch byte       CPU          CPU       CPU
      ACBD      Add compare and branch             E            HD       FPU
                D_floating
      ACBF      Add compare and branch             E            HF       FPU
                F_floating
      ACBG      Add compare and branch             E            HG       FPU
                G_floating
      ACBH      Add compare and branch             E            E         E
                H_floating

      ACBL      Add compare and branch            CPU          CPU       CPU
                longword
      ACBW      Add compare and branch word       CPU          CPU       CPU
      ADAWI     Add aligned word interlocked      CPU          CPU       CPU
      ADDB2     Add byte 2-operand                CPU          CPU       CPU
      ADDB3     Add byte 3-operand                CPU          CPU       CPU

      ADDD2     Add D_floating 2-operand           E            HD       FPU
      ADDD3     Add D_floating 3_operand           E            HD       FPU
      ADDF2     Add F_floating 2_operand           E            HF       FPU
      ADDF3     Add F_floating 3_operand           E            HF       FPU
      ADDG2     Add G_floating 2_operand           E            HG       FPU

                                                                Page 3


      Mnemonic         Description              MicroVAX    MicroVAXI MicroVAXII
                                              Architecture

      ADDG3     Add G_floating 3_operand           E            HG       FPU
      ADDH2     Add H_floating 2_operand           E            E         E
      ADDH3     Add H_floating 3-operand           E            E         E
      ADDL2     Add longword 2-operand            CPU          CPU       CPU
      ADDL3     Add longword 3-operand            CPU          CPU       CPU

      ADDP4     Add packed 4-operand               E           EMA       EMA
      ADDP6     Add packed 6-operand               E           EMA       EMA
      ADDW2     Add word 2-operand                CPU          CPU       CPU
      ADDW3     Add word 3-operand                CPU          CPU       CPU
      ADWC      Add with carry                    CPU          CPU       CPU

      AOBLEQ    Add one and branch on             CPU          CPU       CPU
                less or equal
      AOBLSS    Add one and branch on less        CPU          CPU       CPU
      ASHL      Arithmetic shift longword         CPU          CPU       CPU
      ASHP      Arithmetic shift and               E           EMA       EMA
                round packed
      ASHQ      Arithmetic shift quad             CPU          CPU       CPU

      BBC       Branch on bit clear               CPU          CPU       CPU
      BBCC      Branch on bit clear and clear     CPU          CPU       CPU
      BBCCI     Branch on bit clear and clear     CPU          CPU       CPU
                interlocked
      BBCS      Branch on bit clear and set       CPU          CPU       CPU
      BBS       Branch on bit set                 CPU          CPU       CPU

      BBSC      Branch on bit set and clear       CPU          CPU       CPU
      BBSS      Branch on bit set and set         CPU          CPU       CPU
      BBSSI     Branch on bit set and set         CPU          CPU       CPU
                interlocked
      BCC       Branch on carry clear             CPU          CPU       CPU
      BCS       Branch on carry set               CPU          CPU       CPU

      BEQL      Branch on equal                   CPU          CPU       CPU
      BEQLU (=BEQL) Branch on equal unsigned      CPU          CPU       CPU
      BGEQ      Branch on greater or equal        CPU          CPU       CPU
      BGEQU (=BCC)  Branch on greater or equal    CPU          CPU       CPU
                unsigned
      BGTR      Branch on greater                 CPU          CPU       CPU

      BGTRU     Branch on greater unsigned        CPU          CPU       CPU
      BICB2     Bit clear byte 2-operand          CPU          CPU       CPU
      BICB3     Bit clear byte 3-operand          CPU          CPU       CPU
      BICL2     Bit clear longword 2-operand      CPU          CPU       CPU
      BICL3     Bit clear longword 3-operand      CPU          CPU       CPU

      BICPSW    Bit clear processor status        CPU          CPU       CPU
                word
      BICW2     Bit clear word 2-operand          CPU          CPU       CPU
      BICW3     Bit clear word 3-operand          CPU          CPU       CPU
      BISB2     Bit set byte 2-operand            CPU          CPU       CPU
      BISB3     Bit set byte 3-operand            CPU          CPU       CPU

                                                                Page 4


      Mnemonic         Description              MicroVAX    MicroVAXI MicroVAXII
                                              Architecture

      BISL2     Bit set longword 2-operand        CPU          CPU       CPU
      BISL3     Bit set longword 3-operand        CPU          CPU       CPU
      BISPSW    Bit set processor status          CPU          CPU       CPU
                word
      BISW2     Bit set word 2-operand            CPU          CPU       CPU
      BISW3     Bit set word 3-operand            CPU          CPU       CPU

      BITB      Bit test byte                     CPU          CPU       CPU
      BITL      Bit test longword                 CPU          CPU       CPU
      BITW      Bit test word                     CPU          CPU       CPU
      BLBC      Branch on low bit clear           CPU          CPU       CPU
      BLBS      Branch on low bit set             CPU          CPU       CPU

      BLEQ      Branch on less or equal           CPU          CPU       CPU
      BLEQU     Branch on less or equal           CPU          CPU       CPU
                unsigned
      BLSS      Branch on less                    CPU          CPU       CPU
      BLSSU (=BCS) Branch on less unsigned        CPU          CPU       CPU
      BNEQ      Branch on not equal               CPU          CPU       CPU

      BNEQU (=BNEQ) Branch on not equal unsigned  CPU          CPU       CPU
      BPT       Break point fault                 CPU          CPU       CPU
      BRB       Branch with byte displacement     CPU          CPU       CPU
      BRW       Branch with word displacement     CPU          CPU       CPU
      BSBB      Branch to subroutine with         CPU          CPU       CPU
                byte displacement

      BSBW      Branch to subroutine with         CPU          CPU       CPU
                word displacement
      BVC       Branch on overflow clear          CPU          CPU       CPU
      BVS       Branch on overflow set            CPU          CPU       CPU
      CALLG     Call with general argument        CPU          CPU       CPU
                list
      CALLS     Call with argument list on        CPU          CPU       CPU
                stack

      CASEB     Case byte                         CPU          CPU       CPU
      CASEL     Case longword                     CPU          CPU       CPU
      CASEW     Case word                         CPU          CPU       CPU
      CHME      Change mode to executive          CPU          CPU       CPU
      CHMK      Change mode to kernel             CPU          CPU       CPU

      CHMS      Change mode to supervisor         CPU          CPU       CPU
      CHMU      Change mode to user               CPU          CPU       CPU
      CLRB      Clear byte                        CPU          CPU       CPU
      CLRD (=CLRQ) Clear D_floating               CPU          CPU       CPU
      CLRF (=CLRL) Clear F_floating               CPU          CPU       CPU

      CLRG (=CLRQ) Clear G_floating               CPU          CPU       CPU
      CLRH (=CLRO) Clear H_floating               CPU          CPU       CPU
      CLRL      Clear longword                    CPU          CPU       CPU
      CLRO      Clear ocatword                     E            E         E
      CLRQ      Clear quadword                    CPU          CPU       CPU

                                                                Page 5


      Mnemonic         Description              MicroVAX    MicroVAXI MicroVAXII
                                              Architecture

      CLRW      Clear word                        CPU          CPU       CPU
      CMPB      Compare byte                      CPU          CPU       CPU
      CMPC3     Compare character 3-operand        E            H        EMA
      CMPC5     Compare character 5-operand        E           EMA       EMA
      CMPD      Compare D_floating                 E            HD       FPU

      CMPF      Compare F_floating                 E            HF       FPU
      CMPG      Compare G_floating                 E            HG       FPU
      CMPH      Compare H_floating                 E            E         E
      CMPL      Compare longword                  CPU          CPU       CPU
      CMPP3     Compare packed 3-operand           E           EMA       EMA

      CMPP4     Compare packed 4-operand           E           EMA       EMA
      CMPV      Compare field                     CPU          CPU       CPU
      CMPW      Compare word                      CPU          CPU       CPU
      CMPZV     Compare zero-extended field       CPU          CPU       CPU
      CRC       Calculate cyclic redundancy        E           EMA       EMA
                check

      CVTBD     Convert byte to D_floating         E            HD       FPU
      CVTBF     Convert byte to F_floating         E            HF       FPU
      CVTBG     Convert byte to G_floating         E            HG       FPU
      CVTBH     Convert byte to H_floating         E            E         E
      CVTBL     Convert byte to longword          CPU          CPU       CPU

      CVTBW     Convert byte to word              CPU          CPU       CPU
      CVTDB     Convert D_floating to byte         E            HD       FPU
      CVTDF     Convert D_floating to              E            HD       FPU
                F_floating         
      CVTDH     Convert D_floating to              E            E         E
                H_floating
      CVTDL     Convert D_floating to              E            HD       FPU
                longword

      CVTDW     Convert D_floating to word         E            HD       FPU
      CVTFB     Convert F_floating to byte         E            HF       FPU
      CVTFD     Convert F_floating to              E            HF       FPU
                D_floating
      CVTFG     Convert F_floating to              E            HG       FPU
                G_floating
      CVTFH     Convert F_floating to              E            E         E
                H_floating

      CVTFL     Convert F_floating to              E            HF       FPU
                longword
      CVTFW     Convert F_floating to word         E            HF       FPU
      CVTGB     Convert G_floating to byte         E            HG       FPU
      CVTGF     Convert G_floating to              E            HG       FPU
                F_floating 
      CVTGH     Convert G_floating to              E            E         E
                H_floating

                                                                Page 6


      Mnemonic         Description              MicroVAX    MicroVAXI MicroVAXII
                                              Architecture

      CVTGL     Convert G_floating to              E            HG       FPU
                longword
      CVTGW     Convert G_floating to word         E            HG       FPU
      CVTHB     Convert H_floating to byte         E            E         E
      CVTHD     Convert H_floating to              E            E         E
                D_floating
      CVTHF     Convert H_floating to              E            E         E
                F_floating

      CVTHG     Convert H_floating to              E            E         E
                G_floating
      CVTHL     Convert H_floating to              E            E         E
                longword
      CVTHW     Convert H_floating to word         E            E         E
      CVTLB     Convert longword to byte          CPU          CPU       CPU
      CVTLD     Convert longword to D_floating     E            HD       FPU

      CVTLF     Convert longword to F_floating     E            HF       FPU
      CVTLG     Convert longword to G_floating     E            HG       FPU
      CVTLH     Convert longword to H_floating     E            E         E
      CVTLP     Convert longword to packed         E           EMA       EMA
      CVTLW     Convert longword to word          CPU          CPU       CPU

      CVTPL     Convert packed to longword         E           EMA       EMA
      CVTPS     Convert packed to leading          E           EMA       EMA
                separate
      CVTPT     Convert packed to trailing         E           EMA       EMA
      CVTRDL    Convert rounded D_floating         E            HD       FPU
                to longword
      CVTRFL    Convert rounded F_floating         E            HF       FPU
                to longword

      CVTRGL    Convert rounded G_floating         E            HG       FPU
                to longword
      CVTRHL    Convert rounded H_floating         E            E         E
                to longword
      CVTSP     Convert leading separate           E           EMA       EMA
                to packed
      CVTTP     Convert trailing to packed         E           EMA       EMA
      CVTWB     Convert word to byte              CPU          CPU       CPU

      CVTWD     Convert word to D_floating         E            HD       FPU
      CVTWF     Convert word to F_floating         E            HF       FPU
      CVTWG     Convert word to G_floating         E            HG       FPU
      CVTWH     Convert word to H_floating         E            E         E
      CVTWL     Convert word to longword          CPU          CPU       CPU

      DECB      Decrement byte                    CPU          CPU       CPU
      DECL      Decrement longword                CPU          CPU       CPU
      DECW      Decrement word                    CPU          CPU       CPU
      DIVB2     Divide byte 2-operand             CPU          CPU       CPU
      DIVB3     Divide byte 3-operand             CPU          CPU       CPU

                                                                Page 7


      Mnemonic         Description              MicroVAX    MicroVAXI MicroVAXII
                                              Architecture

      DIVD2     Divide D_floating 2-operand        E            HD       FPU
      DIVD3     Divide D_floating 3-operand        E            HD       FPU
      DIVF2     Divide F_floating 2-operand        E            HF       FPU
      DIVF3     Divide F_floating 3-operand        E            HF       FPU
      DIVG2     Divide G_floating 2-operand        E            HG       FPU

      DIVG3     Divide G_floating 3-operand        E            HG       FPU
      DIVH2     Divide H-floating 2-operand        E            E         E
      DIVH3     Divide H-floating 3-operand        E            E         E
      DIVL2     Divide longword 2-operand         CPU          CPU       CPU
      DIVL3     Divide longword 3-operand         CPU          CPU       CPU

      DIVP      Divide packed                      E           EMA       EMA
      DIVW2     Divide word 2-operand             CPU          CPU       CPU
      DIVW3     Divide word 3-operand             CPU          CPU       CPU
      EDITPC    Edit packed to character           E           EMA       EMA
                string
      EDIV      Extended divide                   CPU          CPU       CPU

      EMODD     Extended modulus D_floating        E            HD       FPU
      EMODF     Extended modulus F_floating        E            HF       FPU
      EMODG     Extended modulus G_floating        E            HG       FPU
      EMODH     Extended modulus H_floating        E            E         E
      EMUL      Extended multiply                 CPU          CPU       CPU

      EXTV      Extract field                     CPU          CPU       CPU
      EXTZV     Extract zero_extended field       CPU          CPU       CPU
      FFC       Find first clear bit              CPU          CPU       CPU
      FFS       Find first set bit                CPU          CPU       CPU
      HALT      Halt (kernel mode only)           CPU          CPU       CPU

      INCB      Increment byte                    CPU          CPU       CPU
      INCL      Increment longword                CPU          CPU       CPU
      INCW      Increment word                    CPU          CPU       CPU
      INDEX     Index calculation                 CPU          CPU       CPU
      INSQHI    Insert at head of queue,          CPU          CPU       CPU
                interlocked

      INSQTI    Insert at tail of queue,          CPU          CPU       CPU
                interlocked 
      INSQUE    Insert into queue                 CPU          CPU       CPU
      INSV      Insert field                      CPU          CPU       CPU
      JMP       Jump                              CPU          CPU       CPU
      JSB       Jump to subroutine                CPU          CPU       CPU

      LDPCTX    Load process context (only        CPU          CPU       CPU
                legal on interrupt stack) 
      LOCC      Locate character                   E            H        EMA
      MATCHC    Match characters                   E           EMA       EMA
      MCOMB     Move complemented byte            CPU          CPU       CPU
      MCOML     Move complemented longword        CPU          CPU       CPU

                                                                Page 8


      Mnemonic         Description              MicroVAX    MicroVAXI MicroVAXII
                                              Architecture

      MCOMW     Move complemented word            CPU          CPU       CPU
      MFPR      Move from processor register      CPU          CPU       CPU
                (kernel mode only)
      MNEGB     Move negated byte                 CPU          CPU       CPU
      MNEGD     Move negated D_floating            E            HD       FPU
      MNEGF     Move negated F_floating            E            HF       FPU

      MNEGG     Move negated G_floating            E            HG       FPU
      MNEGH     Move negated H_floating            E            E         E
      MNEGL     Move negated longword             CPU          CPU       CPU
      MNEGW     Move negated word                 CPU          CPU       CPU
      MOVAB     Move address of byte              CPU          CPU       CPU

      MOVAD (=MOVAQ) Move address of D_floating   CPU          CPU       CPU
      MOVAF (=MOVAL) Move address of F_floating   CPU          CPU       CPU
      MOVAG (=MOVAQ) Move address of G_floating   CPU          CPU       CPU
      MOVAH (=MOVAO) Move address of H_floating   CPU          CPU       CPU
      MOVAL     Move address of longword          CPU          CPU       CPU

      MOVAO     Move address of ocatword           E            E         E
      MOVAQ     Move address of quadword          CPU          CPU       CPU
      MOVAW     Move address of word              CPU          CPU       CPU
      MOVB      Move byte                         CPU          CPU       CPU
      MOVC3     Move character 3-operand          CPU          CPU       CPU

      MOVC5     Move character 5-operand          CPU          CPU       CPU
      MOVD      Move D_floating                    E            HD       FPU
      MOVF      Move F_floating                    E            HF       FPU
      MOVG      Move G_floating                    E            HG       FPU
      MOVH      Move H_floating                    E            E         E

      MOVL      Move longword                     CPU          CPU       CPU
      MOVO      Move octaword                      E            E         E
      MOVP      Move packed                        E           EMA       EMA
      MOVPSL    Move processor status             CPU          CPU       CPU
                longword
      MOVQ      Move quadword                     CPU          CPU       CPU

      MOVTC     Move translated characters         E           EMA       EMA
      MOVTUC    Move translated until              E           EMA       EMA
                character
      MOVW      Move word                         CPU          CPU       CPU
      MOVZBL    Move zero-extended byte to        CPU          CPU       CPU
                longword
      MOVZBW    Move zero-extended byte to        CPU          CPU       CPU
                word

                                                                Page 9


      Mnemonic         Description              MicroVAX    MicroVAXI MicroVAXII
                                              Architecture

      MOVZWL    Move zero-extended word to        CPU          CPU       CPU
                longword
      MTPR      Move to processor register        CPU          CPU       CPU
                (kernel mode only)
      MULB2     Multiply byte 2-operand           CPU          CPU       CPU
      MULB3     Multiply byte 3-operand           CPU          CPU       CPU
      MULD2     Multiply D_floating 2-operand      E            HD       FPU

      MULD3     Multiply D_floating 3-operand      E            HD       FPU
      MULF2     Multiply F_floating 2-operand      E            HF       FPU
      MULF3     Multiply F_floating 3-operand      E            HF       FPU
      MULG2     Multiply G_floating 2-operand      E            HG       FPU
      MULG3     Multiply G_floating 3-operand      E            HG       FPU

      MULH2     Multiply H_floating 2-operand      E            E         E
      MULH3     Multiply H_floating 3-operand      E            E         E
      MULL2     Multiply longword 2-operand       CPU          CPU       CPU
      MULL3     Multiply longword 3-operand       CPU          CPU       CPU
      MULP      Multiply packed                    E           EMA       EMA

      MULW2     Multiply word 2-operand           CPU          CPU       CPU
      MULW3     Multiply word 3-operand           CPU          CPU       CPU
      NOP       No operation                      CPU          CPU       CPU
      POLYD     Evaluate polynomial D_floating     E            HD       FPU
      POLYF     Evaluate polynomial F_floating     E            HF       FPU

      POLYG     Evaluate polynomial G_floating     E            HG       FPU
      POLYH     Evaluate polynomial H_floating     E            E         E
      POPR      Pop registers                     CPU          CPU       CPU
      PROBER    Probe read access                 CPU          CPU       CPU
      PROBEW    Probe write access                CPU          CPU       CPU

      PUSHAB    Push address of byte              CPU          CPU       CPU
      PUSHAD (=PUSHAQ) Push address of D_floating CPU          CPU       CPU
      PUSHAF (=PUSHAL) Push address of F_floating CPU          CPU       CPU
      PUSHAG (=PUSHAQ) Push address of G_floating CPU          CPU       CPU
      PUSHAH (=PUSHAO) Push address of H_floating CPU          CPU       CPU

      PUSHAL    Push address of longword          CPU          CPU       CPU
      PUSHAO    Push address of ocatword           E            E         E
      PUSHAQ    Push address of quadword          CPU          CPU       CPU
      PUSHAW    Push address of word              CPU          CPU       CPU
      PUSHL     Push longword                     CPU          CPU       CPU

      PUSHR     Push registers                    CPU          CPU       CPU
      REI       Return from exception or          CPU          CPU       CPU
                interrupt
      REMQHI    Remove from head of queue,        CPU          CPU       CPU
                interlocked
      REMQTI    Remove from tail of queue,        CPU          CPU       CPU
                interlocked
      REMQUE    Remove from queue                 CPU          CPU       CPU

                                                               Page 10


      Mnemonic         Description              MicroVAX    MicroVAXI MicroVAXII
                                              Architecture

      RET       Return from procedure             CPU          CPU       CPU
      ROTL      Rotate longword                   CPU          CPU       CPU
      RSB       Return from subroutine            CPU          CPU       CPU
      SBWC      Subtract with carry               CPU          CPU       CPU
      SCANC     Scan for character                 E            H        EMA

      SKPC      Skip character                     E            H        EMA
      SOBGEQ    Subtract one and branch           CPU          CPU       CPU
                on greater or equal  
      SOBGTR    Subtract one and branch           CPU          CPU       CPU
                on greater
      SPANC     Span characters                    E            H        EMA
      SUBB2     Subtract byte 2-operand           CPU          CPU       CPU

      SUBB3     Subtract byte 3-operand           CPU          CPU       CPU
      SUBD2     Subtract D_floating 2-operand      E            HD       FPU
      SUBD3     Subtract D_floating 3-operand      E            HD       FPU
      SUBF2     Subtract F_floating 2-operand      E            HF       FPU
      SUBF3     Subtract F_floating 3-operand      E            HF       FPU

      SUBG2     Subtract G_floating 2-operand      E            HG       FPU
      SUBG3     Subtract G_floating 3-operand      E            HG       FPU
      SUBH2     Subtract H_floating 2-operand      E            E         E
      SUBH3     Subtract H_floating 3-operand      E            E         E
      SUBL2     Subtract longword 2-operand       CPU          CPU       CPU

      SUBL3     Subtract longword 3-operand       CPU          CPU       CPU
      SUBP4     Subtract packed 4-operand          E           EMA       EMA
      SUBP6     Subtract packed 6-operand          E           EMA       EMA
      SUBW2     Subtract word 2-operand           CPU          CPU       CPU
      SUBW3     Subtract word 3-operand           CPU          CPU       CPU

      SVPCTX    Save process context (kernel      CPU          CPU       CPU
                mode only)
      TSTB      Test byte                         CPU          CPU       CPU
      TSTD      Test D_floating                    E            HD       FPU
      TSTF      Test F_floating                    E            HF       FPU
      TSTG      Test G_floating                    E            HG       FPU

      TSTH      Test H_floating                    E            E         E
      TSTL      Test longword                     CPU          CPU       CPU
      TSTW      Test word                         CPU          CPU       CPU
      XFC       Extended function call            CPU          CPU       CPU
      XORB2     Exclusive OR byte 2-operand       CPU          CPU       CPU

      XORB3     Exclusive OR byte 3-operand       CPU          CPU       CPU
      XORL2     Exclusive OR longword 2-operand   CPU          CPU       CPU
      XORL3     Exclusive OR longword 3-operand   CPU          CPU       CPU
      XORW2     Exclusive OR word 2-operand       CPU          CPU       CPU
      XORW3     Exclusive OR word 3-operand       CPU          CPU       CPU

================================================================================
Note 25.0                  FPJ11,KDJ11-A compatibility                No replies
FURILO::JACKSON                                      85 lines  19-AUG-1985 11:35
--------------------------------------------------------------------------------






      +---------------+                                    +-----------------+
      | d i g i t a l |                                    |  uNOTE # 025    |
      +---------------+                                    +-----------------+

                                                                         
      +----------------------------------------------------+-----------------+
      | Title:       FPJ11-AA Compatibility with the       | Date: 28-APR-85 |
      |                    LSI-11/73 (KDJ11-A)             |                 |
      +----------------------------------------------------+-----------------+
      | Originator: Mike Collins                           | Page 1 of 2     |
      +----------------------------------------------------+-----------------+


      Early LSI-11/73 (KDJ11-A) modules are  incompatible  with  the  FPJ11-AA
      floating  point  accelerator.   This MicroNote describes how to identify
      those modules which are compatible and those which  are  not  compatible
      with the FPJ11-AA.

      The following information refers to two identifying numbers.   They  are
      the module variation and the module revision.

      The module variation number is stamped  onto  the  end  of  the  plastic
      handles.  It will be 'M8192', 'M8192-YB' or 'M8192-YC'.

      The module revision number can be  found  on  side  two  of  the  module
      (noncomponent  side)  stamped  into  the plastic handle, or written with
      indelible ink.  This number is updated  as  the  board  is  ECO'd.   The
      designation  is a number followed by the module revision.  e.g.  441 C1,
      indicates module revision C1.

      The first LSI-11/73 module is called a KDJ11-AA and is incompatible with
      the  FPJ11-AA.   The module variation for the KDJ11-AA is M8192, and the
      module revision number is C1.   The  KDJ11-AA  can  be  upgraded  to  be
      FPJ11-AA  compatible.  Contact the local DEC office for more information
      concerning the upgrade procedure.

      Two new options have been created.  The KDJ11-AB is a  module  which  is
      fully  compatible  with  the  FPJ11-AA.   The  module  variation for the
      KDJ11-AB is M8192-YB, and the module revision number is A1 or A2.

      The third option is called a KDJ11-AC and is used for  fully  compatible
      modules  which  have  FPJ11-AAs installed onto the board by Digital.  It
      has a module variation of M8192-YC and the module revision number is  A1
      or  A2.  Therefore a KDJ11-AB becomes a KDJ11-AC by simply installing an
      FPJ11-AA.

                                                                Page 2


      The following table summarizes the above information and should be  used
      as a 'quick check' for FPJ11-AA compatibility.

      +----------+------------+------------+--------------------------+
      | OPTION   |    MODULE  |   MODULE   |     FPJ11 COMPATIBLE?    |
      |          |  VARIATION |  REVISION  |                          |
      +----------+------------+------------+--------------------------+
      | KDJ11-AA |    M8192   |     C1     |   NO (But Upgradeable)   |
      +----------+------------+------------+--------------------------+
      | KDJ11-AB |  M8192-YB  |  A1 or A2  |          YES             |
      +----------+------------+------------+--------------------------+
      | KDJ11-AC |  M8192-YC  |  A1 or A2  | YES (FPJ11-AA Installed) |
      +----------+------------+------------+--------------------------+


                                      CAUTION

              An FPJ11-AA installed on a KDJ11-AA may APPEAR  to  work
              but cache errors and parity errors may occur.

              An MXV11-BF must be  REV  C  to  be  compatible  with  a
              KDJ11-A  with  an FPJ11-AA (KDJ11-AC).  Earlier versions
              of  the  MXV11-BF  are  incompatible   with   KDJ11-ACs.
              KDJ11-As  without  FPJ11-AAs  are  compatible  with  all
              versions of the MXV11-BF.

              The MCV11-D is incompatible  with  KDJ11-ACs.   KDJ11-As
              without  FPJ11-AAs  are  compatible with all versions of
              the MCV11-D.


================================================================================
Note 26.0                  MicroVAX II multicomputing                 No replies
FURILO::JACKSON                                     700 lines  19-AUG-1985 11:36
--------------------------------------------------------------------------------






      +---------------+                                    +-----------------+
      | d i g i t a l |                                    |  uNOTE # 026    |
      +---------------+                                    +-----------------+

                                                                         
      +----------------------------------------------------+-----------------+
      | Title:     The MicroVAX II CPU Multicomputing      | Date: 28-JUN-85 |
      |                        Capability                  |                 |
      +----------------------------------------------------+-----------------+
      | Originator: Mike Collins                           | Page 1 of 12    |
      +----------------------------------------------------+-----------------+


      The MicroVAX II CPU may be configured as an arbiter CPU  or  as  one  of
      three  auxiliary  CPU's.   Therefore it is possible to configure a Q-bus
      system with multiple MicroVAX II CPUs.  This 'multicomputing' capability
      is the topic of this MicroNote.

                            Multicomputing Introduction

      The multicomputing capability  is  a  hardware  design  feature  of  the
      MicroVAX  II.  It allows a maximum of four MicroVAX II CPUs to reside on
      the same Q-bus.  Figure 1 below is a block diagram which shows how 2  of
      a  possible  4 CPUs may be configured on the bus.  One of the processors
      will be the arbiter and the others will be auxiliaries.

                                        NOTE

              There is no shared memory between processors,  therefore
              this  system  should  not  be  considered as symmetrical
              multiprocessing.

      Each processor may use expansion memory modules provided that there  are
      sufficient  Q/CD  slots in the backplane.  See the configuration section
      for more detail on the configuration rules.

             +---------------------+         +---------------------+
             |     +---------+     |         |     +---------+     |
             |     |         |     |         |     |         |     |
           +---------+     +---------+     +---------+     +---------+
           | Arbiter |     |         |     |Auxiliary|     |         |
           |Processor|     | Memory  |     |Processor|     | Memory  |
           |         |     |         |     |         |     |         |
           |         |     |         |     |   #1    |     |         |
           |         |     |         |     |         |     |         |
           +---------+     +---------+     +---------+     +---------+
                |                               |
                |                               |
           -----------------------------------------------------------
                                    Q-bus
           -----------------------------------------------------------

                                                                Page 2



                     Figure 1 - Multicomputing Configuration

                                      CAUTION

              Digital's 32-bit operating systems DO  NOT  support  the
              multicomputing  feature.   Users  who  wish to customize
              their systems to take advantage  of  the  multicomputing
              capability  may  do so but are responsible for designing
              the software system.

      The following topics which are pertinent to  the  multicomputing  design
      will be described in detail:

           1.  MicroVAX II Memory System

           2.  Interprocessor Communications Register

           3.  Arbiter/auxiliary Processor Differences

           4.  Bootstrapping an Auxiliary Processor

           5.  Configuration Rules


                                     REFERENCES

              The  MicroVAX  630  CPU   Module   User's   Guide   (P/N
              EK-KA630-UG)   and  MicroNote  #22  have  more  detailed
              information on all aspects of the MicroVAX  II  CPU  and
              memory system.

                             MicroVAX II Memory System
                             --------------------------

      Before describing the  details  of  the  multicomputing  feature  it  is
      necessary to understand the memory system of a MicroVAX II.

      The memory system of the MicroVAX II is unique.  Unlike  previous  Q-bus
      processors,  the  memory  modules do not communicate to the CPU over the
      Q-bus.  Instead, the communication and transfers occur over a dedicated,
      closely  coupled  interconnect.   This design allows for very fast reads
      and writes to memory (400 nsec).  Not only are the transfers very  fast,
      but  none  of  this CPU-memory activity appears on the Q-bus.  Therefore
      the Q-bus is strictly for I/O.

      Since memory is not directly on the Q-bus it is necessary to  allow  DMA
      devices on the Q-bus to access memory.  This feature is called the Q-bus
      I/O map.  It is a mechanism which maps Q-bus addresses (22-bit  physical
      address)  to  the  local memory system of a MicroVAX II (24-bit physical
      address).  This same concept is used on larger UNIBUS based VAXes.

      When one or more auxiliary processors are added to  a  system,  remember
      that  each  has  its  own local memory system.  Therefore it is intended
      that they will each operate out of their own  memory.   This  design  is

                                                                Page 3


      well  suited  for  applications  which can be easily partitioned between
      multiple processors such that only messages are passed between them.

      It would be possible for a processor to operate out  of  memory  on  the
      Q-bus  but  this  would  be unconventional from a systems standpoint and
      would decrease system performance  significantly.   Digital's  operating
      systems  do not support the use of standard Q-bus memories in a MicroVAX
      II.

      With only one processor on the Q-bus, the system software  has  complete
      control  over  DMA transfers.  The software controls the contents of the
      Q-bus map registers.  First,  it  determines  whether  the  register  is
      enabled  and  second,  if  it  is  enabled,  where the DMA transfers are
      directed in the local memory system.

      In a multiple processor configuration (since each has  its  own  set  of
      Q-bus  I/O  map registers) it is now possible for multiple map registers
      to respond to a single Q-bus address.  It is the responsibility  of  the
      system  software  running on each processor to cooperate and assure that
      one and only one  map  register  will  respond  to  any  Q-bus  address.
      Otherwise  multiple  memory  locations  may  respond and the results are
      indeterminate (i.e.  multiple BRPLYs on the Q-bus for a single address).

      A similar situation occurs if standard Q-bus memories  are  added  to  a
      MicroVAX  II  system.   The  system  software  is  again responsible for
      assuring that for any address on the Q-bus which is 'shared' by a  Q-bus
      memory  board and a Q-bus I/O map register, the map register is disabled
      to allow only a Q-bus memory reply.

      Q-bus memories would not be added to 'typical' systems.   However  there
      are  some  special  applications which may require this capability.  For
      example, a graphics system where the Q-bus memory is the bit  map  of  a
      graphics display.

      On power-up, the MicroVAX II boot ROM will check  for  the  presence  of
      Q-bus  memory  and  clear  the  valid  bits of the corresponding mapping
      registers.  This will prevent the above situation from occurring as long
      as the system software does not alter the state of these valid bits at a
      later time.

                       Interprocessor Communications Register
                       --------------------------------------

      The  interprocessor  communications  register  (ICR)  is   the   primary
      mechanism  of  the  MicroVAX II CPU which enables multiple processors to
      cooperate and reside on the same Q-bus.  Figure 3 describes the ICR  and
      the bit definitions.

      The ICR provides the following four functions:

           1.  Any processor on the bus may interrupt  another  without  using
               the  Q-bus  interrupt  lines.   This  is  done  by  setting the
               appropriate bit in the ICR of the second  processor.   The  CPU
               will then interrupt at IPL 14 (HEX) with an interrupt vector of
               204 (HEX).

                                                                Page 4


           2.  The ICR also has a bit which controls external access to  local
               memory  via  the  Q-bus map.  When set this bit allows external
               devices to access the local memory system.   When  reset,  this
               bit  prevents  the  local  memory system from responding to any
               Q-bus address references.

           3.  If a  processor  is  an  auxiliary  then  the  ICR  provides  a
               mechanism  which  allows  it  to be halted by other CPUs.  This
               feature  is  used  at  power-up  to  coordinate  the  bootstrap
               process.

           4.  Parity errors are identified when one occurs during accesses to
               the MicroVAX II's local memory.


      The address for the ICR is located in the Q-bus I/O page  address  space
      and  may  be  accessed by any device which can become Q-bus master.  The
      ICR is byte-addressable.

      Since it is possible to put a maximum of 4 MicroVAX II CPUs on one Q-bus
      they  each  have their own unique ICR.  Table 1 lists each processor and
      the associated ICR address.

      Table 1 - Interprocessor Communication Register Address Assignments

      +--------------+----------------------+----------------------------+
      | Processor    | 22-bit Octal Address | 32-bit Hexadecimal Address |
      +--------------+----------------------+----------------------------+
      | Arbiter      |      17 777 500      |         2000 1F40          |
      +--------------+----------------------+----------------------------+
      | Auxiliary #1 |      17 777 502      |         2000 1F42          |
      +--------------+----------------------+----------------------------+
      | Auxiliary #2 |      17 777 504      |         2000 1F44          |
      +--------------+----------------------+----------------------------+
      | Auxiliary #3 |      17 777 506      |         2000 1F46          |
      +--------------+----------------------+----------------------------+

                           1  1  1  1  1  1
                           5  4  3  2  1  0  9  8  7  6  5  4  3  2  1  0  
                         +--+-----------------+--+--+--+--+-----------+--+
                         |  |   0 0 0 0 0 0   |  |  |  |  |  0 0 0 0  |  |
                         +--+-----------------+--+--+--+--+-----------+--+
                           |                    |     |  |              |
              DMA QPE  ----+                    |     |  |              |
                                                |     |  |              |
              AUX HLT  -------------------------+     |  |              |
                                                      |  |              |
              DBI IE   -------------------------------+  |              |
              LM EAE   ----------------------------------+              |
                                                                        |
              DBI RQ   -------------------------------------------------+

                   Figure 3 - Interprocessor Communications Register

       

                                                                Page 5


              Bit(s) Mnemonic                   Meaning
       
               <15>   DMA QPE         DMA Q22-Bus Address Space Parity Error. 
                                      This read-only bit is set if Memory System
                                      Error Register bit <04> (DMA QPE) is set.
                                      The DMA QPE bit indicates that a parity
                                      error occurred when an external device (or
                                      CPU) was accessing the MicroVAX II CPU 
                                      local memory.

              <14:09>    -            Unused.  Read as zeros.

               <08>   AUX HLT         Auxiliary Halt. On an auxiliary MicroVAX,
                                      AUX HLT is a read-write bit. When set,
                                      typically by the arbiter CPU, it causes
                                      the on-board CPU to transfer program
                                      control to the Halt Mode ROM Code. On
                                      an arbiter MicroVAX II, AUX HLT is a 
                                      read-only bit which always reads as zero.
                                      It has no effect on arbiter CPU operation.

               <07>      -            Unused.  Read as zero.

               <06>   DBI IE          Doorbell Interrupt Enable. This bit, when
                                      set, enables interprocessor doorbell
                                      interrupt requests via ICR <00>. When the
                                      on-board CPU is Q22-Bus master, DBI IE
                                      is a read-write bit. When an external 
                                      device (or CPU) is bus master, DBI IE
                                      is a read-only bit. DBI IE is cleared 
                                      by power up, by the negation of DCOK and
                                      by writes to the Bus Initialize Register.

               <05>   LM EAE          Local Memory External Access Enable. This
                                      bit, when set, enables external access to
                                      local memory (via the Q22-Bus map). When
                                      the on-board CPU is Q22-Bus master, LM EAE
                                      is a read-write bit. When an external
                                      device (or CPU) is bus master, LM EAE is
                                      a read-only bit. LM EAE is cleared by 
                                      power up, by the negation of DCOK and
                                      by writes to the Bus Initialize Register.

              <04:01>    -            Unused.  Read as zeros.
               

               <00>   DBI RQ          Doorbell Interrupt Request. If ICR <06>
                                      (DBI IE) is set, writing a "1" to DBI RQ
                                      sets DBI RQ, thus requesting a doorbell
                                      interrupt. If ICR <06> is clear, writing
                                      a "1" to DBI RQ has no effect. Writing a
                                      "0" to DBI RQ has no effect. DBI RQ is
                                      cleared when the CPU grants the doorbell
                                      interrupt request. DBI RQ is held clear
                                      whenever DBI IE is clear.

                                                                Page 6


      When a processor is interrupted via its ICR the interrupt vector is  204
      (Hex).  This vector is used when the interrupting device is the arbiter,
      auxiliary  1, auxiliary  2, auxiliary  3, or any device which may become
      Q-bus  master.   Therefore  it  is  the  responsibility of the interrupt
      service routine to determine which device caused the interrupt since the
      same  vector  is  used  no  matter what device set the DBI RQ bit.  This
      interrupt occurs at the same interrupt priority level (IPL) as  IRQ4  on
      the Q-bus.


                                        NOTE

              Following such an interrupt, the MicroVAX  II  sets  the
              IPL  to  14  (Hex).  This is different from what happens
              after  a  standard  Q-bus  interrupt.   When   a   Q-bus
              interrupt  occurs  on IRQ4, the processor raises the IPL
              to  17  (Hex)  and  it  is  the  responsibility  of  the
              interrupt service routine to lower the IPL later on.


                      Arbiter/Auxiliary Processor Differences
                      ---------------------------------------

      There are several differences between arbiter and auxiliary  processors.
      It  is  important  to  understand  these  differences  when  configuring
      multiple processors into a system.

           1.  The arbiter MicroVAX II arbitrates bus mastership in accordance
               with  the  Q22-Bus  DMA  protocol.   The  arbitration  logic is
               disabled on an auxiliary MicroVAX II.

           2.  Both  the  arbiter  and  auxiliary  MicroVAX  II  request   bus
               mastership via the Q22-Bus DMA Request protocol.

               a.  They both assert BDMR on the Q22-Bus.

               b.  The arbiter MicroVAX II receives DMGI from its  arbitration
                   logic.   But  an  auxiliary  receives DMGI from its Q22-Bus
                   BDMGI pin.

               c.  Only the auxiliary MicroVAX II actually  asserts  BSACK  on
                   the Q22-Bus.


           3.  The arbiter MicroVAX II asserts the Q22-Bus BINIT  signal  when
               DCOK  is  negated  and  when its CPU software writes to its Bus
               Initialize Register.  An auxiliary MicroVAX  II  never  asserts
               Q22-Bus BINIT, but receives BINIT and uses it to initialize the
               MicroVAX chip and to clear all  internal  registers  which  are
               cleared by the negation of DCOK.

           4.  The  physical  address  of  the  Interprocessor   Communication
               Register  is  different  for  each  of  the  four  MicroVAX  II
               arbiter/auxiliary configurations.

                                                                Page 7


           5.  An auxiliary MicroVAX II can be halted by setting bit <08> (AUX
               HLT)  of  its  Interprocessor  Communication  Register.   On an
               arbiter MicroVAX II this feature is disabled and AUX HLT  is  a
               read-only bit which always reads as zero.

           6.  The CPU halts are controlled by the external connector HLT  ENB
               input.   However,  the external halts which are affected differ
               somewhat for the arbiter and auxiliary MicroVAX II modules.  If
               the HLT ENB signal is asserted (low) the a MicroVAX II CPU will
               halt and enter the console program if:

               a.  The program executes a halt instruction in kernel mode.

               b.  The console detects a break character.

               c.  Arbiter CPU only - the Q-bus halt line is asserted.

               d.  Auxiliary  CPU  only  -  the  Interprocessor  Communication
                   Register AUX HLT bit is set.

               If the HLT ENB signal is negated then:

               a.  The halt line and break character are ignored and  the  ROM
                   program  responds  to  a  halt instruction by restarting or
                   rebooting the system.

               b.  If the MicroVAX  CPU  is  an  auxiliary,  the  ROM  program
                   responds  to  the  assertion  of  the  ICR  AUX  HLT bit by
                   rebooting.

               The state of the HLT ENB bit can be read by  software  via  the
               Boot and Diagnostic Register.

           7.  Each  arbiter  or  auxiliary  MicroVAX  II  module  can   field
               interrupt  requests  from  its interval timer, from its console
               device, and from its interprocessor doorbell.  Only the arbiter
               MicroVAX II can field interrupts from Q22-Bus interrupt request
               lines IRQ7-4.

           8.  The arbiter asserts BIAKO on the Q22-Bus when it responds to  a
               Q22-Bus  interrupt  request.  An auxiliary asserts BIAKO on the
               Q22-Bus when it receives the assertion of  BIAKI  in  order  to
               pass it through to devices after it.

           9.  Although both the arbiter and  auxiliary  MicroVAX  II  modules
               contain   the  same  time-of-year  clock  and  battery  back-up
               circuitry, it is assumed that the auxiliary will be  configured
               without  batteries  and  that  its clock will never actually be
               enabled.  This configuration will ensure a single time base for
               the  system.   If  an  auxiliary  needs to set its time-of-year
               clock it can do so by referencing the arbiter's clock.

          10.  An arbiter processor can bootstrap from a  variety  of  devices
               but  an  auxiliary  will  always  boot  using the ROM bootstrap
               protocol.  See the following section for a detailed description

                                                                Page 8


               of the bootstrap process.


                        Bootstrapping an Auxiliary Processor
                        ------------------------------------

      Since  there  are  distinct  differences  between  the   operation   and
      capabilities  of  arbiter  and  auxiliary processors, it is necessary to
      bootstrap them differently.  An  arbiter  processor  bootstraps  in  the
      conventional  manner  from one of several devices but an auxiliary boots
      using only one method.

      On power-up both processors initialize themselves and perform some  self
      tests.  At this point the primary bootstrap (VMB) begins to execute.  An
      arbiter processor may bootstrap from any one of the following devices:

           1.  DU type device (RX50, RDxx, RC25 or RAxx)

           2.  TK50 tape

           3.  ROM bootstrap protocol

           4.  Ethernet (DEQNA)


      An auxiliary processor will not attempt  to  boot  from  disk,  tape  or
      ethernet.   It will always boot via the ROM bootstrap protocol, which is
      described below.

      In order to  synchronize  the  bootstrap  process,  after  power-up  and
      initialization  an auxiliary processor will not boot until it is allowed
      to do so by the arbiter.  The controlling device is not required  to  be
      the  arbiter,  it  could be another auxiliary or DMA device which is bus
      master, but it is the most logical point of control.

      The following steps summarize the bootstrap procedure for a system  with
      an arbiter and one (or more) auxiliaries:

           1.  Both types of processors initialize themselves after power-up.

           2.  Self-diagnostics execute to check out  major  sections  of  the
               CPU.

           3.  The arbiter boots from one of  the  four  device  types  listed
               above.

               a.  While the arbiter is booting the  auxiliary  completes  its
                   diagnostics and waits to start its bootstrap process.

               b.  The auxiliary clears the valid bit in each of its Q-bus map
                   registers  to  prevent  accidental transfers to or from its
                   local memory.

                                                                Page 9


               c.  The auxiliary loops doing nothing until the AUX HLT bit  in
                   its  ICR is cleared.  When this bit is finally cleared, the
                   auxiliary boots via the ROM bootstrap protocol.


           4.  Somewhere in the system the appropriate data structure has been
               created  to  allow  the auxiliary to boot via the ROM bootstrap
               protocol.  This can be done several ways:

               a.  The bootstrap code is actually in ROM on an MRV11-D module.

               b.  The bootstrap code is loaded into non-volatile RAM.

               c.  The arbiter CPU loads the bootstrap code into its own local
                   memory  then  sets up some Q-bus map registers so that this
                   data can be seen by the auxiliary CPU over the Q-bus.  This
                   method is the most flexible since the bootstrap code can be
                   changed easily.


           5.  When the arbiter is ready and  knows  auxiliary  boot  code  is
               available, it allows the auxiliary CPU to bootstrap by clearing
               the AUX HLT bit in its ICR.

      ROM Bootstrap Protocol.
      To locate a PROM bootstrap, VMB searches the Q22-bus address range  from
      high  to low addresses by page (512 bytes per page) looking for readable
      memory.  If the first six longwords of any such page  contains  a  valid
      PROM  "signature  block"  (see figure 4), VMB passes control directly to
      the bootstrap code in the PROM, it does not copy the PROM code to  local
      memory for execution as it does for all other secondary bootstraps.

      Note that while defined as an MRV11 PROM or  equivalent  bootstrap,  VMB
      does not actually require that the signature block or the bootstrap code
      be in PROM.  It could be in ROM, nonvolatile RAM or it could  be  loaded
      into  another  MicroVAX II's RAM and mapped to the Q22-bus thus enabling
      an auxiliary to see it.


      RB:
             +---------------+---------------+---------------+---------------+
      +  0:  |   check byte  |  any value    |       0       |    18 (hex)   |
             +---------------+---------------+---------------+---------------+
      +  4:  |           any value           |       1       |       0       |
             +-------------------------------+---------------+---------------+
      +  8:  |                     size of PROM in pages                     |
             +---------------------------------------------------------------+
      + 12:  |                          must be zero                         |
             +---------------------------------------------------------------+
      + 16:  |             offset into PROM to start execution               |
             +---------------------------------------------------------------+
      + 20:  |               sum of previous three longwords                 |
             +---------------------------------------------------------------+

                       Figure 4:  PROM Bootstrap Memory Format

                                                               Page 10



             RB + 0:         This byte must be 18 (hex).

             RB + 1:         This byte must be 0.

             RB + 2:         This byte may be any value.

             RB + 3:         This byte must be the ones complement of the sum
                             of the previous three bytes.

             RB + 4:         This byte must be zero.

             RB + 5:         This byte must be 1.

             RB + 6:         These two bytes may be any value.

             RB + 8:         This longword contains the size in pages of  the
                             PROM.

             RB + 12:        This longword must be zero.

             RB + 16:        This longword contains the byte offset into  the
                              PROM where execution is to begin.

             RB + 20:        This entry is a longword containing the  sum  of
                             the previous three longwords.

                                Configuration Rules
                                -------------------

      In order to configure multiple MicroVAX II CPUs onto one bus,  4  issues
      must be addressed:

           1.  Q-bus slot requirements for the CPU and MS630 memory boards.

           2.  Compatible enclosures or boxes.

           3.  Bus termination.

           4.  Using a PDP-11 CPU as the Arbiter.


      1. Q-bus slot requirements.

      To operate properly both the MicroVAX II CPU and  all  versions  of  the
      MS630 memory modules MUST be inserted in Q-bus slots which feature Q-bus
      signals on the A/B side and the CD interconnect on the  C/D  side.   The
      MicroVAX II CPU and any expansion memory modules must all be adjacent in
      the backplane.

                                      WARNING

              The MicroVAX II CPU WILL be damaged if inserted  into  a
              slot which has Q-bus signals on the C/D side.

                                                               Page 11


      2. Compatible enclosures or boxes.

      Since Q/CD slots are required, there are only  4  enclosures  which  are
      compatible with these modules.  They are:

           a.  BA23 (8 slots total, first 3 are Q/CD)

           b.  BA123 (12 slots total, first 4 are Q/CD)

           c.  BA11-S (9 slots total, all 9 are Q/CD)

           d.  BA11-N (9 slots total,  all  9  are  Q/CD)  This  enclosure  is
               electrically compatible but since it is older it is only 18-bit
               compatible and has not been tested  for  FCC  compliance  in  a
               system  package.   Since  the  BA11-S  is  the  22-bit, updated
               version, the BA11-N enclosure is not recommended.


      3. Bus termination.

      Each MicroVAX II processor has 240 ohm termination.  When multiple  CPUs
      are   placed   into  one  system,  take  care  to  abide  by  the  Q-bus
      specification  regarding  termination  and  configuring   multiple   box
      systems.

                                     REFERENCE

              Reference  MicroNote  #29,  entitled  'Q-bus   Expansion
              Concepts'  and  appendix  A of the Microsystems Handbook
              (P/N EB-26085-41) for more information concerning  Q-bus
              configuration rules.

      The BA11-S enclosures are best suited for  multiple  CPUs  because  they
      have  backplanes  with the Q22/CD configuration in all slots.  Therefore
      multiple CPUs and expansion memory can be accommodated most easily.  The
      other  potential  boxes, the BA23 and BA123, are not as flexible because
      they only have 3 and 4 Q22/CD slots respectively.

      When using multiple MicroVAX II CPUs in one system the goal should be to
      configure  each  backplane  with  120  ohm  termination if the number of
      backplanes used is one or two.  In the three backplane  case,  only  the
      first  and  third  backplanes  should  have  120  ohm termination.  This
      implies that no MicroVAX II CPUs should be configured  into  the  middle
      backplane  of  a three backplane system (three backplanes is the maximum
      number allowed for the Q-bus).

      The following configurations assume the BA11-S enclosures will be used.

      Two CPU System:

      A two CPU system  is  the  easiest  case  to  configure.   As  mentioned
      earlier,  each  CPU  has 240 ohm termination.  With two CPUs in the same
      backplane, the proper overall termination of 120 ohms is achieved.   The
      first CPU has 240 ohms in parallel with 240 ohms on the second CPU which
      is 120 ohms, assuming there is no termination on the backplane (which is

                                                               Page 12


      true for the BA11-S enclosure).

      Three CPU System:

      A three CPU system should be configured in 2 backplanes to maintain  120
      ohm  termination  in each.  The first 2 CPUs should be configured in the
      first box which terminates that backplane properly as in the case above.
      The  third CPU should be placed in the second backplane.  The modules of
      the expansion cable set must be terminated differently.  The  module  of
      the  expansion cable set in the first backplane should add no additional
      termination to the system while  the  module  in  the  second  backplane
      should  be  terminated with 240 ohms.  Therefore the second backplane is
      also terminated in 120 ohm (240 on the processor in parallel with 240 on
      the expansion module).

      Four CPU System:

      A four CPU system should also be configured in 2 backplanes.  The  first
      backplane  will  have  2  CPUs  for  120  ohm termination and the second
      backplane will also have 2  CPUs  for  120  ohm  termination.   But  the
      expansion  cable  set connecting the two backplanes will not be the same
      as in the three CPU system.  In this case there should be no termination
      on either of the expansion modules.

      These same basic rules should be followed if the BA23 enclosure is used.
      However  the  configurations  become  more  constrained  because  of the
      relatively few number of Q/CD slots.   The  configuration  also  becomes
      more  complicated  because  the  BA23  has  built  in termination on the
      backplane (termination resistors are socketed and therefore removable).

      4. Using a PDP-11 CPU as the Arbiter.

      The arbiter can be a Q-bus PDP-11 CPU as well as a MicroVAX II CPU.   In
      this configuration only the 3 auxiliary MicroVAXes could be added to the
      system.  Although there are tremendous architectural differences between
      a PDP-11 and MicroVAX CPU, they both perform the arbiter function on the
      Q-bus and therefore such a configuration is possible.  Two issues  arise
      from this 'mixed' configuration.

      1.  All Q-bus PDP-11s to-date have their main memory on the  Q-bus.   In
          order  to  talk to an auxiliary MicroVAX CPU's local memory, part of
          the Q-bus physical address space must be  reserved  for  mapping  to
          that local memory.

      2.  The PDP-11 processor will not have an  interprocessor  communication
          register  because  that  feature  is  unique to the MicroVAX II CPU.
          Therefore, if  it  is  necessary  to  have  the  capability  for  an
          auxiliary CPU to interrupt the arbiter, an additional device must be
          added to the system.  This device will look like the  interprocessor
          communication  register  for  an  arbiter  and  will convert and ICR
          interrupt  into  a  conventional  Q-bus  interrupt  (there   is   no
          capability  which  allows  an auxiliary to interrupt the arbiter via
          the standard Q-bus interrupt protocol).


================================================================================
Note 27.0                  Using Messages with VAXELN                 No replies
FURILO::GIORGETTI                                   292 lines  21-AUG-1985 23:04
--------------------------------------------------------------------------------


      +---------------+                                    +-----------------+
      | d i g i t a l |                                    |  uNOTE # 027    |
      +---------------+                                    +-----------------+

                                                                   
      +----------------------------------------------------+-----------------+
      | Title: USING MESSAGES WITH VAXELN                  | Date: 19-JUN-85 |
      +----------------------------------------------------+-----------------+
      | Originator: Christopher DeMers                     | Page 1 of 5     |
      +----------------------------------------------------+-----------------+


      This  Micronote  discusses  how  VAXELN  uses  messages  for   inter-job
      communication.   Included  is  an  overview of the message architecture,
      benchmark data from MicroVAX II  configurations  and  a  sample  program
      illustrating the message handling technique.

      In a VAXELN application, every job(Pascal,C or Macro-32 program)  has  a
      unique  and protected virtual address space.  Within a single processor,
      the kernel separates each job's virtual  address  space  using  the  VAX
      memory  management  hardware.   Within  a  network,  each  job's virtual
      address space is separated by virtue of the fact that the jobs may exist
      in the memories of different computer systems.

      One of the principal reasons for dividing an application  into  separate
      jobs  is  to  aid  the migration and distribution of the jobs within the
      network.   In  order  for  the  jobs  to  work  together  on  the   same
      application, they must be able to share data, but the only way of moving
      data from the memory of one processor to another  in  a  network  is  by
      packaging  the  data  in a message and directing the network hardware to
      move the message to the destination memory.

      To make the network movement of data between jobs the  same  as  in  the
      non-network  case,  message  passing is the principal means of inter-job
      communication.  The kernel provides a number of facilities  to  make  an
      efficient and transparent means of communication.

      The VAXELN MESSAGE object describes a block of memory that can be  moved
      from  one job's virtual address space to another's.  The block of memory
      is called 'message data' and is allocated dynamically by the kernel from
      physically  contiguous, page-aligned blocks of memory.  A MESSAGE object
      and its  associated  message  data  are  both  created  by  calling  the
      CREATE_MESSAGE kernel service.

      Message data is mapped into a job's P0 virtual address space, so  it  is
      potentially accessible to all the processes in the job.  If a message is
      sent to a job on the sending job's local node, the kernel unmaps the






                                  211

uNOTE # 027
Page 2 of 5


      message data from the sending job's virtual address space and remaps  it
      into  the  receiver's  space.   Instead  of  moving the data, Page Table
      Entries are remapped, resulting in very fast message transmission  time.
      If  a  message  is  sent  to  a remote node, the kernel again unmaps the
      message data, but it remaps  it  into  the  appropriate  network  device
      driver  job  to  send  the  message  to  the remote system.  The reverse
      operations then cause the message data to be remapped in the  receiver's
      space.

      The code necessary to send a message local to  a  machine  or  over  the
      network  is  identical  in  both  cases.   A  port  name table parameter
      (NAME$LOCAL or NAME$UNIVERSAL) allows the programmer to define local  or
      remote  ports.  The kernel maintains the local name list, while the name
      table for network-wide names is maintained by the  name  server.   Names
      known  throughout  the  network are guaranteed to be unique.  Thus, jobs
      can initially be executed on one processor and later be segmented to run
      on multiple processors without modification of the program.

      Datagrams and Circuits
      ----------------------

      Messages can be used two ways to transmit data:

      - One process can obtain the value of a  port  anywhere  in  the  system
      (including  other  jobs) or in a different system running on a different
      Ethernet node.  The process can send the port a message  with  the  SEND
                                     datagram
      procedure.  This is called the datagram method.

      - Any two ports (usually in different jobs) can  be  bound  together  to
               circuit
      form  a  circuit.   In  this  case,  having established the circuit, the
      sending process has one port of its own bound  to  another  port,  which
      usually  is  in  a  different  job  or on a different network node.  The
      sender sends the message to its own port, and it is routed automatically
      to  the  other  port  in  the  circuit.   Processes can both send to and
      receive from a circuit port.

      In the datagram method, as well as in the circuit method, a process  can
      use  the  WAIT  procedures  to  wait for the receipt of a message on the
      specified port.

      The datagram method requires no connection sequence as in circuits,  but
      cannot guarantee that a message is actually received at the destination.
      However, it does guarantee that received messages are correct.

      At the cost of setting up and handling a  circuit  connection,  circuits
      offer several advantages over the basic datagram method:

        Guaranteed delivery
      - Guaranteed delivery.  The circuit method guarantees  that  either  the
      message  arrives  at the destination port regardless of its location, or
      that the sender is notified that the message could not be delivered.



                                  212

                                                           uNOTE # 027
                                                           Page 3 of 5


        Flow control
      - Flow control.  You can prevent a sending process from sending too many
      messages  to  a  slower  receiving process.  If a port is connected in a
      circuit and is full, the sender is put into the waiting state until  the
      port  is  no  longer full (you can override this default).  The implicit
      waiting performed by the SEND  procedure  evens  the  flow  of  messages
      between  the  transmitting  process  and  the  receiving process without
      having to explicitly program for the condition.   Furthermore,  circuits
      guarantee  the sequence of message delivery as no other unconnected port
      can send a message to a connected port.

        Segmentation
      - Segmentation.  Message can have any length (datagrams are  limited  to
      approx.   1500  bytes),  and, if the transmission is across the network,
      the network services will divide the message into segments of the proper
      length,  transmit  the  segments  and reassemble them at the destination
      node.

        User interface
      - User interface via Pascal I/O routines.  The  OPEN  procedure  permits
      you to 'open' a circuit as if it were a file and to use the I/O routines
      such as READ and WRITE to transmit messages.

      There is no performance penalty with circuits for  messages  transmitted
      over  the  same network node and very little over the network.  For full
      generality, programs should assume that the sending and  receiving  jobs
      may  be  distributed  on different nodes in a network.  Circuits are the
      preferred means of sending message in almost every practical case.

      Expedited Messages
      ------------------

      An expedited message bypasses the normal flow-control mechanism and  can
      be  sent  even  if  the receiving port already has its maximum number of
      messages.  The message is received by the port before  any  normal  data
      messages.   The  size of an expedited message is limited to a maximum of
      16 bytes.

      Monitoring Network Integrity
      ----------------------------

      Circuits can be used as a method for monitoring the status of a  network
      connection.   In  addition  to  the  circuit  used to send data, another
      process could establish a secondary circuit with a process in  a  remote
      node.   Neither  process  sends data, they only WAIT on their respective
      ports.  When a node fails,  the  circuit  is  broken  and  the  WAIT  is
      satisfied.   At  this point exception handling routines could be invoked
      to handle this condition.  This allows the programmer  to  separate  the
      error handling code from the message transmission code.







                                  213

uNOTE # 027
Page 4 of 5


      Connecting with VAX/VMS nodes
      -----------------------------

      The VAXELN procedure CONNECT_CIRCUIT can be used to request a connection
      with  a  VAX/VMS program on the same DECnet network.  Instead of using a
      port as the destination for the connection, a VMS  node  and  an  object
      name  (program  name  on  the VMS node) is used.  The program on the VMS
      node completes the connection by opening the "file" SYS$NET.

      A VAX/VMS node may also request a connection by specifying a  node  name
      and port name in the file portion of an OPEN statement.  The VAXELN node
      complete the connection by issuing an ACCEPT_CIRCUIT statement.

      Performance Data
      ----------------

      MicroVAX II, 5MB memory, connection via circuit
      All times in microseconds (us).
      Throughput in thousand bytes/second(KB/s).

                                             Delivery                
      Message Size|Create|Delete|  One  Machine |  Two Machines          
       (bytes)    | Time | Time |Time|Throughput| Time|Throughput
      ------------+------+------+----+----------+-----+----------
         0        |  131 |  144 |1094|   N/A    | 4479|   N/A 
       512        |  361 |  255 |1611|   318    | 5271|    97
      2048        |  450 |  274 |1885|  1087    | 8675|   236
      8192        |  481 |  394 |2139|  3830    |27538|   298

























                                  214

                                                           uNOTE # 027
                                                           Page 5 of 5


      PROGRAM msgsend(INPUT,OUTPUT);
      {++
      { This program connects a circuit to the global name 'msgrecv',
      { sends a message to the receiver and waits for a reply.
      {--}
      VAR  
           send_port,reply_port: PORT;
           msg,reply:            MESSAGE;
           msg_data_ptr:         ^VARYING_STRING(20);
           reply_data_ptr:       ^VARYING_STRING(10);

      BEGIN
        CREATE_PORT(send_port);
        CONNECT_CIRCUIT(send_port, destination_name := 'msgrecv');
        CREATE_MESSAGE(msg,msg_data_ptr);
        msg_data_ptr^ := 'message from msgsend';
        SEND(msg,send_port);
        WAIT_ANY(send_port); 
        RECEIVE(reply,reply_data_ptr,send_port);
        DELETE(reply);
        DISCONNECT_CIRCUIT(send_port);
      END; { program msgsend }


      PROGRAM msgrecv (INPUT,OUTPUT);
      {++
      { This module runs a receive program that accepts a circuit,receives 
      { a message and sends back a reply.
      {--}

      VAR  
           reply_port:     PORT;
           nam:            NAME;
           msg,reply:      MESSAGE;
           msg_data_ptr:   ^VARYING_STRING(20);
           reply_data_ptr: ^VARYING_STRING(20);

      BEGIN
        CREATE_PORT(reply_port);
        CREATE_NAME(nam,'msgrecv',reply_port,table := name$universal);
        INITIALIZATION_DONE;
        ACCEPT_CIRCUIT(reply_port);
        WAIT_ANY(reply_port);
        RECEIVE(msg,msg_data_ptr,reply_port);
        DELETE(msg);
        CREATE_MESSAGE(reply,reply_data_ptr);
        reply_data_ptr^ := 'reply';
        SEND(reply,reply_port);
      END; { program msgrecv }




                                  215

================================================================================
Note 28.0                MSV11-Q/M/J Memory Comparisons               No replies
FURILO::GIORGETTI                                   175 lines  21-AUG-1985 23:07
--------------------------------------------------------------------------------



      +---------------+                                    +-----------------+
      | d i g i t a l |                                    |  uNOTE # 028    |
      +---------------+                                    +-----------------+

                                                                   
      +----------------------------------------------------+-----------------+
      | Title: MSV11-Q/M/J MEMORY COMPARISONS              | Date: 28-JUN-85 |
      +----------------------------------------------------+-----------------+
      | Originator:  JACK TOTO                             | Page 1 of 3     |
      +----------------------------------------------------+-----------------+

      This MicroNote will compare three  of  Digital  Equipment  Corporation's
      newest memory modules.  Following the description of each memory module,
      is a chart which, list the differences between these memories.

      MSV11-Q
      -------
      The MSV11-Q has three versions,  the  MSV11-QA,  the  MSV11-QB  and  the
      MSV11-QC.  The MSV11-QA (M7551-A) is a quad size Q-bus memory module and
      contains 1MB of MOS RAM using 64K bit parts.  The MSV11-QA has two  etch
      revisions  which  must  be  checked  when  configuring the module into a
      system.  The two revisions are the C rev and the A rev,  both  of  these
      revisions  are  discussed  in  the  Users  Guide  (EK-MSV1Q-UG)  and  in
      Micronote # 030.  The second version of  the  MSV11-Q  is  the  MSV11-QB
      (M7551-B)  which  is  a  half  populated  quad  size Q-bus memory module
      containing 2MB of MOS RAM using 256K bit parts.  The last version of the
      MSV11-Q  is  the  MSV11-QC which is a fully populated MSV11-QB quad size
      Q-bus memory module containing 4MB of MOS  RAM  using  256K  bit  parts.
      Both  the  MSV11-QB  and  the  MSV11-QC use the MSV11-QA printed circuit
      board, however that board is ECOed to etch level C.


      MSV11-J
      -------
      The MSV11-J has four versions, the MSV11-JB and MSV11-JC which are  used
      in  the  PDP-11/84 UNIBUS systems and the MSV11-JD and MSV11-JE are used
      in either the MicroPDP-11/83 Q-bus  systems,  or  the  PDP-11/84  UNIBUS
      systems.   All four modules use ECC memory for error correction, as well
      as using 256K bit MOS RAM parts on either a half or fully populated quad
      size module.

                                    NOTE:
                                    -----
               NONE OF THE FOUR MSV11-J  MODULES  CAN BE PLACED  IN A Q/Q
               BACKPLANE SLOT. IF THIS IS ATTEMPTED PERMANENT DAMAGE WILL 
               BE DONE TO THE BOARDS AND TO THE SYSTEM.

      The MSV11-JB (M8637-BA) is a half populated quad size PMI memory  module
      containing  1MB  of  memory.   The  second version of the MSV11-J is the
      MSV11-JC (M8639-CA), this is a fully populated MSV11-JB  quad  size  PMI
      memory  module  containing  2MB of memory.  These two modules can not be
      used in a Q-bus system due to gate array incompatibilities, and can only

                                  217

uNOTE # 028
Page 2 of 3


      be  used  in  PDP-11/84  systems  which use the UNIBUS/PMI bus interface
      (KTJ11-A).  The third version of the MSV11-J is the MSV11-JD  (M8639-DA)
      which  is a half populated quad size PMI memory module containing 1MB of
      memory.  The last version of the MSV11-J  is  the  MSV11-JE,  (M8639-EA)
      which  is  a  fully  populated  MSV11-JD  quad  size  PMI  memory module
      containing 2MB of memory.  These last  two  modules  can  be  used  with
      either  the MicroPDP-11/83 system which uses the Q-bus/PMI bus interface
      or  the  PDP-11/84  system  which  was  mentioned  above.   For  details
      reference the PMI protocol Micronote # xxx.

      Although the MSV11-JD and MSV11-JE are PMI memories they can be used  in
      two other Q-bus configurations.
        1. If either of these two memories are used in slots 1 and/or 2 of 
           a Q/CD backplane  such  as the  H9276  (BA11-S  box) or in  the 
           MicroPDP-11 BA23 backplane, and with the standard 15MHZ KDJ11-B 
           cpu (non-fpj compatible) in slot 3, the system will perform PMI 
           memory cycles. In the case of BA23 backplanes, a maximum of two 
           memory modules may be used in slots ahead of the processor, with 
           a minimum of one memory module in front of the processor  still 
           functioning as  PMI memory. In the case  of the H9276 backplane 
           a number of MSV11-JD/JE memory modules may be used ahead of the 
           processor bringing the system to a full 4MB of PMI memory.

        2. If in a Q/CD or BA23 backplane the memories reside in slots 2&3 
           with  either of  the  KDF11 or KDJ11  processors  in the slot 1 
           the MSV11-J  memories will respond as standard  Q-bus  memories, 
           performing normal Q-bus and block mode memory cycles. This  use 
           of the MSV11-J  memories is   also  true for  the MicroVAX  cpu. 
           However the  fact that  the MicroVAX I cpu is a two   board set 
           requires a slightly different configuration. Slots 1&2  will be 
           used  for the MicroVAX I cpu boards with only  one memory  card 
           used, that being  located in slot 3 for the  BA23 backplane and 
           one or more memory cards being used for other  Q/CD  backplanes.
           The only constraint with either of the second configurations is 
           that  in the BA23  or  other Q/CD  backplanes no module  may be 
           placed  adjacent  to  the MSV11-J  that  uses pins  in  the  CD 
           connector. Instead leave an empty slot between  the MSV11-J and 
           this option. An option  which does not use  the CD interconnect 
           may  be placed adjacent to the MSV11-J. 


      MSV11-M
      -------
      The MSV11-M has two  versions;  the  MSV11-MA  and  the  MSV11-MB.   The
      MSV11-MA  (M7506-AA)  is a half populated dual sized Q-bus memory module
      which contains 0.5MB of MOS RAM using 256K parts.   The  second  version
      the  MSV11-MB  (M7506-BA)  is  a  fully populated dual size Q-bus memory
      module containing 1MB of MOS RAM using 256K parts.





                                  218

                                                           uNOTE # 028
                                                           Page 3 of 3




                             MEMORY COMPARISON TABLE
                             -----------------------
      +-----------------------------------------------------------------------+
      |ATTRIBUTE     | MSV11-QA/QB/QC     |   MSV11-MA/MB  | MSV11-JB/JC/JD/JE|
      +--------------+--------------------+----------------+------------------+
      |MEMORY SIZE   | 1MB, 2MB, 4MB      |   0.5MB, 1MB   |   1MB, 2MB       |
      +--------------+--------------------+----------------+------------------+
      |FORM FACTOR   |   QUAD             |    DUAL        |    QUAD          |
      +--------------+--------------------+----------------+------------------+
      |SYSTEM SIZE   |   Q18/Q22          |    Q18/Q22     |   PMI/CD  ONLY   |
      +--------------+--------------------+----------------+------------------+
      |BLOCK MODE    |   YES              |    YES         | YES  (JD/JE ONLY)|
      +--------------+--------------------+----------------+------------------+
      |BLOCK MODE    |   YES FOR REV-A    |       NO       |       NO         |
      |CONFIGURABLE  |   NO FOR REV-C     |(DEFAULT OPTION)| (DEFAULT OPTION) |
      +--------------+--------------------+----------------+------------------+
      |AC BUS LOADS  |   2.4              |    2.0         |    2.5           |
      +--------------+--------------------+----------------+------------------+
      |DC BUS LOADS  |   1.0              |    1.0         |    0.5           |
      +--------------+--------------------+----------------+------------------+
      |AMPS @ +5 VDC |      TYP    MAX    |     TYP   MAX  |        TYP  MAX  |
      |              | QA   2.4    3.99   | MA  2.19  3.11 | JB/JD  1.5  3.94 |
      |(ACTIVE ONLY) | QB   2.3    3.59   | MB  2.22  3.34 | JC/JE  1.7  4.29 |
      |              | QC   2.5    4.30   |                |                  |
      +--------------+--------------------+----------------+------------------+
      |AMPS @ +12VDC |            NO +12V SUPPLY  NEEDED                      |
      +--------------+--------------------+----------------+------------------+
      |WATTS         |      TYP    MAX    |     TYP   MAX  |        TYP  MAX  |
      |              | QA   12.0   20.95  | MA  11.0  16.3 | JB/JD  7.5  19.7 |
      |(ACTIVE ONLY) | QB   11.5   18.85  | MB  11.1  17.5 | JC/JE  8.5  21.5 |
      |              | QC   12.5   22.58  |                                   |
      +--------------+--------------------+----------------+------------------+
      |MEMORY ERROR  |   PARITY           |     PARITY     |     ECC          |
      |CORERECTION   |                    |                |                  |
      +--------------+--------------------+----------------+------------------+
      |BATTERY BACKUP| YES FOR REV-C      |     YES        |     YES          |
      |SUPPORT       | NO FOR REV-A       |                |                  |
      +--------------+--------------------+----------------+------------------+
      |DIAGNOSTICS   |CVMSAA FOR PDP11s   |     SAME       |     CVMJA0       |
      |              |EHXMS FOR MICROVAX  |     SAME       |                  |
      +--------------+--------------------+----------------+------------------+
      |MAINTENANCE   |     MP01931        |     MP02053    |     MP02056      |
      |PRINTSET      |                    |                |                  |
      +--------------+--------------------+----------------+------------------+
      |USER GUIDE    |  EK-MSV1Q-UG       | EK-MSV1M-UG    | EK-MSV1J-UG      |
      +--------------+--------------------+----------------+------------------+





                                  219

================================================================================
Note 29.0                   Q-bus Expansion Concepts                  No replies
FURILO::GIORGETTI                                   292 lines  21-AUG-1985 23:09
--------------------------------------------------------------------------------


      +---------------+                                    +-----------------+
      | d i g i t a l |                                    |  uNOTE # 029    |
      +---------------+                                    +-----------------+

                                                                   
      +----------------------------------------------------+-----------------+
      | Title: Q-bus Expansion Concepts                    | Date: 24-Jun-85 |
      +----------------------------------------------------+-----------------+
      | Originator: Charlie Giorgetti                      | Page 1 of 5     |
      +----------------------------------------------------+-----------------+


      This   MicroNote   discusses   the   expansion   (multiple   backplanes)
      characteristics of a Q-bus system.  Understanding this topic is critical
      when configuring a system.  The loading, impedance, and single backplane
      characteristics  of  the  Q-bus and some assumptions and definitions are
      discussed prior to defining the expansion rules.  The specific  products
      used in expansion are not discussed here.

                     Viewing the Q-bus for Electrical Analysis
                     Viewing the Q-bus for Electrical Analysis
                     -----------------------------------------

      When analyzing the Q-bus from a configuration rule standpoint the bus is
      treated as a transmission line.  The reasons for this:

       o  The Q-bus has voltage sources at both ends of a conductor.

       o  When one of these voltage sources (typically  a  processor)  changes
          state  (a  control/data signal transitioning) its effect is not seen
          instantaneously at the other end, but after some propagation  delay.
          The  propagation delay could result in signal reflections on the bus
          if it is not properly terminated or expanded.


                                Loading Definitions
                                Loading Definitions
                                -------------------

      The  Q-bus  specification  defines  two  loading  parameters  used  when
      configuring a system.  These parameters, AC and DC loading, indicate the
      load presented to the system by individual elements  on  the  Q-bus.   A
      system  element is either a Q-bus module or a backplane.  The definition
      of AC and DC loads are:

       o  AC loading is the capacitive loading added to a Q-bus  system  by  a
          Q-bus  module  or  by the backplane itself.  Capacitive loading will
          cause bus reflections and impact signal rise and fall  times.   This
          is  measured  at the time the module or backplane is being designed.
          An AC load is 9.35 pf/signal line.

       o  DC loading is the amount of leakage current presented to  the  Q-bus
          by  an  undriven signal line on a Q-bus module.  This information is
          obtained  from  the  specification  data  for  Q-bus   drivers   and

                                  221

uNOTE # 029
Page 2 of 5


          receivers.  A DC load is defined as 210 uA.

      The number of AC and DC loads allowed in a configuration is dictated  by
      the  number  of  backplanes  and  the  termination  used.   This will be
      discussed in later sections of this MicroNote.

      The AC and DC values for Q-bus modules and backplanes can  be  found  in
      either   the  Microcomputer  Products  Handbook  (#EB-26078-41)  or  the
      Microcomponents Configuration Guide (#EB-27318-68).

                              Backplane Configurations
                              Backplane Configurations
                              ------------------------

      The rules that govern Q-bus system  implementation  must  be  viewed  in
      light  of  the  backplane  arrangement  used.   The  two supported Q-bus
      configurations are:  single backplane or multiple backplanes.   How  the
      Q-bus   is   treated  as  a  transmission  line  varies  for  these  two
      configurations and is the foundation for the implementation rules.

                     Impedance and Termination Characteristics
                     Impedance and Termination Characteristics
                     -----------------------------------------

      The characteristic impedance of the Q-bus  is  approximately  120  Ohms.
      Therefore, when implementing a system (single or multiple backplane) the
      basic configuration is:
                            Transmission Line Impedance = 120 Ohms
                               +-----------------------------+
            Source Backplane   |                             |
               +---------+     |                        +----+----+
               |         |     |                        |    |    |
               |  +---+  |     |                        |  +-+-+  |
               |  | S |  |     |                        |  | Z |  |
               |  +-+-+  |     |                        |  +-+-+  |
               |    |    |     |                        |    |    |
               |  +-+-+  |     |                        |  +-+-+  |
               |  | Z |  |     |                        |  | S |  |
               |  +-+-+  |     |                        |  +---+  |
               |    |    |     |                        |         |
               +----+----+     |                        +---------+
                    |          |                   Destination Backplane
                    +----------+ 

            Source (usually the processor)           Far-end termination

                    Z - Bus Termination with 120 Ohms Characteristic Impedance 
                    S - Voltage Source
            
                    The transmission line in this diagram could be a single 
                    backplane or multiple backplanes connected with expansion 
                    cables.

                       Figure 1 - General Q-bus Configuration

                                  222

                                                           uNOTE # 029
                                                           Page 3 of 5


                      Q-bus Configuration -  Single Backplane
                      Q-bus Configuration -  Single Backplane
                      ---------------------------------------

      For the single backplane case the transmission line is the length of the
      etch  runs  on  the  Q-bus  connector  blocks  and the backplane printed
      circuit board.  This orientation has a signal generator at one end  (the
      processor)  and potentially a terminator at the far end of the bus.  The
      length of the etch runs cannot exceed 14 inches (35.56 cm).  In figure 1
      the transmission line is the backplane itself.

      A single backplane system does not require termination if there are less
      than  20 AC loads.  In this case the signals do not lose their integrity
      because the reflections, caused by the mismatched  impedances,  are  not
      significant  enough to disrupt bus activity.  However, in a high ambient
      electrical noise environment, system integrity may be further insured by
      proper termination.

      The single backplane configuration requires termination if the number of
      AC  loads  is  20  or greater.  The number of allowable AC loads in this
      case is dictated by  the  termination  on  the  processor.   A  120  Ohm
      processor  can  have up to 45 AC loads.  A 240 Ohm processor can have up
      to 35 AC loads.

                     Q-bus Configuration - Multiple Backplanes
                     Q-bus Configuration - Multiple Backplanes
                     -----------------------------------------

      For the multiple backplane case (where the multiples are  two  or  three
      backplanes) the transmission line is the cables used to interconnect the
      multiple backplanes.  The expansion cable set consists of:

       o  A module in the source backplane

       o  A module in the destination backplane

       o  Cables to connect the two modules

      The maximum length of the cables is 16.0 feet (4.88 meters).  The length
      of these cables is by comparison significantly longer then the length of
      the Q-bus connector blocks and the backplane etch  used  in  the  single
      backplane  case.  Therefore, only the interconnect cables are considered
      for configuration purposes.  This arrangement has a signal generator  at
      one end and requires termination at the far end.

      The far end termination  must  reside  in  the  last  backplane  of  the
      configuration.  The location of the far end termination can be any place
      in the last backplane, since the backplane etch runs do not  enter  into
      transmission  line considerations.  The lump sum termination must be 120
      Ohms.

      The termination in the source  box  must  also  be  120  Ohms.   If  the
      processor  is  240  Ohms  then  the  expansion  cable  set module or the
      backplane printed circuit board must have 240 Ohm termination to achieve

                                  223

uNOTE # 029
Page 4 of 5


      the 120 Ohms for the lump sum load.

      Lump sum implies that the 120 Ohms  can  be  achieved  by  one  or  more
      expansion  module or backplane printed circuit board mounted terminators
      and its location is position independent in a given backplane.  Figure 2
      shows an example of how such a lump sum load can be accomplished.



                     |  | <--------------------- Expansion Cable from 
       Backplane     |  |                          Source Backplane
         Slot #      |  |
              +------+  +---------------+
              |  +---+  +------------+  |
            1 |  | --+--+--  <-------|--|------- Expansion Module
              |  +-------------------+  |        with Termination (Z1)
            2 |  |                   |  |
              |  +-------------------+  |                               
            3 |  |                   |  |<------ Printed Circuit Board      
            . |  +-------------------+  |                               
            . |  |                   |  |
            . |  |                   |<-|------- Backplane 
            . |  +-------------------+  |
            n |  |                   |  |
              |  +-------------------+  |                               Z1 * Z2
              |    +-+           +-+    |        Lump Sum Termination = -------
              |    | |   <--->   | |    |                               Z1 + Z2
              |    +-+     |     +-+    |
              +------------+------------+
                           |
                           +-------------------- Printed Circuit Board
                                                 Mounted Termination (Z2)


        Figure 2 - Example of Lump Sum Termination in an Expanded Backplane

      Figure 1 shows the double backplane configuration  where  the  expansion
      cable  set is considered the transmission line.  The far end termination
      is  required.   Figure  3  shows  the  three  backplane   configuration.
      Backplane  #2  in  figure  3  for  all practical purposes is part of the
      expansion cable set when looking at it from an expansion point of view.

      The lengths of the expansion cables in multiple box  configurations  are
      strictly  specified.   As  mentioned  the  maximum length of the overall
      cable is 16.0 feet.  The minimum  length  is  2.0  feet  (0.61  meters).
      Therefore,  in a two backplane configuration the expansion cable must be
      between 2.0 and 16.0 feet.

      In the three backplane configuration the maximum cable length  is  still
      16.0  feet.  One of the two interconnect cables must be between 2.0 feet
      and 6.0 feet (1.83 meters) in length.  The other interconnect cable must
      be  at  least  4.0  feet (1.22 meters) but not longer than 10 feet (3.05

                                  224

                                                           uNOTE # 029
                                                           Page 5 of 5


      meters).  The difference in the two cable lengths must be 4.0 feet.

      The cable lengths are specified to insure that any reflections occur  in
      the expansion cables and not in the backplane (if they happen).

      The etch runs on the backplane printed circuit board used in a  multiple
      backplane configuration must be no longer than 10 inches (25.4 cm).  Not
      all backplanes used in single configurations can  be  used  in  multiple
      backplane configurations.


                             Expansion Cable     Expansion Cable
                                #1 to #2            #2 to #3

                              +---------+         +---------+
                              |         |         |         |
               +---------+    |    +----+----+    |    +----+----+    
               |         |    |    |         |    |    |    |    |
               |  +---+  |    |    |         |    |    |  +-+-+  |
               |  | S |  |    |    |         |    |    |  | Z |  |
               |  +-+-+  |    |    |         |    |    |  +-+-+  |
               |    |    |    |    |         |    |    |    |    |
               |  +-+-+  |    |    |         |    |    |  +-+-+  |
               |  | Z |  |    |    |         |    |    |  | S |  |
               |  +-+-+  |    |    |         |    |    |  +---+  |
               |    |    |    |    |         |    |    |         |
               +----+----+    |    +----+----+    |    +---------+    
                    |         |         |         |
                    +---------+         +---------+        
               Backplane #1        Backplane #2        Backplane #3


                    Z - Bus Termination with a Characteristic Impedance
                    S - Voltage Source     


                   Figure 3 - Three Backplane Q-bus Configuration

      Multiple  backplane  configurations   allow   22   AC   loads/backplane.
      Therefore,  it  is  44  AC  loads  in  a  two  or 66 AC loads in a three
      backplane configuration.  To avoid lumping too many  AC  loads  together
      the total number of AC loads should be distributed as evenly as possible
      over the two or  three  backplanes.   The  entire  configuration  cannot
      exceed 20 DC loads.

      In  summary,  following  the  expansion  rules  insures  proper   system
      operation.   The  set of rules to be followed are dictated by the single
      or multiple configuration chosen and the arrangement of the  termination
      in the system.




                                  225

================================================================================
Note 30.0                  PMI on KDJ11-B and MSV11-J                 No replies
FURILO::GIORGETTI                                   587 lines  21-AUG-1985 23:13
--------------------------------------------------------------------------------


      +---------------+                                    +-----------------+
      | d i g i t a l |                                    |  uNOTE # 030    |
      +---------------+                                    +-----------------+

                                                                         
      +----------------------------------------------------+-----------------+
      | Title:  The Private Memory Interconnect            | Date: 28-Jun-85 |
      |         between the KDJ11-B and the MSV11-J        |                 |
      +----------------------------------------------------+-----------------+
      | Originator:  Peter Kent                            | Page 1 of 10    |
      +----------------------------------------------------+-----------------+


                                      Purpose
                                      -------

      This  MicroNote  describes  the  Private  Memory  Interconnect  on   the
      MicroPDP-11/83 system.  It is not intended to be a design guide for PMI,
      since no devices other than the CPU and memory will make use of it.


                                General Description
                                -------------------

      A MicroPDP-11/83 system consists of the KDJ11-B  CPU  and  one  or  more
      MSV11-J  memories  in a Q-bus backplane.  The slots used for the CPU and
      memory use the CD interconnect.  In a MicroPDP-11/83 configuration,  the
      first  1  or  2  slots in a BA23 backplane (an 8 slot backplane with the
      first 3 slots Q/CD) are reserved for MSV11-J memory.  The CPU is put  in
      the  third  slot.   The mechanical design of the signal pathways between
      the CPU and memory were  designed  to  prevent  accidental  interference
      between  the  PMI and other devices that might be placed adjacent to the
      CPU and memory.  It is possible to have a single 2 Mb board  in  slot  1
      followed  by  the  CPU in slot 2.  Putting the CPU after the memory ends
      the PMI because the PMI signals from the CD side of the  CPU  board  are
      only on the component side of the CPU board.

      "Private Memory Interconnect" is the addition of 14  unique  signals  to
      the  Q-bus.   These  new  signals  use the CD part of the backplane in a
      Q-bus system for communications between the KDJ11-B CPU and one  or  two
      MSV11-J memories.  Only the CPU and memory may communicate over this bus
      (hence PRIVATE).  The Q-bus Data/Address lines  are  used  for  passsing
      data  and  addresses  between  the  CPU  and  memory.   All  other Q-bus
      transactions proceed as before.

      The PDP-11/84 Unibus system uses the  KTJ11-B  Unibus  Adaptor,  KDJ11-B
      CPU,  and  one  or  two  MSV11-J  memories.   No  Q-bus  devices  may be
      configured with the PDP-11/84 system.  Five of the PMI signals are  used
      only with Unibus systems.  All communications between Unibus devices and
      the KTJ11-B  occur  according  to  the  Unibus  protocol.   The  KTJ11-B
      provides the interface between PMI and Unibus protocols.  This MicroNote
      does not explain the details of the Unibus and PMI interaction.

                                  227

uNOTE # 030
Page 2 of 10


                                    What is PMI?
                                    ------------

      To understand PMI it is necessary to describe some  of  the  bus  cycles
      used  by  PMI  and compare them with ordinary Q-bus cycles.  There are 4
      PMI cycles used in the MicroPDP-11/83 system:

        DATI - Data word input.  This cycle is used to read one or more 16 
        bit words from memory by the CPU.  

        DATIP - Data word input pause.  This cycle is used to read one or 
        more 16 bit words from memory by the CPU.  It is often used to 
        perform a read/modify/write cycle.
        
        DATO - Data word ouput.  This cycle is used to write a 16 bit word 
        to memory by the CPU.
        
        DATOB - Data byte output.  This cycle is used to write a byte to 
        memory by the CPU.      

      The KDJ11-B does not perform Block Mode reads  or  writes  with  memory.
      Certain other Q-bus devices (such as the RDRX1 and RQDX2 controllers and
      RQC25) perform Block Mode DMA with MSV11-P,MSV11-Q,AND MSV11-M memories.
      The CPU monitors Block Mode transactions to keep its cache in order, but
      it has no control over such transfers once it has  relinquished  control
      of the bus to those devices.


                                     REFERENCES

              PMI signal definitions are listed at  the  end  of  this
              MicroNote.  All other signal definitions are as given in
              the Microcomputer Products  Handbook  (EB  26078-41)  or
              Microsystems Handbook (EB 26085-41).


      TWTBT, a Q-bus  signal,  is  used  somewhat  differently  during  a  PMI
      transaction than during a normal Q-bus transaction.  See the definitions
      section for an explanation of this signal.














                                  228

                                                           uNOTE # 030
                                                          Page 3 of 10


                                        NOTE


              Few timing relationships are given here  because  it  is
              not  necessary  for  a  basic understanding of PMI.  The
              relationships that are given are a comparison  to  Q-bus
              only.  The prefix "T" refers to bus driver input and "R"
              refers  to  bus  receiver   output.    This   helps   to
              distinguish between the device which issues a particular
              signal and that of the receiver of the signal.   If  the
              prefix  "B"  is  used, it denotes a general term for the
              signal on the bus without regard for its timing relation
              with respect to sender or receiver (i.e.  BSYNCH).



                               Address part of cycle
                               ---------------------

      The address portion of the MicroPDP-11/83 PMI cycles is the same for all
      4  PMI cycles.  It is listed here first and the description of the other
      cycles follow.

      1.  For the first part of the cycle, the CPU gates ADDR,  BBS7  (if  the
          I/O  page  is  referenced),  TWTBT,  and  TPBYT onto the Q-bus.  The
          combination of TWTBT and TPBYT (PMI signal) determine what  type  of
          PMI transaction will take place - see Table 1  below.  These signals
          are asserted for a brief period after the assertion of TPBCYC.


                                        Table 1
                                        -------

                     BWTBT L         PBYT L             Description

                       H               H             DATI or DATBI Cycle
                       H               L             DATIP Cycle
                       L               H             DATO Cycle
                       L               L             DATOB Cycle

          As noted above, Q-bus signals such as  TWTBT  are  used  differently
          during a PMI cycle.  TWTBT is not normally used during a DATI cycle,
          for example.

      2.  Next, memory issues TPSSEL after receiving RADDR and RBS7.  The  CPU
          receives  RPSSEL.   This part of the cycle indicates that the memory
          is responding.






                                  229

uNOTE # 030
Page 4 of 10


      3.  If the CPU was the previous bus master and the previous cycle was  a
          Q-bus  cycle,  then  the  CPU  must not assert TPBCYC or TSYNC until
          after the negation of TSYNC and after the negation of RRPLY.  If the
          cycle  was  an interrupt service cycle, then the CPU must wait until
          after the negation of RRPLY.   This  stipulation  allows  for  other
          Q-bus devices equal access to the bus.  Also, if another       Q-bus
          device was previously bus master, then  the  CPU  must  not  asssert
          TPBCYC  or TSYNC until after the negation of RSYNC - this is to make
          sure RRPLY is negated long enough as per Q-bus protocol.

      4.  Now, if RPSSEL is asserted and if RPUBMEM is negated, the PMI master
          proceeds  with  a  PMI  cycle.  The negation of RPUBMEM indicates no
          that no Unibus memory is responding - in other  words  a  Q-bus  PMI
          cycle.   Here is where the diffe- rence between Q-bus cycles and PMI
          cycles becomes visible.

      5.  The CPU asserts TPBCYC after gating TADDR, TBS7,  TPBYT,  and  TWTBT
          onto  the  bus.   The  PMI master continues to gate TADDR, TBS7, and
          TWTBT after the assertion of TPBCYC.

      6.  If at this point RPSSEL is negated, the  system  will  revert  to  a
          normal Q-bus cycle.

      This describes the address portion of  the  PMI  cycle  for  Q-bus  only
      systems.

                                        DATI
                                        ----

      When the CPU (KDJ11-B) is accessing memory for a PMI Data In  Cycle,  it
      transfers 2 words.  This takes advantage of the KDJ11-B restart overhead
      to load a second 16-bit word into the cache on the CPU  module.   Listed
      below equivalent Q-bus cycles are compared with PMI cycles under "Timimg
      Comparisons".  For the read cycle, 2 data words (one after another)  are
      latched  into  the  MSV11-J data gate array and both words are placed on
      the bus.  Interestingly enough, either word may be selected to be placed
      on  the  bus  first.   If the odd word is placed on the bus first, it is
      followed by the preceding even word.  For example, if a word at  address
      17362  is  selected  to  be  placed  on  the  bus  first,  the next word
      transferred will be from address 17360.  If the even word is selected to
      be  placed  on  the  bus  first,  the  next odd word is then transferred
      second.  For example, if a word at  address  17360  is  selected  to  be
      placed  on  the bus first, the next odd word is then transferred second.
      For example, if a word at address 17360 is selected to be placed on  the
      bus, the next word transferred will be at address 17362.








                                  230

                                                           uNOTE # 030
                                                          Page 5 of 10


      Using the MSV11-J memory as a normal Q-bus memory (disabling the PMI  by
      putting  it  after  the  CPU  in the bus) and performing a read cycle, 2
      words will be latched into the data gate array.  However, only one  word
      is placed on the Q-bus.


      1.  At this point the address portion of the cycle is over.  The  memory
          gates TDATA onto the bus after the assertion of RPBCYC.

      2.  Immediately after RPBCYC  the  memory  enables  the  parity  signals
          TPHBPAR and TPLBPAR.

      3.  Memory asserts TPRDSTB immediately after the reception of RPBCYC.

      4.  The strobe signal TPRDSTB is negated by memory after  the  reception
          of RPBCYC.

      5.  The memory gates the second data word onto the bus after TPRDSTB  is
          negated.   Shortly  after the parity in- formation is sent.  Another
          advantage is realized here:  the second  data  word  is  transmitted
          without the need of any further signals between the CPU and memory.

      6.  If the CPU has read 2 words, it negates TPBCYC  after  latching  the
          second data word.

      7.  After the negation of RPBCYC memory removes TDAT from the bus.


      It becomes evident that there is an essential difference between  normal
      Q-bus  transactions  and  PMI  transactions.  Q-bus transactions are all
      based on handshaking.  During  a  DATI  Q-bus  transaction,  the  memory
      responds  with  BRPLY  after BDIN from the processor.  There must be the
      signal between each device that the transaction has taken place.  During
      a  PMI  DATI  transaction, there is only a strobe signal from the memory
      saying that it is ready for the data.  The  only  further  communication
      between  the  memory and CPU is the actual data transfer.  Only upon the
      transmission of the second possible data word is parity information sent
      along with the second data word.  No other memory-CPU signalling occurs.















                                  231

uNOTE # 030
Page 6 of 10




         KDJ11-B                                          MSV11-J
         -------                                          -------

         Address Memory
         --------------
         o Gate Address
           onto Address Lines    ---------+
         o Combination of                 |
           TPBYT and TWTBT                |
           result in DATI Cycle           +------>   Decode Address
         o Assert BBS7 if Address                    --------------
           is in I/O Page                 +-------   o TPSSEL asserted shows
                                          |            Memory is Selected
         PMI Cycle Assertion    <---------+
         -------------------
         o TPBCYC Indicates PMI Cycle
           deasserts Address, BBS7  ------+
           TPBYT,TWTBT Signals            |
           Address part of                +------->  Data
           cycle is finished                         ----
                                                     o TDATA, TPHBPAR, TPLBPAR
                                                       (Data and Parity) is 
                                                       asserted onto Data Lines
                                                     o Memory strobes CPU by
                                                       Asserting TPRDSTB to tell
                                                       CPU Data is on the Bus
                                                     o The strobe signal 
                                                       TPRDSTB is deasserted
                                          +-------   o The second data word and
                                          |            parity info are put on
         PMI Cycle End   <----------------+            the Data Lines
         -------------
         o CPU deasserts TPBCYC
           to end PMI Cycle  -------------+          Data
                                          |          ----
                                          +------>   o Memory removes
                                                       data from Bus

                                 Timing Comparisons
                                 ------------------

      At this point it would be interesting to make  some  timing  comparisons
      between  Q-bus  and  PMI  DATI  transactions.   Considering a Q-bus DATI
      transaction, the cycle  time  (timing  from  BSYNCH  to  TRPLY  ignoring
      addressing  time) is 510 ns for MSV11-M.  The MSV11-M was chosen because
      its cycle time does not include the ECC overhead of the MSV11-J.  Add to
      this  320  ns access time and this totals 830 ns to transfer 1 word from
      memory to CPU.  Now, if 2 words are to be transferred  in  this  manner,
      add  another  300  ns due to delay between RRPLY and TSYNCH in order for
      other Q-bus devices access to the bus.  This results in  1130  ns  total

                                  232

                                                           uNOTE # 030
                                                          Page 7 of 10


      for a 2 word transfer using MSV11-M parity memory.

      The MSV11-J memory access time is 417 ns.  This is the time from  RPBCYC
      to  PRDSTB.   Fifty  eight ns later, at the trailing edge of PRDSTB, the
      CPU receives the second data word.  This means that PMI is approx.   2.5
      times  faster  than Q-bus on 2 word reads from memory to CPU.  Remember,
      this also accounts for the time the ECC  requires  to  do  its  modified
      Hamming  code  versus  the  MSV11-M  parity  check.  For each 18 bits of
      MSV11-J memory there are 6 bits used for ECC.   This  accounts  for  the
      space  needed on the MSV11-J for 2 Mb of memory whereas 4 Mb is possible
      on the MSV11-Q on the same size board.


                                    DATO (DATOB)
                                    ------------


      The CPU uses DATO to transfer a single word (or byte for a DATOB  cycle)
      to memory.  The address portion of the cycle is the same as for the DATI
      and is described above.

      1.  The CPU determines what type of cycle (DATO or DATOB)  by  logically
          combining TWTBT and TPBYT.  During the address portion of the cycle,
          these signals were used to indicate which  type  of  PMI  cycle  was
          selected.

      2.  Memory asserts TRPLY after RPBCYC.

      3.  After the assertion of TPBCYC, data is gated onto  the  bus  by  the
          CPU.

      4.  The CPU asserts TPWTSTB after data is gated onto the bus.

      5.  Memory asserts TPSBFUL after RPWTSTB.

      6.  The CPU deasserts TPBCYC after negating TWTSTB.

      7.  The memory waits before it can accept another PMI  cycle  (or  Q-bus
          cycle) - then it deasserts TRPLY.

      8.  Memory negates TPSBFUL before it can accept another  PMI  (or  Q-bus
          cycle).











                                  233

uNOTE # 030
Page 8 of 10



         KDJ11-B                                          MSV11-J
         -------                                          -------
             
         Address Memory
         --------------
         o Gate Addresses onto
           Address Lines
         o Combination of TPBYT
           and TWTBT Result in
           DATO Cycle
         o Assert BBS7 if Address  ------+
           is in the I/O Page            |
                                         +------->   Decode Address
                                                     --------------
          PMI Cycle Assertion            +--------   o TPSSEL Shows 
          -------------------            |             Memory is address 
          o Assertion of TPBCYC  <-------+             selected
            indicates PMI Cycle
          o CPU deasserts Address, BBS7,
            TPBYT, TWTBT Signals -
            Address Portion of Cycle  ---+             Memory Responding 
            is finished                  |             -----------------
                                         +------->   o After reception of 
                                                       RPBCYC, memory sends
         Data                                          TRPLY to CPU
         ----
         o TDATA, TPHBPAR, TPLBPAR
           (Data and Parity) is put 
           onto the Data Lines
         o CPU then strobes the                     Reception of Data
           Memory by asserting TPWTSTB --+          -----------------
                                         +------->  o Memory asserts TPSBFUL 
                                                      after reception of 
                                         +--------    RPWTSTB
                                         |
         PMI Cycle End     <-------------+
         -------------
         o CPU deasserts TPBCYC
           to indicate current                      Memory Cycle End
           PMI Cycle is finished  -------+          ----------------
                                         +------->  o Memory waits for other
                                                      devices to claim Bus 
                                                      before it can accept 
                                                      another PMI Cycle - then
                                                      deasserts TRPLY
                                                    o Memory must negate
                                                      TPSBFUL before another
                                                      PMI Cycle can begin




                                  234

                                                           uNOTE # 030
                                                          Page 9 of 10


                                 Timing Comparisons
                                 ------------------

      Here is a comparison of a Q-bus  DATO  cycle  with  a  PMI  DATO  cycle.
      Looking  at a Q-bus DATO transaction, the cycle time (timing from RSYNCH
      to TRPLY) for MSV11-M is 550 ns.  Comparing this  to  the  MSV11-J  DATO
      cycle,  the  result of 223 ns is obtained.  This figure is arrived at as
      follows:  38 ns access time for the memory + 80 ns TPBCYC to TDATA +  75
      ns  TPWTSTB  after data is on the bus + 30 ns to hold TPWTSB.  Again the
      speed advantage of PMI transactions over normal  Q-bus  transactions  is
      about 2.5 to 1.


                                       DATIP
                                       -----

      The PMI Data In Pause cycle is identical to the DATI cycle  except  that
      TPBYT   is   asserted  with  TADDR  to  indicate  that  the  next  cycle
      (immediately following the current cycle) will be a data  out  cycle  to
      the same address.


                          PMI and Q-bus signal definitions
                          --------------------------------

      Eight of the PMI signals are used in an MicroPDP-11/83 system, therefore
      only  those  will  be defined here.  One Q-bus signal, BWTBT, is defined
      here  because  it  is  used  differently  than   during   normal   Q-bus
      transactions.


      PBYT L    PMI Byte.  When the CPU gates address onto the bus, it asserts
                this signal with BWTBT to indicate the type of bus cycle (see
                Table 1 above).      

      PBCYC L   PMI bus cycle.  The CPU asserts this signal at the start of 
                a PMI cycle and negates it at the end of that cycle.

      PRDSTB L  PMI read strobe.  Memory asserts and negates this signal to 
                control data transfers during DATI cycles.  The CPU latches
                the received first word data on the negating edge of this 
                signal.  The second word is latched after that without further
                signalling.

      PWTSTB L  PMI Write Strobe.  The CPU asserts this signal after gating 
                data onto the bus.  The memory latches the data into its 
                write buffer after the leading edge of this pulse.

      PSSEL L   PMI slave selected.  Memory asserts this signal whenever it
                decodes its address on the Q-bus.



                                  235

uNOTE # 030
Page 10 of 10


      PHBPAR L   PMI high byte data parity.  This signal is generated by PMI 
                 memory during DATI cycles and provides odd parity for the high
                 byte data on the Q-bus.

      PLBPAR L   PMI low byte data parity.  This signal is generated by PMI 
                 memory during DATI cycles and provides even parity for the low
                 byte data.

      PSBFUL L   PMI memory buffer full.  Memory asserts this signal during a 
                 write cycle indicating that its write buffer is full and that 
                 it cannot respond to another cycle request.  


                                    Q-bus signal
                                    ------------


      BWTBT L Write byte (PMI  write  indication).   In  Q-bus  systems,  this
      signal is used for Q-bus write cycles.  For PMI transactions,        the
      CPU gates this signal with PBYT to indicate the type of     PMI   cycle.
      See Table 1 above.


                                     References
                                     ----------

           Microcomputer Products Handbook     EB-26078-41
           Microsystems Handbook               EB-26085-41
           MSV11-M User Guide                  EK-MSV1M-UG-001
           MSV11-Q User Guide                  EK-MSV1Q-UG-002
           MSV11-J User Guide                  EK-MSV1J-UG-001






















                                  236

================================================================================
Note 31.0                 MSV11-QA Revision Differences               No replies
FURILO::GIORGETTI                                   528 lines  21-AUG-1985 23:16
--------------------------------------------------------------------------------


      +---------------+                                    +-----------------+
      | d i g i t a l |                                    |  uNOTE # 031    |
      +---------------+                                    +-----------------+

                                                                   
      +----------------------------------------------------+-----------------+
      | Title: MSV11-QA Revision Differences               | Date: 28-JUN-85 |
      +----------------------------------------------------+-----------------+
      | Originator: Jack Toto                              | Page 1 of 9     |
      +----------------------------------------------------+-----------------+


      Digital Equipment Corporation recently announce the  addition  of  three
      memories  for the  Q-bus  space;  the  MSV11-QA  quad module at 1MB, the
      MSV11-QB  quad  module   at 2MB, and the  MSV11-QC  quad module at  4MB. 

      Earlier versions of the MSV11-QA  were  shipped using a  revision A etch 
      and the   documentation correctly  showed  the  jumper   configurations.  
      However early in 1985 the MSV11-QA/QB/QC started  shipping with revision 
      C etch.  The documentation  at that point  did  not show how to properly 
      configure the C etch.   It  is the intent of this MicroNote to point out 
      the differences between the two modules and to explain the configuration  
      of  both  the etch  revisions.   

      The two  modules can  be identified  in any one of the three ways listed
      in the table below;
           1. The location and value of the  modules  serial  number.
           2. The location  of CSR  and address jumpers and switches.
           3. The module's designation number, stamped on the insertion
              handles will be  different.  
                  3A. Revision A modules will be labeled M7551-AA.
                  3B. Revision C modules will be labeled M7551-AA. 


      SERIAL NUMBER LOCATION
      ----------------------

      The two modules can be identified by the location of its serial  number.
      The  revision A module will have its serial  number located in the upper 
      right hand corner of the module as you hold it with the fingers pointing  
      down or  at  you and the component side facing you or up as it would lay 
      on a work bench.  This serial number will be 5017547A1.  The location of  
      the serial  number  for revision  C module will be on the component side 
      also, but in the upper  left hand corner.  This   serial   number   will
      be 5017547-01-C1. The attached  diagrams  of the revision A and revision 
      C modules show the location of these numbers.








                                       237

uNOTE # 031
Pag 2 of 9

      JUMPER LOCATION
      ---------------

      The MSV11-QA revision A module allows for the  selection of  Block  Mode  
      DMA  transfers,  parity detection,  and  extended  address  parity error 
      detection as well as CSR and address selection.  The  address  selection  
      includes two  switches,  one  for  the modules  starting address and one 
      for the modules ending address.  The ending  address switch is  used  to  
      control the  decode logic on the module as the same etch is used for 2MB 
      and 4MB boards as well, each with different value memory chips to  reach  
      there designed capacity.   The location  and  function of these switches 
      and  jumpers if   detailed in  the  diagrams and  configuration   tables
      attached to the end of this MicroNote.  

      The MSV11-QA revision C module does not allow for the selection of Block  
      Mode  DMA  or  for  the  selection  of  parity detection, these features 
      are built into  the  module itself and can be used or  not used  through 
      hardware/software compatibility.  When used  in a  system  that supports 
      Block Mode the MSV11-QA  will perform as  a Block Mode device, when used 
      in a non Block Mode  system it will perform  as  a normal  memory module 
      without  any  decrease in  that  system's  performance.  When used  with 
      software  such  as  RSX11 and  using mixed   parity/non-parity  memories
      parity  detection  can  be  disabled through sysgen.  The only functions 
      that a user is required to  configure to use  the MSV11-QA revision C is  
      CSR selection and starting and ending address.  It should be pointed out 
      that the two switches for starting and ending  addresses  have been flip  
      flopped from the positions in which they  were located on the revision A
      module.  Once again refer  to  the  diagrams  and  configuration  tables
      attached  to  this MicroNote for location and function of these switches
      and jumpers.

      The following pages contain diagrams and tables for configuring the two
      versions of the MSV11-QA




















				   238

                                                                  uNOTE # 031
                                                                  Page 3 of 9

      MSV11-QA revision A Module Identification
      -----------------------------------------

      +-----+            +-+           +-+            +-----+
      |     +____________|_|___________|_|____________+     |
      +-----------------------------------------------------+
      |                                                     |
      |                                 5017547A1 <---------+- PRINTED CIRCUIT
      |                                                     |  BOARD NO.
      |                                                     |
      |                                                     |
      |                                                     |
      |                                                     |
      |                 (COMPONENT SIDE)                    |
      |                                                     |
      |                                                     |
      |                                                     |
      |                                                     |
      |                                                     |
      |                                                     |
      |                                                     |
      |                                                     |
      |             +-+          +-+            +-+         |
      ++        +---+ |        +-+ |        +---+ |        ++
       |        |     |        |   |        |     |        |
       +--------+     +--------+   +--------+     +--------+
                  (A) MSV11-QA (ETCH revision A ONLY)
  


      MSV11-QA revision A CSR SELECTION
      ---------------------------------

      NUMBER OF               JUMPER POSITION            CSR REGISTER
      MEMORY MODULE             R    P    N    M         ADDRESS 
      ---------------------------------------------------------------
       1ST                      IN   IN   IN   IN          17772100
       2ND                      OUT  IN   IN   IN          17772102
       3RD                      IN   OUT  IN   IN          17772104
       4TH                      OUT  OUT  IN   IN          17772106
       5TH                      IN   IN   OUT  IN          17772110
       6TH                      OUT  IN   OUT  IN          17772112
       7TH                      IN   OUT  OUT  IN          17772114
       8TH                      OUT  OUT  OUT  IN          17772116
       9TH                      IN   IN   IN   OUT         17772120
      10TH                      OUT  IN   IN   OUT         17772122
      11TH                      IN   OUT  IN   OUT         17772124
      12TH                      OUT  OUT  IN   OUT         17772126
      13TH                      IN   IN   OUT  OUT         17772130
      14TH                      OUT  IN   OUT  OUT         17772132
      15TH                      IN   OUT  OUT  OUT         17772134
      16TH                      OUT  OUT  OUT  OUT         17772136



				   239

uNOTE # 031
Page 4 of 9


      MSV11-QA revision A STARTING AND ENDING ADDRESS
      -----------------------------------------------

      DESIRED          SW1           SW2           STARTING         ENDING
      STARTING         SWITCH        SWITCH        ENDING           SWITCH
      ADDRESS          POSITION      POSITION      ADDRESS          POSITION
      -----------------------------------------------------------------------
      IN KBYTE         12345           6           IN KBYTE          12345
      -----------------------------------------------------------------------
         0             00000           0           128               11111
       128             11111           1           256               01111
       256             01111           1           384               10111
       384             10111           1           512               00111
       512             00111           1           640               11011
       640             11011           1           768               01011
       768             01011           1           896               10011
       896             10011           1          1024 (1MB)         00011
      1024 (1MB)       00011           1          1152               11101
      1152             11101           1          1280               01101
      1280             01101           1          1408               10101
      1408             10101           1          1536               00101
      1536             00101           1          1664               11001
      1664             11001           1          1792               01001
      1792             01001           1          1920               10001
      1920             10001           1          2048 (2MB)         00001
      2048 (2MB)       00001           1          2176               11110
      2176             11110           1          2304               01110
      2304             01110           1          2432               10110
      2432             10110           1          2560               00110
      2560             00110           1          2688               11010
      2688             11010           1          2816               01010
      2816             01010           1          2944               10010
      2944             10010           1          3072 (3MB)         00010
      3072 (3MB)       00010           1          3200               11100
      3200             11100           1          3328               01100
      3328             01100           1          3456               10100
      3456             10100           1          3584               00100
      3584             00100           1          3712               11000
      3712             11000           1          3840               01000
      3840             00010           1          3968               10000
      3968             10000           1          4096 (4MB)         00000


      1 = off position (open)
      0 = on  position (closed)

      NOTE: Switch  S6 of SW1 is not used.  For a memory starting  address of 
            0, switch  S6 of  SW2  should be  set to  0 (on).  For all  other 
            starting addresses S6 of SW2 should be off (1).




				  240
 
                                                                 uNOTE # 031
                                                                 Page 5 of 9

      MSV11-QA revision A
      -------------------

      +-----+            +-+           +-+            +-----+
      |     +____________|_|___________|_|____________+     |
      +-----------------------------------------------------+
      |                                  5017547A1          |   
      |                              ++     +++             |
      |                PARITY -----> ++    A+++ <-----------+- CSR REGISTER
      |                 LED          ++    P+++             |  SELECTION
      |                                    N+++             |
      |                                    M+++             |
      |                                   ++                |
      |                                   ++A <-------------+- ENABLE/DISABLE
      |                                   ++B               |  CSR SELECTION
      |                                   ++                |
      |                                   SW1               |
      |                                  ++++               |
      |                                  ++++1 <------------+- STARTING ADDRESS
      |                                  |++|2              |  SWITCHES
      |                                  |++|3   ++         |  (S6 NOT USED)
      |                                  |++|4   ++W1 <-----+- ENABLE/DISABLE
      |            (COMPONENT SIDE)      |++|5   ++W2       |  BLOCK MODE
      |                                  ++++6   ++  ++     |
      |                                  OFF ON      ++K <--+- ENABLE/DISABLE
      |                                              ++L    |  EXTENDED
      |                                          SW2 ++     |  ERROR ADDRESS
      |                                         ++++        |
      |                                         ++++1 <-----+- ENDING ADDRESS
      |                                         ++++2       |  SWITCHES
      |                                         |++|3       |
      |                                         |++|4       |
      |                                         |++|5       |
      |                                         |++|6       |
      |                                         OFF ON      |
      |                                              ++++ <-+- ENABLE PARITY
      |                                          +5V ++++   |  ERROR DETECTION
      |                                           ++  JH    |
      |                                           ++ <------+- NOT USED, MODULE
      |                                           ++        |  DOES NOT SUPPORT
      |                                          +5VB       |  BATTERY BACKUP
      |             +-+          +-+            +-+         |
      ++        +---+ |        +-+ |        +---+ |        ++
       |   D    |     |   C    |   |   B    |     |   A    |
       +--------+     +--------+   +--------+     +--------+
  
                   Jumper and Switch Locations
                     (Drawing not to scale)






				   241

uNOTE # 031
Page 6 of 9

  MSV11-QA revision C Module Identification
  -----------------------------------------
                    +-----+            +-+           +-+            +-----+
                    |     +____________|_|___________|_|____________+     |
                    +-----------------------------------------------------+
                    |                                                     |
   PRINTED CIRCUIT -+---------> 5017547-01-C1                             |
   BOARD NO.        |                                                     |   
                    |                                                     |
                    |                                                     |
                    |                                                     |
                    |                                                     |
                    |                 (COMPONENT SIDE)                    |
                    |                                                     |
                    |                                                     |
                    |                                                     |
                    |                                                     |
                    |                                                     |
                    |                                                     |
                    |                                                     |
                    |                                                     |
                    |             +-+          +-+            +-+         |
                    ++        +---+ |        +-+ |        +---+ |        ++
                     |        |     |        |   |        |     |        |
                     +--------+     +--------+   +--------+     +--------+
                         (B) MSV11-QA (ETCH revision C OR LATER) 
                             MSV11-QB AND MSV11-QC
  
                                  (Drawings not to scale)

      MSV11-QA revision C CSR SELECTION
      ---------------------------------

      NUMBER OF               JUMPER POSITION            CSR REGISTER
      MEMORY MODULE           J5   J7   J9   J11         ADDRESS 
      ------------------------------------------------------------------------
       1ST                    IN   IN   IN   IN          17772100
       2ND                    OUT  IN   IN   IN          17772102
       3RD                    IN   OUT  IN   IN          17772104
       4TH                    OUT  OUT  IN   IN          17772106
       5TH                    IN   IN   OUT  IN          17772110
       6TH                    OUT  IN   OUT  IN          17772112
       7TH                    IN   OUT  OUT  IN          17772114
       8TH                    OUT  OUT  OUT  IN          17772116
       9TH                    IN   IN   IN   OUT         17772120
      10TH                    OUT  IN   IN   OUT         17772122
      11TH                    IN   OUT  IN   OUT         17772124
      12TH                    OUT  OUT  IN   OUT         17772126
      13TH                    IN   IN   OUT  OUT         17772130
      14TH                    OUT  IN   OUT  OUT         17772132
      15TH                    IN   OUT  OUT  OUT         17772134
      16TH                    OUT  OUT  OUT  OUT         17772136

				   242

                                                                 uNOTE # 031
                                                                 Page 7 of 9


      MSV11-QA revision C STARTING AND ENDING ADDRESS
      ------------------------------------------

      DESIRED          SW2           SW1           STARTING         ENDING
      STARTING         SWITCH        SWITCH        ENDING           SWITCH
      ADDRESS          POSITION      POSITION      ADDRESS          POSITION
      -----------------------------------------------------------------------
      IN KBYTE         12345           6           IN KBYTE          12345
      -----------------------------------------------------------------------
         0             00000           0           128               11111
       128             11111           1           256               01111
       256             01111           1           384               10111
       384             10111           1           512               00111
       512             00111           1           640               11011
       640             11011           1           768               01011
       768             01011           1           896               10011
       896             10011           1          1024 (1MB)         00011
      1024 (1MB)       00011           1          1152               11101
      1152             11101           1          1280               01101
      1280             01101           1          1408               10101
      1408             10101           1          1536               00101
      1536             00101           1          1664               11001
      1664             11001           1          1792               01001
      1792             01001           1          1920               10001
      1920             10001           1          2048 (2MB)         00001
      2048 (2MB)       00001           1          2176               11110
      2176             11110           1          2304               01110
      2304             01110           1          2432               10110
      2432             10110           1          2560               00110
      2560             00110           1          2688               11010
      2688             11010           1          2816               01010
      2816             01010           1          2944               10010
      2944             10010           1          3072 (3MB)         00010
      3072 (3MB)       00010           1          3200               11100
      3200             11100           1          3328               01100
      3328             01100           1          3456               10100
      3456             10100           1          3584               00100
      3584             00100           1          3712               11000
      3712             11000           1          3840               01000
      3840             00010           1          3968               10000
      3968             10000           1          4096 (4MB)         00000


      1 = off position (open)
      0 = on  position (closed)

      NOTE: Switch  S6 of SW2 is not  used. For a memory starting  address 
            of 0, switch S6 of SW1 should be set  to 0 (on). For all other 
            starting addresses S6 of SW1 should be off (1).





				   243

uNOTE # 031
Page 8 of 9

      MSV11-QA revision C          
      -------------------

      +-----+            +-+           +-+            +-----+
      |     +____________|_|___________|_|____________+     |
      +-----------------------------------------------------+
      |                                                     |
      |      5017547-01-C1             +++++ <--------------+-- CSR REGISTER
      |                                +++++                |   SELECTION
      |                                +++++                |
      |                                                     |
      |                                                     |
      |                                                     |
      |                                                     |
      |                                            SW2      |
      |                                           ++++      |
      |                                           ++++1 <---+- STARTING ADDRESS
      |                                           ++++2     |  SWITCHES
      |                                           ++++3     |  (S6 NOT USED)
      |                                           ++++4     |
      |                                           ++++5     |
      |                                           ++++6     |
      |         (COMPONENT SIDE)                            |
      |                                                     |
      |                                                     |
      |                                       SW1           |
      |                                      ++++           |
      |                                      ++++1 <--------+- ENDING ADDRESS
      |                                      ++++2          |  SWITCHES
      |                                      ++++3          |
      |                                      ++++4          |
      |                                      ++++5          |
      |                                      ++++6          |
      |                                                     |
      |                                                     |
      |                                         o   o <-----+- BATTERY BACKUP
      |                                         o   o       |  JUMPERS
      |                                      W2 o   o W1    |
      |                                         o   o       |
      |                                                     |
      |             +-+          +-+            +-+         |
      ++        +---+ |        +-+ |        +---+ |        ++
       |        |     |        |   |        |     |        |
       +--------+     +--------+   +--------+     +--------+
  
                       Jumpers and Switches
                      (Drawing not to scale)







   				   244

                                                                 uNOTE # 031
                                                                 Page 9 of 9

                   COMPARISON OF SIMILAR FUNCTION JUMPERS 
                   --------------------------------------


      JUMPER        SELECTABILITY      ENABLED               DISABLED
      FUNCTION      REV-A    REV-A     CONFIGURATION         CONFIGURATION
      ----------------------------------------------------------------------
      DISABLE       YES      NO        W1 IN (J11 TO J12)   W2 IN (J11 TO J10)
      BLOCK MODE                       W2 OUT               W1 OUT
      -----------------------------------------------------------------------
      DISABLE       YES      NO        JUMPER B IN          JUMPER A IN
      PARITY                           (J14 TO 13)          (J14 TO J5)
      MEMORY                           JUMPER A OUT         JUMPER B OUT
      -----------------------------------------------------------------------
      DISABLE       YES      NO        JUMPER H IN          JUMPER G IN
      PARITY                           (J2 TO J3)           (J1 TO J2)
      DETECTION                        JUMPER G OUT         JUMPER H OUT
      -----------------------------------------------------------------------
      DISABLE       YES      NO        JUMPER L IN          JUMPER K IN
      22-BIT                           (J8 TO J7)           (J8 TO J9)
      ADDRESSING                       JUMPER K OUT         JUMPER L OUT
      -----------------------------------------------------------------------
      BATTERY       NO       YES       W3 AND W1 IN         W4 AND W1 IN
      BACKUP                              WITH                 WITH 
      SUPPORT                          W4 AND W1 OUT        W3 AND W1 OUT
                                      (revision C ONLY)    (revision C ONLY)
      ----------------------------------------------------------------------

      BATTERY BACKUP
      CONFIGURATION   NOTE: JUMPERS W4 AND  W2  ARE LOCATED BETWEEN E21 AND 
                            E13 IN  THE LOWER  RIGHT  HAND  CORNER  OF  THE 
                            COMPONENT  SIDE OF  THE MODULE.  FOR THE ACTUAL 
                            LOCATION OF THESE AND ALL OTHER  JUMPERS PLEASE 
                            REFER TO THE USERS GUIDE.



















				   245

================================================================================
Note 32.0                   KXT11-C Parallel I/O Prog                 No replies
FURILO::GIORGETTI                                  2476 lines  21-AUG-1985 23:19
--------------------------------------------------------------------------------



      +---------------+                                    +-----------------+
      | d i g i t a l |                                    |  uNOTE # 032    |
      +---------------+                                    +-----------------+

                                                                   
      +----------------------------------------------------+-----------------+
      | Title:  KXT11-C Parallel I/O Programming           | Date: 28-JUN-85 |
      +----------------------------------------------------+-----------------+
      | Originator:  Scott Tincher                         | Page 1 of 42    |
      +----------------------------------------------------+-----------------+


      The KXT11-CA is a single board computer  that  provides  the  user  with
      flexible  I/O  programming  options.   One  of  the onboard programmable
      devices is a 20 line parallel I/O port (PIO).  This note  will  describe
      the  operation  of  the  PIO and will provide some programming examples.
      Since the DIGITAL operating system MicroPower/Pascal provides  a  device
      handler for the PIO, the programming examples included in this note will
      be written in MACRO-11 for the user who wishes to  program  the  PIO  in
      MACRO-11.   The  example  programs  assume the user is familiar with the
      KXT11-C Software Toolkit for RT-11 or RSX.


      FEATURES/CAPABILITIES

      The PIO of the KXT11-C supplies the following features:

              o  Two 8-bit, double buffered, bidirectional I/O ports

              o  A 4-bit special purpose I/O port

              o  Four handshake modes

              o  REQUEST signal for utilizing the DMA controller

              o  Pattern recognition logic

              o  Three independent 16-bit counter/timers


      The two 8-bit ports (A and B) are  identical  except  that  Port  B  can
      provide  external  access  to  Counter/Timers 1 and 2.  Each port may be
      configured under program control as a single  or  double  buffered  port
      with handshake logic or as a bit port for control applications.  Pattern
      recognition logic is also included in  each  port.   This  logic  allows
      interrupt generation whenever a specific pattern is recognized.  Ports A
      and B may be linked to form a 16-bit port with handshake.

      When Port A or B is used as a port with handshake the control lines  are
      supplied  by  a  special 4-bit port (Port C).  If no handshake lines are
      required then Port C may be used as a bit port.  Port  C  also  provides
      external  access  to  Counter/Timer 3 and a REQUEST line that allows the

                                  247

uNOTE # 032
Page 2 of 42


      PIO to utilize the DMA controller when transfering data.

      The  PIO  supplies  three  identical   16-bit   Counter/Timers.    These
      Counter/Timers  operate  at  a  frequency  of  2  MHz  which  provides a
      resolution of 500 ns.  Each Counter/Timer may operate with one of  three
      output duty cycles:  pulse, one-shot, or square-wave.  In addition, each
      unit may operate as retriggerable or non-retriggerable.


      REGISTER DESCRIPTION

      The following section provides a brief description of the  registers  of
      the PIO.

      MASTER CONTROL REGISTERS

      There are two registers that control the overall function  of  the  PIO,
      the  Master  Interrupt  Control  Register  and  the Master Configuration
      Control Register.


      Master Interrupt Control Register

                        +-------------------------------+
                        | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
                        +-------------------------------+

                                Address = 177000

        Bit 7:  Master Interrupt Enable (MIE)

              0 - Inhibits this device from requesting an interrupt or 
                  responding to an interrupt acknowledge.
              1 - Allows interrupt logic to operate normally.

        Bits 6,5,4,3,2,1:  These bits must be programmed to zero.

        Bit 0:  Reset

              0 - Clears the reset bit and allows the other registers to 
                  function properly.
              1 - Resets the device.  While this bit is 1 reads of other 
                  registers will be 0 and writes to other registers will be
                  ignored.  This bit is cleared only by writing a 0 to the
                  RESET bit.








                                  248

                                                           uNOTE # 032
                                                          Page 3 of 42


      Master Configuration Control Register

                        +-------------------------------+
                        | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
                        +-------------------------------+

                                Address = 177002

        Bit 7:  Port B Enable (PBE)

              0 - Inhibits Port B from issuing an interrupt request and forces
                  tth Port B I/O lines into a high impedance state.
              1 - Allows Port B to operate normally.

        Bit 6:  Counter/Timer 1 Enable (CT1E)

              0 - Inhibits Counter/Timer 1 from issuing an interrupt request
                  and clears the Count In Progress (CIP) flag.  All trigger
                  inputs are ignored.
              1 - Allows Counter/Timer 1 to operate normally.

        Bit 5:  Counter/Timer 2 Enable (CT2E)

              Provides the same functions for Counter/Timer 2 that CT1E does
              for Counter/Timer 1.

        Bit 4:  Port C and Counter/Timer 3 Enable (PCE) and (CT3E)

              Provides the same functions for Port C that PBE does for Port B
              and the same functions for Counter/Timer 3 that CT1E does for
              Counter/Timer 1.

        Bit 3:  Port Link Control (PLC)

              0 - Allows Ports A and B to operate independently.
              1 - Links Ports A and B to form a 16-bit port.  In this mode
                  Port A's handshake and command and status registers are
                  used.  Port B is specified as a bit port.  This bit must be
                  set before the ports are enabled.

        Bit 2:  Port A Enable (PAE)

              Provides the same functions for Port A that PBE provides for
              Port B.

        Bits 1,0:  Counter/Timer Link Controls

              These two bits specify how Counter/Timers 1 and 2 are linked
              according to the following table:




                                  249

uNOTE # 032
Page 4 of 42


              Bit 1   Bit 0
                0       0     Counter/Timers are independent
                0       1     C/T 1's output (inverted) gates C/T 2
                1       0     C/T 1's output (inverted) triggers C/T 2
                1       1     C/T 1's output (inverted) is C/T 2's count input

              The Counter/Timers must be linked before they are enabled.


      PORT SPECIFICATION REGISTERS

      Ports A and B both utilize the following port specification registers:

      Port Mode Specification Register

                        +-------------------------------+
                        | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
                        +-------------------------------+

                                 Port A = 177100
                                 Port B = 177120

        A RESET forces all of these bits to 0.  All bits are read/write.

        Bits 7,6:  Port Type Select

              These two bits specify the port type as defined by the
              following table:

                 Bit 7   Bit 6
                   0       0     Bit port (No handshake)
                   0       1     Input port with handshake
                   1       0     Output port with handshake
                   1       1     Bidirectional port with handshake

        Bit 5:  Interrupt on Two Bytes (ITB)

              0 - Indicates that Interrupt Pending (IP) should be set when
                  one byte of data is available for transfer.  For an input
                  port IP is set when the Input Data Register is full.  For an
                  output port IP is set when the Output Data Register is
                  empty.
              1 - Indicates that IP should be set when two bytes of data are
                  available for transfer.  For an input port IP is set when
                  both the Input Data Register and the Input Buffer Register
                  are full.  For an output port IP is set when both the Output
                  Data Register and the Output Data Buffer are empty.

                  This bit must be set to zero for ports specified as bit
                  ports, single-buffered ports, or bidirectional ports.



                                  250

                                                           uNOTE # 032
                                                          Page 5 of 42


        Bit 4:  Single Buffered (SB)

              0 - Indicates that the port is double-buffered.
              1 - Indicates the the port is single-buffered.

              This bit is always 0 for bit ports.

        Bit 3:  Interrupt on Match Only (IMO)

              0 - Port operates normally.
              1 - An interrupt is generated when the data moved into the Input
                  Data Register or out of the Output Data Register matches the
                  pattern specification.

        Bits 2,1:  Pattern Mode Specification Bits

              These bits define the operation of the pattern recognition logic
              as shown by the following table:

              Bit 2   Bit 1
                0       0      Disable Pattern Match
                0       1      AND Mode
                1       0      OR Mode
                1       1      OR-Priority Encoded Vector Mode

        Bit 0:  Latch on Pattern Match (LPM) or Deskew Timer Enable (DTE)

              When a port is used as a bit port the LPM function is used.
              When a port with handshake is used the DTE function is used.

              LPM:
              0 - Pattern matches are detected but the data read from the port
                  follows the port pins.
              1 - When a pattern match is detected the input data at the port
                  is latched.

              DTE:
              0 - The deskew timer is not activated.
              1 - The deskew timer is activated to perform delay functions as 
                  set in the Port Handshake Specification Register.


      Port Handshake Specification Register

                        +-------------------------------+
                        | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
                        +-------------------------------+

                                 Port A = 177102
                                 Port B = 177122



                                  251

uNOTE # 032
Page 6 of 42


        These bits are ignored if the port is a bit port.  A RESET forces all
        bits to 0.  All bits are read/write.

        Bits 7,6:  Handshake Type Specification Bits

              These bits define the type of handshake a port will use as shown
              by the following table:

              Bit 7   Bit 6
                0       0      Interlocked Handshake
                0       1      Strobed Handshake
                1       0      Pulsed Handshake
                1       1      3-Wire Handshake

              The Pulsed and 3-Wire Handshakes must not be specified for
              bidirectional ports.  Only one port at a time may use the Pulsed
              Handshake.  If one port uses the 3-Wire Handshake the other port
              must be specified as a bit port.

        Bits 5,4,3:  REQUEST/WAIT Specification Bits (RWS)

              The WAIT function is not implemented on the KXT11-C.  These bits
              define the utilization of the REQUEST line as shown by the
              following table:

              Bit 5   Bit 4   Bit 3
                0       0       0      REQUEST disabled
                0       0       1      Not supported
                0       1       1      Not supported
                1       0       0      Special REQUEST
                1       0       1      Output REQUEST
                1       1       1      Input REQUEST

              Only Port A may use the REQUEST capability - Port B must be
              programmed as a bit port.

        Bits 2,1,0:  Deskew Time Specification Bits

              These bits specify the amount of deskew time to be provided for
              output data.  They define the minimum number of Peripheral Clock
              (PCLK) cycles of delay between the output of a new byte of data 
              and the handshake logic indicating that new data is available.
              PCLK = 250 ns.  0 PCLK cycles are chosen by setting DTE=0 in the
              Port Mode Specification Register.









                                  252

                                                           uNOTE # 032
                                                          Page 7 of 42


                         Bit 2   Bit 1   Bit 0         PCLK cycles
                           0       0       0                2
                           0       0       1                4
                           0       1       0                6
                           0       1       1                8
                           1       0       0               10
                           1       0       1               12
                           1       1       0               14
                           1       1       1               16


      Port Command and Status Register

                        +-------------------------------+
                        | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
                        +-------------------------------+

                                 Port A = 177020
                                 Port B = 177022

        A RESET forces ORE to 1 and all other bits to 0.  All bits are
        readable and four are writeable.

        Bit 7:  Interrupt Under Service  (IUS)

              0 - Cleared to indicate that the port is not servicing an
                  interrupt.
              1 - Indicates that that the port has been recognized by an
                  interrupt acknowledge sequence.

        Bit 6:  Interrupt Enable (IE)

              0 - Interrupt logic disabled.  The port is unable to request an
                  interrupt or to respond to an interrupt acknowledge.
              1 - Interrupt logic operates normally.

        Bit 5:  Interrupt Pending (IP)

              0 - Cleared to indicate that the port does not require service.
              1 - Set to indicate the port needs service because of a pattern
                  match, a handshake, or an error.

        Bits 7, 6, and 5 are written using the following codes:










                                  253

uNOTE # 032
Page 8 of 42


              Bit 7   Bit 6   Bit 5
                0       0       0       Null code
                0       0       1       Clear IP and IUS
                0       1       0       Set IUS
                0       1       1       Clear IUS
                1       0       0       Set IP
                1       0       1       Clear IP
                1       1       0       Set IE
                1       1       1       Clear IE

        Bit 4:  Interrupt Error (ERR)

              This bit is set to 1 when using a a bit port with pattern match
              enabled if a second match occurs before the previous match is
              acknowledged.  This is a read-only bit.

        Bit 3:  Output Data Register Empty (ORE)

              A status bit that indicates when an output port's Output Data
              Register is empty.  This bit can only be cleared by writing to
              the data register.  This is a read-only bit.

        Bit 2:  Input Data Register Full (IRF)

              A status bit that indicates if an input port's Input Data
              Register is full.  This bit can only be cleared by reading the
              Input Data Register.  This is a read-only bit.

        Bit 1:  Pattern Match Flag (PMF)

              If the port pattern match logic is enabled this bit will
              indicate when a match is detected.  This bit is read-only.

        Bit 0:  Interrupt on Error (IOE)

              0 - Disables the generation of an interrupt if an error occurs
                  within the pattern match logic.
              1 - Enables the generation of an interrupt if an error occurs
                  within the pattern match logic.

              This bit is valid only for bit ports with pattern match logic
              enabled.  It is ignored by ports with handshake and should be
              programmed to 0.


      BIT PATH DEFINITION REGISTERS

      Each port has a set of these registers.  Only the four least significant
      bits are valid in the port C registers.




                                  254

                                                           uNOTE # 032
                                                          Page 9 of 42


      Data Path Polarity Registers

        These registers define whether the bits in a port are inverting or
        non-inverting.  These bits are cleared by a RESET and are read/write.

                        +-------------------------------+
                        | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
                        +-------------------------------+

                                 Port A = 177104
                                 Port B = 177124
                                 Port C = 177012

                                 0 = Non-inverting
                                 1 = Inverting


      Date Direction Registers

        These registers are ignored by ports with handshake.  For bit ports
        they define the data direction for each bit.  These bits are cleared
        by a RESET and are read/write.

                        +-------------------------------+
                        | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
                        +-------------------------------+

                                 Port A = 177106
                                 Port B = 177126
                                 Port C = 177014

                                 0 = Output bit
                                 1 = Input bit


      Special I/O Control Registers

        These registers supply special characteristics to the port's data
        paths.  A RESET clears all bits to 0.  All bits are read/write.

                        +-------------------------------+
                        | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
                        +-------------------------------+

                                 Port A = 177110
                                 Port B = 177130
                                 Port C = 177016

                            0 = Normal Input or Output
                            1 = Input with 1's catcher



                                  255

uNOTE # 032
Page 10 of 42


      PATTERN DEFINITION REGISTERS

      These registers are used collectively to specify the match pattern for a
      port.  A RESET clears all bits to 0.  All bits are read/write.

      Pattern Polarity Registers (PPR)

                        +-------------------------------+
                        | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
                        +-------------------------------+

                                 Port A = 177112
                                 Port B = 177132

      Pattern Transition Registers (PTR)

                        +-------------------------------+
                        | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
                        +-------------------------------+

                                 Port A = 177114
                                 Port B = 177134

      Pattern Mask Registers (PMR)

                        +-------------------------------+
                        | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
                        +-------------------------------+

                                 Port A = 177116
                                 Port B = 177136

        The pattern specification for each bit is shown in the following
        table:

                        PPR   PTR   PMR
                         0     0     0     Bit masked off
                         0     1     0     Any transition
                         1     0     0     Zero
                         1     0     1     One
                         1     1     0     One to zero transition
                         1     1     1     Zero to one transition


      PORT DATA REGISTERS

      Ports A and B have a data path that consists of three registers: an
      Input Data Register, and Output Data Register, and a Buffer Register.
      The Buffer Register is used to buffer the input or output data of a port
      with handshake.  It is also used by bit ports to latch data when pattern
      matching is enabled.


                                  256

                                                           uNOTE # 032
                                                         Page 11 of 42


      Port A and B Data Registers

                        +-------------------------------+
                        | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
                        +-------------------------------+

                                 Port A = 177114
                                 Port B = 177134


      The Port C data register consists of two registers:  an Input Data
      register and an Output Data register.  Because Port C is only 4 bits
      wide the least significant four bits of the data register are used for
      the data path.  The four most significant bits are used as a write-
      protect mask for the four least significant bits.

      Port C Data Register

                        +-------------------------------+
                        | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
                        +-------------------------------+
                          |   |   |   |   ^   ^   ^   ^
                          |   |   |   |   |   |   |   |
                          |   |   |   +---|---|---|---+
                          |   |   +-------|---|---+
                          |   +-----------|---+
                          +---------------+

      Bits 7,6,5,4:  0 = Writing of corresponding LSB enabled
                     1 = Writing of corresponding LSB inhibited

                                 Port C = 177036


      COUNTER/TIMER CONTROL REGISTERS

      Each counter/timer has a set of Counter/Timer Control registers to
      specify the operation of the counter/timers.

      Counter/Timer Mode Specification Registers

        These registers define the mode of operation for the counter/timers
        and specify the external control and status lines to provide for it.
        A RESET clears all bits to 0.  All bits are read/write.

                        +-------------------------------+
                        | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
                        +-------------------------------+

                            Counter/Timer 1 = 177070
                            Counter/Timer 2 = 177072
                            Counter/Timer 3 = 177074

                                  257

uNOTE # 032
Page 12 of 42


      Bit 7:  Continuous/Single Cycle

              0 - When the counter reaches 0 the countdown sequence is
                  terminated.
              1 - When the counter reaches 0 the time constant value is
                  reloaded and the countdown sequence is repeated.

      Bit 6:  External Output Enable (EOE)

              0 - No external access.
              1 - The output of the counter/timer is available on the I/O pin
                  associated with that counter/timer.  (See table 2 for pin
                  assignments.)

      Bit 5:  External Count Enable (ECE)

              0 - No external access.
              1 - The I/O line of the port associated with the counter/timer
                  is used as an external counter input.  (See table 2 for pin
                  assignments.)

      Bit 4:  External Trigger Enable (ETE)

              0 - No external access
              1 - The I/O line of the port associated with the counter/timer
                  is used as a trigger input to the counter/timer.  (See
                  table 2 for pin assignments.)

      Bit 3:  External Gate Enable (EGE)

              0 - No external access
              1 - The I/O line of the port associated with the counter/timer
                  is used as an external gate input to the counter/timer.
                  This allows the external line to suspend/continue the
                  countdown in progress by toggling the line.  (See table
                  2 for pin assignments.)

      Bit 2:  Retrigger Enable Bit (REB)

              0 - Triggers (external or internal) that occur during a
                  countdown sequence are ignored.
              1 - Triggers that occur during a countdown sequence cause a
                  new countdown to begin.

      Bits 1,0:  Output Duty Cycle Selects

              These two bits select the output duty cycle as shown in the
              following table:





                                  258

                                                           uNOTE # 032
                                                         Page 13 of 42


              Bit 1   Bit 0
                0       0      Pulse Output
                0       1      One-Shot Output
                1       0      Square Wave Output
                1       1      Do not use

              See figure 2 for a description of each output duty cycle.


      Counter/Timer Command and Status Registers

        Each counter/timer contains a command and status register for
        controlling the operation of the counter/timer.  A RESET clears all
        bits to 0.

                        +-------------------------------+
                        | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
                        +-------------------------------+

                            Counter/Timer 1 = 177024
                            Counter/Timer 2 = 177026
                            Counter/Timer 3 = 177030

      Bit 7:  Interrupt Under Service (IUS)

              The operation of the this bit is the same as the IUS bit
              described on page *.

      Bit 6:  Interrupt Enable (IE)

              The operation of the this bit is the same as the IE bit
              described on page *.

      Bit 5:  Interrupt Pending (IP)

              This bit is set to 1 to indicate that the counter/timer needs
              to be serviced.  It is automatically set to 1 each time the
              counter/timer reaches its terminal count.

        The IUS, IE, IP bits are written by using the codes shown in the
        following table:

              Bit 7   Bit 6   Bit 5
                0       0       0       Null code
                0       0       1       Clear IP and IUS
                0       1       0       Set IUS
                0       1       1       Clear IUS
                1       0       0       Set IP
                1       0       1       Clear IP
                1       1       0       Set IE
                1       1       1       Clear IE


                                  259

uNOTE # 032
Page 14 of 42


      Bit 4:  Interrupt Error (ERR)

              This bit is set to indicate that the counter/timer has reached
              a terminal count before the previous terminal count has been
              serviced.

      Bit 3:  Read Counter Control (RCC)

              Writing this bit to a 1 causes the contents of the Counter/Timer
              Current Count Register (CCR), which normally follows the down-
              counter, to be frozen until the least-significant byte of the
              CCR is read.

      Bit 2:  Gate Command Bit (GCB)

              0 - Halts the countdown sequence.
              1 - Starts or resumes the countdown sequence.

      Bit 1:  Trigger Command Bit (TCB)

              When written with a 1, this bit causes the down-counter to be
              loaded with the time constant value and a countdown sequence
              to be initiated.

      Bit 0:  Count in Progress (CIP)

              This status bit is set to 1 to indicate that a countdown
              sequence is in progress.  It is automatically set to 0 when
              the down-counter reaches 0.


      Counter/Timer Time Constant Registers

        These registers contain the time constant value that is loaded into
        the down-counter when a trigger is detected.  These registers are 16
        bits wide and are accessed as two 8-bit registers.  (Bit 7 of the
        most-significant byte is bit 15 of the Time Constant register).  A
        RESET does not effect these registers.

       Bit 15                                                          Bit 0
        <------------- MSB ------------->  <------------- LSB ------------->
        +-------------------------------+  +-------------------------------+
        | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |  | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
        +-------------------------------+  +-------------------------------+

          Counter/Timer 1 MSB = 177054       Counter/Timer 1 LSB = 177056
          Counter/Timer 2 MSB = 177060       Counter/Timer 2 LSB = 177062
          Counter/Timer 3 MSB = 177064       Counter/Timer 3 LSB = 177066





                                  260

                                                           uNOTE # 032
                                                         Page 15 of 42


      Counter/Timer Current Count Registers

        These 16-bit registers follow the contents of the appropriate down-
        counter until a 1 is written into the RCC register.  At that time the
        contents of the CCR are frozen until the least-significant byte of the
        CCR is read.  A RESET forces the CCR to follow the down-counter again.

       Bit 15                                                          Bit 0
        <------------- MSB ------------->  <------------- LSB ------------->
        +-------------------------------+  +-------------------------------+
        | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |  | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
        +-------------------------------+  +-------------------------------+

          Counter/Timer 1 MSB = 177040       Counter/Timer 1 LSB = 177042
          Counter/Timer 2 MSB = 177044       Counter/Timer 2 LSB = 177046
          Counter/Timer 3 MSB = 177050       Counter/Timer 3 LSB = 177052


      INTERRUPT RELATED REGISTERS

      These registers contain the interrupt vectors output during an interrupt
      acknowledge sequence.  Registers are provided for Port A, Port B, one to
      be shared by the Counter/Timers.  Another register is provided to
      indicate which devices need service in a polled environment.

      Interrupt Vector Registers

        These vectors contain the vector output when the source of an
        interrupt is acknowledged.  If Master Interrupt Enable = 1 then the
        vector register returns status when read according to the following
        table:

        Port Vector Status
        OR-Priority Encoded Vector Mode:

        Bit 3   Bit 2   Bit 1
          x       x       x     Encodes the number of the highest-priority
                                bit with a match

        All other modes:

        Bit 3   Bit 2   Bit 1
         ORE     IRF     PMF    Normal
          0       0       0     Error

        Counter/Timer Status

        Bit 2   Bit 1
          0       0      Counter/Timer 3
          0       1      Counter/Timer 2
          1       0      Counter/Timer 1
          1       1      Error

                                  261

uNOTE # 032
Page 16 of 42


                        +-------------------------------+
                        | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
                        +-------------------------------+

                                 Port A = 177004
                                 Port B = 177006
                             Counter/Timers = 177010

        The native firmware of the KXT11-C initializes these interrupt vectors
        to the following values:

        Port A = 200
        Port B = 204
        Counter/Timers = 210

      Current Vector Register

        When read, this register returns the interrupt vector that would have
        been output by the device during an interrupt acknowledge cycle if its
        IEI input had been high.  The vector returned corresponds to the
        highest priority IP independent of IUS.  The order of priority is:
        Counter/Timer 3, Port A, Counter/Timer 2, Port B, Counter/Timer 1.  If
        no enabled interrupts are pending, a pattern of ones is returned.
        This is useful in a polled environment.

                        +-------------------------------+
                        | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
                        +-------------------------------+

                                Address = 177076


      I/O BUFFER CONTROL REGISTER

      The PIO chip is protected from the connector by a set of buffers.  These
      buffers comply with the IEEE 488 electrical standards.  The buffers
      allow the ports to configured as inputs or outputs.  They also allow the
      ports to be configured as open collectors or active pull-ups.

       +---------------------------------------------------------------------+
       | 15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
       +---------------------------------------------------------------------+

                                   Address = 177140

      Bit 15:  PCTT  (Cleared on RESET)

               0 - Configures the Port C drivers for open collector
               1 - Configures the Port C drivers for active pull-up




                                  262

                                                           uNOTE # 032
                                                         Page 17 of 42


      Bit 14:  PABTT  (Cleared on RESET)

               0 - Configures the Port A and B drivers for open collector
               1 - Configures the Port A and B drivers for active pull-up

      Bits 13:10:  PC DIR  (Cleared on RESET)

               0 - Port C bit is a receiver
               1 - Port C bit is a driver

      Bit 9:  PAHN DIR  (Cleared on RESET)

               0 - Port A high nibble bits (4:7) are receivers
               1 - Port A high nibble bits are drivers

      Bit 8:  PALN DIR  (Cleared on RESET)

               0 - Port A low nibble bits (0:3) are receivers
               1 - Port A low nibble bits are drivers

      Bits 7:0:  PB DIR  (Cleared on RESET)

               0 - Port B bit is a receiver
               1 - Port B bit is a driver



      PROGRAMMING THE I/O PORTS

      This section will describe how to program  the  I/O  ports  and  provide
      example  programs.   In particular this section will describe how to use
      the I/O ports in the following modes:   as  bit  ports,  as  ports  with
      handshake,  in 16-bit linked mode, and with the DMA controller.  The use
      of the pattern recognition logic will also be discussed.

      Programming the I/O Ports as Bit Ports

      Using the I/O ports as bit ports provides up to 20 lines for control and
      status.  Each bit in ports B and C may be independently configured to be
      an input or an output.  Port A must be configured on  a  nibble  (4-bit)
      basis.

      Programming the PIO as a bit port is straight-forward.  First, the  Port
      Mode  Specification  Register  is  used to select the port as a bit port
      with/without pattern matching.  Then the Bit Path  Definition  Registers
      are   used   to   determine   the   polarity,   direction,  and  special
      characteristics of the bits of the  port.   If  pattern  recognition  is
      enabled  the  Pattern Definition Registers must also be initialized.  It
      is then a simple matter to write to the output data  buffer  to  provide
      the correct control signals and to read the input data buffer to monitor
      status.


                                  263

uNOTE # 032
Page 18 of 42


      The following program provides an example for using the PIO in  the  bit
      mode:

                .TITLE  PIO1.MAC
        ;+
        ;  This program provides an example of how to program the PIO's
        ;  I/O ports as bit ports.  This program utilizes the PIO
        ;  loopback connector (Part #H3021 or 54-16227) which makes the
        ;  following connections:
        ;
        ;                       A0  --  B0
        ;                       A1  --  B1
        ;                           .
        ;                           .
        ;                       A7  --  B7
        ;                       C0  --  C3
        ;                       C1  --  C2
        ;
        ;  After this program has been assembled and linked on the
        ;  development machine use the KUI utility of the KXT11-C Software
        ;  Toolkit to load the program into the KXT11-C to execute as
        ;  shown in this example:
        ;
        ;  SET 2
        ;  LOAD PIO1.SAV
        ;  EXECUTE
        ;  !ODT
        ;  !
        ;  !001152
        ;  !R2/000000 
        ;  !1154/041101 
        ;  !001156/042103 
        ;  !001160/043105 
        ;  !001162/177507 
        ;  !001164/041101 
        ;  !001166/042103 
        ;  !001170/043105 
        ;  !001172/000107 
        ;  !001174/000000 
        ;  !
        ;  EXIT
        ;
        ;  A non-zero result in R2 indicates that an error has occurred.  (Try
        ;  running the test without the loopback connector).  Location 1154 is
        ;  the beginning of the output buffer.  Location 1164 is the beginning
        ;  of the input buffer.
        ;-
                ; Register Assignments

                MIC     ==  177000
                MCC     ==  177002


                                  264

                                                           uNOTE # 032
                                                         Page 19 of 42


                PAMODE  ==  177100
                PAPOL   ==  177104
                PADDIR  ==  177106
                PASIO   ==  177110
                PADATA  ==  177032

                PBMODE  ==  177120
                PBPOL   ==  177124
                PBDDIR  ==  177126
                PBSIO   ==  177130
                PBDATA  ==  177034

                IOCNTL  ==  177140

        START::
                MTPS    #340            ; Inhibit recognition of
                                        ;  interrupts

                ;  Initialize PIO
                MOVB    #1,MIC          ; Reset device and inhibit interrupt
                                        ;  requests
                CLRB    MIC             ; Enable device (interrupts still
                                        ;  inhibited)

                ;  Set-up Port A
                CLRB    PAMODE          ; Port A:  bit port, no pattern match
                CLRB    PAPOL           ; Port A bits are non-inverting
                CLRB    PADDIR          ; Port A bits are output bits
                CLRB    PASIO           ; Normal output

                ;  Set-up Port B
                CLRB    PBMODE          ; Port B:  bit port, no pattern match
                CLRB    PBPOL           ; Port B bits are non-inverting
                MOVB    #377,PBDDIR     ; Port B bits are input bits
                CLRB    PBSIO           ; Normal input

                ;  Set-up the PIO buffers
                MOV     #1400,IOCNTL    ; configure the PIO buffers for
                                        ;  A=output and B=input

                ;  Initialize GPRs
                MOV     #OUTBUF,R0      ; Point to data to be output
                MOV     #INBUF,R1       ; Point to input data buffer
                CLR     R2              ; R2 will indicate error status

                ;  Flush input buffer
                TSTB    PBDATA

                ;  Enable Ports A and B and send the data
                MOVB    #204,MCC        ; Enable ports A and B



                                  265

uNOTE # 032
Page 20 of 42


        1$:     MOVB    (R0)+,PADATA    ; Move data out of Port A
                NOP                     ;  .
                                        ;  .
                MOVB    PBDATA,(R1)+    ; and into Port B

                ;  Test to see if done
                TSTB    (R0)            ; IF (R0) is positive
                BPL     1$              ; THEN transfer another byte
                                        ; ELSE check if data is valid

                ;  Compare original data with received data
                MOV     #OUTBUF,R0      ; Point to output data buffer
                MOV     #INBUF,R1       ; Point to input data buffer

                ;  Test to see if done
        2$:     TSTB    (R0)            ; IF (R0) is negative
                BMI     3$              ;  THEN done comparing
                                        ;  ELSE do another compare
                CMPB    (R0)+,(R1)+     ; Compare bytes
                BEQ     2$              ; IF bytes are equal
                                        ;  THEN test another pair
                                        ;  ELSE indicate error
                INC     R2              ; A non-zero value of R2 indicates
                                        ;  an error
        3$:     BR      .               ; Branch here upon completion

        OUTBUF: .BYTE   101,102,103,104,105,106,107,-1
                .EVEN
        INBUF:  .BLKB   7

                .END    START






















                                  266

                                                           uNOTE # 032
                                                         Page 21 of 42


      Programming the I/O Ports as Ports with Handshake

      Ports A and B may be configured as ports with  handshake  to  facilitate
      transferring  data  on  a byte-by-byte basis.  Port C is used to provide
      the handshake lines.  In addition, Port C may use the  REQUEST  line  to
      utilize  a  DMA  controller  to  transfer  the  data.  See table 1 for a
      description of the Port C handshake lines.  Figure 1 shows how two  PIOs
      can  be  connected  directly together to transfer data and the handshake
      lines that are utilized.

                                PIO Handshake Lines

                         OUTPUT                        INPUT
                       +--------+                   +--------+
                       |        |                   |        |
                       |        |-----------------\ |        |
                       |  PIO   |       DATA       \|  PIO   |
                       |        |                  /|        |
                       |        |-----------------/ |        |
                       |        |                   |        |
                       |     DAV| ----------------->|ACKIN   |
                       |   ACKIN|<----------------- |RFD     |
                       |        |                   |        |
                       +--------+                   +--------+ 

                                    - Figure 1 -

      The handshakes that are available are:   Interlocked,  Strobed,  Pulsed,
      and 3-Wire.  A short description of each handshake type follows:

      When using the Interlocked Handshake any  action  by  the  PIO  must  be
      acknowledged  by  the  external  device  before the next action can take
      place.  In other words, an output port does not indicate that it has new
      data  available until the external device indicates that it is ready for
      data.  Likewise, and input port does not indicate that it is  ready  for
      new  data  until the external device indicates that the previous byte of
      data is no longer available,  thereby  acknowledging  the  input  port's
      acceptance of the last byte.

      The Strobed Handshake uses external logic to "strobe" data into  or  out
      of  a  port.   In  contrast  to  the  Interlocked  handshake, the signal
      indicating that the port is ready for  another  data  transfer  operates
      independently  of  the ACKIN input.  External logic must ensure the data
      transfers at the appropriate speed.

      The Pulsed Handshake is used to interface to  mechanical  devices  which
      require  data to be held for relatively long periods of time in order to
      be gated in or out of  the  device.   The  logic  is  the  same  as  the
      Interlocked  Handshake  except  that  Counter/Timer  3  is linked to the
      handshake logic to add the appropriate delays to the handshake lines.

      The 3-Wire Handshake may be used so that one output port can communicate

                                  267

uNOTE # 032
Page 22 of 42


      to  several input ports simultaneously.  This is essentially the same as
      the Interlocked Handshake except that two individual lines are  used  to
      indicate  when  an  input  port  is ready for data (RFD) and when it has
      accepted data (DAC).  Because this handshake requires three  lines  only
      one port can use the 3-Wire Handshake at a time.

                               Port C Handshake Lines

                                                   Port C Bits

         Port A/B Configuration      Pin C3      Pin C2    Pin C1     Pin C0
      +----------------------------------------------------------------------+
      |Ports A & B = Bit Ports    |Bit I/O    |Bit I/O  |Bit I/O    |Bit I/O |
      |-----------------------------------------------------------------------
      |Port A = Input or Output   |RFD or DAV |ACKIN    |REQUEST    |Bit I/O |
      |(Interlocked, Strobed,     |           |         |or Bit I/O |        |
      | or Pulsed Handshake)*     |           |         |           |        |
      |-----------------------------------------------------------------------
      |Port B = Input or Output   |REQUEST    |Bit I/O  |RFD or DAV |ACKIN   |
      |(Interlocked, Strobed,     |or Bit I/O |         |           |        |
      | or Pulsed Handshake)*     |           |         |           |        |
      |-----------------------------------------------------------------------
      |Port A or B = Input Port   |RFD        |DAV      |REQUEST    |DAC     |
      |(3-Wire Handshake)         |(Output)   |(Input)  |or Bit I/O |(Output)|
      |-----------------------------------------------------------------------
      |Port A or B = Output Port  |DAV        |DAC      |REQUEST    |RFD     |
      |(3-Wire Handshake)         |(Output)   |(Input)  |or Bit I/O |(Input) |
      |-----------------------------------------------------------------------
      |Port A or B = Bidirectional|RFD or DAV |ACKIN    |REQUEST    |IN/OUT  |
      |(Interlocked or Strobed    |           |         |or Bit I/O |        |
      | Handshake)                |           |         |           |        |
      +----------------------------------------------------------------------+
        *  Both Ports A & B may be specified as input or output ports with
           the Interlocked, Strobed, or Pulsed Handshakes at the same time
           if neither uses REQUEST.  Only one port can use the Pulsed
           Handshake at a time.

                                    - Table 1 -

      When Ports A and B are configured as ports with handshake they must also
      be  configured  as  single- or double-buffered.  Double-buffering a port
      allows more time for the interrupt service routine to respond to a  data
      transfer.   A  second  byte  of data is input to or output from the port
      before the interrupt for the first byte is serviced.  A  single-buffered
      port is used where it is important to have byte-by-byte control over the
      transfer or where it is important to enter the interrupt service routine
      in a fixed amount of time after the data has been accepted/output.

      The REQUEST line may also be used by ports with handshake.  This control
      line  enables  the  PIO to signal the DMA controller of the KXT11-C that
      the  port  wishes  to  transfer  data  without  CPU  intervention.   The
      operation of the REQUEST line is dependent on the Interrupt on Two Bytes

                                  268

                                                           uNOTE # 032
                                                         Page 23 of 42


      (ITB) bit in the Port Mode Specification Register.  If ITB = 0 then  the
      REQUEST  line  goes  active anytime a byte is available to transfer.  If
      ITB = 1 then the REQUEST line  does  not  assert  until  two  bytes  are
      available  to  transfer.   The  implementation of the PIO on the KXT11-C
      requires that only Port A be used for DMA transfers.  Since the  REQUEST
      line  utilizes one of the Port C bits Port B must be programmed as a bit
      port when Port A uses the REQUEST facility.

      The following example programs display the capabilities of the PIO  used
      as a port with handshake:


                .TITLE  PIO2.MAC

        ;  This program demonstrates the ability of the PIO to transfer data
        ;  on a byte-by-byte basis.  The program uses the Interlocked
        ;  Handshake to transfer data from Port A to Port B.  Both ports are
        ;  configured as single-buffered.  The PIO loopback connector (part
        ;  #H3022 or 54-16227) or a functional equivalent is required to
        ;  successfully run this program.
        ;  
        ;  After this program has been assembled and linked on the
        ;  development machine use the KUI utility of the KXT11-C Software
        ;  Toolkit to load the program into the KXT11-C to execute as
        ;  shown in this example:
        ;
        ;  SET 2
        ;  LOAD PIO2.SAV
        ;  EXECUTE
        ;  !ODT
        ;  !
        ;  !001214
        ;  !1262/065151 
        ;  !001264/066153 
        ;  !001266/067155 
        ;  !001270/070157 
        ;  !001272/000377 
        ;  !001274/065151 
        ;  !001276/066153 
        ;  !001300/067155 
        ;  !001302/070157 
        ;  !001304/000000
        ;  !
        ;  EXIT
        ;
        ;  This verifies that the contents of the output buffer (location 1262
        ;  were successfully transferred to the input buffer (location 1274).
        ;  

                ; Register Assignments

                MIC     ==  177000

                                  269

uNOTE # 032
Page 24 of 42


                MCC     ==  177002

                PAVEC   ==  177004
                PASTAT  ==  177020
                PADATA  ==  177032
                PAMODE  ==  177100
                PAHDSH  ==  177102
                PAPOL   ==  177104
                PASIO   ==  177110

                PBVEC   ==  177006
                PBSTAT  ==  177022
                PBDATA  ==  177034
                PBMODE  ==  177120
                PBHDSH  ==  177122
                PBPOL   ==  177124
                PBSIO   ==  177130

                PCPOL   ==  177012
                PCDDIR  ==  177014

                IOCNTL  ==  177140

        START::
                MTPS    #340            ; Inhibit recognition of interrupts

                MOVB    #1,MIC          ; Reset device and inhibit interrupt
                                        ;  requests from the PIO
                CLRB    MIC             ; Enable device (interrupts still
                                        ;  inhibited)

                MOVB    #200,PAVEC
                MOV     #OUT,@#200      ; Set up Port A interrupt vector
                MOV     #340,@#202      ; ... and PSW

                MOVB    #204,PBVEC
                MOV     #IN,@#204       ; Set up Port B interrupt vector
                MOV     #340,@#206      ; ... and PSW

                ; Set-up Port A
                MOVB    #220,PAMODE     ; Port A: Output Port, single-buffered
                CLRB    PAHDSH          ; Use interlock handshake
                CLRB    PAPOL           ; Port A bits are non-inverting
                CLRB    PASIO           ; Normal output
                MOVB    #300,PASTAT     ; Enable Port A interrupts

                ; Set-up Port B
                MOVB    #120,PBMODE     ; Port B:  Input Port, single-buffered
                CLRB    PBHDSH          ; Use interlock handshake
                CLRB    PBPOL           ; Port B bits are non-inverting
                CLRB    PBSIO           ; Normal input
                MOVB    #300,PBSTAT     ; Enable Port B interrupts

                                  270

                                                           uNOTE # 032
                                                         Page 25 of 42


                ; Set-up the Port C handshake lines.
                ;  All handshake lines are configured as inputs - even
                ;  if they aren't!
                MOVB    #377,PCDDIR     ; Port C bits are inputs

                ; Set-up the PIO buffers
                MOV     #165400,IOCNTL  ; configure the PIO buffers for A=out
                                        ;  B=input, C0,C2=input, C1,C3=output

                ; Set-up data areas
                MOV     #OUTBUF,R0      ; Point to Output Buffer
                MOV     #INBUF,R1       ; Point to Input Buffer

                ; Enable Interrupts
                MOVB    #224,MCC        ; Enable ports A, B, and C
                MOVB    #200,MIC        ; Enable MIC
                MTPS    #0              ; Enable recognition of interrupts

                ; Start the first transfer
                MOVB    #200,PASTAT     ; Set IP to initiate a transfer

                BR      .               ; Wait here for the interrupts

        OUT::   
                TSTB    (R0)            ; IF (R0) are negative
                BMI     1$              ;  THEN transfers are complete
                                        ;  ELSE transfer another byte
                MOVB    (R0)+,PADATA    ; Move byte to the Port A output data 
                                        ;  register
                BR      2$
        1$:     MOVB    #240,PASTAT     ; Clear IP when done
        2$:     MOVB    #140,PASTAT     ; Clear IUS on each pass
                RTI             

        IN::
                MOVB    PBDATA,(R1)+    ; Move byte from Port B input data
                                        ;  register
                MOVB    #140,PBSTAT     ; Clear IUS on each pass
                RTI

        OUTBUF: .BYTE   151,152,153,154,155,156,157,160,-1
                .EVEN
        INBUF:  .BLKB   10

                .END    START








                                  271

uNOTE # 032
Page 26 of 42


                .TITLE  PIO3.MAC

        ;  This program is basically the same as PIO2.MAC with the
        ;  with the exception that the ports are double-buffered.
        ;  The PIO loopback connector (part #H3022 or 54-16227) or a
        ;  functional equivalent is required to successfully run this program.
        ;  
        ;  After this program has been assembled and linked on the
        ;  development machine use the KUI utility of the KXT11-C Software
        ;  Toolkit to load the program into the KXT11-C to execute as
        ;  shown in this example:
        ;
        ;  SET 2
        ;  LOAD PIO3.SAV
        ;  EXECUTE
        ;  !ODT
        ;  !
        ;  !001214
        ;  !1272/065151 
        ;  !001274/066153 
        ;  !001276/067155 
        ;  !001300/070157 
        ;  !001302/000377 
        ;  !001304/065151 
        ;  !001306/066153 
        ;  !001310/067155 
        ;  !001312/070157 
        ;  !001314/000000 
        ;  !
        ;  EXIT
        ;
        ;  This verifies that the contents of the output buffer (location 1272
        ;  were successfully transferred to the input buffer (location 1304).
        ;  

                ; Register Assignments

                MIC     ==  177000
                MCC     ==  177002

                PAVEC   ==  177004
                PASTAT  ==  177020
                PADATA  ==  177032
                PAMODE  ==  177100
                PAHDSH  ==  177102
                PAPOL   ==  177104
                PASIO   ==  177110

                PBVEC   ==  177006
                PBSTAT  ==  177022
                PBDATA  ==  177034
                PBMODE  ==  177120

                                  272

                                                           uNOTE # 032
                                                         Page 27 of 42


                PBHDSH  ==  177122
                PBPOL   ==  177124
                PBSIO   ==  177130

                PCPOL   ==  177012
                PCDDIR  ==  177014

                IOCNTL  ==  177140

        START::
                MTPS    #340            ; Inhibit recognition of interrupts

                MOVB    #1,MIC          ; Reset device and inhibit interrupt
                                        ;  requests from the PIO
                CLRB    MIC             ; Enable device (interrupts still
                                        ;  inhibited)

                MOVB    #200,PAVEC
                MOV     #OUT,@#200      ; Set up Port A interrupt vector
                MOV     #340,@#202      ; ... and PSW

                MOVB    #204,PBVEC
                MOV     #IN,@#204       ; Set up Port B interrupt vector
                MOV     #340,@#206      ; ... and PSW

                ; Set-up Port A
                MOVB    #240,PAMODE     ; Port A: Output Port, double-buffered
                CLRB    PAHDSH          ; Use interlock handshake
                CLRB    PAPOL           ; Port A bits are non-inverting
                CLRB    PASIO           ; Normal output
                MOVB    #300,PASTAT     ; Enable Port A interrupts

                ; Set-up Port B
                MOVB    #140,PBMODE     ; Port B:  Input Port, double-buffered
                CLRB    PBHDSH          ; Use interlock handshake
                CLRB    PBPOL           ; Port B bits are non-inverting
                CLRB    PBSIO           ; Normal input
                MOVB    #300,PBSTAT     ; Enable Port B interrupts

                ; Set-up the Port C handshake lines.
                ;  All handshake lines are configured as inputs - even
                ;  if they aren't!
                MOVB    #377,PCDDIR     ; Port C bits are inputs

                ; Set-up the PIO buffers
                MOV     #165400,IOCNTL  ; configure the PIO buffers for A=out
                                        ;  B=input, C0,C2=input, C1,C3=output

                ; Set-up data areas
                MOV     #OUTBUF,R0      ; Point to Output Buffer
                MOV     #INBUF,R1       ; Point to Input Buffer


                                  273

uNOTE # 032
Page 28 of 42


                ; Enable Interrupts
                MOVB    #224,MCC        ; Enable ports A, B, and C
                MOVB    #200,MIC        ; Enable MIC
                MTPS    #0              ; Enable recognition of interrupts

                ; Start the first transfer
                MOVB    #200,PASTAT     ; Set IP to initiate a transfer

                BR      .               ; Wait here for the interrupts

        OUT::   
                TSTB    (R0)            ; IF (R0) are negative
                BMI     1$              ;  THEN transfers are complete
                                        ;  ELSE transfer another byte
                MOVB    (R0)+,PADATA    ; Move 1st byte to the Port A output
                                        ;  data register
                MOVB    (R0)+,PADATA    ; Move 2nd byte to the Port A buffer
                                        ;  register
                BR      2$
        1$:     MOVB    #240,PASTAT     ; Clear IP when done
        2$:     MOVB    #140,PASTAT     ; Clear IUS on each pass
                RTI             

        IN::
                MOVB    PBDATA,(R1)+    ; Move 1st byte from Port B input data
                                        ;  register
                MOVB    PBDATA,(R1)+    ; Move 2nd byte from Port B buffer
                                        ;  register
                MOVB    #140,PBSTAT     ; Clear IUS on each pass
                RTI

        OUTBUF: .BYTE   151,152,153,154,155,156,157,160,-1
                .EVEN
        INBUF:  .BLKB   10

                .END    START

















                                  274

                                                           uNOTE # 032
                                                         Page 29 of 42


        ;  This example shows something a little more practical - one
        ;  KXT11-C transferring data to another.  Two programs follow:
        ;  one accepts data through Port B using the double-buffered
        ;  mode (PIO4I.MAC); the second one sends data out of Port A
        ;  using the double buffered mode (PIO4O.MAC).  In order to
        ;  successfully run these programs the KXT11-Cs must be connected
        ;  by a "straight-thru" ribbon cable which is given a half twist.
        ;  In other words, it should make the same connections that the
        ;  PIO loopback connector does. (A1-B1,A2-B2,...A7-B7,C0-C3,C1-C2).
        ;
        ;  Each program should be assembled and linked separately on the
        ;  development machine.  Then use the KUI utility of the KXT11-C
        ;  Software Toolkit to load the programs into the KXT11-Cs to execute
        ;  as shown in this example:
        ;
        ;  SET 3
        ;  LOAD PIO4I.SAV
        ;  EXECUTE
        ;  SET 2
        ;  LOAD PIO4O.SAV
        ;  EXECUTE
        ;  SET 3
        ;  !ODT
        ;  !
        ;  !001130
        ;  !1152/065151 
        ;  !001154/066153 
        ;  !001156/067155 
        ;  !001160/070157 
        ;  !001162/000000 
        ;  !
        ;  EXIT
        ;
        ;  This verifies that the data was successfully transferred to
        ;  the input buffer of KXT11-C #3.
        ;
        ;-------------------------------------------------------------------
        ;-------------------------------------------------------------------
                .TITLE  PIO4I.MAC

                ; Register Assignments

                MIC     ==  177000
                MCC     ==  177002

                PBVEC   ==  177006
                PBSTAT  ==  177022
                PBDATA  ==  177034
                PBMODE  ==  177120
                PBHDSH  ==  177122
                PBPOL   ==  177124
                PBDDIR  ==  177126

                                  275

uNOTE # 032
Page 30 of 42


                PBSIO   ==  177130

                PCDDIR  ==  177014

                IOCNTL  ==  177140

        START::
                MTPS    #340            ; Inhibit recognition of interrupts
                MOVB    #1,MIC          ; Reset device and inhibit interrupt
                                        ;  requests from the PIO
                CLRB    MIC             ; Enable device (interrupts still
                                        ;  inhibited)

                MOVB    #204,PBVEC
                MOV     #IN,@#204       ; Set up Port B interrupt vector
                MOV     #340,@#206      ; ... and PSW

                MOVB    #140,PBMODE     ; Port B:  Input Port, double-buffered
                CLRB    PBHDSH          ; Use interlock handshake
                CLR     PBPOL           ; Port B bits are non-inverting
                CLR     PBSIO           ; Normal input
                MOVB    #300,PBSTAT     ; Enable Port B interrupts

                MOVB    #377,PCDDIR     ; Port C bits are inputs

                MOV     #165400,IOCNTL  ; configure the PIO buffers for A=out
                                        ;  B=input, C0,C2=input, C1,C3=output

                MOV     #INBUF,R1       ; Point to input data buffer

                MOVB    #220,MCC        ; Enable ports B and C
                MOVB    #200,MIC        ; Enable MIC

                MTPS    #0              ; Enable recognition of interrupts
                BR      .               ; Wait here for the interrupts

        IN::
                MOVB    PBDATA,(R1)+    ; Move 1st byte from Port B input data
                                        ;  register
                MOVB    PBDATA,(R1)+    ; Move 2nd byte from Port B buffer
                                        ;  register
                MOVB    #140,PBSTAT     ; Clear IUS on each pass
                RTI

        INBUF:  .BLKB   10

                .END    START






                                  276

                                                           uNOTE # 032
                                                         Page 31 of 42


        ;-----------------------------------------------------------------
        ;-----------------------------------------------------------------

                .TITLE  PIO4O.MAC

                ; Register Assignments

                MIC     ==  177000
                MCC     ==  177002

                PAVEC   ==  177004
                PASTAT  ==  177020
                PADATA  ==  177032
                PAMODE  ==  177100
                PAHDSH  ==  177102
                PAPOL   ==  177104
                PADDIR  ==  177106
                PASIO   ==  177110

                PCPOL   ==  177012
                PCDDIR  ==  177014

                IOCNTL  ==  177140

        START::
                MTPS    #340            ; Inhibit recognition of interrupts
                MOVB    #1,MIC          ; Reset device and inhibit interrupt
                                        ;  requests from the PIO
                CLRB    MIC             ; Enable device (interrupts still
                                        ;  inhibited)

                MOVB    #200,PAVEC
                MOV     #OUT,@#200      ; Set up Port A interrupt vector
                MOV     #340,@#202      ; ... and PSW

                MOVB    #240,PAMODE     ; Port A: Output Port, double-buffered
                CLRB    PAHDSH          ; Use interlock handshake
                CLR     PAPOL           ; Port A bits are non-inverting
                CLR     PASIO           ; Normal output
                MOVB    #300,PASTAT     ; Enable Port A interrupts

                MOVB    #377,PCDDIR     ; Port C bits are inputs

                MOV     #165400,IOCNTL  ; configure the PIO buffers for A=out
                                        ;  B=input, C0,C2=input, C1,C3=output

                MOV     #OUTBUF,R0      ; Point to output data buffer

                MOVB    #24,MCC         ; Enable ports A  and C
                MOVB    #200,MIC        ; Enable MIC
                MTPS    #0              ; Enable recognition of interrupts


                                  277

uNOTE # 032
Page 32 of 42


                MOVB    #200,PASTAT     ; Set IP to initiate a transfer
                BR      .               ; Wait here for the interrupts

        OUT::
                TSTB    (R0)            ; IF (R0) are negative
                BMI     1$              ;  THEN all data has been transferred
                                        ;  ELSE do another transfer
                MOVB    (R0)+,PADATA    ; Move 1st byte to the Port A output
                                        ;  data register
                MOVB    (R0)+,PADATA    ; Move 2nd byte to the Port A buffer
                                        ;  register
                BR      2$
        1$:     MOVB    #240,PASTAT     ; Clear IP when done
        2$:     MOVB    #140,PASTAT     ; Clear IUS on each pass
                RTI             

        OUTBUF::.BYTE   151,152,153,154,155,156,157,160,-1

                .END    START


































                                  278

                                                           uNOTE # 032
                                                         Page 33 of 42


        ;  The following two programs demonstrate how the DTC may be used
        ;  to transfer data from the PIO to KXT11-C local memory.  DTC
        ;  transfers may only be accomplished using Port A of the PIO.
        ;  It is not possible to properly connect two PIOs with a ribbon
        ;  cable because the handshake lines will not align correctly when
        ;  connecting Port A to Port A.  Therefore it is necessary to build
        ;  a cable that makes the following connections:
        ;
        ;             Input Port A            Output Port A
        ;                  A0      <-------->       A0
        ;                  A1      <-------->       A1
        ;                   .                        .
        ;                   .                        .
        ;                  A7      <-------->       A7
        ;
        ;                  C2      <-------->       C3
        ;                  C3      <-------->       C2
        ;
        ;  It is also necessary to place a jumper between posts M48 and M49
        ;  so that the REQUEST line from the PIO may signal the DTC.  For more
        ;  information about programming the DTC please refer to Micronote 18.
        ;
        ;  After each program has been assembled and linked on the
        ;  development machine use the KUI utility of the KXT11-C Software
        ;  Toolkit to load the programs into a KXT11-C to execute as
        ;  shown in this example:
        ;
        ;  SET 3
        ;  LOAD PIO5I.SAV
        ;  EXECUTE
        ;  SET 2
        ;  LOAD PIO5O.SAV
        ;  EXECUTE
        ;  SET 3
        ;  !ODT
        ;  !
        ;  !001140
        ;  !1140/000777 
        ;  !001142/065151 
        ;  !001144/066153 
        ;  !001146/067155 
        ;  !001150/070157 
        ;  !001152/001602 
        ;  !
        ;
        ;  Examining the contents of the input buffer (location 1142)
        ;  verifies that the data was successfully transferred.
        ;
        ;------------------------------------------------------------
        ;
        ;------------------------------------------------------------
                .TITLE  PIO5I.MAC

                                  279

uNOTE # 032
Page 34 of 42


                ; This program transfers data from Port A of the PIO
                ; to local memory by utilizing the DTC

                ; Register Assignments

                MMREG   ==  174470
                CMDREG  ==  174454
                CASTF1  ==  174444
                CAOF1   ==  174440

                MIC     ==  177000
                MCC     ==  177002

                PAVEC   ==  177004
                PASTAT  ==  177020
                PADATA  ==  177032
                PAMODE  ==  177100
                PAHDSH  ==  177102
                PAPOL   ==  177104
                PADDIR  ==  177106
                PASIO   ==  177110

                PCPOL   ==  177012
                PCDDIR  ==  177014

                IOCNTL  ==  177140

        START::
                MTPS    #340            ; Inhibit recognition of interrupts

                ; Initialize the DTC - for more information on the DTC
                ; refer to Micronote #18.
                MOVB    #154,MMREG      ; Load Master Mode Reg to Disable DTC
                CLRB    CMDREG          ; Reset the DTC
                MOV     #0,CASTF1       ; Load the CH1 Register SEG/TAG
                MOV     #RELOAD,CAOF1   ; Load the CH1 Register Offset
                MOVB    #155,MMREG      ; Load Master Mode Reg to Enable DTC
                MOVB    #241,CMDREG     ; Start Chain Channel 1

                ; Initialize the PIO
                MOVB    #1,MIC          ; Reset device and inhibit interrupt
                                        ;  requests from the PIO
                CLRB    MIC             ; Enable device (interrupts still
                                        ;  inhibited)

                ; Set-up Port A
                MOVB    #120,PAMODE     ; Port A:  Input Port, single-buffered
                MOVB    #70,PAHDSH      ; Use interlock handshake, input
                                        ;  REQUEST
                CLR     PAPOL           ; Port A bits are non-inverting
                CLR     PASIO           ; Normal input


                                  280

                                                           uNOTE # 032
                                                         Page 35 of 42


                MOVB    #2,PCPOL        ; Invert pin C1 - this is the line
                                        ;  that is used for the REQUEST signal
                MOVB    #377,PCDDIR     ; Port C bits are inputs

                MOV     #164377,IOCNTL  ; configure the PIO buffers for A=in
                                        ;  B=output, C0,C2=input, C1,C3=output

                MOV     #INBUF,R1       ; Point to input data buffer

                MOVB    #24,MCC         ; Enable ports A and C

                BR      .               ; Wait here while the DMA transfers
                                        ;  take place

        INBUF:  .BLKB   10

        ; Chain Load Region

        RELOAD: .WORD   001602  ; Reload Word <Select CARA,CARB,COPC,CM>

                .WORD   000020  ; Current Address Register A Seg/Tag
                .WORD   padata+1; Current Address Register A Offset
                                ; <This local address is the source,
                                ;  its address is held constant, since
                                ;  the DTC is doing byte transfers specify
                                ;  the source address high byte>

                .WORD   000000  ; Current Address Register B Seg/Tag
                .WORD   inbuf   ; Current Address Register B Offset
                                ; <This local address is the destination>

                .WORD   000010  ; Current Operation Count <Transfer 8 words>

                .WORD   000000  ; Channel Mode Register High
                .WORD   000001  ; Channel Mode Register Low
                                ; <No match conditions, do nothing upon
                                ;  completion, transfer type = Single Transfer
                                ;  CARA = source, byte transfers>

                .END    START

        ;-----------------------------------------------------------------
        ;
        ;-----------------------------------------------------------------

                .TITLE  PIO5O.MAC

                ;  This program transfers data out of Port A of the PIO
                ;  utilizing the DTC

                ; Register Assignments


                                  281

uNOTE # 032
Page 36 of 42


                MMREG   ==  174470
                CMDREG  ==  174454
                CASTF1  ==  174444
                CAOF1   ==  174440

                MIC     ==  177000
                MCC     ==  177002

                PAVEC   ==  177004
                PASTAT  ==  177020
                PADATA  ==  177032
                PAMODE  ==  177100
                PAHDSH  ==  177102
                PAPOL   ==  177104
                PADDIR  ==  177106
                PASIO   ==  177110

                PCPOL   ==  177012
                PCDDIR  ==  177014

                IOCNTL  ==  177140

        START::
                MTPS    #340            ; Inhibit recognition of interrupts

                ; Initialize the DTC
                MOVB    #154,MMREG      ; Load Master Mode Reg to Disable DTC
                CLRB    CMDREG          ; Reset the DTC
                MOV     #0,CASTF1       ; Load the CH1 Register SEG/TAG
                MOV     #RELOAD,CAOF1   ; Load the CH1 Register Offset
                MOVB    #155,MMREG      ; Load Master Mode Reg to Enable DTC
                MOVB    #241,CMDREG     ; Start Chain Channel 1

                ; Initialize the PIO
                MOVB    #1,MIC          ; Reset device and inhibit interrupt
                                        ;  requests from PIO
                CLRB    MIC             ; Enable device (interrupts still
                                        ;  inhibited)

                ; Set-up Port A
                MOVB    #220,PAMODE     ; Port A: Output Port, single-buffered
                MOVB    #050,PAHDSH     ; Use interlock handshake, output
                                        ;  REQUEST
                CLR     PAPOL           ; Port A bits are non-inverting
                CLR     PASIO           ; Normal output

                MOVB    #2,PCPOL        ; Pin C1 must be inverted - this is
                                        ;  the line used to signal the DTC
                MOVB    #377,PCDDIR     ; Port C bits are inputs

                MOV     #165400,IOCNTL  ; configure the PIO buffers for A=out
                                        ;  B=input, C0,C2=input, C1,C3=output

                                  282

                                                           uNOTE # 032
                                                         Page 37 of 42


                MOV     #OUTBUF,R0      ; Point to output data buffer

                MOVB    #24,MCC         ; Enable ports A and C

                BR      .               ; Wait here while the DMA transfers
                                        ;  complete

        OUTBUF::.BYTE   151,152,153,154,155,156,157,160,-1
                .EVEN

        ; CHAIN LOAD REGION

        RELOAD: .WORD   001602  ; Reload Word <Select CARA,CARB,COPC,CM>

                .WORD   000000  ; Current Address Register A Seg/Tag
                .WORD   outbuf  ; Current Address Register A Offset
                                ; <This local address is the source>

                .WORD   000020  ; Current Address Register B Seg/Tag
                .WORD   padata+1; Current Address Register B Offset
                                ; <This local address is the destination,
                                ;  Hold the address, must specify high byte
                                ;  for byte transfer>

                .WORD   000010  ; Current Operation Count <Transfer 8 words>

                .WORD   000000  ; Channel Mode Register High
                .WORD   000001  ; Channel Mode Register Low
                                ; <No match conditions, do nothing upon
                                ;  completion, transfer type = Single Transfer
                                ;  CARA = source, byte transfers>
        
                .END    START




















                                  283

uNOTE # 032
Page 38 of 42


      PROGRAMMING THE COUNTER/TIMERS

      This section will describe how to program the Counter/Timers and provide
      example programs demonstrating their capabilities.

      Each of the three Counter/Timers provides up to four lines for  external
      access.   If  these  external lines are used the corresponding port pins
      must be available and programmed in the proper direction.  The following
      table  displays which port pins correspond to the Counter/Timer external
      access lines:

                        Counter/Timer External Access Lines

           +---------------------------------------------------------------+
           |   Function               C/T 1          C/T 2          C/T 3  |
           -----------------------------------------------------------------
           | Counter/Timer Output    Port B4        Port B0        Port C0 |
           | Counter Input           Port B5        Port B1        Port C1 |
           | Trigger Input           Port B6        Port B2        Port C2 |
           | Gate Input              Port B7        Port B3        Port C3 |
           +---------------------------------------------------------------+

                                    - Table 2 -

      The first step in programming a Counter/Timer is to  specify  which  (if
      any)  external  lines are to be used, the output duty cycle, and whether
      the cycle is continuous or single-cycle.  The following figures  display
      the available output duty cycles:

                                 Output Duty Cycles

      If Time Constant Value = 5

      Pulse Output Mode
                                                    -> 500 nS <-
                                                       +-----+
                                                       |     |
                   ------------------------------------+     +------

                   |     |     |     |     |     |     |     |     |
                   T     5     4     3     2     1     T     5     4

      One-Shot Mode

                         +-----------------------------+     +------
                         |                             |     |
                   ------+                             +-----+

                   |     |     |     |     |     |     |     |     |
                   T     5     4     3     2     1     T     5     4



                                  284

                                                           uNOTE # 032
                                                         Page 39 of 42


      If Time Constant Value = 8

      Square Wave Mode
                                           +-----------------------+
                                           |                       |
            -------------------------------+                       +------

            |     |     |      |     |     |     |     |     |     |     |
            T     8     7      6     5     4     3     2     1     T     8

                                    - Figure 2 -

      Next, the Time Constant Registers must be  loaded.   Each  Counter/Timer
      contains  two of these registers which are used to form the 16-bit value
      that  is  loaded  into  the  down-counter  when  the  Counter/Timer   is
      triggered.

      If external lines are to be used then the corresponding port pins should
      be  programmed  as  bit ports with the correct data direction.  Finally,
      the Counter/Timer enable bit for that port must be enabled in the Master
      Configuration Control Register.

      The down-counter is loaded and the countdown sequence is initiated  when
      the  Counter/Timer  is  triggered.   This  trigger may occur because the
      Trigger Command Bit (TCB) in the Command and Status Register is  set  or
      because  an  external trigger input was asserted.  Once the countdown is
      initiated it will continue towards the terminal count  as  long  as  the
      Gate Command Bit (GCB) in the Command and Status Register is set and the
      Gate Input is held asserted (if it is enabled).   If  a  trigger  occurs
      during  a  countdown  sequence  the  action  taken  is determined by the
      Retrigger Enable Bit (REB).  If REB = 0 then the trigger is ignored, but
      if  REB  =  1  then  the down-counter is reloaded and a new countdown is
      initiated.

      When the terminal count is reached the state  of  the  Continuous/Single
      Cycle  bit  (C/SC)  in  the Mode Specification Register is examined.  If
      C/SC = 0 then the countdown sequence stops.  If C/SC = 1 then  the  time
      constant is reloaded and a new countdown is initiated.  If the Interrupt
      Enable Bit (IE) is set  an  interrupt  request  is  generated  when  the
      down-counter  reaches  its  terminal  count.  If a terminal count occurs
      while the Interrupt Pending Bit (IP) then an error is indicated  by  the
      Interrupt Error (ERR) bit.

      The following  program  provides  an  example  of  how  to  program  the
      Counter/Timers:








                                  285

uNOTE # 032
Page 40 of 42


                .TITLE  CT1.MAC

        ;  This program demonstrates how to utilize one of the Counter/Timers
        ;  on the KXT11-C.  Counter/Timer 1 will be used in this program.
        ;  This counter/timer is clocked at a 500 ns rate.  The time constant
        ;  used for the counter is 50,000.  Therefore the countdown sequence
        ;  will take 25 ms.  (500 ns x 50,000 = 25,000,000 ns = 25 ms).  The
        ;  interrupt service routine waits until the countdown sequence has
        ;  completed 40 times and then outputs an 'A' out of the console
        ;  port.  This should happen approximately one time a second.  (25 ms
        ;  x 40 = 1 s).  
        ;
        ;  After this program has been assembled and linked on the
        ;  development machine use the KUI utility of the KXT11-C Software
        ;  Toolkit to load the program into the KXT11-C to execute as
        ;  shown in this example:
        ;
        ;  SET 2
        ;  LOAD CT1.SAV
        ;  EXECUTE
        ;  EXIT
        ;
        ;  Notice that the 'A's keep on coming after you exit KUI!

                ; Register Assignments

                MIC     ==  177000
                MCC     ==  177002
                CTVEC   ==  177010
                CT1CON  ==  177024
                CT1HI   ==  177054
                CT1LO   ==  177056
                CT1MOD  ==  177070

        START::
                MTPS    #340            ; Disable recognition of interrupts

                MOVB    #1,MIC          ; Reset PIO
                CLRB    MIC             ; Enable PIO (Interrupts disabled)

                MOVB    #210,CTVEC      ;
                MOV     #ISR,@#210      ; Initialize Counter/Timer vector
                MOV     #340,@#212      ;  and ISR address

                CLR     R1              ; Used as a counter

                MOVB    #200,CT1MOD     ; Select continuous mode, no external
                                        ;  access, pulse output
                MOVB    #203,CT1HI      ; CT1HI and CT1LO combine to form
                MOVB    #120,CT1LO      ;  141520(8) = 50000(10)

                MOVB    #100,MCC        ; Enable Counter/Timer 1

                                  286

                                                           uNOTE # 032
                                                         Page 41 of 42


                MOVB    #200,MIC        ; Enable PIO interrupts
                MTPS    #0              ; Enable recognition of interrupts

                BISB    #306,CT1CON     ; Set IE,GCB,TCB - this starts the
                                        ;  countdown
                BR      .               ; Wait here for the interrupts

        ISR:
                INC     R1              ; Increment the counter
                CMP     R1,#40.         ; IF this is not the 40th time
                BNE     2$              ;  THEN count again
                CLR     R1              ;  ELSE clear the counter and...
                MOVB    #101,@#177566   ;   send an 'A' to the console
        ;+
        ;  The console in this case is the KXT11-C console - NOT the
        ;  development system console.  Therefore you'll have to hook a
        ;  terminal up  to SLU1 to see the 'A's pop out.
        ;-
        2$:     MOVB    #44,CT1CON      ; Clear IUS and IP but don't bother
                                        ;  GCB
                RTI

                .END    START






























                                  287

uNOTE # 032
Page 42 of 42


      RELATED DOCUMENTS

      For further information about the KXT11-C and the PIO please consult the
      following sources:

      KXT11-C Single-Board Computer User's Guide  (EK-KXTCA-UG)

      AmZ8036 Counter/Timer, Parallel I/O Technical Manual*

        *  This manual may be obtained from Advanced Micro Devices











































                                  288

================================================================================
Note 33.0                  System Config of DL Devices                No replies
FURILO::GIORGETTI                                   758 lines  21-AUG-1985 23:27
--------------------------------------------------------------------------------



      +---------------+                                    +-----------------+
      | d i g i t a l |                                    |  uNOTE # 033    |
      +---------------+                                    +-----------------+

                                                                         
      +----------------------------------------------------+-----------------+
      | Title:  System Configuration of DL-type Devices    | Date: 28-Jun-85 |
      +----------------------------------------------------+-----------------+
      | Originator:  Art Bigler                            | Page 1 of 14    |
      +----------------------------------------------------+-----------------+



      DL-type  devices  are  single,  asynchronous  serial  line  unit   (SLU)
      interfaces  used  on  Digital's Q-bus and UNIBUS processors.  On PDP-11s
      the DL-type SLU is required as the console terminal  interface  for  use
      with console octal debugging technique (ODT), diagnostics, and operating
      system consoles.  They are also used to provide interfacing  to  a  wide
      variety of peripherals on both PDP-11 and VAX processors.

      This MicroNote will examine the proper use and configuration of  DL-type
      SLUs  in system environments.  It will first discuss the characteristics
      of these popular options, and then, some of the  applications  in  which
      they  are used.  Lastly, the configuration of DL-type SLUs in the system
      environment will be discussed and a number of recommendations for  their
      use will be presented.

      It should be noted that the examination of a system  configuration,  and
      any  resulting recommendations, is based upon the particular application
      of the system.  The configuration  guidelines  presented  here  are  not
      necessarily  suitable  for  all.  The system designer must determine the
      extent to which this information is used.



      1.0 CHARACTERISTICS OF THE DL-TYPE SLU


      The DL-type SLU is an interface to asynchronous serial peripherals, such
      as  terminals,  consisting  of  a  host  bus  interface (to the Q-bus or
      UNIBUS), a receiver and transmitter (usually an industry-standard UART),
      and an electrical interface to the peripheral (20 ma.  current loop, EIA
      RS-232-C, RS-422, etc.).  Additional features (e.g.  the line time clock
      register  on the UNIBUS DL11 or modem control on the Q-bus DLVE1) may or
      may not be present on a DL-type SLU.  These features have nothing to  do
      with  the  basic  function  of  the  SLU  which  is transmit and receive
      asynchronous serial data via the data leads only ( modem  control  is  a
      extension  of  the capabilities of the interface, not a basic function).
      A block diagram of a DL-type SLU is presented in figure 1.

                                                                Page 2


      ------------------------------------------------------------------------
                               Q-BUS OR UNIBUS
      ------------------------------------------------------------------------
             ^
             |
             |
             |
             v
         +--------+        +--------+        +--------+
         |        |        |        |        |        |
         |        |        |        |        | ELECT  |        -+
         | HOST   |------->| ASYNC  |------->| INTF   |-------> |   TO/FROM
         | BUS    |        | TRANS  |        | TO     |         +-- SERIAL
         | INTF   |<-------| /REC   |<-------| SERIAL |<------- |   LINE
         |        |        |        |        | LINE   |        -+
         |        |        |        |        |        |
         +--------+        +--------+        +--------+


                                      Figure 1
                             Block Diagram, DL-type SLU




      1.1 DL-TYPE SLU REGISTERS


      All DL-type SLUs must implement four registers, two control  and  status
      registers  (CSRs)  and  two data buffer registers (BUFs).  The same base
      configuration of bits within these registers must also  be  implemented.
      These registers, and their functions, are listed below:

          1.  The receiver control and status register (RCSR) provides, at
              a  minimum,  control  and  status  of  the receive interrupt
              enable (bit 06) and status of the receiver  done  flag  (bit
              07).   The  receiver  done flag is set by the SLU whenever a
              character has been received.  It may be polled by a  program
              or  it  may  generate  an interrupt if the receive interrupt
              enable has been set.  The receiver done flag is reset by  an
              initialization from the host bus or by reading the character
              from the receiver data buffer register.

          2.  The receiver data buffer  register  (RBUF)  provides,  at  a
              minimum,  received  character  data (bits 00 through 07) and
              received data error information (bits 12 through  15).   The
              received  data  is  valid whenever the receiver done flag is
              set in the RCSR.  The error bits are implemented in all  DL-
              type  SLUs  except  the DLV11 and provide status information
              for the received data.  All DL-type SLUs  implement  framing
              error  (bit  13),  overrun error (bit 14), and error summary
              (bit 15).  Additionally, all DL-  type  SLUs,  except  those
              implemented  with the DC319-AA DLART, implement parity error
              status (bit 12).  Error summary is set whenever any  of  the
              other error bits are set.  Overrun error is set when a newly

                                                                Page 3


              received character is received before the receiver done flag
              is  reset.   Framing  error  is  set whenever a character is
              received without a  valid  stop  bit,  usually  by  a  break
              character.   Parity  error  is  set  whenever a character is
              received with the incorrect parity,  if  the  interface  has
              been configured to check parity.

          3.  The transmitter control and status register (TCSR) provides,
              at  a  minimum, control and status of the transmit interrupt
              enable (bit 06) and the transmit break enable (bit 00),  and
              status   of  the  transmitter  ready  flag  (bit  07).   The
              transmitter ready flag  is  set  by  the  SLU  whenever  the
              transmitter  is ready to transmit another character or by an
              initialization from the host bus.  It may  be  polled  by  a
              program  or  it  may  generate  an interrupt if the transmit
              interrupt enable has been set.  The transmitter  ready  flag
              is   reset   by   transferring   another  character  to  the
              transmitter data buffer register.  The transmit break enable
              forces  the  transmitter  to  generate  a  continuous  break
              character (continuous space level) while it is set.

          4.  The transmitter data buffer  register  (TBUF)  holds,  at  a
              minimum,  the  last  character  to  be  transmitted (bits 00
              through 07).  Transferring  a  character  to  this  register
              resets the transmitter ready flag in the TCSR.

      Transfers to these registers are performed by programmed I/O, the result
      of  the  execution  of  an  instruction by the host processor.  The only
      other bus operation a DL-type SLU may initiate is an interrupt from  the
      transmitter or receiver.

      Figure 2 provides graphic representations of these registers.

                                                                Page 4


             1   1   1   1   1   1   0   0   0   0   0   0   0   0   0   0
             5   4   3   2   1   0   9   8   7   6   5   4   3   2   1   0
           +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
      RCSR |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
           +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
                                             ^   ^
                                             |   |
                                             |   |
                       RECEIVER DONE FLAG ---+   +--- RECEIVE INTERRUPT
                                                           ENABLE






             1   1   1   1   1   1   0   0   0   0   0   0   0   0   0   0
             5   4   3   2   1   0   9   8   7   6   5   4   3   2   1   0
           +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
      RBUF |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
           +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
             ^   ^   ^   ^                   ^                           ^
             |   |   |   |                   +-------------+-------------+
             |   |   |   |                                 |
             |   |   |   +--- PARITY ERROR                 |
             |   |   |                                  RECEIVED
             |   |   +--- FRAMING ERROR                 CHARACTER
             |   |                                      DATA
             |   +--- OVERRUN ERROR
             |
             +--- ERROR SUMMARY


                                      Figure 2
                               DL-type SLU registers

                                                                Page 5


             1   1   1   1   1   1   0   0   0   0   0   0   0   0   0   0
             5   4   3   2   1   0   9   8   7   6   5   4   3   2   1   0
           +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
      TCSR |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
           +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
                                             ^   ^                       ^
                                             |   |                       |
                                             |   |                       |
                   TRANSMITTER READY FLAG ---+   |     TRANSMIT BREAK ---+
                                                 |          ENABLE
                    TRANSMIT INTERRUPT ENABLE ---+






             1   1   1   1   1   1   0   0   0   0   0   0   0   0   0   0
             5   4   3   2   1   0   9   8   7   6   5   4   3   2   1   0
           +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
      TBUF |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
           +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
                                             ^                           ^
                                             |                           |
                                             +-------------+-------------+
                                                           |
                                                           |
                                                        TRANSMIT
                                                        CHARACTER
                                                        DATA


                                Figure 2, continued
                               DL-type SLU registers




      1.2 DL-TYPE SLU ADDRESSES AND VECTORS


      DL-type SLUs must implement their addresses and vectors in the following
      manner:

          1.  The four registers, RCSR, RBUF, TCSR, and TBUF, occupy  four
              contiguous  words  in the I/O page address space.  The first
              address is called the base address.

                  1.  RCSR is assigned base address +00.

                  2.  RBUF is assigned base address +02.

                  3.  TCSR is assigned base address +04.

                                                                Page 6


                  4.  TBUF is assigned base address +06


          2.  The receive interrupt  vector  and  the  transmit  interrupt
              vector  occupy  two contiguous vectors in the vector address
              space.

                  1.  The first vector is the receive vector.

                  2.  The second vector is the transmit vector.


      For the console SLU on a PDP-11 processor the  base  address  is  always
      17777560  (octal) and the receive vector is at 60 (octal).  DL-type SLUs
      used for applications other than the console SLU  are  usually  assigned
      address and vectors in the floating address and vector spaces.



      1.3 DL-TYPE SLU PROGRAMMING CONSIDERATIONS


      There are two methods  of  programming  DL-type  SLUs;  polled  I/O  and
      interrupt driven I/O.

          1.  In polled I/O the software executing on the  host  processor
              polls,  or  tests, the receiver done flag in the RCSR or the
              transmitter ready  flag  in  the  TCSR  to  determine  if  a
              character  has  been received or is ready to be transmitted.
              If the flag is set the software executes an  instruction  to
              move  the  character  from  the  RBUF  or  to the TBUF.  The
              polling is then resumed.   Polled  I/O  is  used  by  PDP-11
              diagnostics  because  it is the simplest method and requires
              the least amount of hardware working in a system, a definite
              advantage  when  attempting  to  service  a  system which is
              operating improperly.

          2.  In interrupt  driven  I/O  the  software  sets  the  receive
              interrupt  enable  in  the  RCSR  or  the transmit interrupt
              enable in the TCSR.   If  the  receiver  done  flag  or  the
              transmitter  ready  flag  is  set, an interrupt is generated
              through the appropriate vector.  Execution is transferred to
              an  interrupt  service  routine  (ISR) and an instruction is
              executed to move the character from the RBUF or to the TBUF.
              A  return  from interrupt (RTI) instruction is then executed
              to return control back to the  main  program.   All  Digital
              operating  systems  and most user software utilize interrupt
              driven I/O because processor time is optimized.

      When programming a DL-type SLU, several restrictions must be taken  into
      account.   Most  of  these  are  due  to  the design of the asynchronous
      receiver and  transmitter  and  its  implementation  in  the  SLU.   The
      important restrictions are detailed below.

                                                                Page 7


          1.  There is only a one character buffer in the receive side  of
              the  SLU.   Therefore, any character which has been received
              must be moved from the RBUF  prior  to  the  next  character
              being assembled in the receiver.  If characters are actually
              being received at the maximum character rate as  defined  by
              the  bit data rate of the serial line, the RBUF must be read
              within one character time or an overflow error will occur on
              the SLU and data will be lost.

          2.  The transmitter  also  has  only  a  one  character  buffer.
              However,   while   this   restriction   may  result  in  the
              transmission of characters at a rate lower than the  maximum
              character  rate,  the  transmitter  can wait a theoretically
              infinite time for the next character.  No data will be  lost
              and no errors will occur.

          3.  Direct memory access (DMA) I/O has precedence over interrupt
              I/O.   Therefore, if a DMA device and DL-type SLU wishing to
              interrupt the processor are both requesting use of the  bus,
              the  DMA  device  will  be  granted it.  While this does not
              normally  cause  problems  in  systems  which  make  use  of
              single-cycle  DMA  transfers  (except,  of course, where the
              system is  heavily  loaded  with  a  number  of  active  DMA
              devices),  the  use  of  burst-mode  DMA  or,  on the Q-bus,
              block-mode DMA could conceivably  lock  out  the  interrupts
              from the SLU for an appreciable length of time.  This should
              have little effect on the  transmitter  since  it  can  wait
              indefinitely  for interrupts, but it could have a disastrous
              effect on the  receiver,  allowing  the  loss  of  data  and
              generating overrun errors.




      1.4 DIGITAL'S DL-TYPE SLUs


      Digital manufactures a variety of DL-type SLUs for both  the  Q-bus  and
      the  UNIBUS.   The  following  list  is  compilation  of those currently
      available.

          1.  Q-bus compatible, DL-type SLUs

                  1.  DLV11 - a single line, DL-type SLU on  one  dual
                      height  module.  Data rate from 50 to 9,600 bits
                      per second, full duplex,  data  leads  only  (no
                      modem  control).   RS-232-C  and 20 ma.  current
                      loop serial line interfaces.

                  2.  DLVE1  (formerly  DLV11-E)  -  a  single   line,
                      DL-type  SLU  on  one  dual height module.  Data
                      rate from 50 to 19,200  bits  per  second,  full
                      duplex  with  limited  modem  control.  RS-232-C
                      serial line interface.

                                                                Page 8


                  3.  DLVJ1  (formerly  DLV11-J)  -  four  individual,
                      DL-type  SLUs  on  one dual height module.  Data
                      rate from 150 to 38,400 bits  per  second,  full
                      duplex,  data  leads  only  (no  modem control).
                      RS-232-C serial line interface.


          2.  UNIBUS compatible, DL-type SLUs

                  1.  DL11 - single line,  DL-type  SLU  on  one  quad
                      height small peripheral controller (SPC) module.
                      Data rate from 50 to 9600 bits per second,  full
                      duplex.   A  number  of variations are available
                      some including modem control and line time clock
                      interfaces.   RS-232-C  and 20 ma.  current loop
                      available.


          3.  Digital produces two multifunction modules  for  the  Q-bus,
              the  MXV11-A  and  the  MXV11-B, which contain DL-type SLUs.
              These are intended for the  board-level  applications  where
              RAM  and  ROM  memory and SLUs in a single compact board are
              required.

          4.  Additionally, Digital manufactures a DL-type SLU on a  chip,
              the  DC319-AA  DLART.   The  DLART  is  used  in  several of
              Digital's systems as the console terminal SLU for  processor
              modules such as the KDJ11-B.




      2.0 DL-TYPE SLU APPLICATIONS


      The following are examples of the potential uses  for  DL-type  SLUs  in
      systems.

          1.  In general, DL-type serial line units are required  for  the
              console  device interface on all PDP-11 processors for three
              functions:

                  1.  Console ODT - the console ODT routines in  these
                      processors    can   communicate   with   DL-type
                      interfaces only.

                  2.  Diagnostics - diagnostics which run  under  XXDP
                      and  DEC/X11 assume the use of a DL-type console
                      interface.

                  3.  Operating system console - the operating systems
                      which  run  on  the  PDP-11  processors  require
                      DL-type SLUs for the system  console.   Even  if
                      the  console  interface device can be redirected
                      to another serial line, as is  possible  in  the

                                                                Page 9


                      RSX operating systems, the crash and panic dumps
                      routines usually require the use  of  a  DL-type
                      SLU.

              The reason  that  DL-type  interfaces  are  used  for  these
              functions  is  that  they  are  the  simplest, most reliable
              serial line unit available.  If a system is down,  having  a
              DL-type  SLU  as  the  console  interface will almost always
              eliminate the possibility  that  the  problem  is  with  the
              console interface.

          2.  DL-type SLUs are also used,  in  some  systems,  to  provide
              interactive   terminal   support.    Their   use   for  this
              application  is  not  recommended  for  reasons  which   are
              discussed in following sections.

          3.  Applications requiring the use of a serial hardcopy terminal
              as  a low-cost system printer may use the DL-type SLU as the
              interface.

          4.  Applications  which  require  as  immediate   attention   as
              possible  to  a  serial data stream may require the use of a
              DL-type SLU as the interface.  The  serial  data  stream  is
              most  often  from  an  instrumentation  device,  such  as  a
              thermocouple, in a process control environment.

      The next sections will examine the  configuration  of  DL-type  SLUs  in
      system  environments.   Some  specific recommendations for configuration
      and use of these devices, including the recommendation  of  using  other
      types of SLUs wherever possible, will be presented.



      3.0 SYSTEM CONFIGURATION OF DL-TYPE SLUS


      There are several  items  which  must  be  considered  when  configuring
      DL-type SLUs into systems.

          1.  The data rate at which the SLU is expected to transfer  data
              to  and  from  the  serial  line,  and  therefore,  the host
              processor's bus.

          2.  The aggregate data rate expected from  all  devices  on  the
              host  processor's bus.  This includes the amount and mode of
              DMA activity on the bus and  its  potential  effect  on  the
              DL-type SLU.

          3.  The interrupt priority of the SLU on  the  host  processor's
              bus.

      In the following discussions, much use will be made of an example  based
      upon  the configuration of a DLVJ1 quad SLU in a Q-bus system.  With the
      exception of block-mode DMA, which does not exist  on  the  UNIBUS,  the
      example  is,  in  general,  valid  for  Q-bus  and UNIBUS PDP-11 and VAX

                                                               Page 10


      processors.  It must be remembered that  the  configuration  is  largely
      dependent  upon the system application which may alter some of the rules
      presented.



      3.1 DLVJ1 DESCRIPTION AND CONSIDERATIONS FOR USE


      The DLVJ1 is a dual height Q-bus module consisting of four  individually
      programmed  RS-232-C/RS-449/RS-423  compatible  DL-type  SLUs.  Although
      they share common Q-bus  transceivers  and  device  selection  and  data
      gating  logic,  the  four  SLUs  each have their own sets of serial line
      interfaces circuits, Universal Asynchronous Receiver Transmitter  (UART)
      circuits,  and  DC003  interrupt  controller circuits.  This, in effect,
      gives the system designer four individual DL-type serial line units each
      with  its  own  CSRs  and  data  buffer  registers  and  with  data rate
      capabilities of up to 38.4K bits per second per channel.

      The four DC003 interrupt controllers are configured  and  wired  in  the
      proper  Q-bus  compatible  fashion for bus request level four only (BR4)
      devices (i.e.  BIAKI comes in from the bus, through the first DC003, and
      out  as  BIAKO  which  then goes to the BIAKI input of the second DC003.
      The second DC003 then routes the BIAK signal to the third DC003 and  the
      third  to the fourth which then routes its BIAKO signal out to the Q-bus
      for continuation of the daisy chain.).  The Q-bus specification provides
      for two methods of establishing device priority:

          1.  Distributed arbitration - priority levels are implemented in
              hardware  on the device.  Devices must monitor all interrupt
              requests with  higher  priority  than  their  own  and  pass
              through  the  interrupt  acknowledge  if  one  exists.  When
              devices   of   equal   priority   request    an    interrupt
              simultaneously   ,   priority   is   given   to  the  device
              electrically closest to the processor.

          2.  Position-defined arbitration - priority is determined solely
              by  electrical  position on the bus.  The closer a device is
              to the processor, the higher its priority is.  Devices which
              use   position-defined   arbitration   must   be  placed  in
              descending  bus  request  order  after  any  devices   which
              implement distributed arbitration.

      It should be noted that Digital has produced only one Q-bus device  with
      multiple  interrupt  request  levels,  the  TSV05.   All  other  devices
      produced  to  date  have  implemented  BR4   only,   and   depend   upon
      position-defined arbitration for their priority.  This is largely due to
      the standard Q-bus interface  chips'  lack  of  circuitry  required  for
      performing   the   higher   level   request   monitoring.   Due  to  the
      implementation of the bus, UNIBUS devices do not have this  restriction.
      For  further  information  on  the  subjects of interrupt priorities and
      device placement  consult  the  PDP-11  Architecture  Handbook  and  the
      Microcomputers and Memories Handbook.

      Receiver done and transmitter done interrupt requests are wired  to  the

                                                               Page 11


      DC003's so that the four receiver done interrupts have a higher priority
      than the four transmitter done interrupts.  Elevating the receiver  done
      interrupt  priorities over that of the transmitter done interrupts helps
      reduce the potential for lost input  characters  due  to  receiver  data
      overrun  errors.   Transmitter  operation  is  essentially not affected,
      except potentially in throughput, since the transmitters will hold their
      interrupt  requests  indefinitely.   This  configuration  is,  in  fact,
      preferable to that of four individual DL-type  interfaces  (DLVE1,  etc.
      on  the  Q-bus  or  DL11 on the UNIBUS) which would have the transmitter
      done interrupts placed between the receiver done interrupts.

      The device address selection  circuits  and  vector  address  generation
      circuits  allow  for the DLVJ1 to be configured at a number of different
      base addresses and vectors.  Channel three may be configured for use  as
      the  system  console device interface and it is this capability, not its
      cost, that has made the DLVJ1 an extremely popular option.

      The serial interfaces are capable of data-leads-only  interfacing  (i.e.
      transmit  data,  receive  data  and ground) to external equipment.  Thus
      there is no modem control capability in the DLVJ1.  This is  usually  of
      no consequence since the largest use of this device is for local console
      device and terminal interfacing.  If the user  requires  modem  control,
      the  DLVE1  is  available.   If  the interface is not being used for the
      console terminal, asynchronous multiplexers with modem control  such  as
      the  DZV11  and  DHV11  are  available  and are preferable in almost all
      applications.



      3.2 SLU DATA RATE CONSIDERATIONS


      The UART used in the DLVJ1 is the 6402 which is a member  of  a  generic
      UART  family  in  wide  use in a large number of Digital and third party
      vendor products, including the DLVE1 and DLV11 Q-bus  options,  and  the
      DL11  UNIBUS option.  They are very similar in nature to Digital's DLART
      interface chip which is used on the MXV11-B  multifunction  module,  the
      MicroPDP-11/23  and PDP-11/23-PLUS processor board, the KDF11-B, and the
      MicroPDP-11/73 processor board, the KDJ11-BC.

      The 6402 provides one level of buffering on input and output  data  with
      the implementation of a receiver data holding register and a transmitter
      data holding register respectively.  While the  level  of  buffering  is
      relatively  unimportant  to  the  transmitter due to its ability to wait
      indefinitely for additional characters, it is extremely important to the
      receiver.  To illustrate this the following example is used:

          The 6402 provides a receiver register which holds  the  current,
          incoming  character.  The data is transferred into this register
          at the bit data rate at which the serial line is  running.   The
          time required to fill the receiver register can be calculated as
          follows.

              t=1/(bit data rate)*(number of bits per character)

                                                               Page 12


              Where t is the character time and the number of bits per
              character  includes the start bit, all data bits, parity
              bit if used, and all stop bits.

          Picking some common numbers for this example:

              Bit data rate = 9600.  bits per second.
              Number of data bits = 8.
              Number of parity bits = 0.
              Number of stop bits = 1.

          The character time is therefore:

              t=1/9600*(1+8+0+1)

              t=1.041 msec.  per character

          Therefore, at a 9600 bits per second data rate,  the  time  from
          the  start  of  transmission  of  the  character to the time the
          character  is  loaded  into  the  receiver  buffer  register  is
          approximately one millisecond.

          If the  next  character  starts  transmission  immediately,  the
          processor  has  at  least one character time before the receiver
          buffer register must be  emptied  so  that  it  can  accept  the
          current  input  character,  in  this case one millisecond.  This
          implies that the receiver done interrupt must be serviced within
          that  time  also.   So  long  as the combination of software and
          hardware  is  capable  of  servicing  the  interrupt  within   a
          character time the receive data should never overrun.

      Therefore, the limiting of the serial data rate will help to reduce  the
      amount  of  system  resources  required  to service the SLU and optimize
      processor time.



      3.3 HOST PROCESSOR AGGREGATE DATA RATE CONSIDERATIONS


      The above example does not take into account any other bus interrupt  or
      DMA  activity which will, of course, impact the speed at which the DLVJ1
      interrupt is serviced.  To minimize the effects of the host  processor's
      aggregate data rate two configuration rules should be followed:

          1.  The data rate on the DLVJ1  devices  should  be  kept  to  a
              reasonable  limit  which  is usually considered to be at, or
              below, 1200 bits per second.   This  will  allow  additional
              time   for  the  processor  to  service  the  receiver  done
              interrupt and will keep the the amount of bus  activity  due
              to serial line interrupts reasonable.

          2.  Careful attention should be given to the amount and mode  of
              DMA  activity on the host processor's bus.  Large quantities
              of DMA traffic mean that the  processor  has  less  time  to

                                                               Page 13


              service  interrupts  which  have  a  lower priority than DMA
              operations.   Devices  doing  burst  and  block   mode   DMA
              operations  may  hold  the  bus  for  long  periods of time,
              resulting in interrupts being blocked for  the  duration  of
              the DMA operation.




      3.4 INTERRUPT PRIORITY OF THE DL-TYPE SLU


      The  DL-type  SLU  should  be  configured  as   the   highest   priority
      interrupting  device  on the bus if at all possible.  In most cases this
      will result in the SLU being the first  device  on  the  bus,  with  the
      possible  exception  of  the  line  time  clock or BEVENT line.  This is
      consistent with the MicroPDP-11's, PDP-11/23-PLUS's  ,  and  the  UNIBUS
      processors, all of which have their console device interfaces very close
      to the beginning of the bus.

      By placing the DL-type SLUs  as  close  to  the  front  of  the  bus  as
      possible,  the  interrupt  priority  is elevated above that of the other
      devices on the bus.  This will allow the interrupt requests to  serviced
      before  the  rest of the devices and immediately after the DMA activity,
      resulting in a reduced possibility of data loss.



      4.0 SUMMARY AND RECOMMENDATIONS


      The DL-type SLUs  are  required  by  PDP-11  systems  as  their  console
      interface.   There are several options which may be used to provide this
      function.  Theses include the DLVxx series options on the Q-bus and DLxx
      series  options  on  the  UNIBUS.   Additionally,  several multifunction
      options and processors have DL-type  interfaces  integrated  into  them.
      These include MXV11-As, MXV11-Bs, KDF11-Bs and KDJ11-Bs.

      The use of all DL-type SLUs should be limited in most  systems  (special
      applications  may have valid uses of DL-type devices).  They should , in
      most circumstances, be used only for the console  device  interface  and
      serial  printer applications.  The use of an asynchronous multiplexer is
      recommended for all other serial line requirements, excepting infrequent
      special applications.

      The use of any DL-type SLU for an interactive terminal  on  a  multiuser
      system  is indicative of a poor system configuration.  In this case, the
      proper configuration would include  asynchronous  multiplexers  such  as
      DZV11's,  DZQ11's,  or DHV11's (or their UNIBUS counterparts) to provide
      efficient handling of  terminal  interfaces  with  the  minimum  of  bus
      activity and operating system overhead.

      The use of a DL-type SLU as a low cost printer port is exempt  from  the
      above  statement  because it requires approximately the same overhead as
      the LPV11 or LP11-type line printer controller.  However, the use of  an

                                                               Page 14


      asynchronous multiplexer with DMA output, such as the DHV11, may provide
      a more  efficient  method  of  handling  printers,  depending  upon  the
      implementation.

      The data rate at which any DL-type SLU operates  should  be  kept  to  a
      minimum,  particularly when receiving data, to ensure that the amount of
      bus activity is as low as possible since these interfaces are  interrupt
      intensive.   This holds for any interrupt intensive device (parallel I/O
      devices such as DRV11s, etc.), in general.  The problem is not  that  of
      the  inadequacies  of  the  interface but of the amount of bus bandwidth
      available to support the aggregate bus data rate.

      The DL-type SLU should be  placed  in  as  high  an  interrupt  priority
      position  as  possible  to  insure adequate servicing by software.  This
      will not affect DMA activity since it holds  priority  over  interrupts.
      The  performance  of  most systems will not be affected by the increased
      priority level of the maximum one or two DL-type  interfaces  which  are
      recommended to be active at one time.

      Under no circumstance should any device, including a DL-type  interface,
      be  placed on the bus after a RQDX1 disk controller.  The RQDX1 does not
      pass through the DMA and interrupt grant lines properly, thus  producing
      completely unpredictable results and often times "hung" devices.

      Recommendations for the DL-type SLUs, and any other interrupt  intensive
      devices, are:

          1.  Limit  their  use  whenever  possible.    Use   asynchronous
              multiplexers  or  other  more  advanced  interfaces whenever
              possible.  The cost savings of a DLVJ1 over a DZQ11 must not
              overshadow the performance issues.

          2.  Limit  the  rate  at  which  they  operate.    For   DL-type
              interfaces  a  good limit appears to be 1200 bits per second
              or less although in some applications a higher rate  may  be
              possible.

          3.  Place them so that they have as high an  interrupt  priority
              as possible, in most cases the highest priority.

      Following these few  recommendations  will  result  in  improved  system
      performance  and  far  less headaches when configuring DL-type SLUs into
      systems.

================================================================================
Note 34.0                 Programming KXT11-C Multi SLU               No replies
FURILO::GIORGETTI                                  1413 lines   3-SEP-1985 17:17
--------------------------------------------------------------------------------


      +---------------+                                    +-----------------+
      | d i g i t a l |                                    |  uNOTE # 034    |
      +---------------+                                    +-----------------+

                                                                   
      +----------------------------------------------------+-----------------+
      | Title:  Programming the KXT11-C Multiprotocol SLU  | Date: 19-Jul-85 |
      +----------------------------------------------------+-----------------+
      | Originator: Scott Tincher                          | Page 1 of 24    |
      +----------------------------------------------------+-----------------+


      The KXT11-CA single board computer provides a two-channel  multiprotocol
      serial  line  unit.   The  SLU  is implemented with an NEC uPD7201 chip.
      This Micronote will explain  the  operation  of  this  SLU  and  provide
      example  programs  which display its capabilities.  The example programs
      will be written in Macro-11 so it is  assumed  that  the  programmer  is
      familiar  with  Macro-11  and  either  the RT-11 or RSX KXT11-C Software
      Toolkits.   It  should  be  noted  that  the  DIGITAL  operating  system
      MicroPower/Pascal provides a device handler for the uPD7201 chip.


      FEATURES/CAPABILITIES

      The multiprotocol SLU supplies the KXT11-C with the  following  features
      and capabilities:


       o  Two full duplex channels

           -  Channel A provides full modem control

           -  Channel B provides data and timing leads only

       o  Each channel may be operated in one of three modes:

           -  Asynchronous

               o  5, 6, 7, or 8 Data bits

               o  1, 1-1/2, or 2 Stop bits

               o  Odd, Even, or No Parity

               o  Break generation and detection

               o  Interrupt on Parity, Overun, or Framing Errors

           -  Character-oriented synchronous




                                  303

uNOTE # 034
Page 2 of 24


               o  Monosync, Bisync, and External Sync Operations

               o  Software Selectable Sync Characters

               o  Automatic Sync Insertion

               o  CRC Generation and Checking

           -  Bit-oriented synchronous

               o  HDLC and SDLC Operations

               o  Abort Sequence Generation and Detection

               o  Automatic Zero Insertion and Detection

               o  Address Field Recognition

               o  CRC Generation and Checking

               o  I-Field Residue Handling

       o  Programmable Baud Rates

       o  Double Buffered Transmitted Data

       o  Quadruply Buffered Received Data

       o  Programmable CRC Algorithm

       o  Channel A may utilize the DMA controller to transfer data


      REGISTER DESCRIPTION

      The multiprotocol SLU is controlled by manipulating the registers of the
      uPD7201  chip  as well as registers in support chips that provide access
      to the baud rate generator and the modem control signals.  This  section
      will  provide  a brief description of the registers necessary to program
      the multiprotocol SLU.

      uPD7201 Registers

      This section will describe the registers found in  the  uPD7201  itself.
      These  registers  are  found  in  both  channels  of  the uPD7201 unless
      otherwise indicated.

      Control Register 0

                        +---+---+---+---+---+---+---+---+
                        | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
                        +---+---+---+---+---+---+---+---+

                                  304

                                                           uNOTE # 034
                                                          Page 3 of 24


      Bits 0,1,2:  Register Pointer

             These bits are used to  specify  which  register  will  be
             affected  by  the  next  Control  Register Write or Status
             Register Read.  After a reset the register pointer is  set
             to  0.   When the register pointer is set to a value other
             than 0 the  next  control  or  status  access  is  to  the
             specified register, then the pointer is reset to 0.

      Bits 3,4,5:  Command

             These bits are used to select the command to  be  sent  to
             the uPD7201.  A list of these commands follows:

             NULL (000)
             This command has no effect and is used  when  setting  the
             register pointer or issuing a CRC command.

             SEND ABORT (001)
             When operating in the SDLC mode, this command  causes  the
             uPD7201 to transmit the SDLC abort code.

             RESET EXTERNAL/STATUS INTERRUPTS (010)
             Clears any pending external interrupts and  reenables  the
             latches so that new interrupts may be detected.

             CHANNEL RESET (011)
             After  issuing  a  reset   command   the   receivers   and
             transmitters are disabled, the transmitters are set in the
             marking (high) state, and the modem  control  outputs  are
             set  high.   In addition, all interrupts are disabled, and
             all interrupt and DMA requests are cleared.   All  control
             registers  must  be  rewritten  after  a  reset.   One NOP
             instruction must be issued before writing a new command.

             ENABLE INTERRUPT ON NEXT CHARACTER (100)
             When operating in Interrupt on First Character  mode  this
             command is issued to re-enable the interrupt logic for the
             next received character.

             RESET PENDING TRANSMITTER INTERRUPT/DMA REQUEST (101)
             Issue this command to reset a pending  Transmitter  Buffer
             Becoming  Empty  interrupt  or DMA request without sending
             another character.

             ERROR RESET (110)
             This command resets a Special Receive Condition interrupt.
             It  also  re-enables  the Parity and Overrun Error latches
             that allow you to check for these errors at the end  of  a
             message.

             END OF INTERRUPT (111) (Channel A only)

                                  305

uNOTE # 034
Page 4 of 24


             When an interrupt request has been issued by  the  uPD7201
             all  lower  priority  interrupts are blocked to permit the
             current interrupt to be serviced.  At some  point  in  the
             interrupt  service  routine this command must be issued to
             re-enable the daisy chain and  permit  any  pending  lower
             priority interrupt requests to occur.

      Bits 6,7:  CRC Control Commands

             These  commands  control  the   operation   of   the   CRC
             generator/checker logic.

             NULL (00)
             This command has no effect and is used when issuing  other
             commands or setting the register pointer.

             RESET RECEIVER CRC CHECKER (01)
             This command resets the CRC checker to 0 when the  channel
             is  in  a  synchronous mode and resets to all ones when is
             SDLC mode.

             RESET TRANSMITTER CRC GENERATOR (10)
             This command resets  the  CRC  generator  to  0  when  the
             channel  is  in  a synchronous mode and resets to all ones
             when is SDLC mode.

             RESET IDLE/CRC LATCH (11)
             This command resets the Idle/CRC  latch  so  that  when  a
             transmitter  underrun  condition  occurs,  the transmitter
             enters the CRC phase of operation and begins to  send  the
             16-bit  CRC  character  calculated  up to that point.  The
             latch is  then  set  so  that  if  the  underrun  conition
             persists,  idle  characters  are  sent  following the CRC.
             After a hardware or software reset, the latch  is  in  the
             set state.


      Control Register 1

                        +---+---+---+---+---+---+---+---+
                        | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
                        +---+---+---+---+---+---+---+---+

      Bit 0:  External/Status Interrupt Enable

             When this bit  is  set  to  one,  the  uPD7201  issues  an
             interrupt whenever any of the following occur:

                     o  transition of DCD input




                                  306

                                                           uNOTE # 034
                                                          Page 5 of 24


                     o  transition of CTS input

                     o  transition of synch input

                     o  entering  or  leaving  synchronous  Hunt  Phase
                        break detection or termination

                     o  SDLC abort detection or termination

                     o  Idle/CRC latch becoming set (CRC being sent)

      Bit 1:  Transmitter Interrupt Enable

             When this bit  is  set  to  one,  the  uPD7201  issues  an
             interrupt when:

              o  The character currently in the transmitter  buffer  is
                 transferred  to the shift register (Transmitter Buffer
                 Becoming Empty)

              o  The  transmitter  enters   Idle   Phase   and   begins
                 transmitting sync or flag characters


      Bit 2:  Status Affects Vector (Channel B only)

             This bit must always be programmed  to  one  so  that  the
             fixed  vector  programmed  into  Control  Register  2B  is
             modified to indicate the cause of the interrupt.

      Bits 3,4:  Receiver Interrupt Mode

             This  field  determines  how  the  uPD7201   handles   the
             character receive conditions.

                    RECEIVER INTERRUPTS/DMA REQUEST DISABLED (00)
                    The uPD7201 does not  issue  an  interrupt  or  DMA
                    request   when   a  character  has  been  received.
                    (Polled Mode).

                    INTERRUPT ON FIRST RECEIVED CHARACTER ONLY (01)
                    The uPD7201  issues  an  interrupt  for  the  first
                    character  received  after  an  Enable Interrupt on
                    First Character Command (CR0) has been  given.   If
                    the  channel  is  in DMA mode then a DMA request is
                    issued for each character  received  including  the
                    first.

                    INTERRUPT ON ALL RECEIVED CHARACTERS (10)
                    An interrupt is  issued  whenever  a  character  is
                    present  in  the  receive buffer.  A DMA request is
                    issued if the channel is in  DMA  mode.   A  parity

                                  307

uNOTE # 034
Page 6 of 24


                    error is considered a special receive condition.

                    INTERRUPT ON ALL RECEIVED CHARACTERS (11)
                    This mode is the same as above except that a parity
                    error   is   not   treated  as  a  special  receive
                    condition.

             The  following  are  always  considered  special   receive
             conditions:


                     o  Receiver Overrun Error

                     o  Asynchronous Framing Error

                     o  SDLC End of Message

      Bits 5,6,7:  These bits should always be programmed to 0.


      Control Register 2 (Channel A)

                        +---+---+---+---+---+---+---+---+
                        | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
                        +---+---+---+---+---+---+---+---+
      Bits 0,1:  DMA Mode Select

             These bits determine the mode in which channels  A  and  B
             operate.   If  a  channel operates in a non-DMA mode it my
             perform transfers in either polled or interrupt mode.

                    Bit 1   Bit 0   Channel A   Channel B

                      0       0      Non-DMA     Non-DMA
                      0       1        DMA       Non-DMA
                      1       0      Illegal     Illegal
                      1       1      Illegal     Illegal

      Bit 2:  Priority

             This bit  is  used  to  select  the  appropriate  internal
             priorities  for interrupts.  The Channel A receiver always
             has a higher priority than the Channel A transmitter  when
             Channel A is in DMA mode.

             If Channels A and B are both in Interrupt Mode:

             0 - RxA > TxA > RxB > TxB > extA > extB
             1 - RxA > RxB > TxA > TxB > extA > extB

             If Channel A is in DMA mode and Channel B is in  Interrupt
             Mode:

                                  308

                                                           uNOTE # 034
                                                          Page 7 of 24


             0,1 - RxA > RxB > TxB > extA > extB

      Bits 3,5,6,7:  These bits must be programmed to 0.

      Bit 4:  This bit must always be programmed to 1.


      Control Register 2 (Programmed in Channel B for both channels)

                        +---+---+---+---+---+---+---+---+
                        | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
                        +---+---+---+---+---+---+---+---+


      Bits 0..7:  Interrupt Vector

             The native firmware of the KXT11-C initializes the uPD7201
             interrupt  vector  to  70(8).   All  interrupts  use  this
             vector.  In order to determine the cause of the  interrupt
             the uPD7201 must be operated with Condition Affects Vector
             enabled.  (Control Register 1 - Bit 2).  When this bit  is
             set  the  vector  is  modified to reflect the cause of the
             interrupt.  This  modified  vector  is  read  from  Status
             Register 2.


      Control Register 3

                        +---+---+---+---+---+---+---+---+
                        | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
                        +---+---+---+---+---+---+---+---+

      Bit 0:  Receiver Enable

             0 - Disables the receiver
             1 - Enables the receiver

      Bit 1:  Sync Character Load Inhibit

             In a synchronous mode, this bit inhibits the  transfer  of
             sync  characters  to  the receiver buffer.  When using the
             uPD7201's CRC checking capabilities  this  feature  should
             only  be used to strip leading sync characters preceding a
             message since the  load  inhibit  does  not  exclude  sync
             characters   embedded   in   the   message  from  the  CRC
             calculations.  Synchronous protocols using other types  of
             block  checking  such as checksum or LRC are free to strip
             embedded sync characters with this bit.

      Bit 2:  Address Search Mode

             In SDLC mode, setting  this  bit  places  the  uPD7201  in

                                  309

uNOTE # 034
Page 8 of 24


             Address  Search  mode  where  character  assembly does not
             begin until the 8-bit character (secondary address  field)
             following  the  starting  flag of a message matches either
             the address programmed into  CR6  or  the  global  address
             11111111.

      Bit 3:  Receiver CRC Enable

             This bit enables (enable = 1) the CRC checker in COP  mode
             to   allow   the   selective  inclusion  or  exclusion  of
             characters form the CRC calculation.

      Bit 4:  Enter Hunt Phase

             The uPD7201 automatically enters Hunt Phase after a reset.
             Setting  this  bit to 1 causes the uPD7201 to re-enter the
             Hunt Phase.

      Bit 5:  Auto Enables

             Setting this bit to 1 causes the DCD and CTS inputs to act
             as   enable   inputs  to  the  receiver  and  transmitter,
             respectively.

      Bits 6,7:  Number of Received Bits/Character

             This field specifies the number of data bits per  received
             character:

                    Bit 7   Bit 6   Bits/Character

                      0       0            5
                      0       1            7
                      1       0            6
                      1       1            8


      Control Register 4

                        +---+---+---+---+---+---+---+---+
                        | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
                        +---+---+---+---+---+---+---+---+

      Bit 0:  Parity Enable

             Setting this bit to 1 adds an extra  data  bit  containing
             parity  information  to  each transmitted cahracter.  Each
             received character is expected to contain this  extra  bit
             and the receiver parity checker is enabled.

      Bit 1:  Parity Even/Odd


                                  310

                                                           uNOTE # 034
                                                          Page 9 of 24


             0 - Odd parity generation and checking
             1 - Even parity generation and checking

      Bits 2,3:  Number of Stop Bits/Sync Mode

             This field specifies whether the  channel  is  used  in  a
             synchronous mode or in asynchronous mode.  In asynchronous
             mode, this field also specifies the number  of  stop  bits
             used  by  the transmitter.  The receiver always checks for
             one stop bit.

                    Bit 3   Bit 2   Mode

                      0       0     Synchronous mode
                      0       1     Asynch Mode, 1 stop bit
                      1       0     Asynch Mode, 1-1/2 stop bits
                      1       1     Asynch Mode, 2 stop bits

      Bits 4,5:  Sync Mode

             These bits select the synchronous protocol to use  if  the
             channel has been programmed in a synchronous mode.

                    Bit 5   Bit 4   Mode

                      0       0     Monosync
                      0       1     Bisync
                      1       0     SDLC
                      1       1     External Synchronization

      Bits 6,7:  Clock Rate

             These  bits   specify   the   relationship   between   the
             transmitter  and receiver clock inputs and the actual data
             rate.  When operating in synchronous mode the  clock  rate
             must be specified as 1X the data rate.

                    Bit 7   Bit 6   Clock Rate

                      0       0     Clock Rate = 1X  Data Rate
                      0       1     Clock Rate = 16X Data Rate
                      1       0     Clock Rate = 32X Data Rate
                      1       1     Clock Rate = 64X Data Rate

      Control Register 5

                        +---+---+---+---+---+---+---+---+
                        | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
                        +---+---+---+---+---+---+---+---+

      Bit 0:  Transmitter CRC Enable


                                  311

uNOTE # 034
Page 10 of 24


             A 1 enables the CRC generator calculation.  By setting  or
             resetting this bit just before loading the next character,
             it and subsequent characters are included or excluded from
             the calculation.

      Bit 1:  RTS

             In synchronous and SDLC  modes,  setting  this  bit  to  1
             causes  the  RTS  pin  to go low while a 0 causes it to go
             high.  In asynchronous mode, setting this bit  to  0  does
             not  cause  RTS  to  go  high  until  the  transmitter  is
             completely empty.

      Bit 2:  CRC Polynomial Select

             A 0 selects the CRC-CCITT Polynomial (X**16 + X**12 + X**5
             +  1).  A 1 selects the CRC-16 Polynomial (X**16 + X**15 +
             X**2 +1).  The CRC-CCITT polynomial must be selected  when
             in SDLC mode.

      Bit 3:  Transmitter Enable

             After a reset the transmitted data  output  is  held  high
             (marking)  and  the transmitter is disabled until this bit
             is set.

      Bit 4:  Send Break

             Setting this bit to 1 forces the  transmitter  output  low
             (spacing).

      Bits 5,6:  Transmitted Bits/Character

             These bits specify the number of data bits per transmitted
             character.

                    Bit 6   Bit 5   Bits/Character
                      0       0            5 (or less)
                      0       1            7
                      1       0            6
                      1       1            8

      Bit 7:  DTR

             When this bit is 1, the DTR output is active.


      Control Register 6

                        +---+---+---+---+---+---+---+---+
                        | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
                        +---+---+---+---+---+---+---+---+

                                  312

                                                           uNOTE # 034
                                                         Page 11 of 24


      Bits 0..7:  Sync Byte 1

             Sync byte 1 is used in the following modes:

                    Monosync:       The 8-bit character transmitted during 
                                    the Idle Phase.
                    Bisync:         The least significant 8 bits of the 16-bit
                                    transmit and receive sync character.
                    External Sync:  Sync character transmitted during
                                    the Idle Phase.
                    SDLC:           Secondary address value matched to the
                                    Secondary Address field of the
                                    SDLC frame when the uPD7201 is in Address
                                    Search Mode.


      Control Register 7

                        +---+---+---+---+---+---+---+---+
                        | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
                        +---+---+---+---+---+---+---+---+

      Bits 0..7:  Sync Byte 2
             Sync Byte 2 is used in the following modes:

                    Monosync:  8-bit sync character matched by the receiver.
                    Bisync:    Most significant 8 bits of the 16-bit transmit
                               and receive sync characters.
                    SDLC:      Must contain the flag value, 01111110, for flag
                               matching by the uPD7201 receiver.

      Status Register 0

                        +---+---+---+---+---+---+---+---+
                        | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
                        +---+---+---+---+---+---+---+---+

      Bit 0:  Received Character Available

             When this bit is  set,  it  indicates  that  one  or  more
             characters are available in the receiver buffer.  Once all
             of the available characters have been  read,  the  uPD7201
             resets  this  bit  until  a new character is received.  By
             utilizing this bit the programmer my run  at  higher  data
             rates  than  normal because it will be possible to capture
             more that one character per interrupt service routine.

      Bit 1:  Interrupt Pending (Channel A only)

             The interrupt pending  bit  is  used  with  the  interrupt
             vector  register  (status register 2) to make it easier to
             determine the uPD7201's interrupt status.  In Non-vectored

                                  313

uNOTE # 034
Page 12 of 24


             Interrupt  mode,  interrupt  pending  is  set  when status
             register 2B is read.  If status affects vector is  enabled
             and  interrupt  pending  is  set, the vector read from SR2
             contains valid condition information.

      Bit 2:  Transmitter Buffer Empty

             This bit is set whenever the transmitter buffer is  empty,
             except during the transmission of the CRC.  After a reset,
             the buffer is  considered  empty  and  transmitter  buffer
             empty is set.

      Bit 3:  DCD (Data Carrier Detect)

             This bit reflects the inverted state  of  the  DCD  input.
             When  DCD  is  low,  the  DCD  status  bit  is  high.  Any
             transition of this bit causes an External/Status Interrupt
             request.

      Bit 4:  Sync Status

             The  bit  assumes  different  meanings  depending  on  the
             operating mode of the uPD7201.

             Asynch mode:  Sync Status reflects the inverted  state  fo
             the  Sync  input.   Any  transition  of this bit causes an
             External/Status interrupt request.

             External Sync mode:  Sync  Status  operates  in  the  same
             manner as asynch mode.  A low-to-high transition indicates
             that  synchronization  has  been  achieved  and  character
             assembly begins.

             Monosync,  Bisync,  SDLC  modes:   Sync  Status  indicates
             whether  the  receiver is in the Sync Hunt (bit =1) or the
             Receive Data Phase (bit = 0) of operation.

      Bit 5:  CTS (Clear to Send)

             This bit reflects the inverted state  of  the  CTS  input.
             Any  transition  of  this  bit  causes  an External/Status
             interrupt request.

      Bit 6:  Idle/CRC

             This bit indicates the state of the Idle/CRC latch used in
             synchronous and SDLC modes.

      Bit 7:  Break/Abort

             In async mode, this bit indicates that the detection of  a
             break  sequence  that  occurs  when  the input is held low

                                  314

                                                           uNOTE # 034
                                                         Page 13 of 24


             (spacing) for more than one character time.  This  bit  is
             reset when the input returns high (marking).

             In SDLC mode, Break/Abort indicates the  detection  of  an
             abort  sequence  when  7  or  more  ones  are  received in
             sequence.

             Any  transition  of  the   Break/Abort   bit   causes   an
             External/Status interrupt.


      Status Register 1

                        +---+---+---+---+---+---+---+---+
                        | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
                        +---+---+---+---+---+---+---+---+

      Bit 0:  All Sent

             In async mode, this bit is set  when  the  transmitter  is
             empty  and  reset  when  a  character  is  present  in the
             transmitter buffer or shift register.  In synchronous  and
             SDLC modes, this bit is always 1.

      Bits 1,2,3:  SDLC Residue Code

             The data portion of an SDLC message  can  consist  of  any
             number  of  bits and not necessarily an integral number of
             characters.  Special logic determines and reports when the
             End  of Frame flag has been received, the boundary between
             the data field, and the CRC character in the last few data
             characters that were read.

      Bit 4:  Parity Error

             This bit is set when parity is enabled  and  the  received
             parity  bit  does  not match the sense calculated from the
             data bits.

      Bit 5:  Receiver Overrun Error

             This  error  occurs  when  the  receiver  buffer   already
             contains  three  characters  and  a  fourth  character  is
             completely received, overwriting the last character in the
             buffer.

      Bit 6:  CRC/Framing Error

             In Async modem a framing error is flagged when no sop  bit
             is detected at the end of a character.

             In sync and SDLC modes, this bit indicates the  result  of

                                  315

uNOTE # 034
Page 14 of 24


             the  comparison  between  the  current  CRC result and the
             appropriate check value.

      Bit 7:  End of SDLC Frame

             This flag is used in SDLC mode to indicate that the End of
             FRame  flag  has been received and that the CRC error flag
             and residue code is valid.


      Status Register 2

                        +---+---+---+---+---+---+---+---+
                        | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
                        +---+---+---+---+---+---+---+---+

      Bits 0..7:  Interrupt Vector (Channel B only)

             Reading Status Register 2B returns  the  interrupt  vector
             that   was   programmed  into  Control  Register  2B.   If
             Condition Affects Vector  is  enabled  the  value  of  the
             vector is modified as follows:


                       Condition Affects Vector Modifications

             Bit 2   Bit 1   Bit 0   Condition

               1       1       1     No interrupt pending
               0       0       0     Channel B Transmitter Buffer Empty
               0       0       1     Channel B External/Status Change
               0       1       0     Channel B Received Character Available
               0       1       1     Channel B Special Receive Condition
               1       0       0     Channel A Transmitter Buffer Empty
               1       0       1     Channel A External/Status Change
               1       1       0     Channel A Received Character Available
               1       1       1     Channel A Special Receive Condition

                                    - Table 1 -

             Code 111 has  two  meanings:   either  Channel  A  Special
             Receive  Condition  or  no interrupt pending.  In order to
             distinguish between the two,  the  Interrupt  Pending  bit
             (SR0) must be examined.


      Baud Rate Generator Registers

      Programmable baud rates for channels A and B are supplied  by  an
      Intel  8254-2  timing controller chip with two counters operating
      at 9.8304 MHz.  A third  counter  that  operates  at  800  Hz  is
      available for general use.  This general purpose counter issues a

                                  316

                                                           uNOTE # 034
                                                         Page 15 of 24


      level 6 interrupt request to the T-11 via vector 104.

      Programming these counters is straightforward.   First,  a  Timer
      Control  register  is  initialized to provide the proper counting
      mode.  Then a divider ratio is loaded into a Timer Data  register
      to  obtain  the desired baud rate.  The divider ratio is obtained
      from the following calculations:

      For synchronous transmission,

                Synchronous bit rate = 9830.4K / divider ratio

      Therefore,

                divider ratio = 9830.4K / synchronous bit rate

      A few examples,

                Bit Rate          Ratio

                  1200             8192
                  9600             1024
                  38.4K             256
                  76.8K             128


      For asynchronous transmission (assuming that the  clock  rate  is
      divided by 16),

                Asynchronous bit rate = 9830.4K (1/16) / divider ratio

      Therefore,

                divider ratio = 614.4K / asynchronous bit rate

      A few examples,

                Bit Rate          Ratio

                  1200             512
                  9600              64
                  38.4K             16
                  76.8K              8


      Timer Control Register

                        +---+---+---+---+---+---+---+---+
                        | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
                        +---+---+---+---+---+---+---+---+

      Bit 0:  BCD or Binary

                                  317

uNOTE # 034
Page 16 of 24


             0 - Use 16-bit binary counter
             1 - Use BCD counter with four decades

      Bits 1,2,3:  Mode Select

             The mode of the counter is selected with these bits:

                    Bit 3   Bit 2   Bit 1     Mode

                      0       0       0       Interrupt on Terminal Count
                      0       0       1       Not supported
                      0       1       0       Rate Generator
                      0       1       1       Square Wave Generator
                      1       0       0       Software Triggered Strobe
                      1       0       1       Not supported
                      1       1       0       Reserved
                      1       1       1       Reserved

      Bits 4,5:  Read/Write Sequence Selection

             The Timer Data registers are programmed on a  byte  basis.
             These  bits determine the sequence in which the Timer Data
             registers interpret the data.

                    Bit 5   Bit 4     Sequence

                      0       0       Counter Latch Command
                      0       1       Read/Write least significant byte only
                      1       0       Read/Write most significant byte only
                      1       1       Read/Write least significant byte first,
                                        then most significant byte

      Bits 6,7:  Counter Select

             These bits select which counter is being programmed.

                    Bit 7   Bit 6     Counter

                      0       0       Counter 0
                      0       1       Counter 1
                      1       0       Counter 2
                      1       1       Read-back command



      KXT Control/Status Register A

                        +---+---+---+---+---+---+---+---+
                        | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
                        +---+---+---+---+---+---+---+---+

      This register contains some of the control lines for the uPD7201.

                                  318

                                                           uNOTE # 034
                                                         Page 17 of 24


      Bit 0:  SYNCM B

             0 - Channel B receives its clock  from  the  onboard  baud
             rate generator
             1 - Channel B receives its clock from an external source

      Bit 1:  SLU2B R EN

             0 -  Party  line  receive  data  enabled  (Board  must  be
             properly configured)
             1 - Party line receive data disabled

      Bit 2:  SYNCM A

             0 - Channel A receives its clock  from  the  onboard  baud
             rate generator
             1 - Channel A receives its clock from an external source

      Bit 3:  Data Terminal Ready (DTR)

             0 - DTR is not asserted
             1 - DTR is asserted

      Bit 4:  Terminal in Service (Busy)

             0 - Terminal in Service is not asserted
             1 - Terminal in Service is asserted

      Bit 5:  Diagnostic Prom Enable

             This bit allows two different 1K portions of  the  onboard
             firmware to be visible at addresses 160000-163777.

      Bit 6:  Real Time Clock Enable

             0 - The RTC interrupt is inhibited
             1 - The RTC interrupt is enabled

      Bit 7:  Counter 2 Interrupt Enable

             0 - Counter 2 interrupts are inhibited
             1 - Counter 2 interrupts are enabled


      The following table lists the registers that have been  described
      and their addresses:

             KXT Control/Status Register A       177520     Read/Write

             Timer Control Register              175736     Write only
             Timer 2 Data Register               175734     Write only
             Timer 1 Data Register               175732     Write only

                                  319

uNOTE # 034
Page 18 of 24


             Timer 0 Data Register               175730     Write only
             Timer 2 Data Register               175724     Read only
             Timer 1 Data Register               175722     Read only
             Timer 0 Data Register               175720     Read only

             Channel B Transmitter               175716     Write only
             Channel B Control Register          175714     Write only
             Channel B Receiver                  175712     Read only
             Channel B Status Register           175710     Read only
             Channel A Transmitter               175706     Write only
             Channel A Control Register          175704     Write only
             Channel A Receiver                  175702     Read only
             Channel A Status Register           175700     Read only

                                    - Table 2 -


      PROGRAMMING EXAMPLES

      The following programs provide 'skeletons' on which to base  user
      application programs.

                .TITLE  SLU1.MAC

        ;  This program utilizes the uPD7201 to transfer serial data.  The
        ;  data will be transfered out of Channel A and received by Channel
        ;  A so a loopback connector is required (Part #H3022 or 54-16229-01).
        ;  This example transfers the data in asynchronous mode using
        ;  interrupts.
        ;
        ;  After this program has been assembled and linked on the
        ;  development machine use the KUI utility of the KXT11-C Software
        ;  Toolkit to load the program into the KXT11-C to execute as
        ;  shown in this example:
        ;
        ;  SET 2
        ;  LOAD SLU1.SAV
        ;  EXECUTE
        ;  !ODT
        ;  !
        ;  !001206
        ;  !001302/041101 
        ;  !001304/042103 
        ;  !001306/043105 
        ;  !001310/044107 
        ;  !001312/041101 
        ;  !001314/042103 
        ;  !001316/043105 
        ;  !001320/044107 
        ;  !001322/000000 
        ;  !R4/000000 
        ;  !

                                  320

                                                           uNOTE # 034
                                                         Page 19 of 24


        ;  EXIT
        ;
        ;  This verifies that the data was successfully transfered.  1302 is
        ;  the address of the transmit buffer and 1312 is the address of the
        ;  receive buffer.  R4=0 verifies that no external or special
        ;  condition interrupts were received.
        ;

        ;  Register Definitions

                STATA  == 175700        ; Channel A status register
                RBUFA  == 175702        ; Channel A receiver
                CNTRLA == 175704        ; Channel A Control register
                TBUFA  == 175706        ; Channel A transmitter
                
                STATB  == 175710        ; Channel B status register
                CNTRLB == 175714        ; Channel B control register
        
                TIMREG == 175736        ; Timer control register
                TIMER0 == 175730        ; Timer 0 data register
        
        START::

        ;  This section initializes the KXT11-C system environment

                MTPS    #340            ; Disable recognition of interrupts

                MOV     #ISR,@#70       ; SLU2 interrupts at location 70
                MOV     #340,@#72       ; Let the ISR run at priority 7

                CLR     R0              ; This is the transmit char counter

                MOV     #TBUF,R2        ; R2 points to the transmit buffer
                MOV     #RBUF,R3        ; R3 points to the receive buffer

                CLR     R4              ; This counter keeps track of external
                                        ;  status changes and special receive
                                        ;  receive conditions

        ;  This section initializes the bit rate generator

                MOVB    #26,TIMREG      ; Select timer 0, low byte only,
                                        ;  mode 3, binary
                MOVB    #64.,TIMER0     ; This divider selects 9600 bps
                                        
        ;  This section initializes the 7201 for asynch operation

                MOVB    #30,CNTRLA      ; Reset Channel A
                NOP                     ; Wait for reset to complete

                MOVB    #30,CNTRLB      ; Reset Channel B
                NOP                     ; Wait for reset to complete

                                  321

uNOTE # 034
Page 20 of 24


                MOVB    #2,CNTRLA       ; Point to CR2A
                MOVB    #24,CNTRLA      ; Setup bus interface options:
                                        ; No DMA, RxA>RxB>TxA..., Non-Vectored

                MOVB    #4,CNTRLA       ; Point to CR4
                MOVB    #104,CNTRLA     ; Set operation mode:
                                        ; No parity, asynch mode, 1 stop bit,
                                        ;  clock rate = 16x data rate

                MOVB    #3,CNTRLA       ; Point to CR3
                MOVB    #301,CNTRLA     ; Enable receiver, char length = 8

                MOVB    #5,CNTRLA       ; Point to CR5
                MOVB    #152,CNTRLA     ; Enable transmitter, Char length = 8

                CLRB    CNTRLA          ; Point to CR0
                MOVB    #20,CNTRLA      ; Reset External/Status Interrupts

                MOVB    #1,CNTRLA       ; Point to CR1
                MOVB    #36,CNTRLA      ; Transmit IE, Interrupt on all
                                        ;  received chars, enable condition
                                        ;  affects vector

        MAIN::
                MTPS    #0              ; Enable recognition of interrupts
                MOVB    (R2)+,TBUFA     ; Send first character
                BR      .               ; Stay here while the interrupts occur

        ISR::
                MOVB    #2,CNTRLB       ; Point to SR2B
                MOVB    STATB,-(SP)     ; Store the condition affects vector
                                        ;  on the stack
        
                ;  This section inspects the condition affects vector to
                ;  determine the cause of the interrupt

                ROR     (SP)            ; Rotate bit 0 into the carry bit
                BCS     EXT             ; If this bit was set then the
                                        ;  interrupt was caused by a special
                                        ;  receive condition or an external/
                                        ;  status change
                ROR     (SP)            ; Rotate bit 1 into the carry bit
                BCS     RCV             ; If this bit was set then the
                                        ;  interrupt was caused by a received
                                        ;  character
                        ;+
                        ;  If neither of the above conditions was
                        ;  satisfied then the interrupt must have
                        ;  been caused by the transmitter buffer
                        ;  going empty
                        ;-
        XMIT::

                                  322

                                                           uNOTE # 034
                                                         Page 21 of 24


                INC     R0              ; Increment the xmit char counter
                CMP     R0,#8.          ; IF this is the eight char
                BEQ     1$              ;  THEN branch to 1$
                MOVB    (R2)+,TBUFA     ;  ELSE send another char
                BR      IDONE           ;   and return
        1$:     MOVB    #50,CNTRLA      ;  reset pending xmit interrupt
                BR      IDONE           ;   request - then return

        RCV::   MOVB    RBUFA,(R3)+     ; Store this character
                BR      IDONE           ;  and return

        EXT::   ;  This program does not take any special action if an
                ;  External/Status interrupt or Special Receive Condition
                ;  occurs.  Just note that it occurred (there shouldn't be
                ;  any) and continue.

                INC     R4              ; Increment the counter
                                        ;  and return

        IDONE:: TST     (SP)+           ; Fix the stack
                MOVB    #70,CNTRLA      ; Issue end of interrupt command
                RTI                     ;  and return to main program

        TBUF::  .BYTE   101,102,103,104,105,106,107,110
        RBUF::  .BLKB   8.

                .END    START



                .TITLE  SLU2.MAC

        ;  This example program for the uPD7201 transfers serial data via
        ;  a loopback connector (part #H3022 or 54-16229) between Channel
        ;  A's transmit and receive using the DMA controller.  No ISR is
        ;  included in this example as it is meant to show how the uPD7201
        ;  and the DTC may work together.  A 'real-life' program should
        ;  include an ISR which monitors any External or Special Receive
        ;  condition interrupts.  For more information regarding the
        ;  programming of the DTC please refer to MicroNote #018.
        ;
        ;  After this program has been assembled and linked on the
        ;  development machine use the KUI utility of the KXT11-C Software
        ;  Toolkit to load the program into the KXT11-C to execute as
        ;  shown in this example:
        ;
        ;  SET 2
        ;  LOAD SLU2.SAV
        ;  EXECUTE
        ;  !ODT
        ;  !
        ;  !001234

                                  323

uNOTE # 034
Page 22 of 24


        ;  !1276/041101 
        ;  !001300/042103 
        ;  !001302/043105 
        ;  !001304/044107 
        ;  !001306/041101 
        ;  !001310/042103 
        ;  !001312/043105 
        ;  !001314/044107 
        ;  !001316/000000 
        ;  !
        ;  EXIT
        ;
        ;  This verifies that the data was tranfered successfully.  The
        ;  transmit buffer begins at address 1276 and the receive buffer
        ;  begins at address 1306.
        ;
        ;  Register Assignments

                MMREG   ==  174470      ; Master Mode Register
                CMDREG  ==  174454      ; Command Register
                CASTF0  ==  174446      ; Chan 0 Chain Address Seg/Tag Field
                CAOF0   ==  174442      ; Chan 0 Chain Address Offset Field
                CASTF1  ==  174444      ; Chan 1 Chain Address Seg/Tag Field
                CAOF1   ==  174440      ; Chan 1 Chain Address Offset Field

                STATA  == 175700        ; Channel A status register
                RBUFA  == 175702        ; Channel A receiver
                CNTRLA == 175704        ; Channel A Control register
                TBUFA  == 175706        ; Channel A transmitter
                
                STATB  == 175710        ; Channel B status register
                CNTRLB == 175714        ; Channel B control register

                TIMREG == 175736        ; Timer Control register
                TIMER0 == 175730        ; Timer 0 Data register
        
        START::

        ;  This section initializes the KXT11-C system environment

                MTPS    #340            ; Disable recognition of interrupts

                MOV     #TBUF,R2        ; R2 points to the transmit buffer
                MOV     #RBUF,R3        ; R3 points to the receive buffer

        ;  This section initializes the bit rate generator

                MOVB    #26,TIMREG      ; Select timer 0, low byte only,
                                        ;  mode 3, binary
                MOVB    #64.,TIMER0     ; This divider selects 9600 bps

        ;  This section initializes the 7201 for asynch operation

                                  324

                                                           uNOTE # 034
                                                         Page 23 of 24


                MOVB    #30,CNTRLA      ; Reset Channel A
                NOP                     ; Wait for reset to complete

                MOVB    #30,CNTRLB      ; Reset Channel B
                NOP                     ; Wait for reset to complete

                MOVB    #2,CNTRLA       ; Point to CR2A
                MOVB    #25,CNTRLA      ; Setup bus interface options:
                                        ; Chan A DMA, RxA>RxB>TxA...,
                                        ; Non-Vectored

                MOVB    #4,CNTRLA       ; Point to CR4
                MOVB    #104,CNTRLA     ; Set operation mode:
                                        ; No parity, asynch mode, 1 stop bit,
                                        ;  clock rate = 16x data rate

                MOVB    #3,CNTRLA       ; Point to CR3
                MOVB    #301,CNTRLA     ; Enable receiver, char length = 8
                                        ;
                MOVB    #5,CNTRLA       ; Point to CR5
                MOVB    #152,CNTRLA     ; Enable transmitter, Char length = 8
                                        ; 
                CLRB    CNTRLA          ; Point to CR0
                MOVB    #20,CNTRLA      ; Reset External/Status Interrupts
                                        ;
                MOVB    #1,CNTRLA       ; Point to CR1
                MOVB    #16,CNTRLA      ; Transmit IE, Interrupt on 1st
                                        ;  received char and issue DMA request
                                        ;  enable condition affects vector

        ;  This section initializes the DMA controller

                CLRB    CMDREG          ; Reset the DTC

                MOV     #0,CASTF0       ; Load Chain Address Register Seg/Tag
                MOV     #LOAD0,CAOF0    ; Load Chain Address Register Offset
                MOV     #0,CASTF1       ; Load Chain Address Register Seg/Tag
                MOV     #LOAD1,CAOF1    ; Load Chain Address Register Offset
        
                MOVB    #115,MMREG      ; Load Master Mode Reg to Enable DTC
        
                MOVB    #240,CMDREG     ; Start Chain Channel 0
                MOVB    #241,CMDREG     ; Start Chain Channel 1
        
        MAIN::
                BR      .               ; Stay here while the DMA transfers
                                        ;  occur

                ; Chain Load Region

        LOAD1:  .WORD   001602  ; Reload Word <Select CARA,CARB,COPC,CM>


                                  325

uNOTE # 034
Page 24 of 24


                .WORD   000000  ; Current Address Register A Seg/Tag
                .WORD   TBUF    ; Current Address Register A Offset
                                ; <This local address is the source>
        
                .WORD   000020  ; Current Address Register B Seg/Tag
                .WORD   TBUFA+1 ; Current Address Register B Offset
                                ; <This local address is the destination>
        
                .WORD   000010  ; Current Operation Count <Transfer 8 bytes>
        
                .WORD   000020  ; Channel Mode Register High
                .WORD   000001  ; Channel Mode Register Low
                                ; <No match conditions, do nothing upon
                                ;  completion, transfer type = single transfer
                                ;  CARA = source, byte transfers>
        
        LOAD0:  .WORD   001602  ; Reload Word <Select CARA,CARB,COPC,CM>
        
                .WORD   000020  ; Current Address Register A Seg/Tag
                .WORD   RBUFA+1 ; Current Address Register A Offset
                                ; <This local address is the source>
        
                .WORD   000000  ; Current Address Register B Seg/Tag
                .WORD   RBUF    ; Current Address Register B Offset
                                ; <This local address is the destination>
        
                .WORD   000010  ; Current Operation Count <Transfer 8 bytes>
        
                .WORD   000000  ; Channel Mode Register High
                .WORD   000001  ; Channel Mode Register Low
                                ; <No match conditions, do nothing upon
                                ;  completion, transfer type = single transfer
                                ;  CARA = source, byte transfers>
        
        TBUF::  .BYTE   101,102,103,104,105,106,107,110
        RBUF::  .BLKB   10

                .END    START



      RELATED DOCUMENTS

      For further information about the KXT11-C and the uPD7201  please
      consult the following sources:

      KXT11-C Single-Board Computer User's Guide  (EK-KXTCA-UG)

      uPD7201 Technical Manual *

        *  This manual may be obtained from NEC


                                  326

================================================================================
Note 35.0                Backplane Expansion/Termination              No replies
FURILO::GIORGETTI                                   469 lines   3-SEP-1985 17:22
--------------------------------------------------------------------------------


      +---------------+                                    +-----------------+
      | d i g i t a l |                                    |  uNOTE # 035    |
      +---------------+                                    +-----------------+

                                                                   
      +----------------------------------------------------+-----------------+
      | Title:  Backplane Expansion/Termination            | Date: 19-Jul-85 |
      +----------------------------------------------------+-----------------+
      | Originator: Jack Toto                              | Page 1 of 8     |
      +----------------------------------------------------+-----------------+


      The  following  MicroNote  discusses  the  termination   and   expansion
      configurations  which  are  SUPPORTED  by Digital Equipment Corporation.
      These configurations will deal with  18  and  22-bit  Q-bus  processors,
      backplanes  and  enclosures.   Not all cases presented in this MicroNote
      meet FCC regulations, and only those that do are so marked.
      The MicroNote is partitioned as follows:

           1. System configurations
           2. Single Box expansion/termination rules.
           3. Multiple box expansion/termination rules.
           4. Configuration/case reference chart.
           5. Supported single box configuration cases. 
           6. Supported multiple box configuration cases.


      1. SYSTEM CONFIGURATION
         --------------------
      The following is a list of single  and  multiple  backplane  termination
      rules  which  must  be  followed  when termination is required.  Further
      explanation of these  rules  can  be  found  in  MicroNote  #  029,  the
      Microcomputers   Products   Handbook  (EB-26078-41),  the  Microcomputer
      Products Configuration Guide (EB-27318-68), and generally the user guide
      for any of the CPUs.

      The LSI-11 Bus system can be divided into two types:

          1.  Systems containing one backplane.
          2.  Systems containing multiple backplanes


      Before configuring any system,  module/system  characteristics  must  be
      known.  These characteristics are:

           1.  Power  consumption.   The  +5   Vdc   and   +12   Vdc   current
               requirements.

           2.  AC bus loading.   The  amount  of  capacitance  that  a  module
               presents  to  a  bus  signal  line.  AC loading is expressed in
               terms of  ac  loads  where  one  ac  load  equals  9.35  pf  of
               capacitance.

                                  327

uNOTE # 035
Page 2 of 8


           3.  DC bus loading.  The amount of  dc  leakage  current  a  module
               presents  to a bus signal when the line is high (undriven).  DC
               loading is expressed in terms of dc loads  where  one  dc  load
               equals 210 ma nominal.

           4.  Total backplane loading must include ac and dc  loads  and  the
               power consumption of the processor, modules, terminator module,
               and backplane.

           5.  Processor termination, class as either 120 ohms or 240 ohms, as
               follows:

                  OPTION         TERMINATION     MODEL NAME
                  ------------------------------------------
                  A. KDF11-A       240 OHMS       LSI 11/23
                  B. KDF11-B       120 OHMS       LSI 11/23 +
                  C. KDJ11-A       240 OHMS       LSI 11/73
                  D. KDJ11-B       120 OHMS       PDP 11/73
                  E. MicroVAX I    120 OHMS       MicroVax I CPU
                  F. MicroVax II   240 OHMS       MicroVax II CPU


      Power consumption, ac loading, and dc loading  specifications  for  each
      module can be found in sources mentioned earlier.


      2. SINGLE BACKPLANE TERMINATION RULES
         ----------------------------------

           1.  When using a processor with 240 ohms termination, the  bus  can
               accommodate  up  to  20  ac  loads  (total)  before  additional
               termination  is  required.   If  more  than  20  ac  loads  are
               included,  the  far  end of the bus must be terminated with 120
               ohms, although termination of 240 ohms is  optimum.   Following
               the  addition  of  at least the minimum termination up to 35 ac
               loads may be present in a single backplane.

           2.  When using a processor with 120 ohms termination, up to  35  ac
               loads  (total)  may be present before additional termination is
               required.  If more than 35 ac loads are included, the  far  end
               of  the  bus  must  be terminated with 120 ohms.  When this has
               been done up to 45 ac loads may be present.

           3.  The bus can accommodate up to 20 (total)  dc  loads.   This  is
               true in all cases.

           4.  The bus signal lines on the backplane can be up to 35.6 cm  (14
               in) long.





                                  328

                                                           uNOTE # 035
                                                           Page 3 of 8


      3. MULTIPLE BACKPLANE TERMINATION RULES
         ------------------------------------

           1.  Up to three backplanes maximum can be configured in a  multiple
               backplane system.

           2.  The signal lines on each backplane can be up to 25.4 cm (10 in)
               in length.

           3.  Terminated multiple backplane systems can accommodate up to  44
               ac  loads, for two backplane systems, and 66 ac loads for three
               backplane systems.  In multiple backplane systems no more  than
               22  ac  loads  may be present in any one backplane, nor may any
               unused ac loads  from  one  backplane  be  added  to  the  next
               backplane.   It  is best to load each backplane equally, but if
               not possible, then the first and second backplanes should  have
               the highest number of ac loads.

           4.  DC loading for all modules in all backplanes cannot  exceed  20
               loads (total).

           5.  Both ends of the bus must be terminated with  120  ohms.   This
               means that the first and last backplanes must have an impedance
               of 120 ohms.  To achieve this, each backplane  must  be  lumped
               together  as  a single point.  The resistive termination may be
               provided by combining two of the modules in the backplane;  the
               processor  providing  240  ohms  to  ground in parallel with an
               expansion module providing 240 ohms to give the needed 120 ohms
               termination.  Alternately a processor with 120 ohms termination
               would require no additional termination on the expansion module
               to provide 120 ohms in the first box.  The 120 ohms termination
               in the last box may be provided in three ways.  The termination
               resistors  may reside either on the bus expansion module, or on
               a bus terminator module such as a BDV11, or  on  the  backplane
               itself as in the case of the H9275 and BA23-A backplanes.

           6.  The cable lengths connecting the first and second backplane are
               61 cm (2 ft) or greater.

           7.  The cables connecting the second and third backplane are 122 cm
               (4  ft)  longer or shorter than the cables connecting the first
               and second backplanes.

                                            NOTE

                       NEITHER THE FIRST OR SECOND BOX  CABLE  MAY  BE
                       SHORTER  THAN  2 FEET IN LENGTH AND BOTH CABLES
                       MUST DIFFER IN LENGTH BY 4 FEET.





                                  329

uNOTE # 035
Page 4 of 8


           8.  The combined length of the cables can not exceed 4.88 m  or  16
               feet.

           9.  The cables must have a characteristic impedance of 120 ohms.


      4. CONFIGURATION/CASE REFERENCE CHART
         ----------------------------------

      The chart below is designed to  be  a  quick  reference  to  a  specific
      configuration  combination  of CPU and system box(es).  The actual cases
      themselves are listed after the chart.

      To use the chart below, find the CPU that  is  in  the  system  and  the
      number  of  backplanes  or  enclosures  that  you  will  be  using.  The
      intersection of the two parameters  will  give  you  the  case/variation
      number that is valid for that configuration.  The case/variation will be
      listed as a case number followed by the variation number listed as  ".n"
      (where  n  is an integer from 1 to 9).  Ex.  case 1.2 represents case 1,
      with variation 2.

                              SYSTEM CONFIGURATION CHART
       +----------------------+--------------+---------------+---------------+
       |    PROCESSOR         | SINGLE BOX   |   TWO BOX     |   THREE BOX   |
       +----------------------+--------------+---------------+---------------+
       | KDF11-A  240 OHMS    | CASE 1       | CASE 4.1      | 18-BIT SYSTEMS|
       |                      | CASE 2       | CASE 4.2      |     ONLY      |
       |                      |              | CASE 4.3      |               |
       +----------------------+--------------+---------------+---------------+
       | KDF11-B  120 OHMS    | CASE 1       | CASE 3.1      | 18-BIT SYSTEMS|
       |                      | CASE 2       | CASE 3.2      |     ONLY      |
       |                      |              | CASE 3.3      |               |
       |                      |              | CASE 3.4      |               |
       +----------------------+--------------+---------------+---------------+
       | KDJ11-A  240 OHMS    | CASE 1       | CASE 4.1      | 18-BIT SYSTEMS|
       |                      | CASE 2       | CASE 4.2      |     ONLY      |
       |                      |              | CASE 4.3      |               |
       +----------------------+--------------+---------------+---------------+
       | KDJ11-B  120 OHMS    | CASE 1       | CASE 3.1      | 18-BIT SYSTEMS|
       |                      | CASE 2       | CASE 3.2      |     ONLY      |
       |                      |              | CASE 3.3      |               |
       |                      |              | CASE 3.4      |               |
       +----------------------+--------------+---------------+---------------+
       | MICROVAX I 120 OHMS  | CASE 2       | CASE 3.1      | NOT           |
       |                      |              | CASE 3.2      |  APPLICABLE   |
       |                      |              | CASE 3.3      |               |
       |                      |              | CASE 3.4      |               |
       +----------------------+--------------+---------------+---------------+
       | MICROVAX II 240 OHMS | CASE 2       | CASE 4.1      | NOT           |
       |                      |              | CASE 4.2      |  APPLICABLE   |
       |                      |              | CASE 4.3      |               |
       +----------------------+--------------+---------------+---------------+

                                  330

                                                           uNOTE # 035
                                                           Page 5 of 8



      5. SINGLE BOX SYSTEMS CONFIGURATION CASES
         --------------------------------------

      Single box 18 or 22 bit system  configurations  can  be  terminated  the
      following  two  ways.   The  two  configuration  cases presented in this
      section will give optimum bus termination to  120  ohm  processor  based
      systems and acceptable termination to 240 ohm processor based systems.

           CASE 1.  Use an unterminated enclosure/backplane with a termination
           card  such as the BDV11 in the first unused slot.  This card should
           be ECO'd to etch revision E, when used in 22-bit  systems  .   This
           card should also have the on board processor and memory diagnostics
           disabled if it is going to be used to terminate a system  with  the
           KDJ11-A  or  KDJ11-B  as  the  CPU.  (refer to MicroNote # 003) The
           following enclosures and backplanes are unterminated;

                          OPTION      SYSTEM SIZE
                          -----------------------
                       A. BA11-SA     18/22 BIT 
                       B. BA11-M      18 BIT 
                       C. BA11-N      18 BIT 
                       D. H9270-Q     18/22 BIT 
                       E. H9281-QA    18/22 BIT 
                       F. H9273-A     18 BIT 

           CASE 2.  Use an enclosure/backplane which  is  already  terminated.
           All  but  one of Digital's backplanes are terminated with 120 ohms,
           and will meet the minimum termination required  for  additional  ac
           loading  beyond the capabilities of an unterminated backplane.  The
           one backplane that is not terminated at 120 ohms is the  one  found
           inside  of  the BA23-A enclosure.  This option is terminated at 240
           ohms.  This enclosure is the only option that will provide  optimum
           termination  for 240 ohm CPUs.  The following table list all of the
           terminated  enclosures  and  backplanes  available   from   Digital
           Equipment Corporation:

                          OPTION      SYSTEM SIZE               TERMINATION
                          -------------------------------------------------
                       A. BA23-A      18/22 bit                   240 OHMS
                       B. H9275-A     22 BIT (not expandable)     120 OHMS
                       C. H9281-QB    18/22 BIT                   120 OHMS
                       D. H9281-QC    18/22 BIT                   120 OHMS


      6. MULTIPLE BOX SYSTEMS CONFIGURATION CASES
         ----------------------------------------

      Multiple box configurations can be up to three boxes  maximum.   However
      currently only 18-bit three box systems can be configured and terminated
      properly.  Therefore cases 3 and 4 described below will deal  only  with
      two  box  22-bit system configurations using CPUs of either impedance as

                                  331

uNOTE # 035
Page 6 of 8


      18-bit systems are sufficiently documented as noted below.

                                        NOTE

              FOR 18-BIT MULTIPLE BOX SYSTEMS USING A  CPU  CONTAINING
              EITHER  120  OR  240 OHMS OF IMPEDANCE THE PROCEDURE FOR
              EXPANDING FROM A ONE BOX SYSTEM TO A TWO BOX  SYSTEM  IS
              DOCUMENTED  IN  SEVERAL TECHNICAL RESOURCES, SUCH AS THE
              EXPANSION  PRODUCTS  HANDBOOK  (EB24836-75/68)  AND  THE
              BA11-N    TECHNICAL    MANUAL    (EK-BA11N-TM-001).    A
              PARTICULARLY GOOD RESOURCE FOR 18-BIT MULTIPLE BACKPLANE
              EXPANSION  AND  TERMINATION GUIDELINES IS THE LSI SYSTEM
              SERVICES MANUAL (EK-LSIFS-SV-005).

           CASE 3.  This case deals with a 120  ohm  CPU.   The  120  ohms  of
           impedance on the CPU does not have to matched in the first box, but
           does have to be matched at the far end of the  bus  which  will  be
           located  in  the second box.  This will generate four variations to
           the case dealing with 120 ohm CPUs.  All four of  these  variations
           will  have  in  common  the  BCV2A expansion assembly.  This option
           contains two paddle cards (M9404-00 at 0 ohms and the  M9405-YA  at
           120  ohms)  and  the  BC02D-03  interconnect  cable.   The card for
           expanding the bus out of the first box (M9404) will be installed in
           the  first  unused  slot  of  the  first  backplane, with the cable
           connected to it the bus will be carried to  the  second  backplane.
           Here  the  bus  is  terminated  by  installing the termination card
           (M9405) in the first slot of the second backplane.

               VARIATION 1:  Use  two  unterminated  enclosures  such  as  the
               BA11-SA  master  box  and  the BA11-SE expansion box, connected
               with the BCV2A.  This configuration is not  FCC  compliant  and
               places  the task of FCC compliance on the user.  FCC compliance
               can be obtained by rack mounting these  two  enclosures  in  an
               H9642  cabinet  and  using  the H349 distribution panel to make
               connections from the system to the outside  environment,  using
               the  appropriate  option cabinet kits.  This cabinet system has
               been  tested  by  Digital   Equipment   Corporation   for   FCC
               compliance.

                                            NOTE

                       THE  NEXT  TWO  VARIATIONS  CAN  BE  MADE   FCC
                       COMPLIANT  BY  RACK  MOUNTING  BOTH BOXES IN AN
                       H9642  CABINET  THAT  HAS  THE  H9544-AJ   SIDE
                       PANELS.   THESE  SIDE PANELS ALLOW FOR THE SIDE
                       TO SIDE AIR FLOW FOR THE BA23 ENCLOSURE.   ALSO
                       INCLUDED  IN  THIS CABINET CONFIGURATION IS THE
                       H3490 PATCH PANEL  WHICH  IS  USED  FOR  MAKING
                       CONNECTIONS  FROM  THE  SYSTEM  TO  THE OUTSIDE
                       ENVIRONMENT VIA THE APPROPRIATE  OPTION  MODULE
                       CABINET  KITS.   (REFER  TO  THE MICROCOMPONETS
                       CONFIGURATION GUIDE FOR DETAILS)

                                  332

                                                           uNOTE # 035
                                                           Page 7 of 8


               VARIATION 2:  Use the BA23 enclosure as the  primary  enclosure
               and the BA11-SE as the expansion chassis, again using the BCV2A
               as the interconnect for the two  enclosures.   The  termination
               that  exist  on  the BA23 backplane must be removed because the
               that the CPU has 120 ohms of impedance in  the  first  box  and
               does not require any additional termination at this point.

               VARIATION 3:  Use two BA23 enclosures.  When using  two  BA23-A
               enclosures   and   the  BCV2A  expansion  assembly  option  the
               termination from both backplanes must be removed.  This is  due
               to the fact that the 120 ohms of CPU impedance does not have to
               matched in the first backplane of a multiple  backplane  system
               and  that  the BCV2A will put the required termination into the
               last backplane of this configuration.  The interconnect for the
               two boxes will again be the BCV2A.

               VARIATION 4:  A final variation to the 120 ohm CPU system would
               be   to  follow  the  same  scenario  as  in  the  first  three
               variations, but using a mix of some terminated and unterminated
               backplanes  as  opposed to system enclosures.  These backplanes
               and their termination states are listed in cases one and two.

           CASE 4.  This case deals with the 240 ohm CPUs.  As stated  in  the
           termination  rules  for  240  ohms  CPUs,  the processors impedance
           should be matched in the first box.  This  would  bring  the  total
           impedance  in  the  first  box  to  120  ohms  which  is  the ideal
           impedance.  This 120 ohms from the first box, would be  matched  at
           the  far  end  of  the bus which will be located in the second box.
           Configurations with 240 ohm CPUs have three variations.  All of the
           case 4 variations will have in common the BCV2A expansion assembly.
           The installation of this option is explained above, in the  section
           introducing two box systems.

               VARIATION 1:  This case variation uses the  BA23  enclosure  as
               the  primary  box  and  expands  into  a  BA11-SE.   Using this
               configuration requires that the termination on the backplane of
               the  BA23  be  left  in.   This  will  provide  for  an optimum
               impedance match in the first box.  The bus will  be  terminated
               at  the  far  end  in the second box via the expansion assembly
               termination card (M9405-YA).  This configuration as is will not
               be  FCC  compliant  however  following the guide lines from the
               CASE 3 variations FCC compliance can be achieved.

               VARIATION 2:  The two enclosures used here  will  be  the  BA23
               system   box   and   the   BA23   expansion  box.   While  this
               configuration resembles case  4  with  variation  1,  the  only
               change  will  be the removal of any termination from the second
               (expansion) backplane.  Interconnect between the two boxes  and
               FCC compliance can be achieved as described.




                                  333

uNOTE # 035
Page 8 of 8


                                            NOTE

                       WHEN  CONFIGURING  MULTIPLE  BACKPLANE  SYSTEMS
                       USING  THE  BA23-A  BOX  WITH  THE  RQDX1 RD/RX
                       CONTROLLER INSTALLED, CONSIDERATION  SHOULD  BE
                       GIVEN  TO  THE  PLACEMENT OF THE CONTROLLER AND
                       ITS RELATIONSHIP  TO  THE  DEVICES  THEMSELVES.
                       FURTHER  WHEN  USING MULTIPLE BA23-A ENCLOSURES
                       IT BECOMES POSSIBLE TO HAVE THE BEVNT LINE FROM
                       BOTH  OF THE POWER SUPPLIES TO BE ACTIVE AT THE
                       SAME TIME.  THERE SHOULD  ALWAYS  BE  ONLY  ONE
                       BEVNT  LINE  ACTIVE  AT ANYTIME, THEREFORE CARE
                       MUST TAKEN TO AVOID THIS CONFLICT.


               VARIATION 3:  This final case 4 variation deals with the use of
               terminated  and unterminated backplanes rather than enclosures.
               Using a mix of these products the configurations would resemble
               the  first  two for case 4, and would follow the same rules for
               proper termination.

































                                  334

================================================================================
Note 36.0                       MicroVMS Revealed                     No replies
FURILO::GIORGETTI                                  1473 lines   4-SEP-1985 15:46
--------------------------------------------------------------------------------



      +---------------+                                    +-----------------+
      | d i g i t a l |                                    |  uNOTE # 036    |
      +---------------+                                    +-----------------+

                                                                   
      +----------------------------------------------------+-----------------+
      | Title:  MicroVMS Revealed                          | Date: 19-Jul-85 |
      +----------------------------------------------------+-----------------+
      | Originator:  Edward P. Luwish                      | Page 1 of 25    |
      +----------------------------------------------------+-----------------+



                                      ABSTRACT

              This MicroNote explains the  contents  of  the  MicroVMS
              distribution kit as well as listing the "Full" VMS files
              not  included  in  said  kit.   The  description  is  of
              MicroVMS  V4.1M  and  VAX/VMS V4.1, but will apply, with
              minor changes, to later revisions of VMS V4.



      DESCRIPTION OF THE COMPONENTS OF THE MICROVMS KIT


      The MicroVMS kit comes in  three  parts  -  a  standalone  BACKUP  piece
      (currently  three  diskettes),  the  BASE  system  (which is copied to a
      blank, formatted hard disk by the standalone BACKUP) and a collection of
      additional  pieces  which  are  added to the system (using VMSINSTAL) as
      though they were layered products.  These pieces are labeled UTIL, USER,
      PROG   and   SYSP.    Another  piece,  described  here  but  purchasable
      separately, is NET (DECnet).  Note that the tape  distribution  contains
      all  these  components (except DECnet) on a single volume - even so, the
      partitioning is the same.

      The installation procedure for MicroVMS  is  simple  -  first  boot  the
      standalone  BACKUP  volume,  use  it to copy the BASE system to the hard
      disk, then boot and log into the system thus built.  In many  cases,  no
      other files need be included on the hard disk.  If necessary, additional
      options can be added to the system using  VMSINSTAL  and  the  remaining
      pieces  of  the  distribution  kit.  The following sections describe the
      components, starting with the Base system.

      The files are divided into classes according to their  usefulness  in  a
      turnkey runtime environment.  Class I was established experimentally, as
      described in MicroNote # 37 - "In Search  of  NanoVMS".   The  remaining
      classes   represent   the  author's  opinion,  rather  than  defining  a
      hierarchy, and were based  on  the  author's  experiences  with  minimum
      runtime environments.  Your environment may be somewhat different.



                                  335

uNOTE # 036
Page 2 of 25


      FILES INCLUDED IN THE BASE SYSTEM KIT

      Class I files -
      The following BASE SYSTEM files are required if a system is to  boot  up
      at  all.   The assumption is that the boot disk is an RQDX or other MSCP
      device.

      sys$system:DCL.EXE        - Command language interpreter
                                  (Executes startup command file)
      sys$system:DUDRIVER.EXE   - Class (protocol) driver for MSCP devices
      sys$system:F11BXQP.EXE    - File structure and volume structure
                                  (Extended QIO Processor)
      sys$system:FPEMUL.EXE     - Emulate floating point instructions
      sys$system:INSTALL.EXE    - Utility that installs known images
      sys$system:JOBCTL.EXE     - Job controller/symbiont manager
                                  (Creates detached process for LOGINOUT)
      sys$system:LOGINOUT.EXE   - Login/logout utility
                                  (Needed for response to unsolicited
                                  input from non-logged-in terminals)
      sys$system:MTAAACP.EXE    - Magnetic tape ancillary control process
                                  (Required if system is booted from TK50)
      sys$system:PDDRIVER.EXE   - Pseudo-disk driver for bootstrap
                                  (Required if system is booted from TK50)
      sys$system:PUDRIVER.EXE   - Port (physical) driver for MSCP devices
      sys$system:RMS.EXE        - Record Management Services
      sys$system:RUNDET.EXE     - Runs detached images
                                  (Needed to run JOBCTL.EXE)
      sys$system:SCSLOA.EXE     - Loadable routines used by System
                                  Communication Services
                                  (needed by MSCP, etc.)
      sys$system:SET.EXE        - Processes many SET commands
                                  (Needed frequently by STARTUP.COM)
      sys$system:SETP0.EXE      - Processes SET MESSAGE command
                                  (Needed frequently by STARTUP.COM)
      sys$system:STARTUP.COM    - System-startup DCL command procedure
                                  (Creates a standard VMS environment)
      sys$system:SYS.EXE        - Operating System image file
      sys$system:SYSBOOT.EXE    - System bootstrap utility
                                  (Sets up system parameters prior to
                                  invocation of STARTUP.COM)
      sys$system:SYSGEN.EXE     - System customization utility
                                  (Loads drivers, sets system parameters)
      sys$system:SYSINIT.EXE    - Operating System Initialization image
      sys$system:SYSLOAUV1.EXE  - MicroVAX I-specific initialization
      sys$system:SYSLOAUV2.EXE  - MicroVAX II-specific initialization
                                  (Pick only one of the above two files)
      sys$system:TTDRIVER.EXE   - Terminal driver (including console)
      sys$system:TUDRIVER.EXE   - Class (protocol) driver for TMSCP tapes
                                  (Required if system is booted from TK50)
      sys$system:VAXEMUL.EXE    - Emulate VAX instructions not in uVAX arch.
      sys$system:VAXVMSSYS.PAR  - System parameter file
                                  (Used by SYSGEN.EXE and SYSBOOT.EXE)

                                  336

                                                           uNOTE # 036
                                                          Page 3 of 25


      Class I files - (continued)

      sys$system:VMOUNT.EXE     - Volume mount utility
                                  (Needed to mount system and user disks)
      sys$library:DCLTABLES.EXE - Command-parsing tables
                                  (Required by DCL.EXE)
      sys$library:LBRSHR.EXE    - Runtime shareable library for Librarian
                                  (Required by INSTALL.EXE)
      sys$library:LIBRTL.EXE    - Runtime shareable library of common
                                  system support routines
                                  (Required by Job Controller)
      sys$library:LIBRTL2.EXE   - Runtime shareable library of common
                                  system support routines (Part 2)
                                  (Required by Job Controller)
      sys$library:MOUNTSHR.EXE  - MOUNT shareable image
                                  (Required by VMOUNT)
      sys$library:SCRSHR.EXE    - V3.x screen management package
                                  (Required by SYSGEN.EXE)

      sys$manager:VMSIMAGES.DAT - Data file for installing known images

      sys$message:SYSMSG.EXE    - System error messages
                                  (required for boot up)
      sys$message:SYSMGTMSG.EXE - ACC, EDIT/ACL, BACKUP, INSTALL,
                                  MONITOR and AUTHORIZE error message file
                                  (required for boot up)



























                                  337

uNOTE # 036
Page 4 of 25


      Class IA files -
      These files are required for proper system  initialization  and  orderly
      shutdown, but will not prevent a system from booting if absent:

      sys$system:DISMOUNT.EXE   - Volume dismount utility
                                  (Required for orderly system shutdown
                                  or disk changing)
      sys$system:OPCCRASH.EXE   - System shutdown utility
                                  (Required for orderly system shutdown)
      sys$system:SHUTDOWN.COM   - System shutdown DCL command procedure
                                  (Required for orderly system shutdown)
      sys$system:UVSTARTUP.COM  - Processor-specific startup commands
                                  (Required for orderly system startup)

      sys$library:DISMNTSHR.EXE - DISMOUNT shareable image
      sys$library:MTHRTL.EXE    - Math support runtime shareable library
                                  (required by an image invoked by
                                  SHUTDOWN.COM)
      sys$library:UVMTHRTL.EXE  - MicroVAX version of MTHRTL

      sys$manager:SYSTARTUP.COM - Site-specific startup commands
                                  (Required for orderly system startup)
      sys$manager:SYCONFIG.COM  - Required for orderly system startup
      sys$manager:SYSHUTDWN.COM - Site-specific shutdown commands
                                  (Required for orderly system shutdown)




























                                  338

                                                           uNOTE # 036
                                                          Page 5 of 25


      Class IB Files -
      These files are required by optional hardware:

      sys$system:ANALYZBAD.EXE  - ANALYZE/MEDIA image
                                  (Required only for non-MSCP disk support)
      sys$system:BADBLOCK.EXE   - Dynamic bad block Files-11 ACP subprocess
                                  (Required only for non-MSCP disk support)
      sys$system:DLDRIVER.EXE   - RL02 Disk Driver
      sys$system:DZDRIVER.EXE   - DZV11 Serial Interface Driver
      sys$system:MTAAACP.EXE    - Magnetic tape ancillary control process
                                  (Required for tape support)
      sys$system:SMGMAPTRM.EXE  - TERMTABLE global section - runs at
                                  system startup.  (Required for video
                                  terminal support using VMS screen
                                  management package)
      sys$system:SYSLOAWS1.EXE  - Graphics display initialization
                                  (Required for VAXstation I support only)
      sys$system:SYSLOAWS2.EXE  - Graphics display initialization
                                  (Required for VAXstation II support only)
      sys$system:TERMTABLE.EXE  - Compiled terminal definitions file
                                  (Required for terminal support)
      sys$system:TUDRIVER.EXE   - Class (protocol) driver for TMSCP tapes
                                  (Required for TK50 support only)
      sys$system:YFDRIVER.EXE   - DHV11 Serial Interface Driver





























                                  339

uNOTE # 036
Page 6 of 25


      Class II files -
      These files MAY be required by user applications  or  layered  products,
      since  they  depend  on  which  high-level  language or operating system
      features are used:  [Note that C and ADA  are  absent  -  their  runtime
      licenses are separate from, and in addition to, that of VMS]

      sys$library:BASRTL.EXE    - Runtime shareable library - BASIC
      sys$library:BASRTL2.EXE   - Runtime shareable library - BASIC
      sys$library:CDDSHR.EXE    - Required by layered products using the
                                  Common Data Dictionary - such as
                                  Datatrieve
      sys$library:COBRTL.EXE    - Runtime shareable library - COBOL
      sys$library:ENCRYPSHR.EXE - Dummy encryption module
                                  (Required by layered products that can
                                  optionally use DES data encryption)
      sys$library:FORRTL.EXE    - Runtime shareable library - FORTRAN
      sys$library:PASRTL.EXE    - Runtime shareable library - PASCAL
      sys$library:PLIRTL.EXE    - Runtime shareable library - PL/I
      sys$library:RPGRTL.EXE    - Runtime shareable library - RPG II
      sys$library:SMGSHR.EXE    - VMS screen management package
      sys$library:VMSRTL.EXE    - Old-format VMS runtime library
                                  (Required by V3.x applications)

      sys$message:CLIUTLMSG.EXE - ANALYZE/MEDIA, EXCHANGE, MAIL, PHONE,
                                  PRINT, SUBMIT, RUN, SET, SHOW and
                                  SEARCH error messages.
      sys$message:FILMNTMSG.EXE - ANALYZE/OBJECT, ANALYZE/IMAGE,
                                  EDIT/FDL, ANALYZE/DISK error messages
      sys$message:PASMSG.EXE    - PASCAL language error messages
      sys$message:PLIMSG.EXE    - PL/I language error messages
      sys$message:RPGMSG.EXE    - RPG language error messages
      sys$message:SHRIMGMSG.EXE - CONVERT, DCX (library de/compression
                                  utility), FDL, SORT, SMGSHR and EDT
                                  error messages



















                                  340

                                                           uNOTE # 036
                                                          Page 7 of 25


      Class IIA files -
      These are user utilities that can be called by application programs even
      though  there  may  exist no way to invoke them from the terminal by DCL
      command:

      sys$library:CRFSHR.EXE    - Cross-Reference shareable image
                                  (Required by compilers & linker if
                                  cross-reference option is invoked)
      sys$library:DCXSHR.EXE    - Data de/compression support
      sys$library:EDTSHR.EXE    - Callable editor
                                  (Required by EDT.EXE)
      sys$library:FDLSHR.EXE    - File Description Language parsing
                                  shareable image
                                  (Required by CREATEFDL.EXE and EDF.EXE)
      sys$library:SORTSHR.EXE   - VAX Sort/Merge Runtime library
                                  (Required by SORTMERGE.EXE)


      Class III files -
      These are often used to diagnose or maintain systems in the field.  They
      can  be  used  to  adapt systems to changing user need on an interactive
      basis.  Some applications call these as part of their operation.

      sys$system:BACKUP.EXE     - Backup utility
      sys$system:CHECKSUM.EXE   - Used during installation of
                                  VAX/VMS updates
      sys$system:ERRFMT.EXE     - Error logging facility
      sys$system:LINK.EXE       - Linker
                                  (Development/upgrade utility)
      sys$system:MODPARAMS.DAT  - Site modifactions to sysgen
                                  parameters - Used by AUTOGEN.COM
      sys$system:PATCH.EXE      - Image patching utility
                                  (Required for system updates/bug fixes)
      sys$system:SUMSLP.EXE     - Batch-oriented source file editor
                                  (Required for system updates/bug fixes)

      sys$library:SECURESHR.EXE - Rights database (RIGHTSLIST.DAT)
                                  service routines.
                                  (Required by BACKUP.EXE)
      sys$library:SUMSHR.EXE    - Shareable image required by SUMSLP

      sys$update:AUTOGEN.COM    - System tuning utility
      sys$update:LIBDECOMP.COM  - Library decompression utility
      sys$update:REMOVE.COM     - Update utility
      sys$update:SWAPFILES.COM  - System Tuning utility
      sys$update:VMSINSTAL.COM  - Update utility

      Optional files for disk support:
      sys$system:INIT.EXE       - Volume initialization utility
      sys$system:UNLOCK.EXE     - For reopening improperly closed files
      sys$system:VERIFY.EXE     - For error-correction of disks


                                  341

uNOTE # 036
Page 8 of 25


      Class IV files -
      These set up and maintain a multi-user environment even  if  interactive
      DCL is not supported by the turnkey system:

      sys$system:AUTHORIZE.EXE  - User authorization utility
                                  (Required only for login password support)
      sys$system:CVTNAF.EXE     - Convert NETUAF.DAT utility
                                  (Required only for V3.5+ system upgrades)
      sys$system:CVTUAF.EXE     - Convert SYSUAF.DAT utility
                                  (Required only for V3.5+ system upgrades)
      sys$system:NOTICE.TXT     - Announcement file for logged-in users
      sys$system:OPCOM.EXE      - Operator communications facility
                                  (For systems with a human operator)
      sys$system:REPLY.EXE      - Message broadcasting utility
                                  (For systems with a human operator
                                  /multi-user/secure.  Required by OPCOM)
      sys$system:SETSHOACL.EXE  - SET and SHOW ACCESS CONTROL LIST commands
                                  (For secure systems)
      sys$system:SYSALF.DAT     - Automatically logged-in terminal data file
                                  (Required only if this feature is used)
      sys$system:SYSUAF.DAT     - User authorization data file
                                  (Required only for login password support)

      sys$library:SECURESHR.EXE - Rights database (RIGHTSLIST.DAT)
                                  service routines.
                                  (Required for multi-user systems)

      sys$manager:ADDUSER.COM   - For maintaining multi-user systems
      sys$manager:ALFMAINT.COM  - For managing automatically
                                  logged-in terminals
      sys$manager:EDTINI.EDT    - Editor initialization script for
                                  system manager's account
      sys$manager:LOGIN.COM     - Command file executed when system
                                  manager logs into account
      sys$manager:SUCCESS.TXT   - Not required
      sys$manager:SYLOGIN.COM   - Command file executed when any user
                                  logs in (prior to user's own LOGIN.COM)
                                  (Required for multi-user systems)
      sys$manager:WELCOME.TXT   - Not required

      sys$update:BACKUSER.COM   - Back up user directories before
                                  performing system update
                                  Update utility (multi-user systems)
      sys$update:CVTNAF.COM     - Convert NETUAF.DAT utility
                                  (Required only for V3.5+ system upgrades)
      sys$update:CVTUAF.COM     - Convert SYSUAF.DAT utility
                                  (Required only for V3.5+ system upgrades)
      sys$update:RESTUSER.COM   - Restore user directories after
                                  performing system update
                                  Update utility (multi-user systems)



                                  342

                                                           uNOTE # 036
                                                          Page 9 of 25


      Class V files -
      These are user utilities that exist for the convenience  of  interactive
      users.  Some of these are of interest primarily to programmers.  None of
      the Class V files normally become part of a turnkey application.

      sys$system:CDU.EXE        - For defining new DCL commands
                                  (User-oriented utility)
      sys$system:CONVERT.EXE    - Converts RMS files to
                                  new formats and organizations
                                  (User-oriented utility)
      sys$system:COPY.EXE       - User-oriented file copying utility
      sys$system:CREATE.EXE     - User-oriented file and directory
                                  creation utility
      sys$system:CREATEFDL.EXE  - CREATE/FDL image
      sys$system:DELETE.EXE     - User-oriented file deletion/purge utility
      sys$system:DIRECTORY.EXE  - User-oriented directory utility
      sys$system:EDT.EXE        - Interactive text editor
      sys$system:LIBRARIAN.EXE  - Librarian (Development utility)
      sys$system:RECLAIM.EXE    - Used to recover free space in
                                  ISAM RMS files
                                  (User-oriented utility)
      sys$system:RENAME.EXE     - User-oriented file renaming utility
      sys$system:SHOW.EXE       - SHOW command processor
      sys$system:SORTMERGE.EXE  - SORT and MERGE command processor
      sys$system:TYPE.EXE       - Utility for typing text files on terminal
                                  (User-oriented utility)
      sys$system:VMSHELP.EXE    - Interactive help utility

      sys$library:CONVSHR.EXE   - Shareable image required by CONVERT.EXE
                                  and RECLAIM.EXE
      sys$library:DBGSSISHR.EXE - DEBUG system service intercept handler
                                  (Development utility)
      sys$library:TRACE.EXE     - Error traceback facility
                                  (Development utility)

      sys$help:EDTHELP.HLB      - Help library for EDT
      sys$help:HELPLIB.HLB      - Main help library (small version)
      sys$help:UAFHELP.HLB      - Help library for AUTHORIZE

      sys$message:DBGTBKMSG.EXE - DEBUG, TRACE messages
                                  (Development utility)
      sys$message:PRGDEVMSG.EXE - CDU, DIFF, DUMP, Librarian, Linker,
                                  MACRO, MESSAGE, PATCH, ANALYZE/SYSTEM,
                                  and ANALYZE/CRASH messages
                                  (Development utility)

      sys$update:SPKITBLD.COM   - Utility for building software kits
                                  (Development utility)
      sys$update:VMSKITBLD.DAT  - Data for VMSKITBLD.COM - for building
                                  MicroVMS binary distribution kits
                                  (Development utility)


                                  343

uNOTE # 036
Page 10 of 25


      Class VI files -

      These are files required by options which are not included in  the  BASE
      System:

      sys$message:NETWRKMSG.EXE - DECnet error messages







      FILES INCLUDED IN THE OPTIONAL KITS

      The optional kits include UTIL, USER,  PROG,  SYSP  and  (at  additional
      cost)  NET.   The files of these kits are described in the next sections
      of the MicroNote.  First, a word of explanation about the format:  These
      kits  are  in  VMSINSTAL format - this means they consist of a number of
      BACKUP savesets.  Thus  the  UTIL  option  consists  of  the  UTILxxx.A,
      UTILxxx.B,  etc.   savesets,  where "xxx" is a number giving the version
      and revision level.  Each saveset is listed separately, and  denoted  as
      "UTIL_A",  "UTIL_B",  etc.   The  savesets  are  described  individually
      because they can be added to your system  (or  not)  depending  on  your
      replies  to  the  interactive VMSINSTAL.COM procedure.  The "_A" saveset
      contains the installation data tables and any  default  files  (if  any)
      needed  by  ALL the other savesets, so it will often appear empty in the
      tables below.



                               NETWORK DEVICE DRIVERS

              In order to  permit  the  use  of  DECnet  communication
              devices   as  synchronous  serial  lines,  the  hardware
              drivers are included in the  UTIL  option,  and  do  not
              require  a  DECnet  license.   These same files are also
              included in the DECnet kit so  as  to  simplify  network
              installation.














                                  344

                                                           uNOTE # 036
                                                         Page 11 of 25


      This section lists the files of the UTIL option:

      UTIL_A -- KITINSTAL.COM

      UTIL_B -- MAIL utility

          sys$system:MAIL.COM       -- Command procedure used by DECnet mail
          sys$system:MAIL.EXE       -- Mail Utility
          sys$system:MAILEDIT.COM   -- Default MAIL editing command procedure
          sys$help:MAILHELP.HLB     -- Mail Utility help file

      UTIL_C -- SEARCH utility

          sys$system:SEARCH.EXE     -- File search utility

      UTIL_D -- DIFF utility

          sys$system:DIFF.EXE       -- File compare utility

      UTIL_E -- DUMP utility

          sys$system:DUMP.EXE       -- File dump utility

      UTIL_F -- RUNOFF utility

          sys$system:DSRTOC.EXE     -- RUNOFF/CONTENTS image
          sys$system:DSRINDEX.EXE   -- RUNOFF/INDEX image
          sys$system:RUNOFF.EXE     -- Text formatting utility

      UTIL_G -- PHONE utility

          sys$system:PHONE.COM      -- PHONE startup procedure
          sys$system:PHONE.EXE      -- Phone utility
          sys$help:PHONEHELP.HLB    -- Phone utility help file

      UTIL_H -- MicroVMS HELP library

          sys$help:HELPLIB.HLB      -- Full default (DCL) help file

      UTIL_I -- Remote terminal support via SET HOST/DTE

          sys$system:RTPAD.EXE      -- Remote terminal command interface
          sys$library:DTE_DF03.EXE  -- SET HOST/DTE support for
                                       DF03 dialer

      UTIL_J -- Drivers for network communication devices

          sys$system:NODRIVER.EXE   -- Asynchronous DECnet driver
          sys$system:XDDRIVER.EXE   -- DECnet DMV11 datalink driver
          sys$system:XQDRIVER.EXE   -- DEQNA Ethernet interface driver



                                  345

uNOTE # 036
Page 12 of 25


      (UTIL option, continued)

      UTIL_K -- LAT-11 terminal server support (via Ethernet)

          sys$system:LATCP.EXE      -- LAT-11 Control Program
          sys$system:LTDRIVER.EXE   -- LAT-11 Driver
          sys$system:XQDRIVER.EXE   -- DEQNA Ethernet interface driver
          sys$help:LATCP.HLB        -- LAT-11 Control Program help file
          sys$manager:LTLOAD.COM    -- Command procedure to load and start LAT

      UTIL_L -- Stand-alone backup on system disk support

          sys$system:STABACCOP.EXE  -- Copy program for building
                                       standalone BACKUP kit
          sys$system:STABACKUP.EXE  -- Standalone BACKUP utility
          sys$system:STANDCONF.EXE  -- Standalone BACKUP configure image
          sys$system:STASYSGEN.EXE  -- Standalone SYSGEN utility
          sys$update:STABACKIT.COM  -- Command procedure that builds
                                       standalone BACKUP to media

      UTIL_M -- MicroVAX-I bootstrap that works for any MSCP system device

          sys$system:VMBUVAX1P.EXE  -- Image which boots disks inaccessible
                                       from boot ROM or console command
          sys$update:VMBUVAX1.COM   -- Command procedure to build RX50
                                       console floppy to boot other disks

      UTIL_N -- Error Log Report Generator utility

          sys$system:ERF.EXE        -- ANALYZE/ERROR image
          sys$system:ERFBRIEF.EXE   -- ANALYZE/ERROR brief report generator
          sys$system:ERFBUS.EXE     -- ANALYZE/ERROR bus display generator
          sys$system:ERFDISK.EXE    -- ANALYZE/ERROR disk display generator
          sys$system:ERFINICOM.EXE  -- ANALYZE/ERROR initialize routines
          sys$system:ERFPROC1.EXE   -- ANALYZE/ERROR processing routines
          sys$system:ERFPROC2.EXE   -- ANALYZE/ERROR processing routines
          sys$system:ERFPROC3.EXE   -- ANALYZE/ERROR processing routines
          sys$system:ERFPROC5.EXE   -- ANALYZE/ERROR processing routines
          sys$system:ERFSUMM.EXE    -- ANALYZE/ERROR summary display routines
          sys$system:ERFUVAX.EXE    -- ANALYZE/ERROR uVAX-specific routines
          sys$library:ERFCOMMON.EXE -- ANALYZE/ERROR common data structures
          sys$library:ERFCTLSHR.EXE -- ANALYZE/ERROR shareable image
          sys$library:ERFLIB.TLB    -- ANALYZE/ERROR device descriptions
          sys$library:ERFSHR.EXE    -- ANALYZE/ERROR common routines









                                  346

                                                           uNOTE # 036
                                                         Page 13 of 25


      This section lists the files of the USER option:

      USER_A -- Default files

      USER_B -- File Access Control List utilities

          sys$system:ACLEDT.EXE     -- Access Control List (ACL) Editor
          sys$library:ACLEDIT.INI   -- ACL Editor initialization file
          sys$help:ACLEDT.HLB       -- ACL Editor help file

      USER_C -- Disk Quota utility

          sys$system:DISKQUOTA.EXE  -- Disk Quota Utility
          sys$help:DISKQUOTA.HLB    -- Disk Quota Utility help file

      USER_D -- Print and Batch Queue utilities

          sys$system:LPDRIVER.EXE   -- Line printer driver
          sys$system:PRTSMB.EXE     -- Print symbiont
          sys$system:QUEMAN.EXE     -- Queue managing utility
          sys$system:REQUEST.EXE    -- Operator request facility
          sys$system:SUBMIT.EXE     -- Batch job submission utility
          sys$library:SMBSRVSHR.EXE -- Print symbiont service routines

      USER_E -- Input Queue Symbiont

          sys$system:INPSMB.EXE     -- Card reader input symbiont

      USER_F -- Accounting Log Report Generator utility

          sys$system:ACC.EXE        -- Accounting Utility






















                                  347

uNOTE # 036
Page 14 of 25


      This section lists the files of the PROG option:

      PROG_A -- KITINSTAL.COM

      PROG_B -- Debugger utility

          sys$library:DEBUG.EXE     -- Symbolic debugger
          sys$help:DEBUGHLP.HLB     -- Debugger help file

      PROG_C -- Image Dump utility

          sys$system:ANALIMDMP.EXE  -- ANALYZE/PROCESS_DUMP image
          sys$library:IMGDMP.EXE    -- Image dump procedures

      PROG_D -- RMS Analyze and FDL Editor utilities

          sys$system:ANALYZRMS.EXE  -- ANALYZE/RMS_FILE image
          sys$system:EDF.EXE        -- File Definition Language editor
          sys$help:ANLRMSHLP.HLB    -- ANALYZE/RMS_FILE help file
          sys$help:EDFHLP.HLB       -- FDL Editor help file

      PROG_E -- Message utility

          sys$system:MESSAGE.EXE    -- Message compiler





























                                  348

                                                           uNOTE # 036
                                                         Page 15 of 25


      (PROG option, continued)

      PROG_F -- Object and Shareable Image libraries

          sys$library:IMAGELIB.OLB  -- System default shareable image library
          sys$library:STARLET.OLB   -- System object and runtime library

      PROG_G -- Macro libraries

          sys$library:LIB.MLB       -- Operating system macro library
          sys$library:STARLET.MLB   -- System macro library

      PROG_H -- Macro assembler

          sys$system:MACRO32.EXE    -- VAX MACRO assembler

      PROG_I -- SDL intermediary form of STARLET.MLB

          sys$system:SDLNPARSE.EXE  -- SDL compiler (for installing
                                       optional software)
          sys$library:STARLETSD.TLB -- Text library of STARLET definitions
                                       Used during layered product installations

      PROG_J -- FORTRAN require files

          sys$library:FORDEF.FOR    -- FORTRAN INCLUDE file: FOR$ sysmbols
          sys$library:FORIOSDEF.FOR -- FORTRAN INCLUDE file: IOSTAT error codes
          sys$library:LIBDEF.FOR    -- FORTRAN program utility INCLUDE files
          sys$library:MTHDEF.FOR    -- FORTRAN INCLUDE file: MATH$ symbols
          sys$library:SIGDEF.FOR    -- FORTRAN program utility INCLUDE files
          sys$library:XFDEF.FOR     -- Definitions available for programs
                                       using DR780 support routines





















                                  349

uNOTE # 036
Page 16 of 25


      This section lists the files of the SYSP option:

      SYSP_A -- Default files

          sys$help:INSTALHLP.HLB    -- Install Utility help file
          sys$help:PATCHHELP.HLB    -- Patch Utility help file
          sys$help:SYSGEN.HLB       -- Sysgen Utility help file

      SYSP_B -- Files-11 ODS1 ACP and EXCHANGE utility

          sys$system:EXCHANGE.EXE   -- RT-11/DOS file transfer utility
          sys$system:F11AACP.EXE    -- Files-11 Structure Level 1 ACP
          sys$help:EXCHNGHLP.HLB    -- Exchange Utility help file

      SYSP_C -- Monitor utility

          sys$system:MONITOR.EXE    -- Monitor utility
          sys$help:MNRHELP.HLB      -- Monitor Utility help file

      SYSP_D -- Analyze Object File utility

          sys$system:ANALYZOBJ.EXE  -- ANALYZE/IMAGE and ANALYZE/OBJECT image

      SYSP_E -- Delta debugger (for drivers and other privileged code)

          sys$library:DELTA.EXE     -- DELTA multimode debugging tool image
          sys$library:DELTA.OBJ     -- Alternate debugging tool

      SYSP_F -- System Dump Analyzer utility

          sys$system:SDA.EXE        -- System Dump Analyzer
          sys$help:SDA.HLB          -- System Dump Analyzer help file

      SYSP_G -- System Symbol Table file

          sys$system:SYS.STB        -- Global symbol table of operating system

      SYSP_H -- Misc Symbol Table files

          sys$system:SYSDEF.STB     -- Global definitions for
                                       executive structures

      SYSP_I -- System map

          sys$system:SYS.MAP        -- Map of the operating system

      SYSP_J -- Connect-to-Interrupt Driver

          sys$system:CONINTERR.EXE  -- Connect-to-Interrupt Driver




                                  350

                                                           uNOTE # 036
                                                         Page 17 of 25


      This section consists of the files  included  in  the  DECnet  Kit.   In
      addition  to  these,  a  license  disk  is  included,  which unlocks the
      end-node or the full routing node functionality in these files:

      NET_A -- Default files

          sys$system:EVL.COM        -- Command file used by DECnet
                                       error logging
          sys$system:EVL.EXE        -- DECnet event logging program
          sys$system:NCP.EXE        -- Network control program
          sys$system:NDDRIVER.EXE   -- DECnet pseudo-datalink driver
          sys$system:NETACP.EXE     -- DECnet ancillary control process
          sys$system:NETDRIVER.EXE  -- DECnet logical link driver
          sys$system:NETSERVER.COM  -- Network server DECnet command procedure
          sys$system:NETSERVER.EXE  -- Network server image
          sys$system:NICONFIG.COM   -- Ethernet configurator DECnet
                                       command procedure
          sys$system:NICONFIG.EXE   -- Ethernet configurator image
          sys$system:NML.COM        -- NML server startup procedure
          sys$system:NML.EXE        -- DECnet network manager listener
          sys$system:NODRIVER.EXE   -- Asynchronous DECnet driver
          sys$system:XDDRIVER.EXE   -- DECnet DMV11 datalink driver
          sys$system:XQDRIVER.EXE   -- DEQNA Ethernet interface driver
          sys$library:NMLSHR.EXE    -- DECnet management listener
                                       shareable image
          sys$help:NCPHELP.HLB      -- Network Command Program help file
          sys$manager:LOADNET.COM   -- DCL procedure to create
                                       network ACP process
          sys$manager:NETCONFIG.COM -- DCL procedure to configure
                                       network database
          sys$manager:STARTNET.COM  -- DECnet startup procedure

      NET_B -- Incoming Remote File Access files

          sys$system:FAL.COM        -- FAL startup procedure
          sys$system:FAL.EXE        -- DECnet File Access Listener

      NET_C -- Incoming Remote Terminal files

          sys$system:CTDRIVER.EXE   -- CTERM Driver
          sys$system:REMACP.EXE     -- Remote device ACP
          sys$system:RTTDRIVER.EXE  -- Remote terminal driver
          sys$system:STOPREM.EXE    -- Stop REMACP utility
          sys$manager:RTTLOAD.COM   -- Remote terminal loader









                                  351

uNOTE # 036
Page 18 of 25


      (NET option, continued)

      NET_D -- Outgoing Remote Terminal files

          sys$system:RTPAD.EXE      -- Remote terminal command interface
          sys$library:DTE_DF03.EXE  -- SET HOST/DTE support for DF03 dialer

      NET_E -- Network Test files

          sys$system:DTR.COM        -- DTRECV.EXE server initiating procedure
          sys$system:DTRECV.EXE     -- DTSEND server
          sys$system:DTSEND.EXE     -- DECnet logical links test program
          sys$system:MIRROR.COM     -- MIRROR startup procedure
          sys$system:MIRROR.EXE     -- DECnet node loopback server
          sys$system:MOM.COM        -- Maintenance operations module
                                       DECnet command procedure
          sys$system:MOM.EXE        -- Maintenance operations module image

      NET_F -- Remote Task Loading

          sys$system:HLD.COM        -- Command procedure used by HLD.EXE
          sys$system:HLD.EXE        -- Downline task loading program































                                  352

                                                           uNOTE # 036
                                                         Page 19 of 25


      FILES WHICH ARE INCLUDED IN VMS DISTRIBUTIONS BUT NOT IN MicroVMS:

      Files which are specific to larger CPUs:

        Console-device files for 730, 750, 780:

        VMB.EXE         BOOT58.EXE      BOOTBLOCK.EXE   CONSCOPY.COM
        BOOTBLDR.COM    BOOTUPD.COM     RTB.EXE         WRITEBOOT.EXE
        DXCOPY.COM      SETDEFBOO.COM   780CNSL.DAT     750CNSL.DAT
        730CNSL.DAT     CONSOLBLD.COM

        Part of system startup:

        SYSLOA730.EXE --  CPU-specific initialization (11/730)
        SYSLOA750.EXE --  CPU-specific initialization (11/750)
        SYSLOA780.EXE --  CPU-specific initialization (11/780,782,785)
        SYSLOA790.EXE --  CPU-specific initialization (VAX 8600)
        CONFIGURE.EXE --  Dynamic device configure process

        System-bus attachments:

        CVDRIVER.EXE  --  8600 Console Disk Controller (RL02)
        DQDRIVER.EXE  --  RB730 11/730 Integrated Disk Controller (R80/RL02)
        PADRIVER.EXE  --  CI780 Port Driver
        STACONFIG.EXE --  HSC System Disk Configurator
        XFDRIVER.EXE  --  DR750, DR780 Ultra-high-speed Parallel Interface
        XFLOADER.EXE  --  DR750, DR780 Microcode loader

      Omitted from MicroVMS for reasons of size or performance:

        DES Encryption:

        ENCRYPFAC.EXE --  ENCRYPT command image

        Related to new Screen Management handler for terminals:

        SMGBLDTRM.EXE --  Compiler for TERMTABLE definition file
        SMGTERMS.TXT  --  ASCII source file for DEC terminal definitions
        TERMTABLE.TXT --  Terminal definitions source file

        Related to SORT/MERGE:

        SRTTRN.EXE    --  SORT specification file translator image










                                  353

uNOTE # 036
Page 20 of 25


      VAXCluster support:

      FILESERV.EXE  --  File system cache flush server
      CLUSTRLOA.EXE --  Loadable VAXcluster support code
      CSP.EXE       --  Cluster server process image
      MSCP.EXE      --  MSCP server
      CNDRIVER.EXE  --  CI DECnet Protocol Driver
      MAKEROOT.COM  --  Add new roots to cluster common system disk
      CLUSTRLOA.MAP --  Link map of loadable VAXcluster support code
      SHWCLSTR.EXE  --  SHOW CLUSTER command
      SHWCLHELP.HLB --  SHOW CLUSTER help file

      11/782 Shared Memory support:

      MP.EXE        --  VAX 11-782 multiprocessing code
      MP.MAP        --  Link map of multiprocessing code
      MPSHWPFM.EXE  --  Multiprocessing utility
      MPCLRPFM.EXE  --  Multiprocessing utility
      MBXDRIVER.EXE --  Shared memory mailbox driver

      PDP-11 Compatibility-mode images:

      TECO.EXE      --  TECO text editor and programming language
      TECO.HLB      --  TECO help file

      MASSBUS drivers:

      DBDRIVER.EXE  --  RP05, RP06 Disks
      DRDRIVER.EXE  --  RM03, RM05, RM80, RP07 Disks

      LPA11-K Laboratory Peripheral Accelerator support:

      LADRIVER.EXE  --  LPA11 Laboratory Peripheral Accelerator driver
      LALOAD.EXE    --  Sends requests to LALOADER.EXE
      LALOADER.EXE  --  Loads LPA11 microcode
      LPA11STRT.COM --  LPA11 site-specific startup command file

















                                  354

                                                           uNOTE # 036
                                                         Page 21 of 25


      UNIBUS drivers:

      CRDRIVER.EXE  --  CR11 Card Reader
      DDDRIVER.EXE  --  TU58 Cartridge Tape
      DMDRIVER.EXE  --  RK611 (RK06, RK07) Disks
      DXDRIVER.EXE  --  RX01 Floppy Diskette
      DYDRIVER.EXE  --  RX02 Floppy Diskette
      DZDRIVER.EXE  --  DZ11 Asynchronous Serial Multiplexer
                        (NOT the same as MicroVMS DZDRIVER.EXE)
      LCDRIVER.EXE  --  DMF32 Line Printer Port
      TFDRIVER.EXE  --  TU78 Magnetic Tape
      TMDRIVER.EXE  --  TE16, TU45, TU77 Magnetic Tape
      TSDRIVER.EXE  --  TS11, TS05, TU80 Magnetic Tape
                        (TSV05 will be supported)
      TUDRIVER.EXE  --  TA81, TU81 Magnetic Tape
                        (NOT the same as MicroVMS TUDRIVER.EXE)
      XADRIVER.EXE  --  DR11-W High-speed Parallel Interface
      XEDRIVER.EXE  --  DEUNA Ethernet Interface
      XGDRIVER.EXE  --  DMF32 Synchronous Port
      XMDRIVER.EXE  --  DMC11 Synchronous Communications Adapter
      XWDRIVER.EXE  --  DUP11 Synchronous Serial Line Interface
      YCDRIVER.EXE  --  DMF32, DMZ32, CPI32 Asynchronous Serial Multiplexers































                                  355

uNOTE # 036
Page 22 of 25


      Files from sys$examples:

      ADDRIVER.MAR  --  Example device driver for AD11-K
      CONNECT.COM   --  Command procedure that connects device for
                        LABIO system
      DOD_ERAPAT.MAR -  Example loadable erase pattern generator
      DRCOPY.PRM    --  Parameter file for DRCOPY routines
      DRCOPYBLD.COM --  Command procedure to build DRCOPY.EXE
      DRMAST.MAR    --  VAX RMS interface for DRMASTER.FOR
      DRMASTER.FOR  --  Master subroutines for DRCOPY
      DRSLAVE.FOR   --  Slave subroutines for DRCOPY
      DRSLV.MAR     --  VAX RMS interface for DRSLAVE.FOR
      DTE_DF03.MAR  --  SET HOST/DTE dialer support
      GBLSECUFO.MAR --  Opens file used as global section for LABIO system
      LABCHNDEF.FOR --  Defines information associated with each A/D
                        for LABIO system
      LABIO.OPT     --  Linker options file for linking modules
                        to be used in LABIO
      LABIOACQ.FOR  --  Acquires data for LABIO system
      LABIOCIN.MAR  --  Contains connect-to-interrupt call for LABIO system
      LABIOCIN.OPT  --  Linker options file for linking LABIO_DATA_ACQ
      LABIOCOM.FOR  --  Attaches a LABIO user program to the LABIO
                        system modules of the LABIO system
      LABIOCOMP.COM --  Command procedure to compile and assemble
                        the modules of the LABIO system
      LABIOCON.FOR  --  Handles user requests and modifies the
                        database for LABIO system
      LABIOLINK.COM --  Command procedure to link LABIO system
      LABIOPEAK.FOR --  Samples channel for peak data in LABIO system
      LABIOSAMP.FOR --  Samples channel in intervals, reporting date, time
                        and average value on logical device for LABIO system
      LABIOSEC.FOR  --  Places LABIO_SECTION on page boundary
      LABIOSTAT.FOR --  Displays A/D channel status for LABIO system
      LABIOSTRT.COM --  Command procedure to start LABIO system
      LABMBXDEF.FOR --  Defines mailbox block for LABIO system
      LBRDEMO.COM   --  Command procedure to create Librarian DEMO.EXE
      LBRDEMO.FOR   --  Librarian demo (first part)
      LBRMAC.MAR    --  Librarian demo (second part)
      LPATEST.FOR   --  LPA11-K test program
      LPMULT.B32    --  Example program for line printer
      MAILCOMPRESS.COM  Sample procedure to compress mail files
      MAILCVT.COM   --  Sample procedure to convert V3.x mail files
      MAILUAF.COM   --  Sample procedure to manipulate sys$system:VMSMAIL.DAT










                                  356

                                                           uNOTE # 036
                                                         Page 23 of 25


      Files from sys$examples, continued:

      MSCPMOUNT.COM --  Example cluster disk mount procedure
      PEAK.FOR      --  Peak selection routine in LABIO system
      SCRFT.MAR     --  Optional screen package (SCR$... in RTL) extension
                        to handle foreign terminals
      SYSGTTSTR.MSG --  Sample SYSGEN TERMINAL/ECHO message file
      TDRIVER.MAR   --  Template for user-written driver
      TESTLABIO.FOR --  Tests LABIO system
      USSDISP.MAR   --  Sample user system service dispatch and
                        service examples
      USSLNK.COM    --  Link command procedure for USSDISP
      USSTEST.MAR   --  Sample program to invoke one of the example
                        user services implemented in USSDISP
      USSTSTLNK.COM --  Link command procedure for USSTEST
      XADRIVER.MAR  --  DR11-W driver
      XALINK.MAR    --  Sample DR11-W to DR11-W link program
      XAMESSAGE.MAR --  DR11-W test program
      XATEST.COM    --  Used to set up XALINK.MAR
      XATEST.FOR    --  Companion program for XAMESSAGE
      XIDRIVER.MAR  --  Example driver for parallel port on DMF32

      11/730 Dual RL02 Tailoring Files:

      VMSTAILOR.COM     BLISSREQ.TLR    DECNET.TLR      DEVELOP.TLR
      EXAMPLES.TLR      FILETOOLS.TLR   HELP.TLR        LIBRARY.TLR
      MANAGER.TLR       MISCTOOLS.TLR   QUEUES.TLR      REQUIRED.TLR
      TEXTTOOLS.TLR     UETP.TLR        VMSTLRHLP.HLB

























                                  357

uNOTE # 036
Page 24 of 25


      User Environment Test Package files:

      TCNTRL.CLD    --  Defines UETP DCL commands
      UETP.COM      --  Main command procedure
      UETCLIG00.COM --  For cluster-integration phase
      UETCLIG00.DAT --  For cluster-integration phase
      UETCLIG00.EXE --  For cluster-integration phase
      UETCOMS00.EXE --  DMC and DMR device test
      UETDISK00.EXE --  Disk device test
      UETDMPF00.EXE --  DMP and DMF32 device test
      UETDNET00.COM --  For DECnet phase
      UETDNET00.DAT --  For DECnet phase
      UETDR1W00.EXE --  DR11-W device test
      UETDR7800.EXE --  DR780 and DR750 device test
      UETFORT01.DAT --  Used by load test
      UETFORT01.EXE --  Used by load test
      UETFORT02.EXE --  Used by load test
      UETFORT03.EXE --  Used by load test
      UETINIT00.EXE --  Initializes UETP environment
      UETINIT01.EXE --  Initializes UETP environment
      UETLOAD00.DAT --  Used by load test
      UETLOAD02.COM --  User script for load test
      UETLOAD03.COM --  User script for load test
      UETLOAD04.COM --  User script for load test
      UETLOAD05.COM --  User script for load test
      UETLOAD06.COM --  User script for load test
      UETLOAD07.COM --  User script for load test
      UETLOAD08.COM --  User script for load test
      UETLOAD09.COM --  User script for load test
      UETLOAD10.COM --  User script for load test
      UETLOAD11.COM --  User script for load test
      UETLPAK00.EXE --  LPA11-K device test
      UETMA7800.EXE --  MA780 device test
      UETMEMY01.EXE --  Artificial load for load test
      UETNETS00.EXE --  Used by DECnet phase
      UETPHAS00.EXE --  Test controller
      UETRSXFOR.EXE --  Artificial load for load test
      UETSUPDEV.DAT --  Supported device data file
      UETTAPE00.EXE --  Magnetic tape device test
      UETTTYS00.EXE --  Terminal and line printer device test
      UETUNAS00.EXE --  DEUNA device test












                                  358

                                                           uNOTE # 036
                                                         Page 25 of 25


      Unsupported files for linking against system images:

      RMS.STB       --  RMS symbol table
      CLUSTRLOA.STB --  Symbol table for loadable VAXcluster routines
      MP.STB        --  Symbol table for MP.EXE
      SCSDEF.STB    --  Symbol table for loadable SCS routines
      RMSDEF.STB    --  Global definitions for VAX RMS structures
      IMGDEF.STB    --  Global definitions for image activator structures
      DCLDEF.STB    --  Global definitions for DCL structures
      NETDEF.STB    --  Symbol table for network definition

      BLISS Require Files:

      LIB.REQ       --  Structure definitions of executive internals
                        for use by BLISS programs
      STARLET.REQ   --  User interface structures for use by BLISS programs
      TPAMAC.REQ    --  Structure definitions for BLISS programs using TPARSE

      Superceded or obsolete:

      VMSUPDATE.COM --  For updating VMS or adding layered products







      SUMMARY

      This MicroNote details the contents of the MicroVMS system, as  well  as
      the  portion  of VAX/VMS not supplied with MicroVMS.  The reader can use
      this information to determine  whether  any  unnecessary  files  can  be
      omitted  from  a turnkey system.  Additional information can be found in
      MicroNote # 37 ("In  Search  of  NanoVMS")  which  describes  a  working
      minimal  VMS subset.  Further information about the structure of VMS can
      be found in the full VMS document set (Order # QL001-GZ-V4.0 and  update
      QL001-WZ-V4.1),  "VAX/VMS Internals and Data Structures" (Digital Press,
      1984) and the VAX/VMS source  listings  on  microfiche  (source  license
      required -- see sales representative).

                                        NOTE

              DIGITAL does not recommend the deletion of any component
              files  of  the  MicroVMS  or  VAX/VMS  operating systems
              except  where  explicitly  stated  in   the   respective
              document  sets  (of which this is NOT a part).  A subset
              operating system cannot be  warranted  or  supported  by
              DIGITAL  in  any  way.  This MicroNote is to be used for
              informational  purposes   only,   and   represents   the
              research,  conclusions  and  opinions of the author, not
              those of DIGITAL or OEM Technical Support.

                                  359

================================================================================
Note 37.0                    In Search of "NanoVMS"                   No replies
FURILO::GIORGETTI                                   469 lines   4-SEP-1985 15:51
--------------------------------------------------------------------------------


      +---------------+                                    +-----------------+
      | d i g i t a l |                                    |  uNOTE # 037    |
      +---------------+                                    +-----------------+

                                                                   
      +----------------------------------------------------+-----------------+
      | Title:  In Search of "NanoVMS                      | Date: 19-Jul-85 |
      +----------------------------------------------------+-----------------+
      | Originator:  Edward P. Luwish                      | Page 1 of 8     |
      +----------------------------------------------------+-----------------+



                                      ABSTRACT

              This MicroNote describes the results of ongoing research
              into the size and composition of a minimal VMS system.



                               A WORD ABOUT NOTATION

              Where command lines, prompts and messages are discussed,
              text  printed  by  the  computer  is indicated by normal
              type,  text  entered  by  the  user  is   indicated   by
              [1mboldface[22m type.
              Unless explicitly stated otherwise, all user entries are
              to be terminated by the "return" character.


                                   WHY "NanoVMS"

      MicroVMS as  currently  packaged  and  supported  by  Digital  Equipment
      Corporation is not always an ideal solution for customers who would like
      to use it as a  realtime  application  bed  (rather  than  a  multi-user
      timesharing system).  For this reason, research has been done for over a
      year on minimal VMS systems.   Also,  the  number  of  floppy  diskettes
      required  to bring up the system has been found excessive by some users.
      Currently three floppies for standalone backup are followed by  thirteen
      for  the  base  system.   This  incurs  user inconvenience and a greater
      likelihood of failure in the process.  The TK50 cartridge  tape  is  not
      yet a universal solution to this problem.

                              HOW WAS "NanoVMS" BUILT?

      The problem was approached  by  building  a  VMS  system,  component  by
      component, on the second winchester of a two-disk MicroVAX.  This system
      could be tested simply by shutting  the  system  down  and  booting  the
      second  disk.   If unsuccessful, the full system disk would be rebooted,
      some files added to the minimal system, and it  would  be  tried  again,
      guided by the error messages produced in the previous attempt.


                                  361

uNOTE # 037
Page 2 of 8


                        HOW WAS "NanoVMS BUILT? (continued)

      The first cut at a solution was derived  from  the  "Reboot  Consistency
      Check" offered by sys$system:SHUTDOWN.COM.  Notably absent from the list
      of files was the disk driver!  A number  of  other  missing  files  were
      disclosed,   and   success  was  eventually  achieved  through  repeated
      attempts.  Often the proper functioning of  an  image  depended  on  the
      presence  of  another  (such  as  a library file).  The dependencies are
      shown in the attached directory listing.

                     HOW DOES ONE GENERATE A "NanoVMS" SYSTEM?

      1.  Make some choices

      There are a number of choices which affect how you generate a  "NanoVMS"
      system.   You can create a backup set that can be loaded onto a MicroVAX
      processor using standalone backup [Note - floppies only.  TK50  bootable
      MicroVMS  distributions  cannot  be  created  without access to a source
      kit].  The other choice is to  create  "NanoVMS"  on  a  winchester  and
      physically  install  it in to another MicroVAX.  This choice affects the
      third and fourth steps in the process, "Creating the  distribution"  and
      "Loading  the  distribution".  Another up-front choice that affects your
      work is the list of target CPU's you intend to be able to run  "NanoVMS"
      on  -  currently this includes MicroVAX I, MicroVAX II, VAXstation I and
      VAXstation II.  The work on the latter two  has  not  yet  been  done  -
      special  graphics  font  files  and server files need to be added to the
      list.  Read "Copy the files" below for details.

      2.  Create the directories

      If you have a single-winchester system, create [sys1].  If  you  have  a
      two-disk  system,  create  [sys0]  on  the  non-system disk instead.  In
      either case, create the subdirectories [.sysexe],  [.syslib],  [.sysmgr]
      and [.sysmsg] in the [sys0] or [sys1] directories you just created.
           If you have chosen the distribution option of physically installing
      a  bootable  winchester,  and your non-system disk's data is expendable,
      then you will want to initialize it.  Study the  section  "Creating  the
      Distribution",  below,  with  respect  to initialization options.  After
      initializing the disk, create the previously mentioned directories.

      3.  Copy the files

      Copy all of the files listed on pages 7 and  8  from  the  corresponding
      directories  of  your MicroVMS V4.1M system.  Note that a MicroVAX I CPU
      requires  the  file  SYSLOAUV1.EXE  and  a  MicroVAX  II  CPU   requires
      SYSLOAUV2.EXE.   Make  sure  to  include  the  correct  one (or both) as
      required by the target CPU.  Also be sure to use the /CONTIGUOUS  option
      when copying SYSBOOT.EXE.





                                  362

                                                           uNOTE # 037
                                                           Page 3 of 8


      4.  Create the distribution

      You will first want to decide whether your distribution will include all
      of the files (including your own application files) of the final system,
      or merely a basic "NanoVMS" skeleton to which additional files are added
      from  separate disk volumes.  If the former, at least list and count all
      the additional files you need.  Note  that  VMS  utilities  occasionally
      need  runtime  library  files,  and  your  application  files  may  need
      language-related runtime libraries  not  part  of  the  basic  "NanoVMS"
      system.   Be  sure  to include some extra files in your count.  Remember
      that there are nine files that are part of any VMS volume, and that each
      directory and subdirectory you create is a file as well.

           The nine files that are part of every VMS volume

           INDEXF.SYS         BITMAP.SYS         BADBLK.SYS
           000000.DIR         CORIMG.SYS         VOLSET.SYS
           CONTIN.SYS         BACKUP.SYS         BADLOG.SYS



           If you chose to create a backup set, simply issue  the  appropriate
      mount  and  backup commands, and insert the floppies into the RX50 drive
      (n = floppy unit number, x =  "NanoVMS"  disk  unit  number,  r  =  root
      number):

           $ [1mMOUNT/FOREIGN DUAn:[22m

      If you wish to merge your own software into the backup set:
           $ [1mBACKUP/INITIALIZE/LOG/VERIFY -[22m
           $_ [1mDUAx:[SYSr...]*.*;*,[yourdirectory...]*.*;* -[22m
           $_ [1mDUAn:MICROVMS./SAVE_SET[22m

      If you wish to separate your own software from the backup set:
           $ [1mBACKUP/INITIALIZE/LOG/VERIFY -[22m
           $_ [1mDUAx:[SYSr...]*.*;* -[22m
           $_ [1mDUAn:MICROVMS./SAVE_SET[22m

      The backup set created will then install exactly  as  described  in  the
      Installation chapter of the MicroVMS User's Manual.
           With standalone backup, you lose flexibility in  initializing  your
      system disk - it uses all the default values, which may be unsuitable or
      wasteful in a bounded system.  It is therefore recommended  to  use  the
      "walking  winchester"  as a way to transport bounded systems.  You would
      not be considering "NanoVMS" unless you have a legitimate need  to  save
      disk  space,  and  standalone  backup will often waste space.  The index
      file on an RD volume is greater than 1000 blocks in allocated  size,  in
      order to accomodate a large number of files on the disk.  If you can put
      an upper bound on the number of  files  you  expect  to  have,  you  can
      realize  considerable  savings  in  index file size.  The two parameters
      which most affect disk usage, Cluster Factor and Maximum File Count, are
      explained in the next two paragraphs.

                                  363

uNOTE # 037
Page 4 of 8


      4.  Create the distribution (continued)

           The cluster factor is the number of  disk  blocks  allocated  every
      time  a  new  file  is  created, or if additional blocks are needed when
      editing, etc.  If you issue the DCL command

           $ [1mDIRECTORY/SIZE=ALLOCATION[22m

      you will notice that all the sizes  are  divisible  by  3  (the  default
      cluster size for "large" disks).  If you have many small files, this can
      be  wasteful.   Unless  you  add  the  /CLUSTER_SIZE=n  option  to   the
      INITIALIZE  command,  this number will be 3 for disks larger than 50,000
      blocks, or 1 for smaller disks.   Small  cluster  sizes  will  adversely
      affect  disk  performance since files may be stored as many small pieces
      scattered widely over the disk surface.  On the other hand large cluster
      sizes  will  waste  disk  space,  since only one or two of the three (or
      more) allocated blocks may have data in them.
           The maximum number of files contained on a disk  is  determined  at
      initialization  time  by  the  number  of  empty  file headers allocated
      contiguously in the index file.  The DCL command

           $ [1mINITIALIZE/MAXIMUM_FILES=x DUAn:  label[22m

      initializes a disk with an index file capable of storing x file headers,
      no more.  The largest value of x is derived from the formula

                                        volume size in blocks
              maximum number of files = ---------------------
                                         cluster factor + 1

      The default (when the /MAXIMUM_FILES switch is omitted, or when

           $ [1mBACKUP/INITIALIZE[22m

      is issued) is equal to one-half the number derived by the above formula.
      If  the  default  is much larger than the actual largest number of files
      you anticipate storing, then you can gain many free blocks by specifying
      /MAXIMUM_FILES=x,  where  x is an upper bound on the number of files you
      expect on the disk.  In fact, you get exactly (default_maxfiles)-x  free
      blocks,  since  each  file  header occupies a full block.  The potential
      disadvantage is that the  disk  will  have  to  be  reinitialized  (i.e.
      erased) if you need to store x+1 or more files.
           The following table can be compared with  your  overall  needs,  so
      that the appropriate initialization command line can be given:

                             RD51    RD52    RD53

             Volume Size     19530   60480  138649 blocks
             Cluster Factor    1       3       3   blocks
             Maximum Files    4880    7560   17331 files



                                  364

                                                           uNOTE # 037
                                                           Page 5 of 8


      5.  Load the distribution

      If the  distribution  is  the  "walking  winchester",  then  loading  it
      consists  of installing the disk in the MicroVAX enclosure, removing the
      existing one  if  necessary.   Instructions  for  the  installation  and
      removal of hard disk drives can be found in the system's Owner's Manual.
           If the distribution is a backup set stored  on  a  number  of  RX50
      floppy diskettes, follow the instructions in the Installation chapter of
      the MicroVMS User's Guide.

      6.  Boot "NanoVMS"

      This procedure departs from the normal process, since "NanoVMS" does not
      have  a  paging  file or a system-parameter file, nor can it execute the
      full system startup command procedure since many of the commands  in  it
      try to invoke image (.EXE) files and libraries that are not on the disk.
      A number of error messages  (shown  below)  will  be  displayed  on  the
      console  terminal.  These are normal for "NanoVMS".  To boot the system,
      you must use the conversational boot by typing the commands

           >>> [1mB/1 DUAn[22m

           2..1..0..

           %SYSBOOT-E-Unable to locate file
           SYSBOOT> [1mSET STARTUP_P1 "MIN"[22m
           SYSBOOT> [1mSET VAXCLUSTER 0[22m
           SYSBOOT> [1mCONTINUE[22m


                                        Note

                         If your system is  a  MicroVAX  I,
                         you  will be prompted for the time
                         and  date  before  the   "MicroVMS
                         Version 4.1M" text appears.


           MicroVMS Version 4.1M 13-MAY-1985 22:29

           %SYSINIT-E- lookup failure on paging file, status = 00000000
           %DCL-W-ACTIMAGE, error activating image SETP0
           -CLI-E-IMGNAME, imagefile DUAn:[SYS0.SYSCOMMON.][SYSEXE]SETP0.EXE;
           -RMS-E-DNF, directory not found
           -SYSTEM-W-NOSUCHFILE, no such file
           %RMS-E-FNF, file not found
           %SET-I-NOMSG, Message number 007781B3
           SYSTEM job terminated at 8-AUG-1985 09:39:05.01





                                  365

uNOTE # 037
Page 6 of 8


      6.  Boot "NanoVMS" (continued)

      At this point, press carriage return  and  you  will  be  prompted  with
      "Username:".   Type  any  non-null  alphabetic  string,  followed  by  a
      carriage return.  You will then  be  prompted  twice  with  "Password:".
      Respond  both times with a carriage return.  The familiar "$" DCL prompt
      will then appear.  The default directory is SYS$SYSTEM.

      7.  Further steps...

      The only DCL commands available at this point  are  COPY,  BACKUP,  RUN,
      MOUNT and DISMOUNT, and a very small subset of the SET commands.  If you
      have access to a second winchester with a full MicroVMS  system  on  it,
      you  can mount it and copy additional files to your "NanoVMS" disk.  You
      can also use BACKUP/SELECT to copy  selected  files  from  the  MicroVMS
      distribution  floppies.   Remember  to  try  the  commands  first before
      walking away, since sometimes additional files (primarily in sys$library
      and sys$message) are needed.
           A paging file is often needed, particularly for applications  which
      set  up  large  arrays  or  data buffers, especially when the system has
      limited physical memory.  DECnet requires a 1000 block paging file  just
      to  initialize  itself.   The  file  can  be  created  by  the following
      commands:

           $ [1mRUN SYSGEN[22m
           SYSGEN> [1mCREATE PAGEFILE.SYS /SIZE=1000 /NOCONTIGUOUS[22m
           SYSGEN> [1mEXIT[22m

           To make it less painful to reboot, and to allow  you  to  save  any
      system tuning work, create a parameter file with the following commands:

           $ [1mRUN SYSGEN[22m
           SYSGEN> [1mSET STARTUP_P1 "MIN"[22m
           SYSGEN> [1mSET VAXCLUSTER 0[22m
           SYSGEN> [1mWRITE CURRENT[22m
           SYSGEN> [1mEXIT[22m

      The next time you reboot, you need only type ">>> [1mB DUAn[22m".
           In order to have a  secure  system,  or  to  have  incoming  DECnet
      access,   or   to   support  login  command  files  or  to  run  turnkey
      applications, you will probably want  a  user  authorization  file.   To
      support this, copy the following files from the MicroVMS distribution or
      from    a    MicroVMS    system     disk:      sys$system:AUTHORIZE.EXE,
      sys$library:MTHRTL.EXE    and    sys$library:PLIRTL.EXE    and   INSTALL
      sys$library:SECURESHR.EXE  with  the  /prot/shar/open   options.    When
      running  AUTHORIZE for the first time, you will create the authorization
      file SYSUAF.DAT.  You  will  have  to  reboot  before  you  can  log  in
      successfully.





                                  366

                                                           uNOTE # 037
                                                           Page 7 of 8


                     DIRECTORIES OF FILES NEEDED FOR "NanoVMS"

      Directory DUA1:[SYS0.SYSEXE]

      BACKUP.EXE;1    189 ! Required for adding additional files
                          ! to basic "NanoVMS" from backup sets
      COPY.EXE;1       58 ! Required for adding additional files
                          ! to basic "NanoVMS" from VMS volumes
      DCL.EXE;1       132 ! Required by STARTUP.COM and subsequent
                          ! user command execution
      DISMOUNT.EXE;1    8 ! Required to remove auxiliary volumes
      DUDRIVER.EXE;1   27 ! Disk controller protocol driver
      F11BXQP.EXE;1   107 ! Files-11 server
      FPEMUL.EXE;1     20 ! Floating-point emulator
      INSTALL.EXE;1    46 ! VMOUNT.EXE must be INSTALLed to be run
      JOBCTL.EXE;1    102 ! Required to create LOGINOUT as detached process
      LOGINOUT.EXE;2  103 ! Permits logins after STARTUP.COM exits
      PUDRIVER.EXE;1   13 ! Disk controller port driver
      RMS.EXE;1       211 ! RMS-32 server - required to find and open files
      RUNDET.EXE;1     14 ! Required to run JOBCTL as detached process
      SCSLOA.EXE;1      8 ! Required when using MSCP system disks
      SET.EXE;1       167 ! Required to enable interactive logins
      STARTUP.COM;1    17 ! Sets up LOGINOUT and system logical symbols
      SYS.EXE;1       344 ! The operating system image (except for
                          ! device and file support, instruction emulation)
      SYSBOOT.EXE;1    87 ! The primary bootstrap
      SYSGEN.EXE;1    115 ! Required to alter and save system parameters
      SYSINIT.EXE;1    87 ! The first image to be run as a process
      SYSLOAUV2.EXE;1  15 ! MicroVAX II processor-specific initialization code
      TTDRIVER.EXE;1   45 ! The terminal driver
      VAXEMUL.EXE;1    23 ! Emulates non-floating-point VAX instructions
      VMOUNT.EXE;1     16 ! Required to mount auxiliary volumes

      Total of 24 files, 1954 blocks.

      Directory DUA1:[SYS0.SYSLIB]

      DCLTABLES.EXE;3 248 ! Required by sys$system:DCL.EXE
      DISMNTSHR.EXE;1  11 ! Required by sys$system:DISMOUNT.EXE
      ENCRYPSHR.EXE;1  18 ! Required by sys$system:BACKUP.EXE
      LBRSHR.EXE;1     76 ! Required by sys$system:INSTALL.EXE
      LIBRTL.EXE;1    128 ! Required by sys$system:JOBCTL.EXE
      LIBRTL2.EXE;1    39 ! Required by sys$system:JOBCTL.EXE
      MOUNTSHR.EXE;1  120 ! Required by sys$system:VMOUNT.EXE
      SCRSHR.EXE;1     21 ! Required by sys$system:SYSGEN.EXE
      SECURESHR.EXE;1  58 ! Required by sys$system:BACKUP.EXE

      Total of 9 files, 719 blocks.





                                  367

uNOTE # 037
Page 8 of 8


               DIRECTORIES OF FILES NEEDED FOR "NanoVMS" (continued)

      Directory DUA1:[SYS0.SYSMGR]

      ACCOUNTNG.DAT;1   5 ! This file is created by LOGINOUT.EXE

      Total of 1 file, 5 blocks.

      Directory DUA1:[SYS0.SYSMSG]

      SYSMGTMSG.EXE;1  49 ! Required for intelligible error messages
      SYSMSG.EXE;1    268 ! Required for intelligible error messages

      Total of 2 files, 317 blocks.

      Grand total of 4 directories, 36 files, 2995 blocks.

      Not shown:
          Index file (see text)
          Other files produced by volume initialization
          Directory files (average 5 blocks each)
          Page file (see text)
          Sysgen parameter files (15 blocks each)



                                        NOTE

              This MicroNote describes a minimal VAX/VMS system  which
              is  not  in  any  way  warranted or supported by Digital
              Equipment Corporation - it reports ongoing  research  by
              the  author,  and  represents solely his conclusions and
              opinions, not those of  Digital  Equipment  Corporation.
              The  minimal  VAX/VMS  system described here can only be
              used on MicroVAX computer systems which are licensed  to
              run  MicroVMS.  It is composed of files which are normal
              components of MicroVMS V4.1M.  Earlier or later versions
              of   MicroVMS   may  not  successfully  execute  in  the
              described subset environment.














                                  368

================================================================================
Note 38.0                   DECnet Down-line Loading                  No replies
FURILO::GIORGETTI                                   529 lines   4-SEP-1985 15:54
--------------------------------------------------------------------------------



      +---------------+                                    +-----------------+
      | d i g i t a l |                                    |  uNOTE # 038    |
      +---------------+                                    +-----------------+


      +----------------------------------------------------+-----------------+
      | Title: DECnet Down-line Loading                    | Date: 26-Jul-85 |
      +----------------------------------------------------+-----------------+
      | Originator: Scott D. Blessley                      | Page 1 of 9     |
      +----------------------------------------------------+-----------------+


      This article overviews the downline load  process  used  by  DECnet  for
      remote  loading  of  PDP-11  and  VAX processors.  Downline loading is a
      versatile and complicated process.   This  article  is  intended  as  an
      introduction/aid to the process, not a tutorial.  An extensive reference
      list appears at the  end  of  the  article  for  readers  interested  in
      pursuing the subject further.



      1  OVERVIEW OF THE DOWNLINE LOAD PROCESS

      DECnet downline load is the set of hardware and software features  which
      allow  complete  systems  (RSX-11S and VAXELN) to be loaded into remote,
      potentially unattended processors.   In  addition,  RSX-11S  offers  the
      capability to:  dynamically load tasks over comm lines, checkpoint tasks
      out of memory over the line, and upline dump a failed operating  system.
      RSX-11S  functionality  is  a subset of those features found in RSX-11M.
      VAXELN also features a symbolic debugger that allows debug of the target
      from the host processor.



      2  DEFINITIONS

      2.1  HOST

      The host [node] (for this discussion) refers to both the  machine  which
      originates  the  load,  as well as the machine which loads the software.
      In actuality, these need not be the same machine.



      2.2  TARGET

      The target [node] is the machine being loaded  with  new  software.   It
      must  be  powered  up,  but  may  or may not have to be awaiting primary
      bootstrap, depending on its communications  bootstrap  device  and  boot
      options.



                                  369

uNOTE # 038
Page 2 of 9


      2.3  EXECUTOR

      The executor [node] is the node which initiates the commands to downline
      load a target.  It need not be the same as the host.

                           +------------+
                           |            |
                           | TARGET     |<----------+
                           | (HOBSON::) |           |
                           +------------+           |
                              ^  |                  |
             Operating System |  | Load request     |
                              |  |                  |
                              |  |                  |
                              |  |                  |
                              |  |                  | NCP>TRIGGER NODE HOBSON
                              |  v                  v
                           +------------+      +------------+
                           |            |      |            |
                           | HOST       |      | EXECUTOR   |
                           | (FURILO::) |      | (FURILO::) |
                           +------------+      +------------+
                                     ( ^ same CPU or  ^
                                                     different)


               Relationship between host, target, and executor nodes



      3  PREPARING FOR DOWNLINE LOAD

      There are three overall steps:

       o  Configuring the communications hardware  -  both  on  the  host  and
          target systems

       o  Configuring the DECnet software and the operating system image  that
          will be loaded.

       o  Verification and testing.

      The most frequent problem is the failure to correctly configure the host
      and/or target hardware.  There are two principal places for error:

       -  setting DIP switches inappropriately  resulting  in  incorrect  line
          speeds, wrong power-up boot options (BSEL switches), etc.

       -  Skew  between  hardware  configuration  and  software  (for  example
          mis-specifying the vector/CSR or the Ethernet address for the target
          device).  Be sure  to  have  the  latest  version  of  the  hardware
          manuals.

                                  370

                                                           uNOTE # 038
                                                           Page 3 of 9


      Specific points to be careful about:

      1.  Vector/CSR

      2.  B[oot]SEL[ect] switches - these specify under  what  conditions  the
          comm interface will force a bootstrap.

      3.  Service password - this  is  a  protection  feature  to  lessen  the
          likelihood of an inadvertent or malicious downline load.

      4.  Ethernet address (Ethernet circuits only) - the unique address  that
          the target Ethernet device will respond to.

      5.  Service circuit - this identifies at the end of which wire to expect
          the target.

      6.  Enable SERVICE for the circuit being downline loaded.  This  enables
          the DECnet software to start the downline load process on the host.

      7.  Make sure event logging is enabled, or you'll miss error messages.

      8.  It may seem obvious, but make  sure  that  the  target  comm  device
          you're  using,  and  the  processor bootstrap are *capable* of doing
          what  you  ask.   For  details,  see  uNote  #015,  "Q-bus  Hardware
          Bootstraps"




      4  RSX-11S OVERVIEW

      Configure the RSX-11S image on a VAX/VMS, RSX-11M  or  RSX-11M+  system,
      using  the  normal tools (SYSGEN, MAC, TKB, VMR).  Prepare and build the
      host loader table.  (Refer to the References section  for  documentation
      on RSX downline load procedures)



      5  VAXELN OVERVIEW

      The program/VAXELN image development sequence is:

      1.  Develop the source modules

      2.  LINK the source modules with the RTLSHARE.OLB and RTL.OLB libraries

      3.  EBUILD the LINKed image to produce a bootable VAXELN system.  To  be
          able  to downline load the VAXELN image, you must select Boot Method
          DOWNLINE in the VAXELN System Characteristics portion of EBUILD.




                                  371

uNOTE # 038
Page 4 of 9


      4.  Downline load the target over Ethernet (this is not the only  method
          of  loading  a  VAXELN  target).   The  target can be loaded through
          EDEBUG commands, or via NCP LOAD/TRIGGER commands.

      5.  Debug the application and repeat steps 1-4.



      +------------+     +------------+     +------------+     +------------+
      |PASCAL or C |.OBJ |$ EPAS or   |.EXE | $ EBUILD   |.SYS | $ EDEBUG   |
      |source prog.|---->|$ CC        |---->|            |---->| or NCP     |
      +------------+     +------------+     +------------+     +------------+
                                                      ^
                                                      | Other VAXELN
                                                      | modules
                                                      |


                        VAXELN Program development sequence



      6  OBSERVING & DEBUGGING

      There are a variety of error indications, and diagnostic aids available.
      Some  are at the hardware level (comm device diagnostic LEDs), some from
      the host software (upline dump for RSX-11S, EDEBUG for VAXELN).   Others
      are provided by the DECnet components that handle downline load, through
      the EVL (EVent logger) capability.  Some diagnostic facilities:

      1.  Device status  LEDs  give  a  numeric  indication  as  to  potential
          hardware,  or  hardware configuration problems with the interface or
          its connections.

      2.  Event logging messages:

           -  Event code 0.3 - Auto service:  indication that a portion  of  a
              DLL is taking place.

           -  Event code 0.7 - Aborted service  request:   indication  that  a
              portion  of  a  DLL load request is failing.  This is not always
              bad.  For example, it is an  acceptable  "error"  when  multiple
              hosts (on an Ethernet) offer service and the target accepts only
              one.  The remaining systems report event 0.7.  EVL messages come
              with  varying  amounts  of diagnostic information.  A 0.3 or 0.7
              event includes the type of load being requested, from  where  it
              is requested, to whom it is requested, etc.






                                  372

                                                           uNOTE # 038
                                                           Page 5 of 9


      3.  Failure message from NCP on LOAD/TRIGGER commands -  may  give  some
          insight as to the source of the problem

      4.  Line/circuit counters - indicate how much data has been  transmitted
          and received , and what errors have occurred.

      Remember:  Enable event  logging:   NCP  SET  LOGGING  <facility>  KNOWN
      EVENTS  STATE  ON.   Otherwise,  EVL  will  not  display this diagnostic
      information!



      7  EXAMPLES

      One the next three pages are examples showing the successful load  of  a
      terminal  server and a VAXELN target.  The appearance of the output will
      be approximately the same for your targets,  only  with  different  node
      names and files.



































                                  373

uNOTE # 038
Page 6 of 9






      $ reply/enable=network

      %%%%%%%%%%%  OPCOM  26-JUL-1985 13:09:11.96  %%%%%%%%%%%
      Operator _FURILO$RTA1: has been enabled, username BLESSLEY
      %%%%%%%%%%%  OPCOM  26-JUL-1985 13:09:11.99  %%%%%%%%%%%
      Operator status for operator _FURILO$RTA1:
      NETWORK

      $ run sys$system:ncp
      NCP>show node hobson characteristics      !Hobson is a DECserver 100

      Node Volatile Characteristics as of 26-JUL-1985 13:10:49

      Remote node =   13.102 (HOBSON)

      Service circuit          = UNA-0
      Hardware address         = 08-00-2B-02-0F-5F
      Load file                = SYS$SYSROOT:[DECSERVER]PS0801ENG.SYS
      Dump file                = SYS$SYSROOT:[DECSERVER]PSDMP0F5F.SYS

      NCP>trigger node hobson
      NCP>^Z

      %%%%%%%%%%%  OPCOM  26-JUL-1985 13:10:13.16  %%%%%%%%%%%
      Message from user DECNET on FURILO
      DECnet event 0.3, automatic line service
      From node 7.272 (FURILO), 26-JUL-1985 13:10:13.04
      Circuit UNA-0, Load, Requested, Node = 13.102 (HOBSON)
      File = MOM$LOAD:PS0801ENG, Operating system, Ethernet address
      = 08-00-2B-02-0F-5F

      %%%%%%%%%%%  OPCOM  26-JUL-1985 13:10:18.08  %%%%%%%%%%%
      Message from user DECNET on FURILO
      DECnet event 0.3, automatic line service
      From node 7.272 (FURILO), 26-JUL-1985 13:10:16.40
      Circuit UNA-0, Load, Successful, Node = 13.102 (HOBSON)
      File = MOM$LOAD:PS0801ENG, Operating system,
      Ethernet address = 08-00-2B-02-0F-5F


                        DECserver-100 Downline Load Example








                                  374

                                                           uNOTE # 038
                                                           Page 7 of 9


      Below is an example of down-line load of  a  MicroVAX  II  system  using
      EDEBUG.   The  first  part of the illustration shows the DECnet volatile
      database entries for the target, as seen from the system that ultimately
      boots the target, and from another that fails to boot the target.

      [This command is issued on system "BELKER"]

      BELKER> NCP SHOW NODE TUBBS CHARACTERISTICS

      Node Volatile Characteristics as of  7-AUG-1985 10:38:59
       
      Remote node =   7.453 (TUBBS)
       
      Service circuit          = UNA-0
      Hardware address         = 08-00-2B-02-1C-63
      Load file                = DISK$USER:[SAMPLE.ELN]CHER.SYS;
       
      [This command is issued from system "FURILO"]

      FURILO> NCP SHOW NODE TUBBS CHARACTERISTICS

      Node Volatile Characteristics as of  7-AUG-1985 10:40:52
       
      Remote node =   7.453 (TUBBS)
       
      Load file                = DISK$USER:[SAMPLE.ELN]CHER.SYS;

      -----------------------------------------------------------------------
                Command to downline load the VAXELN image from EDEBUG:

      [This command and related output is from system "BELKER"]

      $ EDEBUG/LOAD=PROG1 TUBBS

      Edebug V2.0-00
      Loading "TUBBS"
      Connecting to "TUBBS"

      .
      .
      .
      (screen mode debugger)

                Event log messages resulting from the EDEBUG command:

      DECnet event 0.7, aborted service request
      From node 7.272 (FURILO),  6-AUG-1985 16:13:14.46
      Circuit UNA-0, Line open error, Unrecognized component, Node
      Ethernet address = 08-00-2B-02-1C-63
                ^ FURILO:: didn't have this address defined in its
                  volatile database so it couldn't service the request


                                  375

uNOTE # 038
Page 8 of 9


      DECnet event 0.3, automatic line service
      From node 7.190 (BELKER),  6-AUG-1985 16:12:51.34
      Circuit UNA-0, Load, Requested, Node = 7.453 (TUBBS)
      File = DISK$USER:[SAMPLE.ELN]CHER.SYS;, Operating system
      Ethernet address = 08-00-2B-02-1C-63
                ^ BELKER:: did have the address, corresponding to an
                  entry for "TUBBS::" Here, the target system is 
                  requesting an operating system load. BELKER's DECnet
                  software is acknowledging the request.

      DECnet event 0.3, automatic line service
      From node 7.190 (BELKER),  6-AUG-1985 16:12:57.62
      Circuit UNA-0, Load, Successful, Node = 7.453 (TUBBS)
      File = DISK$USER:[SAMPLE.ELN]CHER.SYS;, Operating system
      Ethernet address = 08-00-2B-02-1C-63
                  BELKER responds with packet(s) containing the
                  requested O.S. code for the target 
       



      8  SUMMARY

      This Micronote  has  presented  an  overview  of  the  downline  loading
      process.   Many  "components" are involved in the process - at least two
      CPUs and at least two communication interfaces, target operating  system
      and  images  plus  host,  target,  and  executor  DECnet  software.  The
      procedure is akin to bringing up a complex, customized operating  system
      up on a remote processor, without a local load device.  Once configured,
      it offers the  benefits  of  not  requiring  any  mass  storage  devices
      (resulting in higher MTBF and lower cost), plus the ability to bootstrap
      a processor which my be  physically  inaccessible.   There  is  a  great
      amount  of  information  on  DECnet  downline  load.  There is no single
      compendium, although each  of  the  supported  operating  systems,  plus
      VAXELN have a chapter on the subject.


















                                  376

                                                           uNOTE # 038
                                                           Page 9 of 9


      9  REFERENCES

      All of the following references are to Digital publications.

          DECnet-RSX Volume IV - System Manager's Guide AA-H224C-TC

          Guide to Networking VAX/VMS - AA-Y512A-TE (chapter 4)

          QMA DMV11 Synchronous Controller Technical Manual EK-DMVQM-TM

          DEQNA User's Guide EK-DEQNA-UG

          DECnet Digital Network Architecture (Phase IV)  General  Description
          AA-N149A- TC

          DECnet  Digital  Network   Architecture   (Phase   IV)   Maintenance
          Operations Functional Specification AA-X436A-TC

          Networks and Communications Buyer's Guide ED-26347

          "VAXELN Installation and Programming" AA-Z454A-TE

          "MicroVax I Owner's Manual" EK-KD32-OM

          "MicroVAX I Owner's Manual" (Release Notes) EK-KD32A-OM-CN1

          Micronote #015, "Q-Bus Hardware Bootstraps"

      Software Product Descriptions:

          DECnet-11S #10.74

          DECnet-11M #10.75

          DECnet-11M+ #10.66

          DECnet-VAX #25.03
















                                  377

================================================================================
Note 39.0                KDJ11-A and KDJ11-B Differences              No replies
FURILO::GIORGETTI                                   292 lines   4-SEP-1985 15:55
--------------------------------------------------------------------------------



      +---------------+                                    +-----------------+
      | d i g i t a l |                                    |  uNOTE # 039    |
      +---------------+                                    +-----------------+

                                                                         
      +----------------------------------------------------+-----------------+
      | Title:  Differences between KDJ11-A and KDJ11-B    | Date: 8-Aug-85  |
      +----------------------------------------------------+-----------------+
      | Originator:  Peter Kent                            | Page 1 of 5     |
      +----------------------------------------------------+-----------------+


                                      Purpose

      The purpose of this MicroNote is to identify and discuss the differences
      between the KDJ11-A and KDJ11-B CPU modules.

      The table that follows lists the differences between  the  CPU  modules.
      Differences that require explanation follow the table and are marked *.

      +------------------------+------------------+---------------------+
      | FEATURE                |   KDJ11-A        |      KDJ11-B        |
      +------------------------+------------------+---------------------+
      | Cache *                |   Single tag     |      Dual tag       |
      +------------------------+------------------+---------------------+
      | PMI support *          |   No             |      Yes            |
      +------------------------+------------------+---------------------+
      | On-board bootstrap *   |   No             |      Yes            |
      | and diagnostic ROM     |                  |                     |
      +------------------------+------------------+---------------------+
      | Boot/diagnostics  *    |   No             |      Yes            |
      | control status reg.    |                  |                     |
      +------------------------+------------------+---------------------+
      | Boot page *            |   No             |      Yes            |
      | control register       |                  |                     |
      +------------------------+------------------+---------------------+
      | Boot configuration *   |   No             |      Yes            |
      | and display register   |                  |                     |
      +------------------------+------------------+---------------------+
      | Instruction implementation differences  *                       |
      +-----------------------------------------------------------------+ 
      | DCJ-11 speed/FPJ11 differences *                                |
      +-----------------------------------------------------------------+
      | Backplane compatibility  *                                      |
      +-----------------------------------------------------------------+
      | Maintenance register differences  *                             |
      +-----------------------------------------------------------------+
                                                             cont'd





                                  379

uNOTE # 039
Page 2 of 5


      The differences between the CPU modules.  cont'd:

      +------------------------+------------------+---------------------+
      | FEATURE                |   KDJ11-A        |      KDJ11-B        |
      +------------------------+------------------+---------------------+
      | Module I.D.            |   M8192          |      M8190          |
      +------------------------+------------------+---------------------+
      | Size                   |   Dual           |      Quad           |
      +------------------------+------------------+---------------------+
      | Power: 5 volt (12 Volt)|   4.5            |      5.5 (0.2)      |
      +------------------------+------------------+---------------------+
      | AC loading             |   3.4            |      2.3            |
      +------------------------+------------------+---------------------+
      | Console serial line    |   No             |      One            |
      +------------------------+------------------+---------------------+
                                       Cache

      For a full discussion of cache memory as used on the KJD11-A and KDJ11-B
      refer  to  MicroNote #9 and the KDJ11-A and KDJ11-B User's Guides.  Both
      CPU modules have a similar cache organization  using  a  nine  bit  tag.
      This nine bit field contains information that is compared to the address
      label, which is part of the physical address.  When the physical address
      is  generated, the address label is compared to the tag field.  If there
      is a match it can be considered a  hit  provided  that  there  is  entry
      validation  and  no  parity  errors.   The KDJ11-B has an additional tag
      store called the DMA tag.  The DMA tag is an identical copy of the cache
      tag  store  and is used to monitor the main memory DMA updates while the
      cache tag store monitors the DCJ11 requirements.  The  presence  of  the
      second  tag store - DMA tag - allows the J-11 microprocessor to continue
      processing after it has relinquished the system bus  to  a  DMA  device.
      When  the  DMA tag detects a hit (main memory location written to by the
      DMA device), the microprocessor stops and relinquishes the internal  bus
      to  the  cache controller to allow it to monitor further DMA activity on
      the bus.  The KDJ11-A,  however,  has  only  one  tag  store  and  stops
      processing as soon as it relinquishes the system bus to a DMA device.

                                    PMI support

      The PMI or Private Memory Interconnect is described  in  MicroNote  #30.
      The PMI consists of 14 unique signals which use the CD interconnect side
      of the backplane of certain Q-bus backplanes.  PMI is used only with the
      KDJ11-B  and  MSV11-J.   PMI  DATI and DATO bus transactions between the
      KDJ11-B and MSV11-J are more than twice as fast as those between non-PMI
      CPU  and  memory  configurations.   The  KDJ11-A  does  not  offer a PMI
      capability.

      The Unibus adaptor used with PDP11/84 systems enables the Unibus map  if
      a  particular  PMI  signal - PMAPE (Unibus map enable) - is asserted and
      disables the Unibus map when  PMAPE  is  negated.   The  memory  modules
      associated with PMI (MSV11-J) do not use this signal.  PMAPE is asserted
      if Memory Management Register 3, bit 05 is set, and negates this  signal

                                  380

                                                           uNOTE # 039
                                                           Page 3 of 5


      if  MMR3  is  clear.   If there are devices which require this signal to
      work, the KDJ11-A  will  not  and  cannot  (without  warranty  violating
      modifications) be made to issue this signal.

                            KDJ11-B boot/diagnostic ROM

      The are basically 3 parts to the  ROM  code.   The  first  part  is  the
      diagnostic  tests  which are run at power up or at the initiation of the
      operator.  These tests perform checks on  the  CPU  module,  the  memory
      module(s),  and  the Unibus adaptor for Unibus systems.  The second part
      of the ROM is the boot code.  The following devices can be  booted  from
      the  KDJ11-B:   RA80/81/60, RD51/52, RX50, RC25, RL01/02, RX01/02, TU58,
      RK05, TK25/50, TS05, TU81, DEQNA, DECnet DUV11, DECnet  DLV11-E,  DECnet
      and DLV11-F.  The boot code can also start programs stored in the EEPROM
      or programs stored in M9312 type boot ROMs located on the  KTJ11  Unibus
      adaptor  module.   The third part of the the code allows the storing and
      modification of parameters for the CPU,  the  Unibus  adaptor,  and  the
      system.   This  portion  of  the boot code also provides support for the
      EEPROM itself.  The user can also create (using a machine  code  editor)
      his own custom boot code and save this code in the EEPROM.

                   Boot and diagnostic controller status register

      The boot and diagnostic controller status register (BCSR) is  both  word
      and  byte  addressable.   The  BCSR  allows  the boot and diagnostic ROM
      programs to test battery backup and reboot status, to set parameters for
      the  PMG  (processor  mastership  grant)  counter and the line clock, to
      enable the console halt on break feature and to enter or exit from stand
      alone mode.

                             Boot page control register

      The page control register is a read/write register which  is  both  byte
      and  word  addressable.  The PCR high byte provides the most significant
      ROM address bits when the 16 bit ROM sockets are accessed by bus address
      1777300-17773776.   The  PCR  low byte provides the most significant ROM
      (or EEPROM) address bits when the 16  bit  or  8  bit  ROM  sockets  are
      accessed by addresses 17765000-17765776.

                         Configuration and display register

      The configuration and display register reflects the status of the  eight
      switches edge mounted at the top of the module.  It also allows boot and
      diagnostic programs to update the 8 bit LED display located at  the  top
      of the KDJ11-B module.

                            Instruction set differences

      Instructions  which  are  required  to  do   a   read-modify-write   are
      implemented  differently  on  the KDJ11-A and KDJ11-B.  There are only 3
      instructions  which  are  defined  by  the  PDP11  architecture  to   be
      uninterruptible  during  its  read-  modify-write.  They are the TSTSET,

                                  381

uNOTE # 039
Page 4 of 5


      WRTLCK,  and  ASRB  instructions.   The  KDJ11-A  will  implement  these
      read-modify-write  instructions differently than a KDJ11-B.  The KDJ11-A
      processor uses the AIO signal outputs of the J11 to determine whether it
      performs  either  a 1) DATIO cycle or 2) a DATI cycle followed by a DATO
      cycle.  The KDJ11-A will ONLY do a DATIO Q-bus cycle when it executes  a
      TSTSET,  WRTLCK or ASRB instruction.  Past implementations of the PDP-11
      architecture  have  also  implemented   other   instructions   doing   a
      read-modify-write  cycle  as  being  uniterruptable.   The BIS (Bit Set)
      instruction will be used as an example.  This instruction  requires  the
      CPU  to  READ  a word from memory, possibly MODIFY that word, then WRITE
      the word back to  memory.   A  KDJ11-B  uses  a  Q-bus  DATIO  cycle  to
      implement   this   instruction.    Therefore,  the  instruction  is  not
      interruptable between doing the READ and the WRITE.   When  it  executes
      other  instructions  which want to do a read-modify-write operation like
      the BIS instruction, it  will  use  two  separate  Q-bus  cycles.   This
      implementation  allows  for  an  interrupt  or DMA request to be granted
      between the DATI and the DATO (case 2 above).   There  are  third  party
      vendors  whose  equipment assume that a BIS instruction will use a DATIO
      bus cycle.  Those devices will work fine in a system with a KDJ11-B, but
      will  work  intermittently  in a system with a KDJ11-A because what they
      assume to be uninterruptible is  now  interruptible  and  affects  their
      on-board firmware.

                                 Speed and the FPA

      +----------+---------+--------+----------------+--------------+---------+
      |          |  15 MHz | 18 MHz | FPA compatible | FPA on board | system  |
      +----------+---------+--------+----------------+--------------+---------+
      | KDJ11-AA |   Yes   |   No   |     No         |    No        | Q18/Q22 |
      +----------+---------+--------+----------------+--------------+---------+
      | KDJ11-AB |   Yes   |   No   |     Yes        |    No        | Q18/Q22 |
      +----------+---------+--------+----------------+--------------+---------+
      | KDJ11-AC |   Yes   |   No   |     Yes        |    Yes       | Q18/Q22 |
      +----------+---------+--------+----------------+--------------+---------+
      | KDJ11-BB |   Yes   |   No   |     Yes        |    No        | 11/73   |
      +----------+---------+--------+----------------+--------------+---------+
      | KDJ11-BC |   Yes   |   No   |     No         |    No        | 11/73   |
      +----------+---------+--------+----------------+--------------+---------+
      | KDJ11-BF |   No    |   Yes  |     Yes        |    Yes       | 11/83   |
      +----------+---------+--------+----------------+--------------+---------+


                              Notes on the above table

      The 15 MHz or 18 MHz refers to the crystal frequency at which the DCJ-11
      will  run.   FPA means the FPJ11 floating point accelerator chip.  Refer
      to MicroNote #25 for more information on upgrading with the FPJ11.   The
      KDJ11-A  is  a  CPU module that is not sold as part of a package system.
      The reference to Q18/Q22 refers to the fact that the KDJ11-A can be used
      in  any 18 or 22 bit Q-bus backplane.  The notation 11/73 means that the
      indicated KDJ11-B CPUs are used with the MicroPDP-11/73 systems and  the
      indicated KDJ11-B CPU are used with the MicroPDP-11/83 system.

                                  382

                                                           uNOTE # 039
                                                           Page 5 of 5


                                     Backplanes

      The KDJ11-A CPU may be used in any Q18/Q22 slot.  The KDJ11-B,  being  a
      quad  module  must  be  accomodated in a backplane which has Q-bus in AB
      slots and the CD interconnect in the CD slots.  The  KDJ11-B  cannot  be
      used in a backplane (or that part of the backplane) where there is Q-bus
      in both AB and CD slots.

                          Maintenance register differences

      The maintenance register contains the following information in both  the
      KJD11-A  and  KDJ11-B:   POK  (power  ok),  power up mode selected, HALT
      status, Module ID, FPA available,  and  Boot  address.   The  module  ID
      number  is  a  4  bit code that differs between the KDJ11-A and KDJ11-B.
      The ID number for the KDJ11-A is 0001 and 0002 for the KDJ11-B.






































                                  383

================================================================================
Note 40.0                   FPJ11 Theory of Operation                 No replies
FURILO::JACKSON "If you've got straight trousers, " 236 lines  13-FEB-1986 00:26
--------------------------------------------------------------------------------




      +---------------+                                    +-----------------+
      | d i g i t a l |                                    |  uNOTE # 040    |
      +---------------+                                    +-----------------+

                                                                   
      +----------------------------------------------------+-----------------+
      | Title: FPJ11 Theory of Operation                   | Date: 17-SEP-85 |
      +----------------------------------------------------+-----------------+
      | Originator:  Bill Jackson                          | Page 1 of 4     |
      +----------------------------------------------------+-----------------+


      The goal of this MicroNote is to introduce the FPJ11, a  floating  point
      coprocessor   to   the   DCJ11,   and   to  explain  the  interprocessor
      communication between the FPJ11 and DCJ11.  Figure  1  shows  a  typical
      DCJ11  based system which includes the FPJ11.  For a discussion of FPJ11
      support on the KDJ11-A processor, see MicroNote #025.

      +-------+                                                    +------+
      |       |                                                    |      |
      | DCJ11 |                                                    |      |
      |       |----------------------------------------------------|      |
      |       |                    DATA BUS                        |      |
      |       |----+ +--------------+  +--------------+  +---------|      |
      |       |    | |              |  |              |  |         |      |
      |       |    | |     +-DMR    |  |              |  |         |      |
      |       |    | |     |     +--+--+---+        +-+--+--+      |      |
      |       |    | |     V     | FPJ11   |        |       |      | BUS  |
      |       |    | |  +-----+  |         |        | CACHE |      |INTER-|
      |   DMR |<---+ +--| SI  +--+ ACK     |        |       |      | FACE |
      |       |    | |  |     +--+ STL     |        |       |      |      |
      |       |    | |  |     |  | DV      |        |       |      |      |
      |       |    | |  +-----+  | OP      |        |       |      |      |
      |       |    | |           | RDY     |        |       |      |      |
      |   FPE |<---+-+-----------+ FPE     |        |       |      |      |
      |       |    | |           |         |        |       |      |      |
      |   AIO +----+-+---------->| AIO<3:07|        |       |      |      |
      |       |    | |           | ALE     |        |       |      |      |
      |       +----+-+---------->| STRB    |        |       |      |      |
      |       +----+-+---------->| PRDC    |        |       |      |      |
      |       |    | |           | ABORT   |        |       |      |      |
      |       |    | |           |         |        |       |      |      |
      |       |    | |  +---+    |ADDR<2:0>|        |       |      |      |
      +-------+    | |  | L |    +---+-+---+        +--+-+--+      |      |
                   | |  | A |        | |               | |         |      |
                   | +--+ T +--------+ +---------------+ +---------+      |
                   |    | C |             ADDRESS BUS              |      |
                   +----+ H +--------------------------------------+      |
                        +---+                                      |      |
                                                                   +------+

                                Typical DCJ11/FPJ11 Application

                                  385

uNOTE # 040
Page 2 of 4


      The FPJ11 is a single chip floating  point  accelerator  for  the  DCJ11
      microprocessor.   Its  coprocessor  interface,  along with optimizations
      within the chip allow for 5 to  8  times  acceleration  over  the  DCJ11
      microcoded floating point performance.  The FPJ11 provides



       o  Complete FP11 floating point instructions (46)

       o  Two FP11 floating point data types (F and D)

       o  Six 64-bit floating point accumulators

       o  FEC floating exception code register


      The FPJ11 interfaces as a true Co-processor.  The Bus Interface Unit  or
      BIU)  inputs  all  instruction  stream  data and decodes instructions in
      parallel with the DCJ11.  Support microcode in the DCJ11  initiates  all
      I/O  cycles  required  by the FPJ11.  This Co-processor interface allows
      overlap of floating point instruction executing in the FPJ11 and integer
      instructions  executing in the DCJ11.  This allows for reduced execution
      time by interleaving floating point and integer instructions.

      The interface to the FPJ11 involves several DCJ11 signals which indicate
      the  state  of  the DCJ11 processor, and synchronize the two processors.
      Table 1 lists the signals and their use in the FPJ11 interface, Figure 1
      shows their use.

                                      TABLE 1
                                DCJ11/FPJ11 signals

          DCJ11 signal        Use

          AIO<3:0>            Indicate to FPJ11 current DCJ11 cycle type
          PRDC                signal instruction decode to FPJ11
          STRB                signal beginning of bus cycle to FPJ11
          DMR                 used by FPJ11 to stall the DCJ11
          FPE                 indicate to DCJ11 a floating point exception
          ALE                 used to latch cache hit data (trailing edge)
          DV                  used to latch non-cache data (trailing edge)
          DAL<2:0>            indicate GPREAD and GPWRITE information
          FPA-OP              signal to SI that writes come from FPA
          FPA-STL             used to stall DCJ11 during multiple FPA 
                              instructions
          FPA-RDY             indicates FPA data will be ready in 125ns
          FPA-ACK             enable FPA output drivers



      The DCJ11 supports several types of bus operations in communicating with
      the  external  system.   Since the FPJ11 relies on the DCJ11 to initiate

                                  386

                                                           uNOTE # 040
                                                           Page 3 of 4


      all I/O cycles, the FPJ11 will monitor DCJ11 I/O  cycles  for  activity.
      When  specific  I/O  cycles  occur,  the  FPJ11 will 'wake up' and start
      processing.  A subset of the DCJ11 bus cycles are used by the  FPJ11  in
      communicating  with  the DCJ11 and the system interface (SI).  These bus
      cycles are listed in Table 2.  The bus read and write cycles are used to
      read/write data to/from memory (or cache).  The GP transactions are used
      for interprocessor communications between the DCJ11 and FPJ11.


                                      Table Y
                                DCJ11 bus operations

          Cycle               Description

          IREAD               latched to search for FP instruction
          DREAD               used for data fetches for FP instructions
          WRITE               used to write FP data back to memory
          GPREAD              used to read FP data to DCJ11 internal registers
          GPWRITE             used to write FP data to DCJ11 internal 
                              registers



      The DCJ11 divides all bus reads into 3 categories:   Instruction  stream
      Demand READ (IDREAD), Instruction stream Request READ (IRREAD), and Data
      stream READ (DREAD).  Instruction stream reads are used by the DCJ11  to
      fetch  instruction  stream  data  such as PDP-11 instructions, immediate
      data and absolute data.  All other DCJ11 reads are  classified  as  Data
      stream  reads  (for  more  information  on  DCJ11  bus  cycles  and data
      classification see the DCJ11 data sheet EK-26921-00)

      Request reads are reads that the DCJ11 will attempt when doing  internal
      cycles  such  as  register transfers.  This is an attempt at filling the
      DCJ11 4 stage pipeline.  Demand reads are reads that must  be  completed
      in  order  to  finish an instruction.  The DCJ11 will always try to keep
      the pipeline full by doing request reads, but will do  demand  reads  as
      necessary.

      The most typical FPJ11 operation is the  common  FP11  instruction  that
      reads some data from memory, operates on it, then writes the result back
      to memory.  In this operation, the FPJ11 monitors the DCJ11  bus  cycles
      for  either  type  of  instruction stream read.  When the FPJ11 sees any
      type  of  Instruction  stream  read,  it  latches  the  data  from   the
      data/address  lines (DAL) and holds it in its instruction register.  The
      FPJ11 keeps doing this until it sees the DCJ11 indicate that it  is  now
      doing  a  instruction  decode by the assertion of the DCJ11 signal PRDC.
      The FPJ11 then does a parallel decode of the instruction and  checks  if
      it  is  a  floating  point  instruction.   If  the  instruction is not a
      floating point instruction, the FPJ11 'goes to sleep' and  continues  to
      latch  all  I-stream  read data.  If the instruction is a floating point
      instruction, the DCJ11 will initiate all bus cycles while the FPJ11 will
      remove  data  from  the  bus.  The FPJ11 will then do the floating point

                                  387

uNOTE # 040
Page 4 of 4


      operation.  If the operation is a store type operation  the  DCJ11  will
      initiate the bus write operation signaling to the FPJ11 to write data to
      memory.

      When either the source or destination of the floating point  instruction
      is  a  DCJ11 general purpose register, a GP cycle will be used to access
      the DCJ11 register.  Load type operations  would  use  the  GPWRITE  bus
      cycle  to write the contents of the DCJ11 register to the FPJ11.  GPREAD
      operations are used to read data from the FPJ11 and deposit it into  the
      DCJ11 general purpose registers.

      Because of  the  overlapping  instruction  capability,  the  DCJ11/FPJ11
      combination  can  start  to  fetch  operands  for  a next floating point
      operation while one is executing.  Because there is  a  single  datapath
      internal  to  the  FPJ11,  this  prefetched  data  must  not  get to the
      execution unit until the current operation is finished.  The FPJ11  will
      output  FPA-STL  to  the  DCJ11  if  the  current  operation will not be
      completed before all of the data is ready.   This  mechanism  guarantees
      that the datapath will only be used by one floating point operation at a
      time.  When the FPJ11 is done with the current operation  the  DCJ11  is
      continued, and the floating point operation proceeds.
































                                  388
    

================================================================================
Note 41.0            Device Ordering Chart for Q-bus Systems          No replies
FURILO::JACKSON "If you've got straight trousers, " 353 lines  13-FEB-1986 00:27
--------------------------------------------------------------------------------



      +---------------+                                    +-----------------+
      | d i g i t a l |                                    |  uNOTE # 041    |
      +---------------+                                    +-----------------+

                                                                   
      +----------------------------------------------------+-----------------+
      | Title:  Device Ordering Chart for Q-bus Systems    | Date: 16-Sep-85 |
      +----------------------------------------------------+-----------------+
      | Originator:  Jack Howes and Peter Kent             | Page 1 of 6     |
      +----------------------------------------------------+-----------------+


                       Primary Device Ordering Determination
                       -------------------------------------

      DMA devices as well as interrupt  devices  on  the  Q-bus  are  position
      dependant.  That means that the order in which devices are placed in the
      bus relative  to  the  CPU  determines  in  what  order  their  DMA  (or
      interrupt) requests will be serviced.

      The primary factor in determining the device  sequencing  order  is  the
      length  of  time  that each device can wait to become bus master without
      error.  These errors normally occur  when  a  controller's  data  buffer
      fills  to  capacity  before  the device connected to it has finished its
      transfer.  Generally, the cause of this is a higher priority device  (or
      devices)  transferring data over the Q-bus, and the controller that gets
      the error is blocked from becoming  bus  master.   Characteristics  that
      influence  whether  a  device  will  fail in this way are:  the on board
      buffer size that  a  controller/device  has,  the  intelligence  of  the
      controller/device, and the transfer speed of the device connected to the
      controller.


                                    Methodology
                                    -----------

      There has been an in-house test instrument developed  which  can  detect
      the  failure  of  Q-bus  devices when they cannot get bus service.  This
      measurement is the length of time a device can  wait  before  getting  a
      data  late  or  device  timeout  error.   The  test  instrument  can  be
      programmed to hold the Q-bus, per acquisition, for any  time  between  1
      microsecond  and  3.9  milliseconds.   It  runs  in conjunction with the
      device under test.  During the test process the length of time the  test
      instrument  holds the Q-bus is varied until the device under test fails.
      This measurement is called "latency tolerance".  Holding the  Q-bus  for
      3.9  milliseconds is equivalent to the test instrument transferring 4095
      words (non-block mode DMA) per assertion of BSACK.






                                  389

uNOTE # 041
Page 2 of 6


                      Secondary Device Ordering Determination
                      ---------------------------------------

      The large buffer sizes and intelligence built into  some  of  the  newer
      controllers  make  them less susceptible to data late or device time out
      errors.  These devices do not get an error waiting for the Q-bus  up  to
      3.9 milliseconds and consequently are ordered by other criteria:


      1.  The type of Q-bus transfer they do (block mode, burst mode or single
          cycle).    See   MicroNote  #12  for  a  description  of  Q-bus  DMA
          transaction types.

      2.  If interrupted by a lower priority DMA device  will  they  pass  the
          Q-bus (DMG) grant signal, when they are doing a blockmode transfer.

      3.  The effect the ordering has on device and system performance.

      4.  The power consumption and/or cabling requirements of the device.


                                     Examples:
                                     ---------

       o  A magtape advertised as a "streaming" tape drive may not  stream  if
          it  is  assigned  a  lower  priority  than  a device that utilizes a
          significant amount of bus time.  In this  instance  the  tape  drive
          will  be  ordered  ahead  of  a device that it would normally follow
          according to its latency tolerance.

       o  A device that consumes a substantial amount of power may have to  be
          configured  in  an  expander  box  with  another  power  supply  for
          practical reasons, even though this device  would  normally  precede
          other devices.


      The following pages contain the recommendations for the order of devices
      on  the Q-bus.  Also contained in these pages are the measurements taken
      and the reasons for suggesting the guidelines.  This ordering  table  is
      only a guideline for Q-bus system configurations, and it should be noted
      that a system will work satisfactorily in many other  configurations  as
      well.   Additionally,  customers  may alter the configurations to better
      meet their specific application needs.

      The measurement process to determine the device sequence chart has  been
      an evolving one and as such not all the devices on the chart contain the
      same data.  The measurements on this chart were only true for the system
      that they were measured on.  These measurements will vary from system to
      system dependent upon the memory type, system  architecture  (mapped  or
      unmapped  DMA)  and  the  speed  of  each  CPU's  arbitrator logic.  The
      variations in measurements that  can  occur  between  CPU's  should  not
      theoretically effect the bus placement of each device.

                                  390

                                                           uNOTE # 041
                                                           Page 3 of 6


      Table 1 lists the order in which devices should be placed in the  Q-bus.
      Please  refer to the detailed information about each device that follows
      the table.

                                      Table 1
                                      -------

      1.  TSV05 9 track magtape controller
      2.  DMV11 Microprocessor controlled DECnet communications interface
      3.  TQK25 Controller for 8 inch magtape drive
      4.  DHV11 Microprocessor controlled communications multiplexor
      5.  DEQNA Ethernet controller
      6.  TQK50 Controller for single spindle cartridge magtape
      7.  RLV12 Controller for 14 inch RL series disk drives
      8.  RQDX3 Controller for 5 1/4 inch RD/RX drives
      9.  KDA50 Controller for 14 inch RA series disk drives
     10.  RQC25 Controller for 8 inch RC25 series disk drives
     11.  RQDX2 Controller for 5 1/4 inch RD/RX drives
     12.  DRV11-WA General purpose 22 bit DMA interface



      Table 2 lists the transfer time and time between requests for  DATI  and
      DATO cycles and latency tolerance.  All times are microseconds.





























                                  391

uNOTE # 041
Page 4 of 6


                                      Table 2
                                      -------


      +--------+-------------+----------------+--------------+----------+
      | Device |  No. words  |  Transfer time | Time between | Latency  |
      |        | transferred |   DATI |  DATO |   requests   | tolerance|
      |        |             |        |       | DATI |  DATO |          |
      +--------+-------------+--------+-------+------+-------+----------+
      | TSV05  |  1 word     |   2.8  |  2.8  |     8.7      |    12    |
      +--------+-------------+--------+-------+--------------+----------+
      | DMV11  |  1 word     |   3.1  |  3.1  |280 @ 56 Kbits|    175   |
      +--------+-------------+--------+-------+--------------+----------+
      | TQK25  |  4 word     |   5.1  |       |              |          |
      |        |  block mode |        |       |              |          | 
      |        +-------------+--------+-------+--------------+    280   |
      |        | 4 W single  |        |  7.25 |              |          |
      |        | & burst mode|        |       |              |          |
      +--------+-------------+--------+-------+--------------+----------+
      | DHV11  |  1 word     |   2.15 |  2.15 |              |   1200   |
      +--------+-------------+--------+-------+------+-------+----------+
      | DEQNA  |  16 word    |  11.78 | 13.87 | 5.1  |  5.1  |  = or >  |
      |        |  block mode |        |       |      |       |   3900   |
      +--------+-------------+--------+-------+------+-------+----------+
      | TQK50  |    4 word   |   9.49 | 10.7  |24.35 | 20.63 |  = or >  |
      |        |    burst    |        |       |      |       |   3900   |
      +--------+-------------+--------+-------+------+-------+----------+
      | RLV12  |  4 word     |   7.09 |  7.8  | 5.92 |  5.7  |  = or >  |
      |        |   burst     |        |       |      |       |   3900   |
      +--------+-------------+--------+-------+------+-------+----------+
      | RQDX3  |  16 word    |  13.5  | 12.7  | 4.48 |  4.48 |  = or >  |
      |        |  block mode |        |       |      |       |   3900   |
      +--------+-------------+--------+-------+------+-------+----------+
      | KDA50  |  8 word     |   9.0  |  8.9  | 6.68 |  6.68 |  = or >  |
      |        |  block mode |        |       |      |       |   3900   |
      +--------+-------------+--------+-------+------+-------+----------+
      | RQC25  |  2 X 8 word |  14.84 | 16.52 |15.41 | 14.41 |  = or >  |  
      |        |  block mode |        |       |      |       |   3900   |
      +--------+-------------+--------+-------+------+-------+----------+
      | RQDX2  |  16 word    |  15.23 | 15.48 | 1.7  |  1.7  |  = or >  |
      |        |  block mode |        |       |      |       |   3900   |
      +--------+-------------+--------+-------+------+-------+----------+
      |DRV11-WA|  4 word     |   6.6  |  7.0  | 0.17 |  0.17 |  = or >  |
      |        |  burst      |        |       |      |       |   3900 * |
      +--------+-------------+--------+-------+------+-------+----------+

      * for DEC/X11 only






                                  392

                                                           uNOTE # 041
                                                           Page 5 of 6


                           Additional device information
                           -----------------------------

                                       TSV05
                                       -----

      This device does not do 16 word block transfer so it doesn't monitor the
      Q-bus BDMR (DMA request line) signal.

                                       DMV11
                                       -----

      This device does not do 16 word block transfers, so it  doesn't  monitor
      the Q-bus BDMR signal.

      Latency Tolerance was determined while running DECNET on a uVAX-I.   The
      following  error  occurred  when the DMV11 was held off the bus for more
      than 175us:  "COPYEOPENIN RMS-F-SYS, QIO Request  Failed,  SYSTEM-F-LINK
      exit".

                                       TQK25
                                       -----

      This device does not do 16 word block transfers, so it  doesn't  monitor
      the Q-bus BDMR signal.

                                       DHV11
                                       -----

      This device does not do 16 word block transfers, so it  doesn't  monitor
      the  Q-bus  BDMR  signal.   It performs DMA on output to the controller,
      however is interrupt  driven  when  accepting  data  from  the  attached
      asynchronous lines.

                                       DEQNA
                                       -----

      This device monitors Q-bus BDMR signal and passes grant when interrupted
      by  a  lower priority device.  This device is placed relatively close to
      the CPU because it cannot quickly recover from bus  latency  conditions.
      Re-transfers over the ethernet are costly in system resources.

                                       TQK50
                                       -----

      This device does not do 16 word block transfers, so it  doesn't  monitor
      the Q-bus BDMR signal.

      While this tape drive has a high latency tolerance, it should be  placed
      in  front  of the other devices that utilize a significant amount of bus
      time.  Doing this enhances its ability to stream data.


                                  393

uNOTE # 041
Page 6 of 6


                                       RLV12
                                       -----

      This device does not do 16 word block transfers so  it  doesn't  monitor
      the  Q-bus  "BDMR" signal.  It is configured in this position because of
      its ability to avoid bus latency conditions even though  it  doesn't  do
      block mode transfers.

                                       RQDX3
                                       -----

      This device monitors BDMR and passes grant when interrupted by  a  lower
      priority  device.   This device may have to be placed as the last device
      in the CPU box because of cabling requirements.

                                       KDA50
                                       -----

      Instead of monitoring BDMR, the KDA50 does an eight word block  transfer
      and  releases  the  bus between transfers to allow other devices access.
      Although this device works more efficiently before the RQDX2  and  RC25,
      it  may  have to be configured in an expansion box due to its high power
      consumption.

                                       RQC25
                                       -----

      This device does not monitor BDMR.  It performs  two  consecutive  eight
      word block transfers, during which it will not pass the grant to a lower
      priority device.

                                       RQDX2
                                       -----

      This device monitors BDMR however it does not  pass  grant  to  a  lower
      priority  device  when  interrupted.   It  holds  the Q-bus from a lower
      priority device for 288us average.  In a dual expander box  system  this
      device  may  have  to  be  configured  in the first expansion box due to
      cabling requirements.

                                      DRV11-WA
                                      --------

      This device does not do 16 word block transfers so  it  doesn't  monitor
      the Q-bus BDMR signal.  The DRV11-WA may "monopolize" the bus if traffic
      to/from the device is sufficiently high.  The placement of  this  device
      is  very  dependent  upon  the  customers  application.  For DEC/X11 and
      diagnostic testing it should be configured as the  last  device  on  the
      Q-bus.




                                  394
    

================================================================================
Note 42.0                 Software Features Comparison                No replies
RENKO::PROPPER                                      232 lines  16-JUL-1986 10:14
--------------------------------------------------------------------------------
      +---------------+                                    +-----------------+
      | d i g i t a l |                                    |  uNOTE # 042    |
      +---------------+                                    +-----------------+

                                                                   
      +----------------------------------------------------+-----------------+
      | Title: Software Features Comparison                | Date: 20-MAY-86 |
      +----------------------------------------------------+-----------------+
      | Originator: Dave Smith                             | Page 1 of 4     |
      +----------------------------------------------------+-----------------+


      Digital offers different operating system solutions for different  needs
      and  applications.   The  operating systems described here are the major
      systems in use today on Q-bus "super-microcomputer" systems.  The charts
      are  subdivided  into  32-bit  and  16-bit  operating  systems.  Various
      attributes are listed and information about the characteristics of  each
      are provided.


      This MicroNote is  meant to be a  guide to  selecting the best operating 
      system  for  your  particular   application.   It  is  not  meant  as  a 
      comprehensive  list  of  all  features.   Refer to the  Software Product 
      Descriptions (SPDs) for more details and support information.






























                                  395

uNOTE # 042
Page 2 of 4

                                Comparison of DIGITAL's
                                32-bit System Software


                             MicroVMS          ULTRIX-32m       VAXELN
     +--------------------+-----------------+---------------+-------------+
     |  Real Time         |        Y        |       N       |      Y      |
     +--------------------+-----------------+---------------+-------------+
     |  General Purpose   |        Y        |       Y       |      N      |
     +--------------------+-----------------+---------------+-------------+
     |  Multitasking      |        Y        |       Y       |      Y      |
     +--------------------+-----------------+---------------+-------------+
     |  Multiuser         |        Y        |       Y       |     N/A     |
     +--------------------+-----------------+---------------+-------------+
     |  File System       |    Files-11     |  4.2 BSD      |  Files-11   |
     |                    |    (ODS-2)      | Fast File Sys.|  (ODS-2)    |
     |                    |                 |               |  See Note 1 |
     +--------------------+-----------------+---------------+-------------+
     |  User Interface    |      DCL,       |   C, Bourne   |     N/A     |
     |                    |      MCR,       |    shells     |             |
     |                    |    DEC/Shell    |               |             |
     +--------------------+-----------------+---------------+-------------+
     |  Editor(s)         |      EDT,       |    ed, vi,    |     N/A     |
     |                    |     VAXTPU,     |    others     |             |
     |                    |     others      |               |             |
     +--------------------+-----------------+---------------+-------------+
     |  Languages         |      MANY       |      C,       | Pascal, C   |
     |  Commonly Used     |                 |     MANY      | ADA, others |
     +--------------------+-----------------+---------------+-------------+
     |  Communications    |  DECnet,        |    TCP/IP,    |   DECnet    |
     |                    |  SNA (gateway), |    UUCP,      |             |
     |                    |  2780/3780,     |    DECnet     |             |
     |                    |  3270 etc.,     |               |             |
     |                    |  TCP/IP, X.25   |               |             |
     +--------------------+-----------------+---------------+-------------+
     |  Layered Products  |      Many       |     Some      |    Some     |
     +--------------------+-----------------+---------------+-------------+
     |  Included Software |      Some       |     Many      |    N/A      |
     +--------------------+-----------------+---------------+-------------+
     |  Program Dev.      |                 |               |             |
     |  Support           |        Y        |       Y       |     N       |
     +--------------------+-----------------+---------------+-------------+
     |  Dev. Hosts        |    VMS,uVMS     | ULTRIX family,|  VMS,uVMS   |
     |                    |                 | other UNIX    |             |
     +--------------------+-----------------+---------------+-------------+
     |  Debugging         |     DEBUG       |      DBX      |   EDEBUG    |
     +--------------------+-----------------+---------------+-------------+
     |  Minimum Memory    |      1 MB       |      2 MB     |   256 KB    |
     |                    |     (2 MB       |               |             |
     |                    |  recommended)   |               |             |
     +--------------------+-----------------+---------------+-------------+
     |  ROMable           |       N         |       N       |     Y       |
     +--------------------+-----------------+---------------+-------------+

                                  396

                                                           uNOTE # 042
                                                           Page 3 of 4

                                Comparison of DIGITAL's
                                    16-bit Software


               MicroPower/Pascal  RT-11    MicroRSX   MicroRSTS  ULTRIX-11
     +-----------------+-------+--------+------------+------+------------+
     |Real Time        |   Y   |   Y    |     Y      |  N   |     N      |
     +-----------------+-------+--------+------------+------+------------+
     |General Purpose  |   N   |   Y    |     Y      |  Y   |     Y      |
     +-----------------+-------+--------+------------+------+------------+
     |Multitasking     |   Y   |   Y    |     Y      |  Y   |     Y      |
     +-----------------+-------+--------+------------+------+------------+
     |Multiuser        |   N   |   N    |     Y      |  Y   |     Y      |
     +-----------------+-------+--------+------------+------+------------+
     |                 |       |        |            |      |       *    |
     |File System      | RT-11 | RT-11  |  Files-11  | RSTS |   UNIX     |
     |                 |       |        |  (ODS-1)   |      |            |
     +-----------------+-------+--------+------------+------+------------+
     |User Interface   | N/A   |  DCL   |  MCR,DCL   | DCL, |  Bourne,   |
     |                 |       |        |            | CCL  |  C shell   |
     +-----------------+-------+--------+------------+------+------------+
     |Editor(s)        | N/A   |KED,KEX |  EDI,EDT   | EDT  |  ed, vi    |
     +-----------------+-------+--------+------------+------+------------+
     |Languages        |PASCAL,| MACRO, |  FORTRAN,  |BASIC,|    C,      |
     |Commonly Used    |MACRO  | FORTRAN|  MACRO,    |Others|  Others    |
     |                 |       |        |  Others    |      |            |
     +-----------------+-------+--------+------------+------+------------+
     |Communications   |X.25,  | DECnet |DECnet, SNA |DECnet|   UUCP,    |
     |                 |serial |        |(gateway),  |      |  TCP/IP    |
     |                 |       |        |2780/3780,  |      |            |
     |                 |       |        |3270, X.25  |      |            |
     +-----------------+-------+--------+------------+------+------------+
     |Layered Products | N/A   | Some   |   Many     | Many |   Some     |
     +-----------------+-------+--------+------------+------+------------+
     |Included Software| N/A   | Some   |   Some     | Some |   Many     |
     +-----------------+-------+--------+------------+------+------------+
     |Program Dev.     |       |        |            |      |            |
     |Support          |  N    |   Y    |     Y      |  Y   |     Y      |
     +-----------------+-------+--------+------------+------+------------+
     |Dev. Hosts       |RT,RSX |RT,RSX  |  RSX,VMS,  | RSTS |ULTRIX fam.,|
     |                 | VMS   |VMS,RSTS|    RSTS    |      |other UNIX  |
     +-----------------+-------+--------+------------+------+------------+
     |Debugging        |PASDBG | ODT,   |     ODT,   | ODT, |    ADB     |
     |                 |       | MACDBG |  SYMBOLIC  |SYMBL.|            |
     +-----------------+-------+--------+------------+------+------------+
     |Minimum Memory   |  8KB  | 16KB   |   512KB    |256KB |   256KB    |
     |                 |       |        |            |      | See Note 2 |
     +-----------------+-------+--------+------------+------+------------+
     |ROMable          |   Y   |    N   |     N      |  N   |     N      |
     +-----------------+-------+--------+------------+------+------------+




                                  397

                                                           uNOTE # 042
                                                           Page 4 of 4



        NOTE 1:
                
                The ODS-2 Files-11 on VAXELN does not support ISAM files.


        NOTE 2:

                The 256KB minimum memory requirement for ULTRIX-11 requires
                extreme limitations in functionality.  Consult the SPD for
                details.

         *
          UNIX is a Trademark of AT&T Bell Labs







































                                  398

================================================================================
Note 43.0                  RQDX Controller Status/Info                No replies
FURILO::PROPPER                                     819 lines  13-AUG-1986 15:04
--------------------------------------------------------------------------------
      +---------------+                                    +-----------------+
      | d i g i t a l |                                    |  uNOTE # 043    |
      +---------------+                                    +-----------------+

                                                                   
      +----------------------------------------------------+-----------------+
      | Title: RQDX CONTROLLER STATUS/INFORMATION          | Date: 10-Jun-86 |
      +----------------------------------------------------+-----------------+
      | Originator: JACK TOTO                              | Page 1 of 14    |
      +----------------------------------------------------+-----------------+

      This MicroNote contains a collection of data and charts which will allow
      users to match the correct RD/RX controller and firmware revision to his
      system/CPU, as well as compatibility of disk formatting  software.   All
      chart  compatibilities  were  developed  using  the  latest  versions of
      operating system software available  as  of  the  date  posted  on  this
      MicroNote.   The  MicroNote  is divided into 4 sections, one for each of
      the controllers as outlined below.


                I. RQDX1
                    A. RQDX1 History
                    B. RQDX1 Firmware
                    C. RQDX1 Compatibility
                         1. Controller/TYU Upgrades
                         2. System Upgrade Examples

                II. RQDX2
                     A. RQDX2 History
                     B. RQDX2 Firmware
                     C. RQDX2 Compatibility

                III. RQDX3
                      A. RQDX3 History
                      B. RQDX3 Firmware
                      C. RQDX3 Compatibility
                          1. Controller/CPU Upgrades
                          2. System Upgrade Examples

                IV. Compatibility Charts
                      A. RQDX1
                      B. RQDX2
                      C. RQDX3








                                  399

uNOTE # 043
Page 2 of 14


      I. RQDX1 HISTORY:
      -----------------


      The   first   version   of   RQDX1   micro-code   (version   7.0)    had
      incompatibilities   with  RX50  diskettes/drives  transported  from  one
      machine to another, this was noted and  changed  with  ECO  (Engineering
      Change  Order)  M8639-ML002  dated  June  1984.   The new ROM micro-code
      became known as Version 8.0.


      When the RD52 was announced, the same controller was  to  be  used  with
      these  drives,  but the firmware obviously needed to be changed in order
      to recognize this new drive.  The new micro-code for  the  RD52s  became
      known as version 9.0, and was documented in ECO M8639-ML004.


      The RQDX1 later underwent another ECO that allowed it to be resident  in
      any  Q-bus  slot after the CPU.  This ECO involved changes in etch work,
      micro-code and nomenclature.  The  controller  name  and  module  number
      changed  from  the  RQDX1  with  module  number  M8639-YA stamped on the
      handles, to the RQDX2 with module number M8639-YB stamped on the handle.
      The  firmware  revision became known as version 9.4E, and was compatible
      with the RX50 and RD5n (n = 1, 2, 3) series devices.


      RQDX1 FIRMWARE:
      ---------------
      The RQDX1 has had three revisions to its firmware.  The ROM part numbers
      for  the  RQDX1  controller  are listed below.  The two ROM part numbers
      represent the low and high byte pieces of micro-code, and both parts are
      needed when upgrading a system from one level to the next.  The low byte
      ROM is installed in socket E106 and the high byte ROM  is  installed  in
      socket E105.  Refer to the RQDX1 maintenance prints (PN MP-01731-01) for
      the location of those sockets.


       Version 7.0 ROMs  For RQDX1 Support of The RX50 and RD51:
                             23-238E4-00 for the low byte ROM.
                             23-239E4-00 for the high byte ROM.

       Version 8.0 ROMs  For RQDX1 Support of The RX50 and RD51:
                             23-264E4-00 for the low byte ROM.
                             23-265E4-00 for the high byte ROM.

       Version 9.0 ROMs  For RQDX1 Support of The RX50 and RD51/52:
                             23-042E5-00 for the low byte ROM.
                             23-043E5-00 for the high byte ROM.





                                  400

                                                           uNOTE # 043
                                                          Page 3 of 14


      RQDX1 COMPATIBILITY 
      -------------------


                          CONTROLLER/CPU UPGRADES: 
                          ------------------------
      It is important to note that when upgrading either the CPU or the  RX/RD
      controller,  that  you  change the firmware on both of the modules.  For
      example if your current system is  a  MicroPDP-11/23  with  version  8.0
      firmware   on  both  the  CPU  and  the  controller,  your  system  will
      successfully boot an RD51 as a fixed device in the system.  If you  wish
      to  upgrade  your  system  to allow for the usage of a larger fixed disk
      (RD52), you will need to upgrade the ROMs on the RQDX1 from version  8.0
      to version 9.0 (see RQDX1 HISTORY for actual part numbers).  However due
      to some timing considerations the ROMs on the CPU card  should  also  be
      changed  to  version  9.0 (this will change the CPU from a KDF11-BE to a
      KDF11-BF).  Further the formatter used with the  newer  micro-code  will
      not be the same as the one used for the older micro-code.  To obtain the
      proper formatter file name, refer to the chart below.


             SYSTEM UPGRADE EXAMPLES:
             ------------------------

                          VERSION 7.0/8.0 SYSTEM
                          ----------------------
      CPU ROMs: (KDF11-BE)                RQDX1 ROMs:
          23-158E4-00                           23-238E4-00   {version 7.0}
          23-159E4-00                           23-239E4-00   

                                             -- OR --
                                                
                                                23-264E5-00   {version 8.0}
                                                23-265E5-00


                          VERSION 9.0/9.4E SYSTEM
                          -----------------------
      CPU ROMs: (KDF11-BF)                RQDX1 ROMs
          23-183E4-00                           23-042E5-00   {version 9.0}
          23-184E4-00                           23-043E5-00   {RQDX1      }

                                             -- OR --

                                                23-172E5-00   {version 9.4E}
                                                23-173E5-00   {RQDX2       }







                                  401

uNOTE # 043
Page 4 of 14


      II. RQDX2 HISTORY:
      ------------------
      As mentioned above, the RQDX1 controller became the RQDX2 with an ECO to
      the board itself and a change to the firmware allowing it to support the
      latest mass storage devices on MicroPDP-11s and  MicroVAX  I's  (RD52s).
      The  announcement  day (MicroVAX II) ROMs (version 10.0D) were available
      to be used with the RD53s, and have been upgraded once, to  the  version
      10.0E  micro-code.   These two versions of the firmware will boot any of
      the RD devices available for the MicroPDP-11s or the MicroVAXs.


      RQDX2 FIRMWARE:
      ---------------
      The RQDX2 has had three revisions to its firmware.  The ROM part numbers
      for  the  RQDX2  controller  are listed below.  The two ROM part numbers
      represent the low and high byte pieces of micro-code, and both parts are
      needed when upgrading a system from one level to the next.  The low byte
      ROM is installed in socket E106 and the high byte ROM  is  installed  in
      socket E105.  Refer to the RQDX2 maintenance prints (PN MP-01731-01) for
      the location of those sockets.


        Version 9.4E ROMs For RQDX2 Support With The RX50 and RD51/52:
                              23-172E5-00 for the low byte ROM.
                              23-173E5-00 for the high byte ROM.

        Version 10.0D ROMs For RQDX2 Support With The RX50 and RD51/52/53:
                              23-178E5-00 for the low byte ROM.
                              23-179E5-00 for the high byte ROM.

        Version 10.0E ROMs For RQDX2 Support With The RX50 and RD51/52/53:
                              23-188E5-00 for the low byte ROM.
                              23-189E5-00 for the high byte ROM.


      RQDX2 COMPATIBILITY 
      -------------------

                          CONTROLLER/CPU UPGRADES:
                          ------------------------
      It is important to note that when upgrading either the CPU or the  RX/RD
      controller,  that  you  change the firmware on both of the modules.  For
      example if your current system is a MicroPDP-11/23 with version  9.0  or
      firmware  on the CPU and version 9.0 or 9.4E firmware on the controller,
      your system will successfully boot an RD52 as  a  fixed  device  in  the
      system.   If you wish to upgrade your system to allow for the usage of a
      larger fixed disk (RD53), you will need to upgrade the ROMs on the RQDX2
      from  whatever version you currently have to version 10.0D.  This change
      will further require that the CPU be able to boot  the  RD53.   If  your
      system is a MicroPDP-11, the user will need install the KDF11-B3 ROM set
      installed on the CPU.  If the user's system is a MicroVAX II the  system
      ROMs on the KA630 CPU module will boot the RD53.  Finally, the formatter

                                  402

                                                           uNOTE # 043
                                                          Page 5 of 14


      used with the newer/upgraded micro-code will not be the same as the  one
      used  for  the  older  micro-code.   To  obtain  the  correct  formatter
      filename, refer to the chart below.


             SYSTEM UPGRADE EXAMPLES:
             ------------------------


                          VERSION 9.0/9.4E SYSTEM
                          -----------------------
      CPU ROMs: (KDF11-BF)                RQDX1/2 ROMs:
          23-183E4-00                           23-042E4-00   {version 9.0}
          23-184E4-00                           23-043E4-00   {RQDX1      }

                                             -- OR --
                                                
                                                23-172E5-00   {version 9.4E}
                                                23-173E5-00   {RQDX2


                          VERSION 10.0D/10.0E SYSTEM
                          --------------------------
      CPU ROMs: (KDF11-BH)                RQDX2 ROMs
          23-380E4-00                           23-178E5-00   {version 10.0D}
          23-381E4-00                           23-179E5-00   {RQDX2        }

                                             -- OR --

                                                23-188E5-00   {version 10.0E}
                                                23-189E5-00   {RQDX2        }

      III. RQDX3 HISTORY:
      -------------------
      The RQDX3 is the enhanced version of  the  RQDX  family  of  MSCP  RX/RD
      device  controllers.   Disks previously formatted on RQDX1/2 controllers
      will not be compatible with the RQDX3 controller.   The  RQDX1/2  stores
      the  disk geometry information in ROM while the RQDX3 stores the data on
      the disk itself and reads in the track that  contains  this  information
      during  the  power  up sequence.  Further the RQDX3 uses a 17 sector per
      track format while the RQDX1/2 uses  an  18  sector  per  track  format.
      There  are  also a few performance enhancements to the RQDX3 that add to
      its preference as a disk controller over the older versions, those being
      a  1:1  disk  interleaving  versus  3:1  interleaving  for  the  earlier
      controllers, an elevator seek reordering algorithm is used as well as an
      algorithm to handle overlapped seeks when multiple RD5ns are resident in
      a system.  Further the problem that  existed  with  the  RQDX2  hold-off
      timer  has been fixed on the RQDX3 by increasing the length of the timer
      so as not to steal DMA grants from a second RX/RD  controller  or  other
      DMA devices in the system.



                                  403

uNOTE # 043
Page 6 of 14


      RQDX3 FIRMWARE:
      ---------------
      The RQDX3 has had only one firmware  version  to  date.   The  ROM  part
      numbers  for  the  RQDX3  controller are listed below.  The two ROM part
      numbers represent the low and high byte pieces of micro-code,  and  both
      parts  are  needed  when  upgrading a system from one level to the next.
      The low byte ROM is installed in socket E22 and the  high  byte  ROM  is
      installed  in socket E21.  Refer to the RQDX3 maintenance prints for the
      location of those sockets.


        VERSION 1.10 ROMs 23-216E5-00 for the low byte ROM.
                          23-217E5-00 for the high byte ROM.


      RQDX3 COMPATIBILITY:
      -------------------

                          CONTROLLER/CPU UPGRADES:
                          ------------------------
      It should be noted that whenever you upgrade your system  by  adding  an
      RQDX3 controller in place of an RQDX1/2 that the disks (RD51/52/53) will
      have to be reformatted using the newest XXDP+  or  MDM  formatter.   The
      disks  are  NOT  forward compatible as they were when upgrading with the
      two earlier controllers.  Along with this controller  upgrade  the  user
      SHOULD  upgrade his CPU.  If your system is a MicroPDP-11, the user will
      need to install the KDF11-B3 ROM set on the CPU module.   If  the  users
      system  is  a  MicroVAX  II the system ROMs on the KA630 CPU module will
      boot the RD53.


             SYSTEM UPGRADES EXAMPLES:
             -------------------------

                          VERSION 1.10 SYSTEM
                          -------------------
      CPU ROMs: (KDF11-BF)                RQDX3 ROMs:
          23-183E4-00                           23-216E5-00   {version 1.10}
          23-184E4-00                           23-217E5-00   

       -- OR --
       
      CPU ROMs: (KDF11-BG)
          23-380E4-00
          23-381E4-00    








                                  404

                                                           uNOTE # 043
                                                          Page 7 of 14


      IV. COMPATIBILITY CHART: 
      ------------------------ 
      When using any of  the  RQDX*  compatibility  charts  find  the  correct
      controller  type (RQDX1/2/3) and revision level.  Then follow any of the
      connected lines from that point, any of the devices that are on the line
      are  compatible,  any  of  the  devices  not  connected by the lines are
      obviously not compatible.  The formatters  for  PDP-11  systems  can  be
      found  either  in  the  XXDP+ diagnostics package or on the set of RX50s
      that ship with the system.  It is the specific diagnostic  routine  that
      is listed in the column under formatter.  The formatter for MicroVAX I's
      and II'S are found either in the MDM diagnostic package for MicroVAX  II
      and  on  the RX50s that come with the MicroVAX I system.  The RX50s that
      come with the MicroVAX II contain NO formatter and the MDM package  must
      be  obtained.   It  is  possible  to take the unformatted drive to Field
      Service and have them format the disk.


      The charts are outlined as follows:


             A. RQDX1
                 1. Version 7.0
                 2. Version 8.0
                 3. Version 9.0
             B. RQDX2
                 1. Version 9.4E
                 2. Version 10.0D
                 3. Version 10.0E
             C. RQDX3
                 1. Version 1.10




                                        NOTE

              There are no diagnostics  that  are  available  for  the
              RQDX3  on  a MicroVAX I that is the only reason that the
              RQDX3 is not supportted on a MicroVAX I.














                                  405

uNOTE # 043
Page 8 of 14


       RQDX1:
       -----



       CONTROLLER           CPU                DISK(S)       FORMATTER
       ----------           ---                -------       ---------
                                            

                           KDF11-BE             RD51     ZRQBA0, ZRQBC1
                       +------------------> ---------->  -------------->  
                       |
                       |
                       |
                       |
       RDQX1           |                   
       VERSION 7.0     |   KDJ11-AA             RD51    ZRQBA0, ZRQBC1
      ---------------> +------------------> ----------> -------------->
                       |
                       |
                       |
                       |
                       |
                       |   KDJ11-BA             RD51     ZRQBA0, ZRQBC1
                       +------------------> ---------->  -------------->
                       |
                       |
                       |
                       |
                       |  
                       |   FALCON PLUS          RD51     ZRQBA0, ZRQBC1
                       +------------------> ---------->  --------------> 
                       |
                       |
                       |
                       |
                       |
                       |   MICROVAX I           RD51     SYSTEM DIAGNOSTICS
                       +------------------> ---------->  ------------------>
                                                         EHXRQ

                        











                                  406

                                                           uNOTE # 043
                                                          Page 9 of 14



       CONTROLLER           CPU                DISK(S)       FORMATTER
       ----------           ---                -------       ---------


                                                RD51  
                                            +--------->
                           KDF11-BE         |            ZRQBA0, ZRQBC1 
                       +------------------> |            ------------->
                       |                    |   RD52   
                       |                    +---------> 
                       |
                       |
                       |                        RD51   
                       |                    +---------> 
                       |   KDF11-BF         |            ZRQBA0, ZRQBC1  
                       +------------------> |            -------------->
                       |                    |  RD52  
                       |                    +--------->
                       |
                       |
                       |                        RD51   
       RQDX1           |                    +--------->
       VERSION 8.0     |   KDJ11-AA         |           ZRQBA0, ZRQBC1
      ---------------> +------------------> |           -------------->
                       |                    |   RD52
                       |                    +--------->
                       |
                       |
                       |                        RD51 
                       |                    +--------->
                       |   KDJ11-BA         |            ZRQBA0, ZRQBC1
                       +------------------> |            -------------->
                       |                    |   RD52
                       |                    +--------->
                       |
                       |
                       |                        RD51 
                       |                    +---------> 
                       |   MicroVAX I       |            SYSTEM DIAGNOSTICS
                       +------------------> |            ------------------>
                       |                    |  RD52      EHXRQ
                       |                    +--------->
                       |
                       |
                       |
                       |   FALCON PLUS          RD51     ZRQBA0, ZRQBC1
                       +------------------> ---------->  -------------->





                                  407

uNOTE # 043
Page 10 of 14



       CONTROLLER           CPU                DISK(S)       FORMATTER
       ----------           ---                -------       ---------
                       

                                                RD51 
                                            +--------->  
                           KDF11-BF         |            ZRQCB1, ZRQBC1
                       +------------------> |            -------------->
                       |                    |   RD52
                       |                    +--------->
                       |
                       |
                       |                        RD51 
                       |                    +--------->
                       |   KDF11-BG         |            ZRQCB1, ZRQBC1
                       +------------------> |            -------------->
                       |                    |   RD52
                       |                    +--------->
                       |
                       |
                       |                        RD51 
       RQDX1           |                    +---------> 
       VERSION 9.0     |   KDJ11-AA         |            ZRQBC1, ZRQCB1
      ---------------> +------------------> |            -------------->
                       |                    |   RD52
                       |                    +---------> 
                       |
                       |
                       |                        RD51
                       |                    +--------->
                       |   KDJ11-BA         |            ZRQBC1, ZRQCB1
                       +------------------> |            -------------->
                       |                    |   RD52  
                       |                    +--------->
                       |
                       |
                       |                        RD51 
                       |                    +--------->
                       |   MicroVAX  I      |            SYSTEM DIAGNOSTICS
                       +------------------> |            ------------------>
                       |                    |   RD52     EHXRQ
                       |                    +--------->
                       |
                       |
                       |                        RD51 
                       |                    +--------->  
                       |   MicroVAX  II     |            MDM 1.06 
                       +------------------> |            --------->
                                            |   RD52     MDM 1.08
                                            +--------->


                                  408

                                                           uNOTE # 043
                                                         Page 11 of 14



       RQDX2:
       -----


       CONTROLLER           CPU                DISK(S)       FORMATTER
       ----------           ---                -------       ---------

                                                RD51
                                            +---------->  
                           KDF11-BF         |            ZRQBC1, ZRQCB1
                       +------------------> |            -------------->
                       |                    |   RD52
                       |                    +---------->
                       |
                       |                        RD51     
                       |                    +---------->
                       |   KDF11-BG         |   RD52     ZRQBC1, ZRQCB1
                       +------------------> +----------> -------------->
                       |                    |  RD53
                       |                    +---------->
                       |
                       |                        RD51 
       RQDX2           |                    +---------->
       VERSION 9.4E    |   KDJ11-AA         |   RD52     ZRQBC1, ZRQCB1
      ---------------> +------------------> +----------> -------------->
                       |                    |   RD53
                       |                    +---------->
                       |
                       |                        RD51 
                       |                    +---------->
                       |   KDJ11-BA         |   RD52     ZRQBC1, ZRQCB1
                       +------------------> +----------> -------------->
                       |                    |   RD53
                       |                    +----------> 
                       |
                       |                        RD51 
                       |                    +---------->
                       |   MicroVAX  I      |            SYSTEM DIAGNOSTICS
                       +------------------> |            ------------------>
                       |                    |   RD52     EHXRQ
                       |                    +----------> 
                       |
                       |                        RD51 
                       |                    +---------->
                       |   MicroVAX II      |   RD52     MDM 1.06 
                       +------------------> +----------> -------->
                                            |   RD53     MDM 1.08
                                            +---------->




                                  409

uNOTE # 043
Page 12 of 14



       CONTROLLER           CPU                DISK(S)       FORMATTER
       ----------           ---                -------       ---------


                                                RD51 
                                            +---------->
                           KDF11-BF         |            ZRQBC1, ZRQCB1
                       +------------------> |            -------------->
                       |                    |   RD52
                       |                    +----------> 
                       |
                       |
                       |                        RD51 
                       |                    +---------->
                       |   KDF11-BG         |            ZRQBC1, ZRQCB1
                       +------------------> |            -------------->
                       |                    |    RD52
                       |                    +----------> 
                       |
                       |
                       |                        RD51 
       RQDX2           |                    +---------->  
       VERSION 10.0D   |   KDJ11-AA         |            ZRQBC1, ZRQCB1
      ---------------> +------------------> |            -------------->
                       |                    |   RD52
                       |                    +---------->
                       |
                       |
                       |                        RD51
                       |                    +---------->  
                       |   KDJ11-BA         |            ZRQBC1, ZRQCB1
                       +------------------> |            -------------->
                       |                    |   RD52
                       |                    +----------> 
                       |
                       |
                       |                        RD51 
                       |                    +---------->
                       |   MicroVAX  I      |             SYSTEM DIAGNOSTICS
                       +------------------> |             ------------------>
                       |                    |   RD52      EHXRQ
                       |                    +---------->
                       |
                       |
                       |                        RD51 
                       |                    +---------->
                       |   MicroVAX  II     |             MDM 1.06
                       +------------------> |             -------->
                                            |   RD52      MDM 1.08
                                            +---------->


                                  410

                                                           uNOTE # 043
                                                         Page 13 of 14



       CONTROLLER           CPU                DISK(S)       FORMATTER
       ----------           ---                -------       ---------


                                                RD51 
                                            +---------->
                           KDF11-BF         |            ZRQBC1, ZRQCB1
                       +------------------> |            -------------->
                       |                    |   RD52
                       |                    +---------->
                       |
                       |
                       |                        RD51 
                       |                    +---------->
                       |   KDF11-BG         |            ZRQBC1, ZRQCB1
                       +------------------> |            -------------->
                       |                    |  RD52
                       |                    +---------->
                       |
                       |
                       |                        RD51 
       RQDX2           |                    +---------->
       VERSION 10.0E   |   KDJ11-AA         |            ZRQBC1, ZRQCB1
      ---------------> +------------------> |            -------------->
                       |                    |   RD52
                       |                    +---------->
                       |
                       |
                       |                        RD51 
                       |                    +---------->
                       |   KDJ11-BA         |            ZRQBC1, ZRQCB1
                       +------------------> |            -------------->
                       |                    |   RD52
                       |                    +----------> 
                       |
                       |
                       |                        RD51 
                       |                    +---------->
                       |   MicroVAX  I      |            SYSTEM DIAGNOSTICS
                       +------------------> |            ------------------>
                       |                    |   RD52     EHQRX
                       |                    +---------->
                       |
                       |
                       |                        RD51 
                       |                    +---------->
                       |   MicroVAX  II     |   RD52     MDM 1.06
                       +------------------> +----------> -------->
                                            |   RD53     MDM 1.08
                                            +---------->


                                  411

uNOTE # 043
Page 14 of 14



       RQDX3:
       -----

       
       CONTROLLER           CPU                DISK(S)       FORMATTER
       ----------           ---                -------       ---------

                                                RD51 
                                            +---------->
                           KDF11-BF         |   RD52     ZRQCB1
                       +------------------> +----------> ------>
                       |                    |  RD53
                       |                    +---------->
                       |
                       |
                       |                        RD51    
                       |                    +---------->
                       |   KDF11-BG         |   RD52     ZRQCB1
                       +------------------> +----------> ------>
                       |                    |   RD53
                       |                    +---------->
                       |
                       |
                       |                        RD51 
       RQDX3           |                    +---------->
       VERSION 1.10    |   KDJ11-AA         |   RD52     ZRQCB1
      ---------------> +------------------> +----------> ------>
                       |                    |   RD53
                       |                    +---------->
                       |
                       |
                       |                        RD51    
                       |                    +---------->
                       |   KDJ11-BA         |   RD52     ZRQCB1
                       +------------------> +----------> ------>
                       |                    |   RD53
                       |                    +---------->
                       |
                       |
                       |                        RD51 
                       |                    +---------->
                       |   MicroVAX  II     |   RD52     MDM 1.08
                       +------------------> +----------> -------->
                                            |   RD53
                                            +---------->







                                  412

================================================================================
Note 44.0                 VAX/VMS Realtime Programming                No replies
FURILO::PROPPER                                    1235 lines  13-AUG-1986 15:08
--------------------------------------------------------------------------------
      +---------------+                                    +-----------------+
      | d i g i t a l |                                    |  uNOTE # 044    |
      +---------------+                                    +-----------------+

                                                                   
      +----------------------------------------------------+-----------------+
      | Title:    VAX/VMS REALTIME PROGRAMMING             | Date: 10-Jun-86 |
      +----------------------------------------------------+-----------------+
      | Originator:   Bill Forbes                          | Page 1 of 21    |
      +----------------------------------------------------+-----------------+


      The realtime programmer who faces a VAX/VMS system for  the  first  time
      may  feel  intimidated  by  the  seeming  complexity  of  the  system in
      comparison to, say, PDP-11 systems  running  RT-11  SJ.   In  fact,  the
      program  development  environment under VAX/VMS is very rich, comprising
      many tools, utilities and system services  for  developing  and  running
      realtime application programs.

      The material contained in this application note is intended to help  you
      get  started using some basic VAX/VMS services for realtime programming.
      A more informal title might have been "How to Do  Programmed  I/O  under
      VAX/VMS  without  Writing a Device Driver." Specifically, information is
      presented on two relevant techniques:  accessing the VAX  I/O  page  for
      direct  device  control, and using the connect-to-interrupt driver to do
      interrupt programming.  An emphasis has been placed  on  explaining  the
      principles  underlying the use of these services rather than the details
      of their operation.   A  more  detailed  description  may  be  found  in
      Appendix C of the VAX/VMS Release notes for Version 4.0.  For additional
      copies of these notes or for technical assistance, call  the  Laboratory
      Data Products Hotline at (617) 467-5441.


         1  DIRECT PROGRAM CONTROL OF I/O MODULES UNDER MICROVMS

      The most basic level at which realtime devices can be controlled  is  by
      direct manipulation of the contents of device registers.  Direct control
      of device registers is relatively simple in PDP-11 systems and, in fact,
      is  a  common  programming  technique  for  certain  kinds  of  realtime
      applications.   For  example,  the  following  MACRO-11  code   fragment
      illustrates the acquisition of a single data value from an A/D device.

                 ADCSR   = 770400        ;Address of device CSR
                 ADBUF   = ADCSR+2       ;Address of device buffer

                 MTPS    #340            ;Set processor priority level to 7
                 MOV     #1,ADCSR        ;Set the GO bit to start a conversion
         LOOP:   BIT     #200,ADCSR      ;Test the A/D DONE bit
                 BEQ     LOOP            ;If clear, test again
                 MOV     ADBUF,R0        ;If set, move the data to R0
                 MTPS    #0              ;Drop priority level back to 0


                                  413

uNOTE # 044
Page 2 of 21


      In this example, the processor priority level  is  first  raised  to  7.
      This insures that the processor will execute the subsequent instructions
      without interruption.  An A/D conversion is then  initiated  by  setting
      bit  0 of the device control/status register (CSR).  When the conversion
      is complete, bit 7 of the  CSR  is  set  by  the  device.   The  program
      repeatedly  tests  this  bit until it finds it to be set, then moves the
      data value from the device's  buffer  register  into  a  general-purpose
      processor  register  (or  into a storage location in main memory).  This
      technique is called "polled I/O".

      Since many polled I/O operations require that the processor  be  totally
      dedicated  to  the polling loop, this technique has not been widely used
      on VAX/VMS systems, which typically support multiple tasks or users at a
      time.   However,  the  increasing  use of MicroVAX systems for dedicated
      realtime processing has brought about a demand for polled  I/O  routines
      implemented under MicroVMS.

      As with RT-11 based PDP-11  systems,  improper  manipulation  of  device
      registers in the MicroVAX I/O page can lead to undesirable consequences.
      Generally speaking, direct device control techniques should be  used  to
      manipulate  only  process-dedicated  realtime  option  module registers.
      Inadvertently changing other device register contents may cause a system
      crash or the corruption of a mass storage volume.  You should be sure to
      have a secure backup copy of the system whenever debugging direct device
      control routines.

      To develop polled I/O (or other direct control routines) under MicroVMS,
      two special techniques are called for:


         1.  A means of addressing device registers in the I/O page, and

         2.  A means of raising and lowering the processor priority level.

      This  section  illustrates  the  techniques  used  to  accomplish  these
      operations  in  the  context  of  programs for performing single-channel
      clocked analog input using an AXV11-C analog module and a KWV11-C  clock
      module.


         1.1  Accessing Device Registers In The VAX I/O Page

      On PDP-11  systems  running  the  RT-11  Single-Job  monitor,  accessing
      addresses  in the I/O page involves nothing more than supplying a 16-bit
      address  in  the  range  160000  -  177776  (octal).   Those   addresses
      correspond  to  the  portion  of the physical address space within which
      device registers are defined - the I/O page.  As  with  PDP-11  systems,
      the VAX architecture reserves a region of the physical address space for
      device registers.  For MicroVAXes (I and II)  the  I/O  page  starts  at
      address 20000000 (hex), and is 2000 (hex) bytes in length.



                                  414

                                                           uNOTE # 044
                                                          Page 3 of 21


      Under MicroVMS, the 32-bit virtual address space of the system is mapped
      into physical memory, so that a user-supplied address does not


      ordinarily correspond to any particular physical address.  The  problem,
      then,  is  to  establish  a  means  of  addressing a particular range of
      physical addresses - that is, the MicroVAX I/O page.

      This is accomplished by mapping the physical addresses which  constitute
      the I/O page into a portion of the process's virtual address space.  The
      VMS $CRMPSC system service is used.  The following parameters are passed
      to the $CRMPSC service:


         o  The starting and ending virtual addresses into which  the  section
            is  to  be  mapped;  this virtual address block should be 8K bytes
            long and page-aligned

         o  The starting page frame number of the section to be mapped (a page
            frame  is  a  512-byte block of physical memory); computed as <I/O
            page starting physical address>/512

         o  The number of pages in the section (16 in this case)


      In addition, the $CRMPSC system service accepts a flag  mask  specifying
      the  type  of section to be created, as well as its characteristics.  In
      the present context, the essential flags are SEC$M_PFNMAP and SEC$M_WRT,
      which  define  the  section  as a page frame section with the read/write
      attribute.

      Finally, the call to the $CRMPSC system  service  must  specify  storage
      locations  into  which  the  starting  and ending virtual pages actually
      mapped and the channel number assigned by the system to the section  may
      be  written.   Ordinarily, these data are not used by the programmer and
      need not be elaborated on here.  For a fuller discussion of the  $CRMPSC
      system service, see the VAX/VMS System Services Reference Manual.

      Once the mapped section has been  created,  instructions  which  address
      locations  within  the  virtual address space into which the section has
      been mapped will effectively address the corresponding locations in  the
      I/O  page.  To address a particular device register in the I/O page, the
      absolute offset in the I/O page of the register is  added  to  the  base
      address  of  the virtual address block, yielding a virtual address which
      corresponds to the desired physical address.








                                  415

uNOTE # 044
Page 4 of 21


         1.2  Raising And Lowering Processor Priority Level

      VAX architecture defines 32 interrupt priority levels (IPL 0 - IPL  31).
      At  any  point  in  time,  the  processor will be operating at some IPL,
      usually 0 during execution of user code.  Device interrupts occur at IPL
      20  -  23,  corresponding  to  bus request levels 4 - 7.  On MicroVAXes,
      driver code executes at IPL 23, regardless of the  level  at  which  the
      device  interrupted.   For example, a device interrupt on BR 4 would not
      be granted until the processor priority dropped below 20.  However, when
      the request was granted, the processor priority would be

      set to IPL 23, thus blocking ALL  device  interrupts  until  the  driver
      lowered  the  IPL.  The system timer interrupts at IPL 22 and is granted
      at the same level.

      When the processor is executing code at a low  IPL,  device,  timer,  or
      software  interrupts at a higher IPL can pre-empt the system.  When this
      happens, the processor saves the  context  of  the  currently  executing
      image (program counter, processor status longword) and transfers control
      to the interrupt service routine (ISR).   When  the  ISR  completes  the
      context  of  the pre-empted image is restored and it continues executing
      where it left off (assuming there are no new interrupts pending).  Thus,
      an  image executing at a low IPL may be suspended for various periods of
      time due to the occurrence of interrupts.

      When performing polled I/O it may be  desirable  for  the  processor  to
      respond  as  quickly  as  possible  to the availability of data from the
      device  being  polled.   To  prevent  interrupts  from  distracting  the
      processor  from the polling operation, the polling code must be executed
      at an IPL above that of any device which might  generate  a  pre-emptive
      interrupt.   To accomplish this, the code raises the IPL to 30 using the
      DSBINT system macro.  The value of 30 is chosen to enable  a  power-fail
      interrupt (IPL 31) to be processed, should one occur.  This is advisable
      since allowing the power-fail ISR to execute may prevent  corruption  of
      the  system  device.  Besides, blocking the power-fail ISR will probably
      not salvage the application.

      VAX processor design imposes the restriction that IPL cannot  be  raised
      except  while  the  processor  is operating in kernel mode.  The $CHMKNL
      system service must be invoked to change mode to kernel before executing
      the  DSBINT  macro.   The  polling  code  then  executes in kernel mode.
      Whenever the processor is executing above IPL 2, page faults  are  fatal
      (the system will crash).  Thus, before entering kernel mode, the $LCKPAG
      system service must be called to lock any data areas that are  addressed
      in  the  polling routine into physical memory.  When the polling routine
      completes, the program should restore  the  original  IPL  (usually  0),
      return  to user mode, and, optionally, unlock the pages addressed in the
      polling routine.





                                  416

                                                           uNOTE # 044
                                                          Page 5 of 21


      In summary, the sequence of program steps in performing  polled  I/O  at
      elevated IPL is as follows:

         1.  The I/O page is mapped into process virtual address space using
             the $CRMPSC system service.

         2.  Any required device initialization is performed at IPL 0, user
             mode.

         3.  Any pages addressed in the polling routine are locked into
             physical memory using the $LCKPAG system service.

         4.  The processor mode is changed to kernel using the $CHMKNL system
             service.

         5.  In kernel mode, the IPL is raised to 30.

         6.  The polling code executes and data is moved into a process buffer
             which has been locked into memory (step 3, above).

         7.  When data transfer is complete the IPL is returned to its prior
             value (usually 0).

         8.  The processor mode is changed back to user by exiting the kernel
             mode routine.

         9.  The device is reset, if necessary.

        10.  Optionally, the pages addressed in kernel mode are unlocked using
             the $ULKPAG system service.

        11.  Post-processing of the acquired data is performed in user mode 
             at IPL 0.


         The following FORTRAN and MACRO-32 modules  illustrate  this  sequence
         for  single-channel  clocked  analog  input  using AXV11-C and KWV11-C
         modules.

         To execute:
                 $ FORTRAN POLLED_AD
                 $ MACRO FASTAD32
                 $ LINK POLLED_AD,FASTAD32
                 $ SET PROCESS/PRIV=(CMKRNL,PSWAPM,PFNMAP) !Required privileges
                 $ RUN POLLED_AD








                                  417

uNOTE # 044
Page 6 of 21





                 PROGRAM POLLED_AD

                 INCLUDE '($SYSSRVNAM)'

                 INTEGER*2 IOFF, IVAL, IBUF(60000)
                 INTEGER*4 ISTATUS, MAPIOP, NPNTS, LOCKS(2)

         o  Use the $LCKPAG system service to lock the input buffer into 
         o  physical memory.

                 LOCKS(1)=%LOC(IBUF(1))
                 LOCKS(2)=%LOC(IBUF(60000))
                 ISTATUS=SYS$LCKPAG(LOCKS,,)
                 IF(.NOT.ISTATUS) CALL EXIT(ISTATUS)

         o  Call routine MAPIOP to map the I/O page in virtual address space.

                 ISTATUS=MAPIOP()
                 IF(.NOT.ISTATUS) CALL EXIT(ISTATUS)

         o  Input/initialize data acquisition parameters

                 TYPE 9060
         9060    FORMAT('$Base clock rate, clock preset, number of samples?')
                 ACCEPT *, IRATE, KOUNT, NPNTS
                 ICHAN = 0
                 MODE  = 0

         o  Call the sampling routine. Control will return to the main program 
         o  only after I/O is complete. 

                 CALL FASTAD32(ICHAN,KOUNT,IRATE,IBUF,NPNTS,MODE,ISTATUS)

         o  Output data, return status (residual AXV CSR)

                 TYPE 9130, (J, IBUF(J),J=1,NPNTS)
         9130    FORMAT(1X,2I10)
                 TYPE 9140,ISTATUS
         9140    FORMAT(/' ISTATUS =',O10)

                 END









                                  418

                                                           uNOTE # 044
                                                          Page 7 of 21





              .TITLE FASTAD32

              .LIBRARY /SYS$LIBRARY:LIB.MLB/

              .PSECT  MAPIOP_MAIN     RD,WRT,PAGE

      ; NOTE: all subsequent MACRO-32 code in this example is contained in this
      ;       .PSECT.


      VIOP:           .BLKB   8192            ; The virtual pages to which 
      VIOP_END:                               ;  the I/O page will be mapped

      PIOPAGE:        .LONG   VIOP            ; Starting and ending virtual page
                      .LONG   VIOP_END        ;  addresses
      RETPAGE:        .BLKL   2               ; Starting and ending page addrs
                                              ;  used (should be the same)
      SECNAME:        .ASCID  /IOPAG_GLSEC/   ; Name of the section to be 
                                              ;  created
      IOPAGECHAN:     .LONG                   ; Channel # to be associated with 
                                              ;  the created section
      PFNUM:          .LONG   ^X100000        ; Page frame number of the I/O 
                                              ;  page (20000000 hex) /(200 hex)

      ;++
      ; Routine to map the I/O page into process virtual address space
      ;--

              .ENTRY  MAPIOP,^M<>

              $CRMPSC_S-
                      INADR=PIOPAGE,-
                      RETADR=RETPAGE,-
                      FLAGS=#SEC$M_PFNMAP+SEC$M_WRT,-
                      GSDNAM=SECNAME,-
                      CHAN=IOPAGECHAN,-
                      PAGCNT=#16.,-
                      VBN=PFNUM
                RET
        ;++
        ;       FASTAD32 - Performs single channel, polled I/O using AXV11-C 
        ;                  and KWV11-C modules.
        ;
        ;       The FORTRAN calling interface is:
        ;
        ;       CALL FASTAD32(ichan,kount,irate,ibuf,npnts,mode,istatus)




                                  419

uNOTE # 044
Page 8 of 21


        ;
        ;       where:
        ;               ichan   =       AXV11-C A/D channel number
        ;               kount   =       KWV11-C preset value
        ;               irate   =       clock rate:
        ;                                       1 = 1 MHz
        ;                                       2 = 100 KHz
        ;                                       3 = 10 KHz
        ;                                       4 = 1 KHz
        ;                                       5 = 100 Hz
        ;               ibuf    =       array to store data
        ;               npnts   =       number of elements in ibuf
        ;               mode    =       if 0 then start immediately; 
        ;                               if<>0 then start on ST2
        ;               istatus =       return status; if<0 then error
        ;
        ; This routine should be in the same .PSECT as the MAPIOP routine.
        ;
        ; The CLK OVFL pin on the KWV is strapped to the RTC IN pin on the AXV.
        ;
        ;--

                ADCSR   = VIOP+^O10400  ;address of AXV11-C A/D CSR
                ADBUF   = ADCSR+2       ;address of AXV11-C A/D BUFFER
                KWCSR   = VIOP+^O10420  ;address of KWV11-C CSR
                KWPRE   = KWCSR+2       ;address of KWV11-C BUFFER/PRESET

                ; Argument pointer offsets

                ICHAN   =  4
                KOUNT   =  8
                IRATE   = 12
                IBUF    = 16
                NPNTS   = 20
                MODE    = 24
                ISTATUS = 28


                .ENTRY  FASTAD32,^M<R6,R7,R8,R9,R10>

        ; Note that all instructions which address the I/O page are WORD MODE.

                TSTW    @#ADBUF         ;clear A/D DONE flag
                MOVZWL  @ICHAN(AP),R6   ;channel # to sample
                ASHL    #8,R6,R6        ;move channel # to byte 2 of R6
                BISB    #^O40,R6        ;enable clock driven

                MOVW    R6,@#ADCSR      ;load A/D CSR





                                  420

                                                           uNOTE # 044
                                                          Page 9 of 21




                MOVZWL  @IRATE(AP),R6   ;clock rate in R6
                BICL    #^O177770,R6    ;clear excess bits
                ASHL    #3,R6,R6        ;shift rate to bits 3 - 5
                MOVW    R6,@#KWCSR      ;load KW CSR

                MNEGW   @KOUNT(AP), -
                        @#KWPRE         ;load KW preset register

                MOVL    IBUF(AP),R6     ;load address of IBUF into R6
                MOVZWL  @NPNTS(AP),R7   ;load NPNTS into R7
                MOVL    #ADCSR,R8       ;R8 points to A/D CSR
                MOVL    #ADBUF,R9       ;use R9 as pointer to A/D buffer reg
                MOVZWL  @MODE(AP),R10   ;pass MODE arg to POLL in R10

                 $LCKPAG_S -             ;lock polling code into memory
                        INADR=LCKPAG, -
                        RETADR=LCKRET

                $CMKRNL_S POLL          ;execute routine POLL in kernel mode

                CLRW    @#KWCSR         ;zero KWCSR - turns clock off
                MOVZWL  (R8), -         ;return status is residual AXV CSR
                        @ISTATUS(AP)
                CLRW    (R8)            ;clear A/D CSR

                RET                     ;return to fortran

        LCKPAG: .LONG   POLL
                .LONG   POLL_END
        LCKRET: .BLKL   2

                .ENTRY  POLL,^M<R6,R7,R8,R9,R10>

                DSBINT  #30             ;disable all interrupts (except pwrfail)
                TSTW    R10             ;test mode
                BEQL    1$              ;if 0 then trigger immediately
                BISW    #20002,@#KWCSR  ;set clock to wait for ST2
                BRB     2$              ;and skip over next instruction
        1$:     BISW    #3,@#KWCSR      ;trigger immediately

        2$:     BBC     #7,(R8),2$      ;is conversion done?
                MOVW    (R9),(R6)+      ;store A/D value
                SOBGTR  R7,2$           ;decrement NPNTS; if not zero loop again

                ENBINT                  ;restore IPL to prior value

        POLL_END:
                RET

                .END

                                  421

uNOTE # 044
Page 10 of 21




        ;++
        ;  These routines are not used in the present example. They are provided
        ;  only for general reference.
        ;
        ;  FORTRAN calling interface:
        ;
        ;     CALL IPEEK32 ( OFFSET, VALUE )
        ;
        ;     CALL IPOKE32 ( OFFSET, VALUE )
        ;
        ;        where
        ;
        ;           OFFSET    = integer*2 offset in the I/O page
        ;
        ;           VALUE     = integer*2 value from/for the register selected
        ;
        ; These routines should be in the same .PSECT as the MAPIOP routine.
        ;
        ;--

                .ENTRY  IPEEK32,^M<R6>

                MOVZWL  @4(AP),R6               ;put OFFSET in R6
                MOVZWL  L^VIOP(R6),@8(AP)       ;put value from iopage in VALUE

                RET


                .ENTRY  IPOKE32,^M<R6>

                MOVZWL  @4(AP),R6               ;put OFFSET in R6
                MOVW    @8(AP),L^VIOP(R6)       ;put VALUE into iopage

                RET

















                                  422

                                                           uNOTE # 044
                                                         Page 11 of 21


         2  INTERRUPT PROGRAMMING UNDER VMS USING CONNECT-TO-INTERRUPT

      Interrupt service routines on unmapped, single-tasking systems  such  as
      PDP11s  running RT11-SJ are fairly straightforward.  An interrupt occurs
      and control is transfered directly  to  the  interrupt  service  routine
      (ISR).   This  involves  saving  the  current  program  counter (PC) and
      processor status word (PSW) and replacing  them  with  the  PC  and  PSW
      stored  at  the vector address for the interrupting device.  When I/O is
      complete, a completion flag may be set to notify  the  mainline  program
      that  the  data  have  been  stored  (or output).  The interrupt service
      routine returns control to the mainline  program  by  executing  an  RTI
      instruction which restores the saved PC and PSW registers.  The mainline
      program may test the completion flag to detect I/O completion.

      The virtual, multi-tasking, multi-user nature of VAX/VMS makes interrupt
      handling  more  complicated.   Since the process which requested the I/O
      might not be current at the time an interrupt occurred, the ISR code and
      data  must  reside  in  system virtual address space and must execute in
      system context.  If this were not the case, a context switch to that  of
      the  requesting  process  might  be needed before the interrupt could be
      serviced and this would impose too great a  penalty  in  response  time.
      Similarly,    notification   of   I/O   completion   must   be   handled
      asynchronously.  Finally, the sharing of I/O resources  among  multiple,
      possibly  non-cooperating  processes  imposes  additional  architectural
      demands.

      VMS resolves these issues through  the  implementation  of  an  elegant,
      though complex, I/O subsystem.  All VMS device drivers must interface to
      the I/O subsystem to insure the orderly flow of information between  the
      various  users'  processes  and  shareable  I/O  devices.  However, most
      realtime application programmers would prefer to avoid  writing  a  full
      VMS  device  driver  for  controlling  realtime  I/O  modules.   This is
      particularly true in light of the fact that realtime  devices  generally
      need  not  be  shareable among non-cooperating processes, whereas device
      shareability is one of the sources of complexity in the  I/O  subsystem.
      The  connect-to-interrupt  driver  enables  users  to  program interrupt
      service routines and asynchronous I/O completion routines without having
      to write a full VMS device driver.



         2.1  The Connect-to-Interrupt User Interface

      The connect-to-interrupt driver (CONINTERR or CIN)  is  a  template  VMS
      device  driver  into  which blocks of user-supplied code and data may be
      linked.  The user-supplied code and  data  are  contained  in  a  single
      .PSECT  hereafter  referred  to  as the "CIN buffer".  The CIN buffer is
      compiled and linked as part of the application  program.   The  linkages
      between  the  CIN  driver and the user-supplied CIN buffer are formed at
      run-time by the $QIO system service.   As  a  part  of  the  process  of
      building  these  links,  the  CIN  buffer  is mapped into system virtual
      address space (S0) while  preserving  the  mapping  in  process  virtual

                                  423

uNOTE # 044
Page 12 of 21


      address  space (P0).  The result is that the CIN buffer is doubly-mapped
      in S0 and P0 virtual address space.  Thus, code  and  data  in  the  CIN
      buffer are accessible in both system and process context.
        The CIN buffer comprises 5 sections:

        1. A data area containing all data structures to be addressed  during
           the execution of user-supplied CIN code.

        2. A device initialization routine which is executed during  recovery
           from a power failure.

        3. A start I/O routine which is executed at  the  time  the  $QIO  is
           issued.

        4. An interrupt service routine which is executed in  response  to  a
           device interrupt.

        5. A cancel I/O routine which  is  executed  when  the  user  process
           issues a cancel I/O request.

      In addition, the user may specify an  AST  routine  to  be  executed  in
      process  context  on  I/O  completion  (or  partial  completion).  It is
      important to note that any user-supplied code in the CIN buffer may only
      address  data  and  code  contained  within  the CIN buffer.  Code which
      executes in process context, including the user-specified  AST  routine,
      may  also address data and code in the CIN buffer and, of course, in any
      other portion of process virtual address space.   The  sections  of  the
      user-supplied CIN buffer are illustrated diagramatically below.

                   .PSECT  CIN_USER        PIC,USR,CON,REL,LCL,NOSHR,EXE,RD,WRT
                    ________________________________
                   |         Data buffers           |
                   |________________________________|
                   |         INIT routine           |
                   |    Executed after powerfail    |
                   |________________________________|
                   |        START routine           |
                   |       Executed by $QIO         |
                   |________________________________|
                   |         INT routine            |
                   |  Executed on device interrupt  |
                   |________________________________|
                   |       CANCEL routine           |
                   |     Executed by $CANCEL        |
                   |________________________________|

      This application note is intended to provide an  overview  of  CONINTERR
      concepts  for  intermediate  to  advanced  programmers  who  want to get
      started  using  this  facility.   Many  of  the  details  of   CONINTERR
      functionality  and internals have been omitted, though what is presented
      is sufficient for many applications.  For a more detailed description of
      CONINTERR, see the VAX/VMS Release Notes, Appendix C.

                                  424

                                                           uNOTE # 044
                                                         Page 13 of 21


           2.2  Example Code Internals

      The example program performs continuous interrupt-driven analog input to
      a  process  buffer  using  an  AXV11-C analog module and a KWV11-C clock
      module for timebase generation.  Data are sampled into a 4096-word  ring
      buffer  with  2  sub-buffers.   The  ring buffer is contained in the CIN
      buffer and is therefore doubly mapped in S0 and P0.  When  a  sub-buffer
      is  filled, an AST is delivered to the calling process.  The AST routine
      moves the data from the sub-buffer to a process buffer (singly mapped in
      P0  virtual  address space).  It then checks to determine whether I/O is
      complete; that is, whether the process buffer has received all the  data
      requested.   If  it has, the AST issues a $CANCEL system service call to
      terminate I/O and sets a completion flag to notify the  calling  program
      of I/O completion.



                           SYSTEM SETUP FOR CONNECT-TO-INTERRUPT


           1. Log in to SYSTEM account.

           2. Insert the following line in the file SYS$SYSTEM:MODPARAMS.DAT

              REALTIME_SPTS = 20

           3. Enter:

              $ @SYS$UPDATE:AUTOGEN SAVPARAMS REBOOT
                   .
                   .
              (system reboots)

           4. Log in to SYSTEM account or other privileged account and enter:

              $ MCR SYSGEN
              SYSGEN> CONNECT 
                      AXA0:/ADA=0/CSR=%O770400/VEC=%O400/DRIVER=CONINTERR
              SYSGEN> EXIT

              $ MACRO AXV
              $ FORTRAN CALL_AXV
              $ LINK CALL_AXV,AXV
              $ SET PROCESS/PRIV=(PSWAPM,CMKRNL)   !Required privileges
              $ SET PROCESS/PRIORITY=17
              $ RUN CALL_AXV


      .page
      System page table entries for double-mapping of  CONINTERR  buffers  are
      drawn  from  a  pre-allocated  pool.  In steps 1 - 3, above, the size of
      this pool is set by modifying the SYSGEN parameter  REALTIME_SPTS.   The

                                  425

uNOTE # 044
Page 14 of 21


      number  of  page  table  entries allocated must be sufficient to map the
      user buffers (data and code) of all CONINTERR-driven devices  which  are
      connected  at  any  given  time.   In the present example, 20 page table
      entries are allocated, sufficient to map 5120 words of  data  and  code.
      This  step  needs  to  be  taken  only when additional REALTIME_SPTS are
      required for mapping CONINTERR buffers.

      In step 4, above, the device is connected to the system.  In this  case,
      the  device  was  given  the  name  "AXA0"; this is the name used in the
      $ASSIGN system service call.  Switches are used to designate the adapter
      number  (always  0  on  MicroVAXes), the CSR and vector addresses of the
      module, and the driver name (CONINTERR).  This step needs  to  be  taken
      each  time  the system is booted.  The commands may be inserted into the
      file SYS$MANAGER:SYCONFIG.COM, if desired.


                 PROGRAM CALL_AXV        !Calling program for AXV_SAMPLE

                 INCLUDE '($SYSSRVNAM)'

                 BYTE ICMPF
                 INTEGER*2 PBUFF(30000)
                 INTEGER*4 ISTATUS, ICHAN, IPRESET, ICOUNT
                 INTEGER*4 LOCKS(2)
                 INTEGER*4 AXV_SAMPLE

                 COMMON /PROCESS_DATA/ PBUFF, ICMPF

         o  Lock the process buffer into the working set. This is not essential,
         o  but it helps to avoid page faulting in the AST routine.

                 LOCKS(1) = %LOC(PBUFF(1))
                 LOCKS(2) = %LOC(PBUFF(30000))
                 ISTATUS = SYS$LCKPAG (LOCKS,,)
                 IF(.NOT.ISTATUS) CALL EXIT (ISTATUS)

         o  Assign a channel number for the AXV

                 ISTATUS = SYS$ASSIGN ('_AXA0:' ,ICHAN,,)
                 IF(.NOT.ISTATUS) CALL EXIT (ISTATUS)

         o  Input/initialize arguments to be passed to the calling routine

                 TYPE *, 'KWV preset, sample count?'
                 ACCEPT *, IPRESET, ICOUNT








                                  426

                                                           uNOTE # 044
                                                         Page 15 of 21




         o  Routine AXV_SAMPLE handles all of the details of setting up and
         o  executing the I/O operations. When the process buffer is filled,
         o  the completion flag is set.

                 ICMPF = 0       ! Clear the completion flag
                 ISTATUS = AXV_SAMPLE (ICHAN, IPRESET, ICOUNT)
                 IF(.NOT.ISTATUS) CALL EXIT (ISTATUS)

         o  By looping on the completion flag, the process is insured of 
         o  remaining computable throughout the I/O operation.

           100     IF(ICMPF.EQ.0) GO TO 100

         o  For the sake of simplicity in this example, only a few of the 
         o  acquired data values are output. In a real application, the 
         o  following step would be replaced with file/graphic output.

                   TYPE 9000, (J,PBUFF(J),J=1,1000,100)
           9000    FORMAT(2I10)

                   END


                 .TITLE  AXV

                 .LIBRARY /SYS$LIBRARY:LIB.MLB/

                 $IDBDEF                 ; Definition for I/O drivers
                 $UCBDEF                 ; Data structurs
                 $IODEF                  ; I/O function codes
                 $CINDEF                 ; Connect-to-interrupt 
                 $CRBDEF                 ; CRB stuff
                 $VECDEF                 ; more


                 .PSECT PROCESS_ROUTINES   PIC,USR,CON,REL,LCL,NOSHR,EXE,RD,WRT

         ;++
         ; This example routine issues the QIO to connect to the AXV 
         ; interrupts.  It takes care of the internals associated with the 
         ; connect-to-interrupt QIO. 
         ;
         ; FORTRAN calling sequence:
         ;
         ;   STATUS = AXV_SAMPLE ( CHAN, PRESET, COUNT )
         ;
         ;   where
         ;
         ;      CHAN     = longword channel # for device _AXA0
         ;

                                  427

uNOTE # 044
Page 16 of 21


         ;      PRESET   = longword preset value for KWV
         ;                 (positive value <= 32K)
         ;
         ;      COUNT    = longword # of samples
         ;
         ;      STATUS   = longword return status of $QIO call
         ;
         ; In this example, the AXV and KWV CSRs are "firm-wired" for the 
         ; following characteristics:
         ;
         ;       AXV - gain=1, RTC ENABLE, DONE INT ENABLE, channel=0
         ;
         ;       KWV - GO, mode=1, rate=1 (1 MHz)
         ;
         ; Ordinarily, they would be configured according to arguments passed
         ; to this routine from the calling program.
         ;
         ; The CLK OVFL pin on the KWV is strapped to the RTC IN pin on the AXV.
         ;
         ;--

                 .ENTRY  AXV_SAMPLE,^M<>

         ; These values are stored in process address space for use in the AST
         ; routine

                 MOVL    @4(AP),AXV_CHAN         ; Channel # for $CANCEL
                 MOVL    @12(AP),POINT_COUNT     ; Point count


         ; These values are stored in system address space for use in the CIN 
         ; user start routine.

                 MOVW    #^O13,KWV_CSR_VALUE     ; GO, MODE=1, 1MHz
                 MOVW    #^O140,AXV_CSR_VALUE    ; RTC ENABLE, DONE INT ENABLE
                 MNEGW   @8(AP),KWV_PRESET_VALUE ; Negated KWV preset value

                 $QIO_S  CHAN=@4(AP),-           ;Channel
                         FUNC=#IO$_CONINTWRITE,- ;Allow writes to data buffer
                         IOSB=AXV_CIN_IOSB,-     ;I/O status Block
                         P1=AXV_CIN_BUF_DESC,-   ;Buffer descriptor
                         P2=#AXV_CIN_ENTRY,-     ;Entry list
                         P3=#AXV_CIN_MASK,-      ;Status bits,etc
                         P4=#USER_AST,-          ;AST service routine
                         P6=#10                  ;preallocate some AST control
                                                 ; blocks
                 RET                             ;Return to calling routine

         AXV_CIN_BUF_DESC:                       ;Buffer descriptor for CIN
                 .LONG   USER_END - RINGBUF
                 .LONG   RINGBUF


                                  428

                                                           uNOTE # 044
                                                         Page 17 of 21


         AXV_CIN_ENTRY:
                 .LONG   USER_INIT - RINGBUF     ;Init code
                 .LONG   USER_START - RINGBUF    ;Start code
                 .LONG   USER_INT - RINGBUF      ;Interrupt service routine
                 .LONG   USER_CNCL - RINGBUF     ;I/O cancel routine

         AXV_CIN_IOSB:
                 .LONG   0                       ; I/O Status Block
                 .LONG   0

         ; Control mask - see VMS Release Notes, Appendix C for explication

         AXV_CIN_MASK = CIN$M_REPEAT!CIN$M_START!CIN$M_ISR!CIN$M_CANCEL



                 .SBTTL  USER_AST, User AST routine

         ;++
         ; This routine is invoked when I/O complete is signaled by the USER_INT
         ; routine. It is queued to the user's process in the access mode of the
         ; $QIO which initiated the I/O. It executes in process context at
         ; IPL$_ASTDEL (IPL 2).
         ;
         ; I/O completion is signalled by loading SS$_NORMAL (1) into R0 on 
         ; exiting the USER_INT routine. In the present example, this does not 
         ; signal full completion of the I/O, since the CIN$M_REPEAT flag was 
         ; set in the $QIO call.
         ;
         ;--

                 .ENTRY  USER_AST,^M<R2,R3,R4,R5>



                 MOVAL   RINGBUF,R2              ; Get CIN buffer address
                 MOVZWL  RINGBUF_INDEX,R3        ; Get buffer index
                 BBS     #11,R3,10$              ; Is bit 11 set?
                 ADDL    #4096,R2                ; No, xfer the top half
         10$:    MOVAL   PBUFF,R4                ; Get process buffer address
                 ADDL    PBUFF_INDEX,R4          ; Add Index
                 MOVC3   #4096,(R2),(R4)         ; Move data (trashes R0-R5)
                 ADDL    #4096,PBUFF_INDEX       ; Update process buffer "index"
                 SUBL2   #2048,POINT_COUNT       ; Update point count
                 BGTR    20$                     ; Have we moved all the data?
                 JMP     ALL_DONE                ; Yes - Finish up
         20$:    MOVZWL  #SS$_NORMAL,R0          ; Set return status
                 RET                             ; And return

         ALL_DONE:
                 $CANCEL_S -                     ; Cancel the I/O request
                         CHAN=AXV_CHAN
                 CLRL    PBUFF_INDEX             ; Reset index into PBUFF

                                  429

uNOTE # 044
Page 18 of 21


                 MOVB    #1,ICMPF                ; Set the completion flag
                 MOVZWL  #SS$_NORMAL,R0          ; Set return status
                 RET                             ; And return

         PBUFF_INDEX:
                 .LONG   0

         POINT_COUNT:
                 .LONG   0

         AXV_CHAN:
                 .LONG   0


                 .PSECT PROCESS_DATA     PIC,OVR,REL,GBL,SHR,NOEXE,RD,WRT,LONG

         ;++
         ; This is the FORTRAN common block /PROCESS_DATA/ 
         ;--

         PBUFF:  .BLKW   30000

         ICMPF:  .BYTE   0

                 .PSECT CIN_USER         PIC,USR,CON,REL,LCL,NOSHR,EXE,RD,WRT

         ;++
         ; This is the CIN buffer. In the present example, it is contained in
         ; the same source code module as the process routines shown above.
         ;--

                 .SBTTL  DATA STRUCTURES

         DATA_BUF_SIZE  =        4096

         RINGBUF:                .BLKW   DATA_BUF_SIZE
         RINGBUF_END:
         RINGBUF_INDEX:          .WORD

         AXV_CSR_VALUE:          .WORD
         KWV_CSR_VALUE:          .WORD
         KWV_PRESET_VALUE:       .WORD

         ; In the CIN user routines, the system virtual address of the CSR of 
         ; the device is supplied. Other addresses in the I/O page used by the
         ; code must be handled as offsets from the device CSR.

         AXV_ADDRESS     = ^O170400               ;Address of AXV
         KWV_ADDRESS     = ^O170420               ;Address of KWV
         KWV_OFFSET      = KWV_ADDRESS-AXV_ADDRESS ;Offset for KWV CSR
         PRESET_OFFSET   = KWV_OFFSET+2           ;Offset for KWV BPR
         DBR_OFFSET      =2                       ;Offset for AXV DBR 

                                  430

                                                           uNOTE # 044
                                                         Page 19 of 21



                 .SBTTL  USER_INIT       ; Dummy dev intialization routine
         ;++
         ; This routine is invoked after power recovery. It executes in system
         ; context at IPL$_POWER (IPL 31). 
         ;
         ; This routine is not implemented in the present example. However, the
         ; entry point must be defined and included in the entry list of the
         ; $QIO (P2).
         ;
         ; See VAX/VMS Release Notes, Appendix C for inputs.
         ;
         ;--

         USER_INIT::
                 RSB


                 .SBTTL  USER_START, Start I/O routine

         ;++
         ; This routine is invoked by the $QIO system service. It executes in
         ; system context at IPL$_QUEUEAST (IPL 6). 
         ;
         ;   On entry:


         ;
         ;       0(R2)  - arg count of 4
         ;       4(R2)  - Address of the process buffer (system mapped)
         ;       12(R2) - Address of the device's CSR
         ;
         ; See VAX/VMS Release Notes, Appendix C for other inputs.
         ;
         ; The routine must preserve all registers except R0-R4.
         ;
         ;--

         CSR_ADD = 12               ; Argument list offset of CSR addr
                                    ; (only valid in USER_START and USER_INT)

         USER_START::
                 CLRW    RINGBUF_INDEX           ; Clear ring buffer index
                 MOVL    CSR_ADD(R2),R0          ; Get address of the AXV CSR 
                 TSTW    DBR_OFFSET(R0)          ; Clear AD DONE bit, if set,
                                                   ;   by reading AXV DBR
                 MOVW    AXV_CSR_VALUE,(R0)      ; Set up the AXV
                 MOVW    KWV_PRESET_VALUE, -     ; Set KWV preset
                         PRESET_OFFSET(R0)
                 MOVW    KWV_CSR_VALUE, -        ; Set KWV CSR
                         KWV_OFFSET(R0)
                 MOVZWL  #SS$_NORMAL,R0          ; Load a success code into R0.

                                  431

uNOTE # 044
Page 20 of 21


                 RSB                             ; Return


                 .SBTTL  USER_INTERRUPT, Interrupt service routine

         ;++
         ; This routine is invoked on device interrupt. It executes in system
         ; context at IPL$_DIPL (IPL 23 in MicroVMS).
         ;
         ; On entry:
         ;
         ;       0(R2)  - arg count of 5
         ;       4(R2)  - Address of the process buffer
         ;       8(R2)  - Address of the AST parameter
         ;       12(R2) - Address of the device's CSR
         ;
         ; See VAX/VMS Release Notes, Appendix C for other inputs.
         ;
         ; The routine must preserve all registers except R0-R4
         ;
         ;--

         USER_INT::
                 MOVL    CSR_ADD(R2),R0          ; Get AXV CSR address
                 MOVAL   RINGBUF,R1              ; Get CIN buffer address
                 MOVZWL  RINGBUF_INDEX,R3        ; Get buffer index
                 MOVW    DBR_OFFSET(R0),(R1)[R3] ; Read data (assume no error)
                 INCW    R3                      ; Increment buffer index
                 BICW    #^O170000,R3            ; Clear all but bottom 12 bits 
                                                 ; of (ring) buffer index


                 MOVW    R3,RINGBUF_INDEX        ; Put updated index in storage
                 CLRL    R0                      ; Clear return status
                 BICW    #^O174000,R3            ; Now test bottom 11 bits of
                                                 ;   buffer index
                 BNEQ    10$                     ; Skip AST if not zero

         ; The user AST will be queued if the LSB of R0 is set on return

         5$:     MOVZWL  #SS$_NORMAL,R0          ; Queue the AST
         10$:    RSB


                 .SBTTL  USER_CANCEL, Cancel I/O routine

         ;++
         ; This routine is invoked by the $CANCEL system service. It executes in
         ; system context at IPL$_QUEUEAST (IPL 6). 
         ;
         ; On entry:
         ;

                                  432

                                                           uNOTE # 044
                                                         Page 21 of 21


         ;   JSB interface:
         ;
         ;       R3      -  Addr of current IRP
         ;       R4      -  Addr of PCB of cancelling process
         ;       R5      -  Addr of the UCB
         ;
         ;   CALL interface:
         ;
         ;       0(AP)   Arg count 4
         ;       8(AP)   Addr of IRP
         ;       12(AP)  Addr of PCB
         ;       16(AP)  Addr of UCB
         ;
         ; See VAX/VMS Release Notes, Appendix C for other inputs.
         ;
         ; The routine must preserve all registers except R0 and R3.
         ;
         ;--

         USER_CNCL::
                 MOVL    UCB$L_CRB(R5),R0         ; Get Address of the CRB
                 MOVL    CRB$L_INTD+VEC$L_IDB(R0),R0 ; Address of the IDB
                 MOVL    IDB$L_CSR(R0),R0         ; Get addr of AXV
                 CLRW    KWV_OFFSET(R0)           ; Stop clock
                 TSTW    DBR_OFFSET(R0)           ; Clear AD DONE bit
                 CLRW    (R0)                     ; Clear AXV CSR
                 MOVZWL  #SS$_NORMAL,R0           ; Load return status
                 RSB                              ; And return

         ; Label that marks the end of the module

         USER_END:                               ; Last location in module
                 .LONG

                 .END


















                                  433
