corrected mouse device specs on day 5

This commit is contained in:
sejo 2022-01-07 15:15:29 -06:00
parent 118503c983
commit 3aa890efe4
1 changed files with 57 additions and 25 deletions

View File

@ -6,32 +6,56 @@ we also discuss possible structures to create loops and more complex programs us
# the mouse device
the mouse device in the varvara computer is similar to the controller device in several ways: it has a vector that is called with any mouse event (change of buttons state, movement, wheel movement) and a couple of bytes to check its state.
the mouse device in the varvara computer is similar to the controller device in several ways: it has a vector that is called with any mouse event (change of buttons state, movement, scroll movement) and a couple of bytes to check its state.
additionally, it has a couple of shorts corresponding to the x,y coordinates of the mouse pointer.
we see this device defined in uxntal in the following way:
```
|90 @Mouse [ &vector $2 &x $2 &y $2 &state $1 &wheel $1 ]
|90 @Mouse [ &vector $2 &x $2 &y $2 &state $1 &pad $3 &scrollx $2 &scrolly $2 ]
```
## state byte
the state byte has these possible values:
the state byte encodes the on/off state of up to 8 buttons in the mouse; one per bit.
* 01 when the left button is pressed
* 10 when the right button is pressed
* 11 when both buttons are pressed
counting from right to left, the first bit corresponds to the first mouse button, the second bit to the second mouse button, and so on.
usually, in a three-button mouse, the first button is the left one, the second button the middle one, and the third button the right one.
using a three-button mouse like this, we would have eight possible values for the state byte, for example:
* 00 when none of the buttons are pressed
* 01 when only the first button is pressed
* 02 when only the second button is pressed
* 04 when only the third button is pressed
## wheel byte
note that similarly to the controller device, this system allows us to check for several buttons pressed at once:
the wheel byte has these possible values:
* 03 when the first and second buttons are pressed
* 05 when the first and third buttons are pressed
* 06 when the second and third buttons are pressed
* 07 when the threee buttons are pressed
* 01 when the mouse wheel is moving upwards
* ff when the mouse wheel is moving downwards
* 00 when the mouse wheel is not moving
remember that we can use AND masks, as introduced on {uxn tutorial day 3}, to isolate and evaluate separately any of these bits.
## scroll shorts
the mouse device has a couple of shorts to indicate if the mouse is scrolling.
scrolly will indicate a vertical scroll with a "positive" value when moving upwards (or actually, "away from the user"), and a "negative" value moving downwards (or "towards the user")
* 0001 when scrolling upwards
* ffff when scrolling downwards
* 0000 when not moving
similarly, scrollx will indicate an horizontal scroll
* 0001 when scrolling to the right
* ffff when scrolling to the left
* 0000 when not moving
depending on the device, the values can be greater than 0001 or less than ffff depending on the speed of the scrool.
## mouse vector
@ -46,7 +70,7 @@ the mouse vector will be fired in any of the following events:
let's start drawing!
the following is a simple example that illustrates the use of
the following is a simple example that illustrates the use of the following elements:
* mouse vector
* mouse x and y coordinates
@ -64,7 +88,7 @@ it draws our square in the position of the mouse, changing its color when any mo
( devices )
|00 @System [ &vector $2 &pad $6 &r $2 &g $2 &b $2 ]
|20 @Screen [ &vector $2 &width $2 &height $2 &pad $2 &x $2 &y $2 &addr $2 &pixel $1 &sprite $1 ]
|90 @Mouse [ &vector $2 &x $2 &y $2 &state $1 &wheel $1 ]
|90 @Mouse [ &vector $2 &x $2 &y $2 &state $1 &pad $3 &scrollx $2 &scrolly $2 ]
( init )
|0100
@ -85,7 +109,7 @@ BRK
.Mouse/x DEI2 .Screen/x DEO2
.Mouse/y DEI2 .Screen/y DEO2
( jump if a button is pressed )
( jump if any button is pressed )
.Mouse/state DEI ,&pressed JCN
( draw sprite using color 2 and 0 in background )
@ -116,7 +140,7 @@ this procedure can happen whenever the mouse vector is fired.
we can use a set of variables in the zero page in order to store the pointer position, so that we have a way of clearing the sprite in the previous coordinates of the mouse.
additionally, here we have a 1bpp sprite of a mouse pointer, taken from the uxn examples:
additionally, here we have the data of a 1bpp sprite of a mouse pointer, taken from the uxn examples:
```
@pointer_icn [ 80c0 e0f0 f8e0 1000 ]
@ -132,7 +156,7 @@ this is a program that accomplishes drawing the pointer on the screen!
( devices )
|00 @System [ &vector $2 &pad $6 &r $2 &g $2 &b $2 ]
|20 @Screen [ &vector $2 &width $2 &height $2 &pad $2 &x $2 &y $2 &addr $2 &pixel $1 &sprite $1 ]
|90 @Mouse [ &vector $2 &x $2 &y $2 &state $1 &wheel $1 ]
|90 @Mouse [ &vector $2 &x $2 &y $2 &state $1 &pad $3 &scrollx $2 &scrolly $2 ]
( zero page )
|0000
@ -182,7 +206,7 @@ this blending mode would allow you to draw things in the background and have the
i invite you to try this!
draw in the background and see how the pointer looks, and then replace its sprite byte with e.g. 42 to see the difference!
draw some things in the background and see how the pointer looks as it is now. then replace the pointer's sprite byte with e.g. 42 to see the difference!
### some issues
@ -192,7 +216,7 @@ that's even more true if we consider that we are only drawing the pointer, and n
creating a macro for all this code could be possible, but also kind of impractical due to the amount of code.
maybe we could have a JMP to another section of the program, that at its ends has another JMP to return to the corresponding position in the on-mouse subroutine?
maybe we could have a JMP to another section of the program, that at its end has another JMP to return to the corresponding position in the on-mouse subroutine?
actually, that's almost what we will do, but with an additional element of uxn: its return stack!
@ -233,6 +257,13 @@ first of all, let's move our pointer drawing subroutine to another label in our
#4a .Screen/sprite DEO
BRK
```
note that we could join the actions of updating the pointer position and sending it to the screen, using a pair of DUP2:
```
( update pointer position and send to screen )
.Mouse/x DEI2 DUP2 .pointer/x STZ2 .Screen/x DEO2
.Mouse/y DEI2 DUP2 .pointer/y STZ2 .Screen/y DEO2
```
this would leave our on-mouse subroutine empty:
@ -242,13 +273,6 @@ this would leave our on-mouse subroutine empty:
BRK
```
note that we could join the update pointer position with sending it to the screen, using a pair of DUP2:
```
( update pointer position and send to screen )
.Mouse/x DEI2 DUP2 .pointer/x STZ2 .Screen/x DEO2
.Mouse/y DEI2 DUP2 .pointer/y STZ2 .Screen/y DEO2
```
### using normal jumps
@ -282,6 +306,8 @@ at the end of our draw-pointer subroutine, we'd need to "jump back" like this:
;on-mouse/return JMP2
```
it would work, but it's not the best approach.
let's meet an alternative, the "jump and stash" instruction!
# jump and stash
@ -332,6 +358,12 @@ whenever this flag is set, uxn will perform the given instruction but using as s
in uxntal, we indicate that we want to set this flag adding the letter 'r' to the end of an instruction mnemonic.
for example, the following code would push two numbers down into the return stack, add them, and push the result back into the return stack:
```
LITr 01 LITr 02 ADDr
```
as each of the modes is an independent bit, it is possible to combine them, e.g. activating the return mode and the short mode by using the suffix '2r'.
## jumping to return