Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Lonewolf10]

Hi,

I have just re-read the html version of the manual regarding the Limit Mouse command. It states that you are supposed to use hardware coordinates when using the command, for example:

Code: [Select]

Limit Mouse XHard(0),YHard(0) To XHard(320),YHard(250)

I can amend the code so that it automatically uses hardware coordinates all the time. Is this a good idea??

Also, the Limit Mouse (with no specified limits) automatically limits it to the size of the screen, sort of. On a 320x250 screen it allows the mouse to move an extra 10 pixels past the right of the screen (e.g. to 330,Y), an additional 12 pixels past the bottom of the screen (e.g. to X,262) and similarly when you move the mouse off the left (an extra 16 pixels!) and top (an extra 15 pixels!).
This seems odd to me. Is this also worth fixing, or is there a reason for this strange behaviour?

I have attached a .zip containing an Excel file with notes. The first tab contains some of bruceuncles notes regarding +w.s, whilst the 2nd tab is what I worked on today and includes the sourcecode relating to the Limit Mouse commands.

[SamuraiCrow]

Hi,

I have just re-read the html version of the manual regarding the Limit Mouse command. It states that you are supposed to use hardware coordinates when using the command, for example:

Code: [Select]

Limit Mouse XHard(0),YHard(0) To XHard(320),YHard(250)

I can amend the code so that it automatically uses hardware coordinates all the time. Is this a good idea??

Yes and no.  Remember that the AGA chipset has 4 times the horizontal coordinate resolution of ECS.  Other than that, it should work as the manual states.

Also, the Limit Mouse (with no specified limits) automatically limits it to the size of the screen, sort of. On a 320x250 screen it allows the mouse to move an extra 10 pixels past the right of the screen (e.g. to 330,Y), an additional 12 pixels past the bottom of the screen (e.g. to X,262) and similarly when you move the mouse off the left (an extra 16 pixels!) and top (an extra 15 pixels!).
This seems odd to me. Is this also worth fixing, or is there a reason for this strange behaviour?

It all depends on the size and hot-spot of the mouse pointer.  Is it taking those numbers for granted or is it calculating them properly?

I have attached a .zip containing an Excel file with notes. The first tab contains some of bruceuncles notes regarding +w.s, whilst the 2nd tab is what I worked on today and includes the sourcecode relating to the Limit Mouse commands.

THanks.  I'll look at it and post back here once I figure it out.

[Lonewolf10]

Hi,

I have just re-read the html version of the manual regarding the Limit Mouse command. It states that you are supposed to use hardware coordinates when using the command, for example:

Code: [Select]

Limit Mouse XHard(0),YHard(0) To XHard(320),YHard(250)

I can amend the code so that it automatically uses hardware coordinates all the time. Is this a good idea??

Yes and no.  Remember that the AGA chipset has 4 times the horizontal coordinate resolution of ECS.  Other than that, it should work as the manual states.

I have no experience or real knowledge about AGA hardware at present. I'm glad I asked before proceeding

Also, the Limit Mouse (with no specified limits) automatically limits it to the size of the screen, sort of. On a 320x250 screen it allows the mouse to move an extra 10 pixels past the right of the screen (e.g. to 330,Y), an additional 12 pixels past the bottom of the screen (e.g. to X,262) and similarly when you move the mouse off the left (an extra 16 pixels!) and top (an extra 15 pixels!).
This seems odd to me. Is this also worth fixing, or is there a reason for this strange behaviour?

It all depends on the size and hot-spot of the mouse pointer.  Is it taking those numbers for granted or is it calculating them properly?

For Limit Mouse it is taking the size of the screen and calculating the limits accordingly. Should they be greater than like 660x524 (in screen coords) it automatically sets the limits to 660x524.
As far as I can see it is not taking the mouse pointer size or hotspot into account, just the size of the screen.


For Limit Mouse X1,Y1 To X2,Y2 it sets them up assuming the coordinates given are hardware coordinates (e.g. X1=128+Screen coord). Should X2/Y2 be smaller than X1/Y1 then the coordinates are switched as appropriate (so that registers d1 and d2 contain the top-left corner of the area limit and d3 and d4 contain the bottom right corner of the area).

