🚀 go-pugleaf

	Someone mentioned once how to avoid the problem of the EOF test
not being valid, due to a bug in ST BASIC which somehow made the first
byte of a file unreadable and hence got the byte count wrong. Well, I have
something new to add to the list of file reading bugs.
	Suppose you have a 20K BASIC program loaded in and you use it to
read in some file. The first time, the aforesaid bug is evident, and a check
for ERR = 62 resolves the problem. But if you do a bit of editing (to cope
with other Basic bugs) and then rerun the program, you get some sort of
"Undefined error at line 740", where 740 is the line where you first
try to read in something. And the punchline is that the third time, the
file seems to read in perfectly. It even gives you the very FIRST elusive 
byte of the file. (I saw it with my very own eyes!!) BUT when you go to
use what you've read in, you find that the strings read in have got other
strings written all over them. So the solution is to clear out all of the
string space before doing any input using Basic.
	So now there are at least 3 distinct failure modes for an input
routine to cope with. Now that I have identified them, my disassembler
is running beautifully. But it just shows what can happen when a company
is too keen to convince the market that software exists. 
	My next step is to dump the operating system to see how it works,
and then start writing an assembler and start programming. Of course, if
my developer's kit comes first, I might be able to skip the assembler
writing stage. ...........................ak.