From: nowhere@never.at   
      
   On 12/11/2023 01:15, Robert Pengelly wrote:   
   > On Saturday, 11 November 2023 at 23:56:50 UTC, wolfgang kern wrote:   
   >> On 11/11/2023 18:44, Robert Pengelly wrote:   
   >> ,,,   
   >>> Awesome it works thanks. As for:   
   >>>   
   >>> and before you touch any part of the interrupt chain you should disable   
   >>> IRQs with this single byte reserved for that, re-enable after done.   
   >>>   
   >>> Do you mean some like if I want to do something like:   
   >> CLI   
   >> mov [0x33 * 4], offset handler   
   >> mov [0x33 * 4 + 2], segment   
   >> ;also during write to any PIT-I/O 0x20/A0 0x21/A1   
   >> STI   
   >>> then I should disable the IRQ first then re-enable it after I setup the   
   interrupt.   
   >> yes, this prevents IRQs in the middle of a change which would make it   
   >> crash for sure.   
   >>> As for the timer I'm using a handler for int 1Ch, is that bad practice or   
   something?   
   >> INT 1C is a software INT called by PIC-handler, so it's fine for tests.   
   >> But if you use it permanent your mouse is polled rather then interrupt   
   >> driven.   
   >>   
   >> almost all my 16 bit IRQ-routines start with:   
   >>   
   >> push ax   
   >> push ds   
   >> in al,port ;03F8 in case of COM_1 this read releases the IRQ-pin   
   >> mov buffer,al   
   >> inc buffer   
   >> cmp buffer,limit   
   >> ja ... ;to reset count and tell received packet is complete   
   >> cmp al,..   
   >> jz ...   
   >> __   
   >> wolfgang   
   > The INT 1Ch was just temporary until I got the interrupt working, I've now   
   moved the mouse stuff into INT 0Ch and it all works. Again thanks for the help   
   to enable interrupts.  I'm not exactly sure what I want to do in INT 1C at the   
   moment so using it    
   for tests is fine for now.  As for the INT 0C handler I have:   
   >   
   > mouse_handler:   
   >   
   >      push    ax   
   >      push    dx   
   >   
   >      mov     dx,     HEX (03FD)   
   >      xor     ax,     ax   
   >      in      al,     dx   
   >      nop   
   >   
   >      test    al,     0b01000000   
   >      jz      mouse_handler.done   
   >   
   >      test    al,     0b00000001   
   >      jz      mouse_handler.done   
   >   
   >      mov     dx,     HEX (03F8)   
   >      xor     ax,     ax          ;this isn't required   
   >      in      al,     dx   
   >      nop                         ;NOPs wont delay   
   >   
   >      mov     dx,     HEX (03F8)  ;DX  didn't change   
   >      xor     ax,     ax   
   >      in      al,     dx   
   >      nop   
   >   
   >      mov     al,     'M'   
   >      call    writechr   
   >   
   > mouse_handler.done:   
   >   
   >      mov     dx,     HEX (20)   
   >      mov     al,     HEX (20)   
   >      out     dx,     al   
      
   how about a shorter variant: MOV AL,0x20  OUT AL,[0x20]   
      
   >      pop     dx   
   >      pop     ax   
   >      iret   
      
   you could imply button recognition here.   
      
      
   > Also, still regarding mice I also have PS/2 support using INT 15h to set   
   everything up and then I have:   
   >   
   > mouse_callback:   
   >   
   >      push    bp   
   >      mov     bp,     sp   
   >   
   >      push    ax   
   >      push    bx   
   >      push    cx   
   >      push    dx   
   >   
   >      mov     al,     [bp + 12]   
   >      mov     bl,     al   
   >      mov     cl,     3   
   >      shl     al,     cl   
   >   
   >      sbb     dh,     dh   
   >      cbw   
   >   
   >      mov     dl,     [bp + 8]   
   >      mov     al,     [bp + 10]   
   >   
   >      neg     dx   
   >   
   >      mov     cx,     cs:[mouse_y]   
   >      add     dx,     cx   
   >   
   >      mov     cx,     cs:[mouse_x]   
   >      add     ax,     cx   
   >   
   >      mov     cs:[mouse_x],       ax   
   >      mov     cs:[mouse_y],       dx   
   >   
   >      call    writedec   
   >      mov     al,     ' '   
   >      call    writechr   
   >      mov     ax,     dx   
   >      call    writedec   
   >      call    crlf   
   >   
   > mouse_callback.done:   
   >   
   >      pop     dx   
   >      pop     cx   
   >      pop     bx   
   >      pop     ax   
   >      pop     bp   
   >      retf   
   >   
   > which works but I get values 0000 - FFFF from it when the screen is 80x25   
   initially so should I be capping the X and Y coordinates?   
      
   yes the mouse send only delta X/Y coordinates w/o knowing screen limits,   
   so it's on you to scale and clip to the current screen mode.   
   __   
   wolfgang   
   btw: I don't like your awful slow detouring HLL-styled mouse callback.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)