I have attached a .zip containing an Excel file with notes. The first tab contains some of bruceuncles notes regarding +w.s, whilst the 2nd tab is what I worked on today and includes the sourcecode relating to the Limit Mouse commands.

THanks.  I'll look at it and post back here once I figure it out.

I hope you can understand it. I flagged up the lsl's with a background colour of red as I couldn't see what that would do. I now think they are converting the coordinates to the equivalent highres values.
Am I right, or am I misunderstanding something? (If I am, forgive me. I'm not used to constant 30 degree celsius heat here in the UK, as we have had for the last week and a bit).

[bruceuncle]

I hope you can understand it. I flagged up the lsl's with a background colour of red as I couldn't see what that would do. I now think they are converting the coordinates to the equivalent highres values.

For some reason, AMOS keeps the mouse coords in two places:

+WEqu.s - starting line 174

***************************************************************
*      SPRITES HARD
***************************************************************
HsNb      equ    64
* Limites souris (= Mouse limits)
      Rw   MouYMax,1
      Rw   MouXMax,1
      Rw   MouYMin,1
      Rw   MouXMin,1

* Gestion souris (= Mouse management)
      Rw   MouYOld,1
      Rw   MouXOld,1
      Rw   MouHotY,1
      Rw   MouHotX,1
      Rw   MouseY,1
      Rw   MouseX,1
      Rw   MouseDY,1
      Rw   MouseDX,1
      Rw   YMouse,1
      Rw   XMouse,1
      Rw   OldMk,1

These are in the negative offset A5 data area used by amiga.library.  So in the code they will all have the T_ prefix put there by the Rl, Rw and Rb macros.

In the VBL interrupt routines:

+W.s - starting line 10524

******* Traitement de la souris (= Process the mouse)
MousInt: tst.b    T_AMOSHere(a5)
         beq      MouF

         move.w   T_MouseX(a5),d0
         move.w   T_MouseY(a5),d1

; Limite la souris (= Limit the mouse)
MouV7    cmp.w    T_MouXMin(a5),d0
         bge.s    Mou5
         move.w   T_MouXMin(a5),d0
Mou5:    cmp.w    T_MouXMax(a5),d0
         ble.s    Mou6
         move.w   T_MouXMax(a5),d0
Mou6:    cmp.w    T_MouYMin(a5),d1
         bge.s    Mou7
         move.w   T_MouYMin(a5),d1
Mou7:    cmp.w    T_MouYMax(a5),d1
         ble.s    Mou8
         move.w   T_MouYMax(a5),d1
Mou8:    move.w   d0,T_MouseX(a5)
         move.w   d1,T_MouseY(a5)
         lsr.w    #1,d0
         lsr.w    #1,d1
         move.w   d0,T_XMouse(a5)
         move.w   d1,T_YMouse(a5)

So, for some reason MouseX and MouseY are always twice the values in X_Mouse and Y_Mouse.  Don't know why - yet!

While you guys are looking at the Limit Mouse bugs, you might want to also look at the mouse limiting bug in Resource Screen Open.  No matter what screen size is specified, the mouse is limited to whatever size is set for the Default screen.  As the Default screen is set to 320 x 200 when AMOS Pro is installed, opening a Resource screen in 320 x 256 (or 640 x 256) limits the mouse vertical to 200 lines.  Easy fixed by setting the Default screen to suit your monitor, but still a bug.

If it's any help, these are the only references to these definitions:

File +w.s:

T_MouseX
10528         move.w   T_MouseX(a5),d0
10544      Mou8:   move.w   d0,T_MouseX(a5)
10940      MSa2:   move.w   d1,T_MouseX(a5)
12760         add.w   d1,T_MouseX(a5)
T_MouseY
10529         move.w   T_MouseY(a5),d1
10545         move.w   d1,T_MouseY(a5)
10953      MSa4:   move.w   d2,T_MouseY(a5)
12762         add.w   d1,T_MouseY(a5)
T_XMouse
9091       AmXMou:   move.w   T_XMouse(a5),d2
10548         move.w   d0,T_XMouse(a5)
10735         move.w   T_XMouse(a5),d2
10783         move.w   T_XMouse(a5),d1
10860         move.w   T_XMouse(a5),d1
10869         move.w   T_XMouse(a5),d1
10942         move.w   d1,T_XMouse(a5)
11193      SyMouZ:   move.w   T_XMouse(a5),d3
T_YMouse
10549         move.w   d1,T_YMouse(a5)
10736         move.w   T_YMouse(a5),d3
10784         move.w   T_YMouse(a5),d2
10861         move.w   T_YMouse(a5),d2
10870         move.w   T_YMouse(a5),d2
10955         move.w   d2,T_YMouse(a5)
11194         move.w   T_YMouse(a5),d4

I'll join in with some of these bug fixes in more detail when I've finished the CSI AMOS stuff.

[Lonewolf10]

While you guys are looking at the Limit Mouse bugs, you might want to also look at the mouse limiting bug in Resource Screen Open.  No matter what screen size is specified, the mouse is limited to whatever size is set for the Default screen.  As the Default screen is set to 320 x 200 when AMOS Pro is installed, opening a Resource screen in 320 x 256 (or 640 x 256) limits the mouse vertical to 200 lines.  Easy fixed by setting the Default screen to suit your monitor, but still a bug.

There does appear to be a slight bug with it. I'm not familiar with the Resource Screen Open command, but a quick play tonight reveals the command format to be:

Resource Screen Open SCREEN,WIDTH,HEIGHT,BG_COLOR

The width is always in hires pixels!

The way round it is to do this:

Code: [Select]

Resource Screen Open SCREEN,WIDTH,HEIGHT,BG_COLOR
Wait VBL: Rem important, it takes 1 VBL for new screen settings to take effect
Limit Mouse: Rem mouse now limited to resource screen size


SamuraiCrow, have you had a chance to look at the Limit Mouse code? Does the extra few pixels have anything to do with hiding the mouse sprite from instantly appearing/disappearing apon reaching the limits?

[SamuraiCrow]

Re:LSR.W opcodes
Actually shifting to the right divides by two, thus converting high-resolution pixels to low-resolution ones.  On ECS the only way to have high-resolution sprite coordinates is to open the super-high-resolution screen mode.  All other screenmodes use low-resolution pixels.  This is also the default characteristic of AGA unless it uses an AGA-specific screenmode flag.

[bruceuncle]

The width is always in hires pixels!

The resolution (Hires/Lowres) will be what was used for the original picture.  That's the one used to define the graphic elements, lines and boxes used in Interface programs.

So, if the original piccie is Hires, the Width parameter will be in Hires pixels.  If it was Lowres, the Width parameter will be in Lowres pixels.

The Limit Mouse bug for Resource Screen Open is not related to the Limit Mouse instruction.  What happens is, after a Resource Screen Open (Hires source picture or Lowres source picture) the mouse is trapped to the height of the Default screen no matter what you set for the Height parameter.

If AMOS Pro is installed on a PAL system, the Default screen height is set to 200 lines in Lowres.  So opening a resource screen 256 lines high sees the mouse trapped to the top 200 lines.

An easy fix is to set up the Default screen properly in the Editor's Config menu.  It's on the page 1 option button (from memory, I haven't got WINUAE and AMOS open while I write this).  Setting the Default Screen Size and Position also affects the Editor display.  So it's also well worthwhile if you find your Editor's display isn't positioned correctly on your screen.

That fixes the problem permanently, but it's not a programmatic solution.  So I see it as a bug 

I now use the Default Screen's hardware offsets to set up any screen in my code.  That way the screen will always be positioned perfectly for the user's setup (assuming they have set it up!).  The example below is from the DBL Editor code and opens a Resource Screen.  But it works for any screen:

   '
   '   Offsets from Screen Base address: 
   '
   GC_EC_WX=$52 : Rem    X display offset
   GC_EC_WY=$54 : Rem    Y display offset (in low byte)

   ...
   ...

   Auto View Off
   '  Grab the display offsets from the default screen;
   Default
   A=Screen Base
   G_XPOS=Deek(A+GC_EC_WX)
   G_YPOS=Deek(A+GC_EC_WY) and $FF
   Resource Screen Open 0,640,G_YSIZE,0
   Screen Display 0,G_XPOS,G_YPOS,640,G_YSIZE
   Auto View On
   Wait Vbl

[Lonewolf10]

The width is always in hires pixels!

The resolution (Hires/Lowres) will be what was used for the original picture.  That's the one used to define the graphic elements, lines and boxes used in Interface programs.

Ahh, I see now.

I spent a few hours today trying to dissect the source for the Resource Screen Open instruction. Simple put: it's a nightmare 
The main code calls subroutines, which call more subroutines, which call more subroutines, which call more subroutines and on and on...

The original method I had for dissecting instructions worked on Limit Mouse because it only used a handful of subroutines. My current ( **unfinished** ) notes will be attached to this post - a zipped excel file.
I'm going to try a new method where instead of listing all subroutine code on one tab, I will have a separate tab for each subroutine and store them in alphabetical order. The only catch is that I don't know how many tabs one Excel file can hold - though I do have one with 30 or so tabs, so I guess the limit may be 255/256. Does anyone here know the limit?

[bruceuncle]

The original method I had for dissecting instructions worked on Limit Mouse because it only used a handful of subroutines. My current ( **unfinished** ) notes will be attached to this post - a zipped excel file.
I'm going to try a new method where instead of listing all subroutine code on one tab, I will have a separate tab for each subroutine and store them in alphabetical order. The only catch is that I don't know how many tabs one Excel file can hold - though I do have one with 30 or so tabs, so I guess the limit may be 255/256. Does anyone here know the limit?

Yikes!  It'll drive you bonkers trying to do it like that.  Try putting a simple descriptor together for each lowest level subroutine:

• Name
• Brief description
• Parameters in (eg. d0=xxx, a0=yyy, a1=zzz, etc.)
• Results our (eg. d1=aaa)
• Data affected (eg. nnn(a5) updated with bbb, etc.)
• Registers preserved
• Resisters trashed

It gets rid of the blocks of code and lets you concentrate on what's actually going on.  Some of it can be flowcharted more easily then too.

You don't need to include all the stuff above each time.  Eg. if a routine just takes a couple of registers in and updates those registers and nothing else is affected, then the Data affected, Registers preserved and Registers trashed aren't needed.  And don't bother with the effects of any debug code.  We know AMOS Pro works 99% which is pretty good considering how complex it is.  Multi-tasking run lists from an interpreted Basic using interrupt control in a complex hardware environment.  Doesn't sound like a "walk in the park" does it?   

Good luck with it.  No one said it was easy...   

[Lonewolf10]

Yikes!  It'll drive you bonkers trying to do it like that.

It's already driven me bonkers!

Try putting a simple descriptor together for each lowest level subroutine:

• Name
• Brief description
• Parameters in (eg. d0=xxx, a0=yyy, a1=zzz, etc.)
• Results our (eg. d1=aaa)
• Data affected (eg. nnn(a5) updated with bbb, etc.)
• Registers preserved
• Resisters trashed

It gets rid of the blocks of code and lets you concentrate on what's actually going on.  Some of it can be flowcharted more easily then too.

How is a routine going to mess up "Resisters"?! 

That's a good idea. I may combine the two. A quick google has revealed this Excel macro:

Code: [Select]

Sub New_Sheets()
Dim intNumber As Integer, Counter As Integer
intNumber = _
Application.InputBox("Create how many sheets?", "Number of new sheets", "300")

Application.ScreenUpdating = False
For Counter = 1 To intNumber
Worksheets.Add
Next
Application.ScreenUpdating = True
End Sub

A test in Excel 2000 (9.0.3821 SR-1) reveals that the limit is not 255/256. The only limit appears to be memory

Good luck with it.  No one said it was easy...   

I never thought it was going to be easy, but I didn't expect it to be this insanely complicated...

[bruceuncle]

How is a routine going to mess up "Resisters"?!

Well, I do remember reading that being a bit careless accessing the hardware registers can 'cook' an Amiga.  So I suppose that could include a few resistors, capacitors, chips and tansistors.  But that would be really pedantic!   

I never thought it was going to be easy, but I didn't expect it to be this insanely complicated...

Also try just following what's happening to the data (a bit like the stuff I've been publishing).  A few routines will require a lot of head-scratching and mapping stuff out on paper.  But it's eventually the effect on the data that's important.  Like most things, start at the beginning.  That's why I'm up to my neck in the Loader and Interpreter rather than jumping into the deep end in the middle of display stuff.  Until I know how AMOS really works I'm steadfastly resisting that temptation. (And how AMOS really works is probably not at all like you might think!  This is a multi-tasking language that can be running AMAL, Menu and Interface programs all at once and still responding to Every n Proc instructions too.  I haven't got into that in any depth yet but it seems to put together lists of stuff to run - but don't quote me on that - I've only skimmed through that bit and could be completely wrong.)

