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,949 of 4,255    |
|    wolfgang kern to Robert Pengelly    |
|    Re: Does a PS/2 mouse get detected if pl    |
|    19 Nov 23 03:35:49    |
      From: nowhere@never.at              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              --- 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