SM>  *** Glen McNabb wrote in a message to Scott McNay:
SM> SM> GM> Actually, (and I checked) it can happen on all of them.
SM> SM> You sure of this?  Last I heard, as of the 80C86/80C88, that had been 
SM> GM> I checked my Intel Handbook on these processors and up to
SM> GM> 386DX and they all can be interupted between those two
SM> GM> instructions... As for testing that in Debug.EXE that's
SM> Ok, I will disagree more seriously at this point... my CPUID program
SM> specifically checks to see if an interrupt is possible between a load of 
SM> SS and the following instruction.
SM> ;-------------------------------------------------------------
SM> ; See if an interrupt is allowed immediately after an SS load.
SM> ;-------------------------------------------------------------
SM>    .8086
SM>    mov   ax,3501h
SM>    int   21h
SM>    mov   word ptr INT1,bx
SM>    mov   word ptr INT1+2,es
SM>    push   ds
SM>    mov   dx,offset INT1_Handler
SM>    mov   bx,seg INT1_Handler
SM>    mov   ds,bx
SM>    mov   ax,2501h
SM>    int   21h
SM>    pop   ds
SM> 
SM>    pushf            ;Save flags
SM>    pushf
SM>    pop   ax
SM>    or   ah,00000001y      ; Set TF (single-step)
SM>    push   ss         ; Push SS...
SM>    push   ax         ; Enable TF
SM>    popf
SM>    pop   ss         ; Do we trap after this instruction?
SM> chkint_01:                              ; shouldn't ever trap here
SM>    popf            ; Restore flags
SM> 
SM>    les   bx,INT1
SM>    mov   ax,2501h
SM>    int   21h
SM> @@:
SM> 
SM> *********************************
SM> 
SM> ;------------------------------------------
SM> ; INT1 handler is used to check to see if
SM> ; an interrupt is allowed after an SS load.
SM> ;------------------------------------------
SM>    ASSUME   CS:_TEXT, DS:_DATA, ES:NOTHING, SS:NOTHING
SM>    .8086
SM> INT1_handler   proc   near
SM>    push   bp
SM>    mov   bp,sp
SM> 
SM>    cmp   ss:[bp+2],offset ChkInt_01
SM>    jne   @f
SM>    or   BruteFlags3,00010000y
SM> @@:
SM>    pop   bp
SM>    iret
SM> INT1_Handler   endp
SM> 
SM> 
SM> Sorry, I don't recall the original author of that code; it's not me.  I'd 
SM> have to look it up, if you're interested.  I just modified it to fit the 
SM> needs of my program.
I'll have to examine that closely, as soon as I have the time. It been
quite a while since I wrote any single tracing code.
SM> SM> GM> In the case of the NMI, it's used for parity checking. The
SM> SM> GM> NMI should never activate unless you have a parity error. If
SM> SM> GM> you have a failed parity, a stack is gonna be the least of
SM> SM> GM> your problems.
SM> I thought I had some code that would disable NMI, but I can't find it.
I would think it would have to do with writing a port at the PIC.
Glen..
--- ProBoard v2.16 [Reg]
---------------