From: nowhere@never.at   
      
   On 17/11/2023 12:37, Robert Pengelly wrote:   
   > On Friday, 17 November 2023 at 10:37:56 UTC, wolfgang kern wrote:   
   >> On 17/11/2023 07:37, Robert Pengelly wrote:   
   >>> On Friday, 17 November 2023 at 03:37:08 UTC, wolfgang kern wrote:   
   >>>> On 16/11/2023 14:39, Robert Pengelly wrote:   
   >>>>> On Thursday, 16 November 2023 at 06:35:59 UTC, wolfgang kern wrote:   
   >>>>>> On 15/11/2023 09:27, Robert Pengelly wrote:   
   >>>>>> ...   
   >>>>>>> Right, I rewrite all the IRQ12 related stuff and it seems to work as I   
   get an A printed in the handler when I capture the mouse with qemu, how do I   
   tell the controller that I've got the data? I've tried:   
   >>>>>>>   
   >>>>>>> in al, 0x20   
   >>>>>>> out 0x20, al   
   >>>>>>>   
   >>>>>>> in al, 0x60   
   >>>>>>> out 0x60, al   
   >>>>>>>   
   >>>>>>> and   
   >>>>>>>   
   >>>>>>> in al 0x64   
   >>>>>>> out 0x64, al   
   >>>>>>>   
   >>>>>>> and nothing happens as I only get the A printed once   
   >>>>>> END of INTERRUPT(IRQ12):   
   >>>>>> MOV AL, 0xA0   
   >>>>>> OUT 0xA0,AL ;release IRQ 12   
   >>>>>> OUT 0x20,AL ;and the cascaded IRQ0..7   
   >>>>>>   
   >>>>>> END OF INTERRUPT(IRQ4):   
   >>>>>> MOV AL,0x20   
   >>>>>> OUT 0x20,AL   
   >>>>>>   
   >>>>>> but if the mouse is out of sync it may need a reset   
   >>>>>> __   
   >>>>>> wolfgang   
   >>>>> Right, I have:   
   >>>>   
   >>>>> ps2_handler:   
   >>>>> push ax   
   >>>>> in al, HEX (60)   
   >>>> OK this releases the IRQ-pin   
   >>>>> mov al, 'A'   
   >>>>> call writechr   
   >>>> hope this call doesn't alter any SEGreg, IE-bit or rely on PIC timer.   
   >>>>   
   >>>> **; mov al, HEX (A0)   
   >>>>   
   >>>> MOV AL,0x20   
   >>>>   
   >>>>> out HEX (A0), al   
   >>>>   
   >>>> **; mov al, HEX (20)   
   >>>>   
   >>>> it is still 0x20   
   >>>>> out HEX (20), al   
   >>>>>   
   >>>>> pop ax   
   >>>>> iret   
   >>>>   
   >>>>> and I get three A's printed every time I move the mouse so that's a good   
   sign. Looking at the PS/2 packets on https://roborooter.com/post/serial-mice/   
   it has:   
   >>>>   
   >>>>> D7 D6 D5 D4 D3 D2 D1 D0   
   >>>>> Byte 1 XV XV YS XS 1 M R L   
   >>>>> Byte 2 X7 X6 X5 X4 X3 X2 X1 X0   
   >>>>> Byte 3 Y7 Y6 Y5 Y4 Y3 Y2 Y1 Y0   
   >>>>>   
   >>>>> L Left button state (1 = pressed down)   
   >>>>> M Middle button state (1 = pressed down)   
   >>>>> R Right button state (1 = pressed down)   
   >>>>> X0-X7 Movement in X direction   
   >>>>> Y0-Y7 Movement in Y direction   
   >>>>> XS,YS Movement data sign bits (1 = negative)   
   >>>>> XV,YV Movement data overflow bits (1 = overflow has occurred)   
   >>>>>   
   >>>>> Is the D3 the status bit? Also, what is the XV/YV for? It says overflow   
   bit but I'm a little confused as to what I do with it.   
   >>>> in case of overflow discard movement data and read again.   
   >>>> someone tried to use OV-bits for movement expansion but worked rare.   
   >>>> __   
   >>>> wolfgang   
   >>> Okay, I have:   
   >>>   
   >>> ps2_handler:   
   >>>   
   >>> push ds   
   >>> push ax   
   >>> push bx   
   >>> push cx   
   >>> push dx   
   >>>   
   >>> mov ax, cs   
   >>> mov ds, ax   
   >>>   
   >>> in al, HEX (60)   
   >>>   
   >>> test al, HEX (08)   
   >>> jz ps2_handler.skip_init   
   >>>   
   >>> xor bx, bx   
   >>> mov cx, 3   
   >>>   
   >>> mov [count], cl   
   >>> mov [index], bx   
   >>>   
   >>> ps2_handler.skip_init:   
   >>>   
   >>> mov bx, offset buffer   
   >>> add bx, [index]   
   >>>   
   >>> mov [bx], al   
   >>>   
   >>> inc word ptr [index]   
   >>> dec byte ptr [count]   
   >>>   
   >>> mov al, HEX (20)   
   >>> out HEX (A0), al   
   >>> jnz ps2_handler.done   
   >>>   
   >>> ps2_handler.got_all:   
   >>>   
   >>> xor ax, ax   
   >>> xor dx, dx   
   >>> xor cx, cx   
   >>>   
   >>> mov bx, offset buffer   
   >>> mov al, [bx]   
   >>>   
   >>> test al, HEX (08)   
   >>> jz ps2_handler.done   
   >>>   
   >>> mov cl, 3   
   >>> shl al, cl   
   >>>   
   >>> sbb dh, dh   
   >>> cbw   
   >>>   
   >>> mov dl, [bx + 2]   
   >>> neg dx   
   >>> add [mouse_y], dx   
   >>>   
   >>> mov al, [bx + 1]   
   >>> add [mouse_x], ax   
   >>>   
   >>> ps2_handler.done:   
   >>>   
   >>> mov al, HEX (20)   
   >>> out HEX (20), al   
   >>>   
   >>> pop dx   
   >>> pop cx   
   >>> pop bx   
   >>> pop ax   
   >>> pop ds   
   >>> iret   
   >>>   
   >>> which works but the mouse can be a little jumpy sometimes, am I doing   
   something wrong? Also, where would I disregard the movement if there's   
   overflow? I'm guessing in ps2_handler.got_all but let me know if I'm mistaken.   
   >> Yeah, something in got_all seems to be odd, any reason for SBB and NEG ?   
   >> CBW works on AL->AX only, it wont alter anything on DX.   
   >> Carry-flag is always clear after SHL.   
   >> I'd have mouse-position update apart from IRQ-handler because we get   
   >> only one byte per interrupt and IRQ-routines should be as short/fast as   
   >> possible. And avoid updates in case of overflow (just keep previous).   
      
   > Looking at https://c9x.me/x86/html/file_module_x86_id_285.html it says:   
   >   
   > Bits shifted beyond the destination operand boundary are first shifted into   
   the CF flag, then discarded. At the end of the shift operation, the CF flag   
   contains the last bit shifted out of the destination operand.   
      
   Yes you are right here, I meant to tell SHL will put a zero into bit 0.   
      
   > So that would mean that the carry flag would either have 0 or 1 (maybe -1   
   and 1) according to the PS/2 section on https://roborooter.com/p   
   st/serial-mice/.  As for the neg, without it moving the mouse up moves the   
   cursor down and moving the mouse down    
   moves the cursor up.   
      
   rotate your mouse?  :)   
   just kidding.   
   but my mouse variables are (except motions) unsigned.   
   So when I setup or change screen resolution I store the X/Y limits to be   
   used as bottom/right mouse limits (but I sub 8 for keeping the image   
   visible) and also use half of these X/Y values for screen center start.   
      
   then I only SUB motions and easy clip to top left by making any negative   
   Zero and replace any larger than limit with the limit.   
      
   If you SUB a negative it will result in an ADD w/o need for extra job.   
   __   
   wolfgang   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)