From: nowhere@never.at   
      
   On 12/11/2023 02:26, Robert Pengelly wrote:   
   > On Sunday, 12 November 2023 at 01:14:22 UTC, wolfgang kern wrote:   
   >> 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.   
      
   >> btw: I don't like your awful slow detouring HLL-styled mouse callback.   
   > What do you mean by "HLL-styled"?   
      
   it looks like C-compiled bloatware crap copied from a C-library.   
   __   
   wolfgang   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)