🚀 go-pugleaf

This issue is partially resolved.  It's apparently a bds2006 debugger issue.

Using a hacked program to externally read the debuggee process memory after 
a bogus trip (in the filler region being checked by bytesOK) shows that, in 
fact, the byte at that particular location is _NOT_ what the debugger is 
displaying in the CPU pane.  The debugger is displaying 0xff for location 
0x04403f8.  The hack program shows the byte as 0xcc (and all the other bytes 
in the filler region as 0xff, as does the debugger. hackprog also agrees 
about 4-bytes preceding and following the filler area [so I think the hack 
is probably working correctly].  It seems to differ only in the one byte 
currently of interest.)

The bds2006 debugger cpu window memory dump display is apparently incorrect.

So what if I can't trust the tools (not that I have anyway for a while) - I 
got Bob G to write me some nifty faster code - maybe it'll balance out if I 
can manage that a few more times. :) (Well, would need it a LOT more 
times...)

And I guess I can assume my CPU isn't actually failing in this regard - that 
at least is good.