jhs@MITRE-BEDFORD.ARPA.UUCP (01/28/87)
Several users of my Atari 8-bit uudecode program have reported problems with the output file not containing any data despite the fact that the program otherwise seems to run correctly. I now believe that the problem is caused by my using an incorrect test for whether or not BASIC is present, inside the machine language subroutine. The test I used is to check location $6 and take a nonzero value there to mean BASIC Not Enabled (BNE!). I am either going slowly bonkers or else I somewhere found information to the effect that this was a reasonable thing to do. Since it worked on my 800XL, I stopped trying to fix it until people started complaining. Now I see that Mapping The Atari seems to feel that location $6 should be a 1 if and only if BASIC **IS** enabled. Clearly that is inconsistent with what I thought was true and so my subroutine would interpret the 1 to mean that it is being called without BASIC. It would therefore refrain from updating the Current Length parameter, and Voila!, OBUF$ would appear to have whatever current length value was last set by somebody who knew what they were doing. (Not me, obviously.) Since my own 800XL seems to disagree with this interpretation, it seems that reversing the logic of my current test is not the right thing to do. (However, this might solve the problem for you 800 owners.) Does anybody out there in Net-landt know what is the RIGHT way to test for the presence of BASIC? Failing that, of course I could patch the subroutine to simply ASSUME that it should set the current length parameter. This would affect only users of the subroutine who wanted to call it directly from assembly language, but clearly this patch would work for all users who merely took my BASIC program and used it. Any suggestions? -John Sangster jhs@mitre-bedford.arpa