Re: [MiNT] XaAES / GEM memory issues

[Petr Stehlik <joy@sophics.cz>]

On Thu, 11 Jan 2001, Henk Robbers wrote:

> > > > So nobody (but me :) ever had the change to see that there is a little bug
> > > > in it.
> > Is there a bugfix for it?
> 
> Not yet. :-) Petr offered to help me with this.

that's true and I owe you the excuse that I haven't helped yet. I have
been facing hardware problems with my own machine lately and I am really
unable to do any serious work on it right now :-(

Anyway, before we start fixing anything, we should make clear how the
mouse should work in the first place (from enhanced AES' Fselect(mouse)
point of view) regarding the Fselect() versus VDI vq_mouse
synchronization. My opinion is still the same (perhaps based on wrong
information or assumption): if the AES itself or its applications use both
AES mouse information and VDI mouse calls then either AES must use VDI
mouse calls (1) or VDI must use the AES source of mouse information (2).

ad 1) VDI does not provide "nonblocking" mouse information (as Fselest()
does). For traditional AESes this was perhaps OK but with XaAES that is
able to sleep when there's no mouse activity (and continue to run other
apps even with a pull down menu pulled down) this is no longer an option.

ad 2) current ROM VDI (or NVDI) does not know /dev/mo[ou]se, naturally. I
suggested to try to learn it about that device with a TSR hack that would
replace certain VDI mouse calls. Naturally much better would be to
implement this into fVDI clearly and switch from current VDI to fVDI. This
might not be an option for everyone, though.

So my way is to analyze the possibility of hacking VDI and if it wasn't
working then jump on fVDI and learn it about /dev/mouse. Then XaAES could
switch from moose to mouse and everything would be just great :-)

Petr
--
News: Clocky 3.10b, PARCP 3.80!, Atari800 1.04 at http://joy.atari.org/