[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] an urgent GEM question :-)



>>>> I don't think it was intended to work, in a graphics mode at least.
...
>>>> v_rvon(), etc. That is, functions that mainly make sense for a text
>>>> based (non-graphics) mode.
>>>
>>> For positioning the alpha cursor the function vs_curaddress is defined.
>>
>> That's why I was (in the very next paragraph) talking about the
>> "hardware mouse cursor".
>
> All the VDI docs I can find talk about the graphics cursor in connection
> with v_dspcur.  The Atari does not even have a genuine text mode.

But the thing is that GEM and the VDI predates the Atari machines (I'm
not sure about the actual release dates, but Digital Research was
definitely working on it long before Atari got involved). It was
developed for PC:s (well, originally for CP/M machines), where there
was indeed a real text mode. Thus it made (sort of) sense to have
support in the VDI for pure text output, which is what the VDI
function 5 (escape) set was for (well, there was some printer stuff
there too).

Anyway, I just happened to find the original VDI documentation (GEM
(TM) Programmer's Guide, Volume 1: VDI, First Edition: April 1985) and
it has the following to say regarding v_dspcur():

--- begin quote ---
This escape places a graphic cursor at the
specified location. The cursor is usually a
cross hair cursor and is of the same type as
that used for Input Locator, Request Mode. If
sample mode input is supported, the application
can use this call to generate the cursor for
Input Locator, Sample Mode. In memory-mapped
devices, the cursor is drawn in XOR mode so GEM
VDI can remove it.
--- end quote ---

This is distinct from the normal mouse cursor, about which the
following is said in one place:

--- begin quote ---
	The mouse form is drawn as follows:

			1.  The data under the mouse form is saved so
			    that it can be restored when the cursor
			    moves.
--- end quote ---

The above actually does not mention a hardware cursor, but it is also
obvious that it is not the normal mouse cursor that v_dspcur() is
doing anything with.

Even if v_dspcur() is indeed useless on the Atari machines, it's not
alone in being so. I doubt anyone has ever used the rest of the text
mode stuff, nor the Input Locator/Choice/String stuff (if that is even
implemented in the standard VDI, I have no idea). They are probably
just left over from the pre-VDI days. DR had something called GSX
earlier, where all these things were already available. Indeed, the
"GSX tm Graphics Extension Programmer's Guide", from 1983 says:

--- begin quote ---
Place Graphic Cursor at the specified location.
This is device dependent and can be an
underbar, block, or similar character.       This
cursor should be the same type as used for
request mode locator input.  In this way, if
sample mode input is supported, the application
may use this call to generate the cursor for
rubber band type d-awing.     In memory mapped
devices, it is drawn in XOR mode so that it can
be removed.  The cursor has no attributes; for
example, style or color index.
--- end quote ---

That manual does not mention any mouse cursor at all, and no functions
related to it existed.

To conclude, I don't think it's surprising that v_dspcur() doesn't do
what one might expect today. It's historical function apparently is
not hardware cursor related after all (rather something more much more
primitive), but still distinct from (and preceding) the mouse pointer.

To "compatibly" move the mouse pointer would probably require faking
movement via the vex_motv() vector. But that means supervisor mode and
masked interrupts.

/Johan