sejo
/
compudanzas
2
3
Fork 3
Code Issues Pull Requests Projects Releases Wiki Activity

replaced #01 ADD or #0001 ADD2 with INC or INC2

This commit is contained in:
sejo 2021-08-18 13:01:10 -05:00
parent 5e5267791f
commit b3e6b72da4
1 changed files with 17 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

35
src/uxn_tutorial_day_4.gmo
View File

@ -55,7 +55,7 @@ BRK
#01 .Screen/pixel DEO
( increment Screen/x )
.Screen/x DEI2 #0001 ADD2 .Screen/x DEO2
.Screen/x DEI2 INC2 .Screen/x DEO2
BRK
```
@ -136,7 +136,7 @@ as an example, the following code would read the two bytes from pixel/x, increme
```
;pixel/x LDA2 ( load pixel/x into the stack )
#0001 ADD2 ( increment )
INC2 ( increment )
;pixel/x STA2 ( store the result into pixel/x )
BRK
@ -150,7 +150,7 @@ the following is a variation that also duplicates the new pixel/x value in order
```
;pixel/x LDA2 ( load pixel/x into the stack )
#0001 ADD2 ( increment )
INC2 ( increment )
DUP2 ( duplicate result )
.Screen/x DEO2 ( set as screen/x )
;pixel/x STA2 ( and store the result into pixel/x )
@ -160,7 +160,7 @@ BRK
@pixel [ &x $2 &y $2 ]
```
we could have achieved the same result by storing the result first, then re-loading it and sent it as an output.
we could have achieved the same result by storing the result first, then re-loading it and sending it as an output.
here we can see how a DUP2 can make that operation easier, as long as we keep a mental (or tangible!) model of what is happening on the stack.
@ -240,14 +240,14 @@ BRK
#01 .Screen/pixel DEO
( increment pixel/x )
.pixel/x LDZ2 #0001 ADD2 .pixel/x STZ2
.pixel/x LDZ2 INC2 .pixel/x STZ2
BRK
```
as an example to practice with the stack, note that the following instructions would also increment .pixel/x, but using its address only once:
```
.pixel/x DUP LDZ2 #0001 ADD2 ROT STZ2
.pixel/x DUP LDZ2 INC2 ROT STZ2
```
i recommend you to follow how the stack contents change in each of the steps :)
@ -258,7 +258,7 @@ a possible disadvantage is that it might be less readable. and a possible advant
```
( increment a short from the zero-page )
%ZP-INC2 { DUP LDZ2 #0001 ADD2 ROT STZ2 } ( zp-address -- )
%ZP-INC2 { DUP LDZ2 INC2 ROT STZ2 } ( zp-address -- )
```
## variables in relative addresses
@ -294,7 +294,7 @@ the following is the on-frame subroutine that draws the growing line, but storin
#01 .Screen/pixel DEO
( increment pixel/x )
,pixel/x LDR2 #0001 ADD2 ,pixel/x STR2
,pixel/x LDR2 INC2 ,pixel/x STR2
BRK
@pixel [ &x $2 &y $2 ]
@ -316,8 +316,7 @@ if we declared these variables as sublabels of on-frame, the code would look as
#01 .Screen/pixel DEO
( increment pixel/x )
,&pixel-x LDR2 #0001 ADD2 ,&pixel-x STR2
( .pixel/x DUP LDR2 #0001 ADD2 ROT STZ2 )
,&pixel-x LDR2 INC2 ,&pixel-x STR2
BRK
( on-frame local variables )
&pixel-x $2 &pixel-y $2
@ -401,7 +400,7 @@ BRK
( 2: change position )
( increment sprite/pos-x )
.sprite/pos-x LDZ2 #0001 ADD2 .sprite/pos-x STZ2
.sprite/pos-x LDZ2 INC2 .sprite/pos-x STZ2
( 3 : draw sprite )
( load x coordinate from zero page and send to screen )
@ -422,7 +421,7 @@ regarding optimization, and as an example, section 2 and the first part of secti
```
( 2: change position )
( increment sprite/pos-x )
.sprite/pos-x LDZ2 #0001 ADD2
.sprite/pos-x LDZ2 INC2
DUP2 ( duplicate result )
.sprite/pos-x STZ2 ( store the first copy of the result )
@ -512,7 +511,7 @@ BRK
&right
( increment sprite/pos-x )
.sprite/pos-x LDZ2 #0001 ADD2 .sprite/pos-x STZ2
.sprite/pos-x LDZ2 INC2 .sprite/pos-x STZ2
( 3 : draw sprite )
&draw
@ -541,7 +540,7 @@ for example, instead of having an unconditional increment in the x coordinate:
```
( increment sprite/pos-x )
.sprite/pos-x LDZ2 #0001 ADD2 .sprite/pos-x STZ2
.sprite/pos-x LDZ2 INC2 .sprite/pos-x STZ2
```
we could check first if it has reached a specific amount, like the width of the screen, and not increment if that's the case:
@ -554,7 +553,7 @@ EQU2 ( is x equal to screen width - 8 ? )
&increment
( increment sprite/pos-x )
.sprite/pos-x LDZ2 #0001 ADD2 .sprite/pos-x STZ2
.sprite/pos-x LDZ2 INC2 .sprite/pos-x STZ2
&continue
```
@ -576,7 +575,7 @@ we can apply those macros after incrementing or decrementing. for example:
```
( increment sprite/pos-x )
.sprite/pos-x LDZ2 #0001 ADD2
.sprite/pos-x LDZ2 INC2
.Screen/width DEI2 MOD2 ( apply modulo screen width )
.sprite/pos-x STZ2 ( store result )
```
@ -633,7 +632,7 @@ and in the on-frame subroutine we increment it:
```
( increment framecount )
.framecount LDZ #01 ADD .framecount STZ
.framecount LDZ INC .framecount STZ
```
note that we are using a single byte to count, so it will go from 0 to 255 in a little bit more than 4 seconds, and then restart when overflowing its count.
@ -812,7 +811,7 @@ BRK
@on-frame ( -> )
( 0: increment framecount )
.framecount LDZ #01 ADD .framecount STZ
.framecount LDZ INC .framecount STZ
( 1: clear sprite )
( clear sprite from the fg )