Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!unmvax!uokmax!gene
From: gene@uokmax.uucp (Gene E. Johannsen)
Newsgroups: comp.os.msdos.programmer
Subject: Re: Programming the Mouse
Message-ID: <1990Jul31.193800.18227@uokmax.uucp>
Date: 31 Jul 90 19:38:00 GMT
References: <1990Jul30.182430.7493@uokmax.uucp> <34725@ut-emx.UUCP>
Organization: Engineering Computer Network, University of Oklahoma, Norman, OK
Lines: 43

In article <34725@ut-emx.UUCP> readdm@walt.cc.utexas.edu (David M. Read) writes:
>In article [abridged] gene@uokmax.uucp (Gene E. Johannsen) writes:
>!>
>!>	I am writing a program that I want to use the mouse with.  I don't
>!>have a reference work to the mouse so I am using a list of interrupts.  Below
>!>is a small program I writing to learn how to use the mouse.  All it will do is
>!>set up and turn on the mouse and then print an '*' when I press the left
>!>button.  It prints the '*' but freezes immediately afterwards:
>!>
>!>.MODEL	SMALL
>!>
>!>.CODE
>!>
>!>  [...]
>!>
>!>BUTTON		PROC	FAR
>!>	push ax		;This is where the problem comes.  It prints 
>!>	push dx		;the '*' okay, but then it freezes.
>!>	mov ah,02h	
>!>	mov dl,2ah
>!>	int 21h
>!>	pop dx
>!>	pop ax
>!>	ret
>        ^^^
>!>BUTTON		ENDP
>!>
>!>	END
>>
>I may be wrong here, but shouldn't this be an 'iret' instruction?  After
>all, the routine *is* an interrupt service routine, called by a hardware
>interrupt...If you return with a regular 'ret' call, none of the registers
>are popped off the stack and restored to their state before the interrupt,
>and the CPU doesn't know where to pick up, so it *should* freeze!
>
>-Dave


I thought the same thing, but I tried 'iret' and it didn't work any better.
Anyway, I found my problem.  It is the 'int 21h' that freezes it.  I honestly
don't know why.

gene