z80: fix tricky memory initialization issue

Among random "better safe than sorry" changes, the real fix is in
changing "4" for "5" above _find declaration. This off-by-one error
had that word, which is the root word in z80, have a 0x01 prev field
instead of a 0x00 one.

When all memory was initialized to zero, it didn't matter, we ended
up hitting 0 prev and considered ourselves properly at the end of
dict.

When memory wasn't initialized, however, we would end up jumping at
all kinds of places, leading to random behavior.

blk/213

@@ -1,5 +1,5 @@
-VARIABLE ORG
-VARIABLE BIN( 0 BIN( !
+CREATE ORG 0 ,
+CREATE BIN( 0 ,
 VARIABLE L1 VARIABLE L2 VARIABLE L3 VARIABLE L4
 : A 7 ; : B 0 ; : C 1 ; : D 2 ;
 : E 3 ; : H 4 ; : L 5 ; : (HL) 6 ;

blk/243

@@ -3,7 +3,7 @@
 : BJP, BIN( @ + JP, ;
 : BJPc, BIN( @ + JPc, ;
 
-VARIABLE lblchkPS
+CREATE lblchkPS 0 ,
 : chkPS, lblchkPS @ CALL, ; ( chkPS, B305 )
 CREATE lblnext 0 , ( stable ABI until set in B300 )
 : JPNEXT, lblnext @ ?DUP IF JP, ELSE 0x1a BJP, THEN ;

blk/263

@@ -1,4 +1,4 @@
-VARIABLE XCURRENT
+CREATE XCURRENT 0 ,
 : XCON XCURRENT CURRENT* ! ;
 : XCOFF 0x02 RAM+ CURRENT* ! ;
 : (xentry) XCON (entry) XCOFF ;

blk/291

@@ -1,5 +1,5 @@
 ( Native words )
-H@ 4 + XCURRENT ! ( make next CODE have 0 prev field )
+H@ 5 + XCURRENT ! ( make next CODE have 0 prev field )
 CODE _find  ( cur w -- a f )
     HL POP, ( w ) DE POP, ( cur ) chkPS,
     HL PUSH, ( --> lvl 1 )

blk/387

@@ -10,7 +10,7 @@
 : BS? DUP 0x7f = SWAP 0x8 = OR ;
 
 : KEY
-    85 RAM+ @ ( (key) override )
+    0x55 RAM+ @ ( (key) override )
     ?DUP IF EXECUTE ELSE (key) THEN ;
 ( cont.: read one char into input buffer and returns whether we
   should continue, that is, whether CR was not met. )