The following notes relate to fixes to DU.MAC in order to use an RQDX3 
controller under RT-11 Version 5.01B.  The fixes concern the use of the Status-
and-Address (SA) register.  Patches can be applied manually, or automatically
by SLP.  DU.MAC may then be used as part of the SYSGEN process, or can be
re-assembled with a system conditional file (from a previous SYSGEN) and
relinked to recreate DU.SYS.  This has been tested with an RQDX1, RQDX2, and
RQDX3, on an 11/23+ system running SJ and FB monitors, both with one and two
"ports" (RT-11 nomenclature for MSCP controllers) but is not guaranteed to be 
totally bug-free (i.e. the usual disclaimer applies).

This sample procedure re-assembles, links, and copies the new driver.  It
assumes SLP.SAV, DU.MAC (original), DU.COR, MACRO.SAV, SYSMAC.SML, LINK.SAV,
and a SYSGEN.CND file reside on the system disk (DK:), which has space for the
new source, listing, object, and binary files (32+108+5+4=149 blocks). 
Removing the "/LIST:DU" from the MACRO command will save 108 blocks.  It also
assumes DU1: is not the system disk, but contains a bootable RT11 system:

   .SLP DU.MAC=DU.MAC,DU.COR
   .MACRO/SHOW:MEB/LIST:DU/OBJ:DU SYSGEN.CND+DU
   .LINK/NOBITMAP/EXE:DU.SYG DU
   .COPY DU.SYG DU1:DU.SYS
   .COPY/BOOT DU1:RT11SJ.SYS DU1:

This applies the patches from DU.COR, creating a new DU.MAC, and renaming the 
old one as DU.BAK; then DU.MAC is assembled with a file from a previous SYSGEN 
which contains essential system parameters, creating a listing (with all macros 
expanded) called DU.LST, and an object file; this file (DU.OBJ) is linked to 
create an executable driver DU.SYG.  This must be renamed DU.SYS prior to use; 
not done here because DU might be the system device!  Instead, it is copied to 
another DU: device, and the boot code it contains is copied to the monitor and 
the disk boot block for testing.  If all is well, DU1: will be bootable and 
the renaming can be carried out on (what was) the system disk as well.

More adventurous souls, those who wish to apply the patches manually, and those 
who are curious as to the changes, read on...

On an RQDX1 or RQDX2, SA is normally zero, except during initialisation (when 
it returns various data in confirmation of the initialisation process, and one 
of four flag bits indicating which step it is performing) or in case of an 
error (when bit 15 is set).  

On an RQDX3, SA will usually be found to contain an echo of the interrupt 
vector as well as the above flags/data.  

Whatever the controller, it is possible for RT-11 to execute a RESET 
instruction, causing a re-init of the RQDX.  This will be reflected by bit 11 
in SA being set, and requires that the initialisation process be re-done.

The following code is from DU.MAC (RT-11 Version 5.01B) with my annotations to 
show the sections to be patched in order to use an RQDX3 controller.  DU.COR
contains concise patches.

START:	CLR	R5		; start here for all function calls
	TST	ISTEP		; system been initialised successfully ?
	BPL	INIT		; not unless this locn = 1000000
	MOV	@UDASA,R5	; check for error
;	BEQ	DISPAT		; OK if RQDX1 or RQDX2 running
;	BIT	#ISTEP4,R5	; see if doing/done last step in init seq
;	BNE	DISPAT		; OK if so - go to function dispatch
	bit	#104000,R5	; error ? or (externally-triggered) reset ?
	beq	dispat		; dispatch function if not, INIT if either set
INIT:	MOV	#100000,INITFL  ; global "init-in-progress" flag
	DEC	RETRY		; one less in hand
	BGE	10$		; if retries not in overdraft, carry on...
	JMP	DUHERR		; ...otherwise flag a hard error
10$:	MOV	R5,@UDAIP	; hard init (any write to IP reg)
	PIC	ISTEP,R4	; get pointer to ISTEP
	MOV	#ISTEP1,(R4)+	; ISTEP indicates step#1, R4 points to INISEQ
	MOV	R4,@R4		; INISEQ non-zero: points to self
	CMP	(R4)+,(R4)+	; inc R4 by 4 - points to MRPTR
	MOV	R4,@R4		; MRPTR points to self
	ADD	#MRING-MRPTR,@R4	; and now to MRING (ringbase)
INISTP:	PIC	UDASA,R4	; R4 points to SA address pointer
	MOV	@(R4)+,R5	; R5 holds contents of SA, R4 points to ISTEP
	BMI	INIT		; restart init if error shown in SA
	BIT	R5,@R4		; if SA doesn't show step we're about to do...
	BEQ	INISTP		; ...then wait (tho' we get IRQ for all but #1)
	ASL	(R4)+		; change ISTEP indicator to next step
	ADD	#2,(R4)		; add two to pointer in INISEQ
	MOV	@(R4),@UDASA	; copy data indicated by INISEQ to RQDX
	TST	-(R4)		; point R4 to step indicator, check it
	BMI	START		; if done all 4 steps, proceed with function
	RTS	PC		; wait for interrupt at start of next step

  ( Function dispatch is here)

.SBTTL INTERRUPT ENTRY POINT
	.DRAST	DU,5
	.FORK	DUFBLK
	TST	ISTEP		; in initialisation process ?
	BGT	INISTP		; if not zero and not 1000000, yes
	MOV	@UDASA,R5	; to check for errors flagged in SA
;	BNE	INIT		; old code for RQDX1 or 2
	bit	#170000,r5	; see if in init sequence or error
	bne	init		; yes if any set
	MOV	DUCQE,R5	; proceed to decode function-in-progress

The following two branches are in the bootstrap code:

2$:	TST	@R3		; R3 points to the SA register
;	BNE	4$		; for RQDX3, check for error with BMI...
	bmi	4$		; not BNE... could have vector as well as flag

3$:	TST	@R3
;	BNE	4$		; BMI not BNE - see comment above
	bmi	4$
								Pete Turnbull
								York, U.K.
								March 1994