knnngt@ukma.UUCP (Alan Kennington) (12/30/85)
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.