And as you come across stuff in the data where you know what it's being used for, please document it.  I've got duplicate files of the AMOS includes and just update the comments as I come across stuff.  It finally ends up in my sources database.  Ideally, we want to be able to publish a documented source set - data and routines - when we've got through all this.

If you haven't found it already, use Google Translate for the French comments.  It works really well and puts my schoolboy French to shame (well, it was a long time ago  ).

[Lonewolf10]

How is a routine going to mess up "Resisters"?!

Well, I do remember reading that being a bit careless accessing the hardware registers can 'cook' an Amiga.  So I suppose that could include a few resistors, capacitors, chips and tansistors.  But that would be really pedantic!   

I did read somewhere about a register that is used to regulate the power - apparently the Amiga can call on more power when needed. I know modern CPU's can regulate their power consumption but I still don't fully understand how they can do that.

I never thought it was going to be easy, but I didn't expect it to be this insanely complicated...

Also try just following what's happening to the data (a bit like the stuff I've been publishing).  A few routines will require a lot of head-scratching and mapping stuff out on paper.  But it's eventually the effect on the data that's important.  Like most things, start at the beginning.

I plan to. Next step is to translate the french text to English (most of which can be easily done without using translators ), then I can really get to grips with what each routine is doing

And as you come across stuff in the data where you know what it's being used for, please document it.  I've got duplicate files of the AMOS includes and just update the comments as I come across stuff.  It finally ends up in my sources database.  Ideally, we want to be able to publish a documented source set - data and routines - when we've got through all this.

