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