From mint-bounce@lists.fishpool.fi Sat Dec 27 19:11:49 2008 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=7LraGwasmqFqKU2gC0kmqcuNRL6i4AY+8YGdSggEXUw=; b=f+571YdCwYBzIw5XDRPy5u5yBDPfoKJOj2JLzQi4gh0q6Pc/af5Wce6DY6HJ94CEmd 4SLp48ndspugSluEmJyIb47QWaOYY9OmnReVoKS8JlIhZL7EQAszW2Z7tTF9dZyJczj4 aV/vFaLDVfbgwX8ald2GA0R5M/WcjPvMu6FF4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=m3/lHq/eV3sZgcCvl8lWDtNfP8IfnuKZHxV7IgIwPeIlC2TVdPMYVBxhmACxc+aDf3 cxbhCPdgItbMH7+7CZWCFd7jyciPCdVlMtS/pmpUjdcCsEslLL+EOKseXSaWBuTbILMy ivsTlXzkKOhQUbbd1/apq7To28s2nMyS8LR+s= Message-ID: Date: Sun, 28 Dec 2008 01:06:38 +0100 From: "Johan Klockars" To: mint@lists.fishpool.fi Subject: Re: [MiNT] an urgent GEM question :-) In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1230022147.7318.6.camel@joy> <20081223172329.6b2125e8@phineus> X-Google-Sender-Auth: 66b98563b88653b2 X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: johan@klockars.net Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: >>>> 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