From: robertapengelly@gmail.com   
      
   On Sunday, 12 November 2023 at 03:04:32 UTC, wolfgang kern wrote:   
   > 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   
   No, I found the code at https://stackoverflow.com/questions/5428   
   828/making-a-mouse-handler-in-x86-assembly.  Not sure where they got the code   
   though.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)