Yes, I plan to document and update source files where appropriate.

If you haven't found it already, use Google Translate for the French comments.  It works really well and puts my schoolboy French to shame (well, it was a long time ago  ).

I prefer Babelfish, but there are quite a few online translators about now.

[bruceuncle]

I prefer Babelfish, but there are quite a few online translators about now.

I got hooked on Google Translate because:

• You don't have to click a button - it does it as soon as you enter a phrase.
• Each translated word in a phrase can be clicked for a list of alternatives.
• If you pick an alternative, you can tell it that your choice is a better translation.  So you can steer it in the direction of techo-IT words rather than common everyday words.  Very useful for AMOS sources where Francois used words that are a bit ambiguous unless you know they're referring to a computer and hardware environment.

If you haven't used it for a while, have another look 

[james666]

I think I've found a fix for the Limit Mouse bug.  I tracked the problem back to the X Hard() and Y Hard() conversion functions in w.s (amos.library).  These rely on the EcWX and EcWY variables, which store the origin of the screen in hardware coordinates.  When a new screen is created there is a 1 vertical blank delay before EcWX and EcWY are updated in the EcCopper routine.  If you create a new screen, you therefore have to Wait Vbl before X Hard and Y Hard give the right answers.  This can be demonstrated with the following code:

Code: [Select]

Screen Open 0,640,256,2,hires
Print X Hard(0)
Print Y Hard(0)
Wait Vbl
Print X Hard(0)
Print Y Hard(0)


The Limit Mouse function calls exactly the same routines to get the screen limits so it too only works after a Wait Vbl.  My solution is to insert a patch in the EcView routine so that EcWX and EcWY are updated immediately when a screen is created.  X/Y Hard and Limit Mouse then seem to work correctly.  My patched amos.library and modified w.s source code are attached (patch starts at line 3282).

[Lonewolf10]

Thanks for that

Will download and install over the weekend.