Bill,

Got a few minutes while i'm watching things heat up here in the lab.  
One of the nice things about my job.  I may spend a day or a couple 
of weeks building a "pilot" unit with all the controls here in the 
lab.  Once it's running, it's watch and pull samples as needed.

OK, regarding the ISR......

On physical page >00 beginning at >0428 is the beginning of the 
tables for the XOP's.  Each table entry is 4 words.  The first two 
words are the pages mapped into >F110 to >F113.  The next word is the 
XOP Entry Vector and the 4th word is XOP Powerup Vector.

When I write a TSR or for an ISR, I would place into the powerup 
vector the MDOS Memory XOP calls to preserve those pages that are 
reserved for the operating system.  It's documented in Paul's GenASM 
manual.  The only requirement while the code is running that physical 
page >00 be mapped in >F110.

So at:
>0428, we have the table for XOP 5 (KBD).
>0430, we have the table for XOP 6 (VID).
>0438, we have the table for XOP 7 (MEM)
>0440, we have the table for XOP 8 (I/O)
>0448, we have the table for XOP 9 (UTILS)
>0450, we have the table for XOP >A (MATH)
>0458, we have the table for XOP >B (11) Windows Library XOP
>0460, we have the table for XOP >C (12), TSR and GEME
>0468, unused for XOP >D
>0470, used for Mouse Driver for XOP >E
>0478, unused for XOP >F

The only way to "hold" a memory page that I am aware from being 
released is presently "installing" into the operating system an XOP 
and having the powerup routine call that memory opcode. Thus, the 
reason the TSR and Mouse Driver occoupying vectors in the XOP tables.

OK, both the KBD and VID XOP's occupy the same memory pages as they 
are intertwined.  If you read the first two words at >0428 and >042A, 
they will be the same as what you would find at >0430 and >0432.  
Assuming MDOS never changes these pages, what you will find is >0008, 
and >0409.  Page >00 is always present when an XOP is mapped in and 
is at >F110.  While the XOP is executing, you have at:

F110 = >00
F111 = >08
F112 = >04
F113 = >09

If you look at the MDOS source file at MDOS\L6\XOPS-S, you will see a 
pretty good breakdown of the initial few words and vectors that are 
in page >08 mapped at >F111 in the >2000 to >3FFF space.

The first few instructions are:

 RORG 0       >2000 = "JMP 2018"
 JMP  PWRUP   >2002
 B    @KINT   >2004
 B    @VINT   >2008
 B    @XOPA   >200C
 B    @XOP9   >2010
 DATA KEYSDN  >2012
 DATA KEYINT  >2014
 DATA EXTVEC  >2016
PWRUP .... other code >2018


Critical to your code is that first instruction at >2000 as MDOS has 
in Physical page 0 to do a BL @>2000 in any XOP.  Now, I have never 
used the RORG statement, and not until now did I realize it would 
assemble as an instruction.  In this case, it assembles as an 
equivalent to JMP $+18 that jumps into the PWRUP routine.  This 
defines the character sets, etc.

Yesterday, I would have thought you would have wanted to intercept 
the instruction at >2000, however, upon closer examination, I would 
now modify either the instruction at >2004 or more likely the 
instruction at >2008.

The first instruction will be >0460 (B = Branch) , so really, I would 
suggest modifying >200A that contains a destination address.  You 
would want to save this address, and replace it with your own vector 
during the initial "setup" of the ISR.  The code you would want to 
place could go to >7F00 or above (like what I did in the TSR code I 
sent) and if need be, you could use that same workspace I used at 
>7FE0.

If you didn't want to interfere with the TSR space, go a few words 
above that to write your code. I tried to avoid using registers to 
minimize downstream coding impacts.

Now that code should do one thing.  It should store what's mapped in 
at >F111 (i'm assuming you won't have anything over 8K), map in your 
code at >F111, Branch to your code for your ISR in the >2000 to >3FFF 
range making sure you define the original code as an XOP setup, and 
when you exit, return back to the code at the next instruction in 
>7F00 space, map the original >F111 page back, and do a B @vector for 
the video vector you saved.

Now, as most everything I have written, i've "discovered" it had 
glitches, especially dealing with the intracies of the powerup 
routines, interrupt routines, xop routines, vectors, etc.  99% of the 
code for setting up what I described is in the TSR code I sent and 
only requires a couple of changes and then the "real code" for 
handling whatever ISR someone wants.

Initially, I figured a lot of what I needed using Bruce Hellstrom's 
BHDMV program before MDOS source was available.  Believe me, it took 
a lot of time.  Between a combination of BHDMV and the debugger one 
can use with MESS, you can really watch what your code is doing.  
Basically, the debugger with MESS is an equivalent to RSBUG in 
capabilities. RSBUG communicates through the RS232 port to not 
disrupt the display screen while the MESS Debugger uses a separate 
window on the screen to talk to the "computer".

Hopefully, this should give you a good foundation for what you or 
anyone else will need.

Beery