Trying to read PS2 mouse clock/data

[jejump]

Hello my fellow.asm Programmers.  This is my first post ever to masm32 so I hope my question is posted in the correct place. 

I have a project I'm doing using a dedicated pentium III PC.  The main program is written in QB7 but all the hardware accessing is handled in a TSR assembled with Masm 6.11.  I'm hooking the 08h timer interrupt only.  The user interface is 4 momentary buttons and a 2-bit data wheel.  Those signals all land on LPT1 lines and now, that one and only parallel port is now completely consumed.  I also have the one and only com port used to talk to another piece of hardware.  I really need one more input line for a rotary key switch and I'm trying to avoid adding another LPT card just to obtain one more input line.  Both PS2 inputs will be  available to me in the end as there will be no keyboard or mouse, but during developing, I'm using a ps2 keyboard.  I want to pull the clock or data line low preferably on the mouse connector with the key switch and read the "stuck low" condition from the 8042 (or whatever is present).  I have successfully done so using the 8042 command A9h, but it isn't a clean straight forward reading of the line status.  For whatever reason, it causes undesired affects with the keyboard hardware.  I'm polling the status register at port 64h and obeying the rules as far as when to obtain hardware access, but there is something I'm not doing correctly still. 

Has anyone dealt with any similar issue? 

Thanks for reading,

John

[Gunther]

Hi jejump,

you should provide the critical part of your code, because remote diagnostics is mostly difficult. Welcome to the forum.

Gunther

[FORTRANS]

Hi,

   "The Undocumented PC", by Frank van Gilluwe has a good
description of the keyboard and PS/2 mouse system.  Your
description of reading the mouse status matches his as far as
I can tell.  What are the undesired affects that you see?

Regards,

Steve

[MichaelW]

For the PS/2 mouse port perhaps you could bypass some of the complexity by using the Interrupt 15h pointing device interface. I have no idea how practical this would be, because as far as I can see the attached device would need to more or less emulate a PS/2 mouse, or at least the packet interface.

I posted a test, coded in FreeBASIC, here.

I used to do a lot of coding in QB and PDS, sometimes combined with MASM modules, but for this sort of thing I now much prefer the DOS version of FreeBASIC, 32-bit instructions and address space, inline assembly (GAS, but using Intel syntax), naked functions, macros, etc.

[Gunther]

Hi Michael,

I posted a test, coded in FreeBASIC, here.

interesting code example, indeed. Thank you for sharing the source.

Gunther

[jejump]

Sorry for the long silence.  Had to tend to other things (Other reasons to pull out the reset of my hair).   

Here is the entire code for reading the mouse lines.  I haven't made it a part of the final routine for my project and won't until I work out the bugs, so it's its own little tsr for now. 

At present, I can run the subroutines in debug and things work like they should.  For some reason when I re-enable the 8042's ability to send keyboard interrupts, it generates an interrupt and tries to process the activity that was never meant for the keyboard.


John

[jejump]

I just caught something about my code.  I'm brand new to the loopnz instruction as of pursuing this whole mouse line idea thing.  Am I perhaps initializing the loop and/or comparing CX incorrectly?  It's initialized with 0 and soon after I compare to 0 for jumping.  Does loopnz decrement or increment CX, then examine for 0 or does it examine for 0 first?

[jejump]

I just answered my last question with debug  :lol:

[dedndave]

the LOOPZ, LOOPNZ, JCXZ instructions are a bit mystical in that they branch on an "unseen flag"
that is to say that the condition of CX = 0 does not set a zero flag that may be otherwise examined
that's an important concept because the condition of ZF is seperate

LOOPNZ decrements CX (without altering any visible flags)
if the zero flag is 0 from previous operations, and CX is not zero, it will branch to the label operand
otherwise, execution falls through

[jj2007]

that is to say that the condition of CX = 0 does not set a zero flag

Nice find - opens new options for cryptic and confusing code:
    dec eax
    mov ecx, somevar
    jecxz @F
    jne @B
:icon_mrgreen:

[dedndave]

i have used them for things other than loops (i.e. forward branches)

Code: [Select]

        loopnz  Label0
;
;
;
Label0:

[jejump]

I was hopeful about maybe using int 15h after the post from MichaelW.  There is some return information about interface (ok/error), but it doesn't make any distinction about the kind of error like communicating directly to the 8042 will do.  I guess stuck closed lines in either state is an interface error (3 returned in AH).  Thanks for posting Michael and to everyone for that matter.

[jejump]

Well, through trial and error (mostly error), I discovered that I can't leave the 2nd PS2 device (mouse) always enabled or it will be perceived as a keyboard action.  That's weird to me because they have separate IRQ lines leaving the 8042 hardware.  Anyway, I think I'm getting closer.

[jejump]

By George, I've actually done it!!  It only took 4 days! 

I learned other things about the interface that I was making assumptions about.  The clock and data signals DO NOT have any internal pull up devices on them.  They're floaters.  Add a couple of 4.7k resistors between the red wire and each input wire and she's stable.  If anyone thinks this would be useful for one of your own projects, hit me up for the source.  Thanks everybody

Jj