Wondering about INT 33h ... Questions
wolf3y3
I got out my reference on the INT 33 functions, got the
cursor to display, move around, amusing...
Once and a while I run the application and it immediately returns
even if there was no button press (on the actual mouse),
MS-Edit seems to work fine still when this happens so I believe
my problem is with my code or what its missing.
Here is my code:
bits 16
org 100h
mov ax, 0xdead
call printw
mov ax, 0 ; Reset driver
int 0x33 ; Mouse interrupt
mov ax, 1 ; Show mouse cursor
int 0x33
loop:
call getcords ; read back coordinates in CX & DX and button status in
BX
test bx, 1 ; bit 0 set then left button pressed
jnz exit ; if so exit and print coordinates
jmp loop
exit:
mov ax, cx ; column
call printw ; print value of AX
mov ax, dx ; row
call printw
ret
getkey:
mov ah, 6 ; Function 6 Direct Con I/O
mov dl, 0xff ; DL==255 input from keyboard
int 0x21 ; call DOS function request interrupt
jnz getkey_exits ; if ZF=0 then keystroke is available
ret
getkey_exits:
pop ax ; pop return offset for getkey routine
jmp exit
getcords:
mov ax, 3 ; Get position and button status
int 0x33 ; Mouse interrupt
mov ax, cx ; CX=column in multiples of 8 (text cell size)
call changecord ; convert to text screen coordinate
mov cx, ax
mov ax, dx ; DX=row in multiples of 8 as well...
call changecord
mov dx, ax
ret
changecord:
cmp ax, 0 ; if 0 then no division necessary
jz changecord_e ; was 0? then immediately return
shr ax, 3 ; divide by 8, 2^3
changecord_e:
ret
printw: ; prints hex values to screen
push ax
shr ax, 8
call printb
pop ax
push ax
and ax, 0xff
call printb
pop ax
ret
printb:
push ax
shr al, 4
call printasc
pop ax
and al, 0xf
call printasc
ret
printasc:
push dx
add al, 0x30
cmp al, 0x39
jle printasc_e
add al, 7
printasc_e:
mov dl, al
mov ah, 2
int 0x21
pop dx
ret
wolfgang kern
wolf3y3 wrote:
> I got out my reference on the INT 33 functions, got the
> cursor to display, move around, amusing...
> Once and a while I run the application and it immediately returns
> even if there was no button press (on the actual mouse),
> MS-Edit seems to work fine still when this happens so I believe
> my problem is with my code or what its missing.
I don't use INT 33h since long, but this is another story ...
so what I can remember is that int33-0 answers with:
AX = FFFF ;0000 if no driver found or the mouse didn't respond in time.
BX = button-count.
IIRC there once were a recommendation to clear BX before int33-3 to
overcome driver-faults.
And not all mouse drivers may do the required delay after mouse-RESET
(5 to 200mS before you can use other mouse-functions), so I added one.
Out of sync-errors caused by too long lasting event handling can also
spoil the game, especially on the PS/2 shared keybd/mouse port 60h.
__
wolfgang
Rod Pemberton
"wolf3y3" <wol...@MUNGED.microcosmotalk.com> wrote in message
news:4b1617a0$0$4878$9a6e...@unlimited.newshosting.com...
>
> Once and a while I run the application and it immediately returns
> even if there was no button press (on the actual mouse),
>
I'm not experiencing this problem with your code. The problem could be the
mouse, the mouse driver, the BIOS, the type or version of DOS, the DOS
environment: Windows console or Linux DOSEMU, or even the keyboard - IRQ
priorities...
I only tested on only one machine, with only one mouse, and only one
keyboard. I moved the mouse rapidly, slowly, moved the third wheel, pressed
various mouse buttions - except left, and I also tried to mess it up with
interspersed keyboard keypresses, etc. I tested under real mode MS-DOS
v7.10 (Win98SE) with CuteMouse mouse driver. I didn't test in a Windows
console.
I'm using CuteMouse V2.0 Alpha 4. It's been a while since I updated
CuteMouse, so I haven't tried the V2.1 series. IIRC, I had problems with
the V1.9 series on the machine prior to this one.
http://cutemouse.sourceforge.net/
> bits 16
> org 100h
>
> mov ax, 0xdead
> call printw
> mov ax, 0 ; Reset driver
> int 0x33 ; Mouse interrupt
RBIL suggests doing some checks before calling int 0x33, ax=0h.
> [...]
> loop:
> call getcords ; read back coordinates in CX & DX and button status in
> BX
> test bx, 1 ; bit 0 set then left button pressed
> jnz exit ; if so exit and print coordinates
> jmp loop
FYI, NASM, at least the older version of it, doesn't like instructions as
labels. "loop" is an instruction. Otherwise, this compiles with NASM.
> [...]
> getkey:
> mov ah, 6 ; Function 6 Direct Con I/O
> mov dl, 0xff ; DL==255 input from keyboard
> int 0x21 ; call DOS function request interrupt
> jnz getkey_exits ; if ZF=0 then keystroke is available
> ret
getkey doesn't seem to be used.
> getkey_exits:
> pop ax ; pop return offset for getkey routine
> jmp exit
getkey_exits doesn't seem to be used
> [...]
> mov ax, cx ; CX=column in multiples of 8 (text cell size)
> call changecord ; convert to text screen coordinate
> mov cx, ax
If you take my suggestion below on "changecord", this can be replaced with:
shr cx,3
> mov ax, dx ; DX=row in multiples of 8 as well...
> call changecord
> mov dx, ax
If you take my suggestion below on "changecord", this can be replaced with:
shr dx,3
>[...]
> changecord:
> cmp ax, 0 ; if 0 then no division necessary
> jz changecord_e ; was 0? then immediately return
> shr ax, 3 ; divide by 8, 2^3
> changecord_e:
> ret
Is there really a need to _not_ shift ax by 3 when ax is zero? I.e., this
is effectively "shr ax,3" and can be eliminated by rolling into code above.
AFAICT, the comparison and branch are only slowing down the code.
My hex and print routines are "horrible," so I'll let someone else critique
those.
Rod Pemberton
wolf3y3
Thanks on that one not bitshifting when zero was qwite
unnecessary I was being a dumbass, because 0000 >> 3 = 0000.
I've tried your suggestions hasn't eliminated the problem
yet, thanks for the replies.
Jim Leonard
On Dec 12, 9:05=A0pm, wolf3y3 <wolf...@MUNGED.microcosmotalk.com> wrote:
> Thanks on that one not bitshifting when zero was qwite
> I've tried your suggestions hasn't eliminated the problem
> yet, thanks for the replies.
How are you compiling/running? Are you doing so with a buttonclick?
If so, is it possible that the button might still be down or
registered as down when the program starts up?
I ran into this writing mouse code on a fast (at the time) Pentium. I
would click compile->run in my IDE and ran into race conditions, etc.
I learned to hit ctrl-F9 instead.