added sys.waitrasterline() routine like sys.waitvsync() but wait for a given raster line

optimize uword <= $xx00 into msb(uword)<$xx

docs/source/structpointers.rst

@@ -19,18 +19,18 @@ Structs and Pointers
     if it is a pointer to a struct type.
     The compiler tries its best to give a descriptive error message but sometimes there is still a
     parser limitation that has to be worked around at the moment. For example, this pointer arithmetic
-    indexing syntax is not supported right now and will result in a parse error::
+    indexing syntax is not supported right now *to assign to* and will result in a parse error (note that
+    using it as an expression value does work correctly)::
 
         ^^Node  np
-        np[2].field = 9999
+        np[2].field = 9999          ; cannot assign to this yet
+        ubyte value = np[2].field   ; this does work though.
 
     To work around this (and similar) cases you'll have to break up the expression in multiple steps,
     in this case something like::
 
-        ^^Node thirdnode = &&np[2]
-        thirdnode.field = 9999
-
-    *Note: this example is not regular array indexing syntax, it's pointer arithmetic by indexing on the pointer itself. Regular array syntax is supported just fine for arrays containing pointers etc.*
+        ^^Node thenode = &&np[2]
+        thenode.field = 9999
 
 
 

docs/source/todo.rst

@@ -161,6 +161,7 @@ Libraries
 Optimizations
 -------------
 
+- while c64.RASTER!=lsb(line) or c64.SCROLY&$80==0 { }   generates code that really wants to use 1/0 boolean values as intermediates. why? can't that be optimized away?  I want it to use th BIT instruction on the msb even
 - check that expressions such as  targetvar = value1 + value2  , targetvar = value1 ^ value2   etc.   use the target variable directly and not use needless temp var / registers
 - Port benchmarks from https://thred.github.io/c-bench-64/  to prog8 and see how it stacks up.
 - Since fixing the missing zp-var initialization, programs grew in size again because STZ's reappeared. Can we add more intelligent (and correct!) optimizations to remove those STZs that might be redundant again?