On Mar 15 2005, 16:16, Eric Smith wrote: other It might. Basically the bug is that the driver assumes the SA register is 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). That's fine for an RQDX1 or RQDX2, but not for an RQDX3. On an RQDX3, SA will usually be found to contain a copy of the interrupt vector as well as the above flags/data. The MSCP docs don't actually say it should be zero other than the flag bits, just what certain flag bits mean. At certain points in the code, the SA register is checked to see if bit 15 is set (the error flag). However, the V5.01 code uses BNE, which of course branches if *any* bit is set, instead of BMI, which checks only bit 15. Here's my original (1994) patch, a file called DU.COR to patch DU.MAC: \ -23 ; ; Added (commented) fixes in 4 places, to use with RQDX3. ; Fixes concern use</interpretation of SA register. -561,563 ; 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 -634,634 ; BNE INIT ; old code for RQDX 1 or 2 bit #170000,r5 ; see if in init sequence or error bne init ; yes if any set -846,846 ; BNE 4$ ; for RQDX3, check error with BMI... bmi 4$ ; not BNE... could have vector as well as flag -852,852 ; BNE 4$ ; likewise, I'm sure ! bmi 4$ / If you want a bit more of the context, look in http://www.dunnington.u-net.com/public/RQDX/DUX.TXT I spent ages working this out. Someone on Compuserve also published a fix, but it was incomplete and didn't always work. -- Pete Peter Turnbull Network Manager University of York