On Sun, 14 Apr 2002 00:52:16 +0200
Henk Robbers <h.robbers@...> wrote:
> mdoering@... wrote:
> > Shit!
> > The linea variables are wrong. The distance in bytes is not correct.
> > So WE will have no problem, but programs running on top of us will:
> > save_addr: .ds.l 1 // -328 return address GEMDOS call
> > save_stat: .ds.w 1 // -324
> > /* Sprite save buffer */
> > save_area: .ds.l 0x40 // -322
> > /* Timer vectors */
> > _tim_addr: .ds.l 1 // -66 timer interrupt vector
> > Must be:
> > save_area: .ds.l 0x42 // -330
> Are you sure of this?
> The Profibuch TT says (page 309)
> long save_area[$40(64)] at -$142(-322)
> > Shit, shit shit.... Will too check the rest of it... And I bet,
> > XaAES will use them, because it needs to do so. Otherwise the mouse
> > button vector is useless.
> Linea isnt used in any way by neither vmoose nor XaAES.
> The use of thr VDI vectors made this possible.
> Another reason of using them.
> Yet another reason for using the vectors:
> I can stick to maccel3 (Yes very old, but I like its proportionality
> the most on my TTM195)
> This is what vmoose expects and what you must provide, whether the
> vectors are exchanged or not:
> button vector:
> new button state in DO
Yes, this is ok. And it is exactly, like in TOS 1.0. I did check this.
This is a part of our interrupt routine:
and.w #3, d0 // isolate mouse buttons
lsr.b #1, d0 // left button pressed?
bcc no_left // no
bset #1, d0 // set bit 0 for left button
move.b _cur_ms_stat,d1 // get previous mouse state
and.w #3,d1 // mask out state codes bits 6,7
cmp.b d1,d0 // has button state changed
beq xy_update // no go test x,y change
move.w d1,-(sp) // save previous mouse state
move.l _user_but,a1 // get user routine address
move.w (sp)+, d1 // get back previous mouse button state
eor.b d0, d1 // compute which buttons have changed
ror.b #2, d1 // put deltas in bits 6 & 7
or.b d1, d0 // combine deltas and states
move.b d0,_cur_ms_stat // store change in button stat
There is not much between this mouse driver and your XaAES. So really I
think, there could be something else, that stays it away from functioning.
> mouse move vector:
> new absolute x in D0
> new absolute y in D1
This still works. I can move and see the mouse. It is mysterious. :-|
Ok, with the clipping there is something not sooo good. I made the
mousedriver working, before the VDI is up. so there is no workstation
information, and the clipping must be wrong, because it depends on it. But
at the time, when XaAES is started, the VDI and it's Workstation gets
initialized. So everything should be fine then.
Can you (if you have time) send me some code, that shows, what XaAES gets
- just for the buttons?