🚀 go-pugleaf

In article <1992Oct5.000501.3735@ccu1.aukuni.ac.nz> stuartw@ccu1.aukuni.ac.nz (Stuart Woolford) writes:

>How do you write a routine in pascal ( or C...asm...etc ) which will be called
>by the standard callback function of the driver ( when a button is pressed, etc
>), and which can still address the programs global variables, the problem is
>that, when the routine is called, DS points at the MOUSE DRIVERS data segment,
>and I at least could not think of an easy way to address the programs global
>data, which will NOT be at a fixed address :-(

You could stick a copy of the program's DS into the ICA (4F0:0-F) on
startup and then have your routine pick it up from there.

************************************************************************
A note to new readers:  the weasely :-) symbol is frowned upon in this
group.  Any questions, see Phil Gustafson who will gladly rearrange your
diodes for you.
			- From the AFU FAQ -

	- pynq@quads.uchicago.edu, who is still costing the net
	  hundreds, if not thousands, of dollars, every time he posts -
************************************************************************

stuartw@ccu1.aukuni.ac.nz (Stuart Woolford) writes:


> A friend of mine has a small problem with the useage of Msoft mouse drivers...

>How do you write a routine in pascal ( or C...asm...etc ) which will be called
>by the standard callback function of the driver ( when a button is pressed, etc
>), and which can still address the programs global variables, the problem is
>that, when the routine is called, DS points at the MOUSE DRIVERS data segment,
>and I at least could not think of an easy way to address the programs global
>data, which will NOT be at a fixed address :-(


I have used the following as inline assembler with Turbo-C. It works. 
I couldn't think of a pure C way to do it.

    push ds
    mov  ds seg DGROUP

    ......

    pop ds

This works because T-C keeps its global variables in a group called 
DGROUP. Basically what you have to do is get ds loaded with a 
_constant_ of the correct value, since no registers have what you want 
when the call occurs. The above code generates such a constant (fixed 
up at link time, of course).


>Also, he said that there is a problem with the mouse in all 256 color VGA modes
>( under TP 6.0, using BGI's ), any comment ????

Are BGI's supposed to support the mouse? The usoft mouse driver 
doesn't really support anything but the standard IBM video modes, i.e. 
only 320x200 (yecch!) if you want 256 colours. You can do it yourself, 
the hard way, by only using the lowest level mouse calls, and 
drawing/erasing the pointer yourself, as required.


>any replies appreciated...

>------------------------------------------------------------------------------
>stuartw@ccu1.aukuni.ac.nz

>   >>>>In VI Where Available<<<<
>------------------------------------------------------------------------------

gay@selkirk.sfu.ca (Ian D. Gay) writes:

>stuartw@ccu1.aukuni.ac.nz (Stuart Woolford) writes:


>> A friend of mine has a small problem with the useage of Msoft mouse drivers...

>>How do you write a routine in pascal ( or C...asm...etc ) which will be called
>>by the standard callback function of the driver ( when a button is pressed, etc
>>), and which can still address the programs global variables, the problem is
>>that, when the routine is called, DS points at the MOUSE DRIVERS data segment,
>>and I at least could not think of an easy way to address the programs global
>>data, which will NOT be at a fixed address :-(


>I have used the following as inline assembler with Turbo-C. It works. 
>I couldn't think of a pure C way to do it.

>    push ds
>    mov  ds seg DGROUP

sorry, not thinking, that should be
     push ds
     mov ax, seg DGROUP
     mov ds,ax
since you cant load a constant to a segment register



>    ......

>    pop ds

>This works because T-C keeps its global variables in a group called 
>DGROUP. Basically what you have to do is get ds loaded with a 
>_constant_ of the correct value, since no registers have what you want 
>when the call occurs. The above code generates such a constant (fixed 
>up at link time, of course).


>>Also, he said that there is a problem with the mouse in all 256 color VGA modes
>>( under TP 6.0, using BGI's ), any comment ????

>Are BGI's supposed to support the mouse? The usoft mouse driver 
>doesn't really support anything but the standard IBM video modes, i.e. 
>only 320x200 (yecch!) if you want 256 colours. You can do it yourself, 
>the hard way, by only using the lowest level mouse calls, and 
>drawing/erasing the pointer yourself, as required.


>>any replies appreciated...

>>------------------------------------------------------------------------------
>>stuartw@ccu1.aukuni.ac.nz

>>   >>>>In VI Where Available<<<<
>>------------------------------------------------------------------------------