home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   alt.os.development      Operating system development chatter      4,255 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 3,953 of 4,255   
   Robert Pengelly to wolfgang kern   
   Re: Does a PS/2 mouse get detected if pl   
   18 Nov 23 23:14:24   
   
   From: robertapengelly@gmail.com   
      
   On Sunday, 19 November 2023 at 02:35:54 UTC, wolfgang kern wrote:   
   > On 18/11/2023 19:53, Robert Pengelly wrote:   
   > > On Friday, 17 November 2023 at 22:13:21 UTC, wolfgang kern wrote:   
   > >> On 17/11/2023 18:06, Robert Pengelly wrote:   
   > >>> On Friday, 17 November 2023 at 15:56:54 UTC, wolfgang kern wrote:   
   > >>>> On 17/11/2023 16:28, Robert Pengelly wrote:   
   > >>>>>>> ...   
   > >>>>>>> "I store the X/Y limits to be used as bottom/right mouse limits"   
   > >>>>>>   
   > >>>>>>> Yeah that is the plan eventually, I'm just testing things at the   
   moment. Am I right by checking bit 4? If I am then how do I know that it's not   
   byte 2 or 3 that has bit 4 set?   
   > >>>>>> on PS/2 you check bit3 with TEST AL,8   
   > >>>>>> but b3 would only show up set in byte2&3 when a motion is reported,   
   > >>>>>> so there is a good chance to see only 1st byte have b3 set.   
   > >>>>>>   
   > >>>>>> But it is a crap design anyway, if you move your mouse fast it may   
   jump   
   > >>>>>> because of false indication of the sync bit.   
   > >>>>> That's what I'm doing. Is there not anything I can do to stop false   
   detections?   
   > >>>> I once checked and the only halfway working solution was to have all   
   > >>>> IRQ-routines (especially IRQ_0 PIT) as short and fast as possible with   
   > >>>> all event handlers apart (not within IRQ handlers) in an idle queue.   
   > >>>> So the mouse packets will rare to never be split to fall out of sync.   
   > >>>>   
   > >>>> I used this method for all interrupts and it sped up my whole OS by   
   > >>>> magnitudes.   
   > >>>> __   
   > >>>> wolfgang   
   > >>> I changed to:   
   > >>>   
   > >>> 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   
   > >>>   
   > >>> mov byte ptr [ps2_updated], 0   
   > >>>   
   > >>> xor bx, bx   
   > >>> mov cx, 3   
   > >>>   
   > >>> mov [count], cl   
   > >>> mov [index], bx   
   > >>>   
   > >>> ps2_handler.skip_init:   
   > >>>   
   > >>> mov bx, offset ps2_buffer   
   > >>> add bx, [index]   
   > >>>   
   > >>> mov [bx], al   
   > >>>   
   > >>> inc word ptr [index]   
   > >>> dec byte ptr [count]   
   > >>>   
   > >>> mov al, HEX (20)   
   > >>> out HEX (A0), al   
   > >>>   
   > >>> mov al, HEX (20)   
   > >>> out HEX (20), al   
   > >>>   
   > >>> jnz ps2_handler.done   
   > >>>   
   > >>> ps2_handler.got_all:   
   > >>>   
   > >>> mov byte ptr [ps2_updated], 1   
   > >>>   
   > >>> ps2_handler.done:   
   > >>>   
   > >>> pop dx   
   > >>> pop cx   
   > >>> pop bx   
   > >>> pop ax   
   > >>> pop ds   
   > >>> iret   
   > >>>   
   > >>> and   
   > >>>   
   > >>> update_mouse:   
   > >>>   
   > >> *> push ax   
   > >> *> push bx   
   > >> *> push cx   
   > >> *> push dx   
   > >> *> push ds   
   > >> *>   
   > >> *> mov ax, cs   
   > >> *> mov ds, ax   
   > >> *>   
   > >> *> cmp byte ptr [ps2_updated], 1   
   > >> *> jne update_mouse.serial   
   > >>   
   > >> I'd use instead of the above:   
   > >> update_ mouse:   
   > >> cmp byte ptr [cs:ps2_updated],1   
   > >> jne update   
   > >> ret   
   > >> update:   
   > >> push ...   
   > >>> xor ax, ax   
   > >>> xor dx, dx   
   > >>> xor cx, cx   
   > >>>   
   > >>> mov bx, offset ps2_buffer   
   > >>> mov al, [bx]   
   > >>>   
   > >>> test al, HEX (08)   
   > >>> jz update_mouse.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   
   > >>>   
   > >>> update_mouse.serial:   
   > >>>   
   > >>> mov bx, [mouse_x]   
   > >>> shr bx   
   > >>> shr bx   
   > >>> shr bx   
   > >>>   
   > >>> mov cx, [mouse_y]   
   > >>> shr cx   
   > >>> shr cx   
   > >>> shr cx   
   > >>> shr cx   
   > >>>   
   > >>> update_mouse.move:   
   > >>>   
   > >>> mov ah, HEX (02)   
   > >>> xor bh, bh   
   > >>> mov dh, cl   
   > >>> mov dl, bl   
   > >>> int HEX (10)   
   > >>>   
   > >>> update_mouse.done:   
   > >>>   
   > >>> pop ds   
   > >>> pop dx   
   > >>> pop cx   
   > >>> pop bx   
   > >>> pop ax   
   > >>> ret   
   > >>>   
   > >>> Just for testing and the mouse detection is even worse.   
   >   
   > >> save time by using less registers (DS AX CX) in IRQ12 and   
   > >> perhaps replace 'updated' by [count]==0 as packet complete indicator   
   > >> (save on one memory access).   
   >   
   > >>> The update mouse is called from my INT 1Ch handler.   
   > >> this is the main problem, INT 1C is called by the IRQ_0 handler which   
   > >> slows all IRQ-response that way.   
   >   
   > >> my main idle code contains almost nothing:   
   > >>   
   > >> MAIN_IDLE:   
   > >> STI   
   > >> TEST,dword [SS:global_flags],-1 ;I have all variables on stack bottom   
   > >> ;and can check 32 event flags at once   
   > >> JE MAIN_IDLE ;loop as long no event reported   
   > >> ... here I check for keys, mouse moves, buttons pressed/released   
   > >> ... act on it (fast and short) reset parameters if required   
   > >> JMP MAIN_IDLE   
   > > After I do:   
   > >   
   > > mov al, HEX (AB)   
   > > call ps2_write_command_read_data   
   >   
   > > on real hardware, I get 0x9C in al. Any ideas what the 9C means? I've   
   tried googling it but I can't seem to find anything.   
   > you might read from keyboard instead of mouse, but as long I don't know   
   > what this call does in detail I can only guess.   
   > how about the other issues? are mice still jumping around ? :)   
   > __   
   > wolfgang   
   No I got slightly different code now:   
      
   ps2_handler:   
      
       push    ax   
       push    bx   
       push    cx   
       push    dx   
       push    si   
      
       mov     si,     cs:[ps2_index]   
       in      al,     HEX (64)   
      
       test    al,     HEX (20)   
       jz      ps2_handler.done   
      
       in      al,     HEX (60)   
      
       mov     cs:[ps2_buffer + si],       al   
       inc     word ptr cs:[ps2_index]   
      
       cmp     si,     2   
       jb      ps2_handler.done   
      
   ps2_handler.got_all:   
      
       mov     word ptr cs:[ps2_index],    0   
      
       xor     ax,     ax   
       xor     dx,     dx   
       xor     cx,     cx   
      
       mov     bx,     offset ps2_buffer   
       mov     al,     cs:[bx]   
      
       test    al,     HEX (08)   
       jz      ps2_handler.done   
      
       mov     cl,     3   
       shl     al,     cl   
      
       sbb     dh,     dh   
       cbw   
      
       mov     dl,     cs:[bx + 2]   
       neg     dx   
       add     cs:[mouse_y],   dx   
      
       mov     al,     cs:[bx + 1]   
       add     cs:[mouse_x],   ax   
      
   ps2_handler.done:   
      
       mov     al,     HEX (20)   
       out     HEX (A0),   al   
       out     HEX (20),   al   
      
       pop     si   
       pop     dx   
       pop     cx   
       pop     bx   
       pop     ax   
       iret   
      
   and it's been working great so far just can't get IRQ12 working on a laptop   
   due to that 0x9C issue.  Forgot to add that even:   
      
   mov     al,     HEX (A9)   
       call    ps2_write_command_read_data   
      
   gives me 0x9C. So both keyboard and mouse aren't detected but they were   
   working when I had the INT 15h stuff implemented.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca