From: robertapengelly@gmail.com   
      
   On Sunday, 12 November 2023 at 13:46:59 UTC, wolfgang kern wrote:   
   > On 12/11/2023 14:27, Robert Pengelly wrote:    
   > > On Sunday, 12 November 2023 at 12:08:42 UTC, wolfgang kern wrote:    
   > >> On 12/11/2023 12:11, Robert Pengelly wrote:    
   > >> ...    
   > >>> I'm having a little bit of trouble with the cooridnates from the IRQ4.   
   Going by https://roborooter.com/post/serial-mice/ I have:    
   > >>>    
   > >>> mov dx, HEX (03FD)    
   > >>> xor ax, ax    
   > >>> in al, dx    
   > >>> nop    
   > >>>    
   > >>> test al, 0b01000000    
   > >>> jz serial_handler.done    
   > >>>    
   > >>> test al, 0b00000001    
   > >>> jz serial_handler.done    
   > >>>    
   > >>> mov dx, HEX (03F8)    
   > >>> xor ax, ax    
   > >>> in al, dx    
   > >>> nop    
   > >>>    
   > >>> mov si, ax    
   > >>> mov di, ax    
   > >>>    
   > >>> and si, 0b00001100    
   > >>> and di, 0b00000011    
   > >>>    
   > >>> mov cl, 4    
   > >>> shl si, cl    
   > >>>    
   > >>> mov cl, 6    
   > >>> shl di, cl    
   > >>>    
   > >>> mov dx, HEX (03F8)    
   > >>> xor ax, ax    
   > >>> in al, dx    
   > >>> nop    
   > >>>    
   > >>> or di, ax    
   > >>> add di, cs:[mouse_x]    
   > >>>    
   > >>> mov dx, HEX (03F8)    
   > >>> xor ax, ax    
   > >>> in al, dx    
   > >>> nop    
   > >>>    
   > >>> or si, ax    
   > >>> add si, cs:[mouse_y]    
   > >>>    
   > >>> but the initial values seem a bit off (e.g. for Y I have 205 and X is   
   77), have I mixed up the values or am I just doing the calculations wrong   
   after I read the port?    
   > >> the mouse sends a sequence of bytes where every byte causes in IRQ.    
   > >> so you first need to fill a buffer with the gotten bytes before you can    
   > >> calculate/scale/interpret the values. mouse IRQs can easy come out of    
   > >> sync, so checking always for the first byte mark is a good idea.   
   > > Oh I thought you had to get them all at the same time when the interrupt   
   was fired. As for filling the buffer how would I tell the interrupts apart? I   
   can test for 0x40 and 0x01 (which I'm already doing) I'm just a little   
   confused how I would know    
   whether it's the 1st, 2nd and 3rd bytes.   
   > there is a mark for the first byte (reread the RBIL I posted)    
   > I use one variable for count down (easier than count up) and use this    
   > with BX as an index into my buffer.    
   > and when the buffer is filled I adjust all my mouse-variables which I    
   > later use on my mSec timer-base schedule to update cursor and act on    
   > buttons.    
   > __    
   > wolfgang   
   Yeah, there's bit 6 for the initial bit, I weren't sure if there's anything   
   identifying the others.  So basically have two variables one being a counter   
   and just write to the buffer until I get three (or if it's counting down then   
   it would be until I hit    
   zero)?  As for:   
      
   > I use one variable for count down (easier than count up) and use this    
   > with BX as an index into my buffer.   
      
   How do you use it for the buffer if your counting down?  If you were counting   
   up you could shl by 8 and add that to the buffer offset.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)