A strange quick of Applesoft Basic

[vol]

I am perplexed by a strange quirk.  I haven't find any mention of this in any documentation.  Would anyone like to help me to get any explanation of the quirk.  It is about the work with text files.  Let's examine my example.

10 D$=CHR$(4)
20 PRINT D$ "OPEN F1"
30 PRINT D$ "WRITE F1"
40 PRINT "HELLO WORLD!"
50 PRINT D$ "CLOSE"

This program just creates a text file that has name F1.  Let's read this file.

10 D$=CHR$(4)
20 PRINT D$ "OPEN F1"
30 PRINT D$ "READ F1"
40 ONERR GOTO 80
50 GET A$
60 PRINT A$;
70 GOTO 50
80 PRINT:PRINT D$ "CLOSE"

This doesn't work for me.  I need to change line 60 with 

60 PRINT " " A$;

and this works!  I have checked this on MAME and MICROM8.  It seems the first printed symbol always disappears somewhere.
 

[+OLD CS1]

Been a looooong time, but ISTR that anything I/O by PRINT or INPUT/GET after {CTRL-D}READ/WRITE is sent to the DOS data channel for that file until the command channel is {CTRL-D}CLOSEd.  What you are doing is GETting a character from the file then sending it right back to the data channel, which definitely is an error as the file is being READ.  I remember reading in an Apple 2 book in high school, chapter on file processing, that any first character other then {CTRL-D} bypasses the DOS channels (sends to screen) when in a file processing mode.  The space in your revised line 60 is doing that, and notice how the space does not print if you make line 60:

 

60 PRINT " ";A$;

 

There is some technical reason, but it is way beyond me.

 

As an aside, I never realized AppleSoft BASIC can do without semicolons in some print lists.

[vol]

@OLD CS1 Thank you very much.  However I have not been able to find any mention that the READ command affects write operations or the WRITE command affects read operations.  Examples in the DOS Programmer's manual show that if a file is open to read then writing to the screen must work the usual way.  Moreover I can't find anywhere a kosher way to read an arbitrary text file! 🙁

Let me also add an example from page 64 of the manual

1000 GET C$: PRINT C$ ; (Read 1 character and echo it)

This line reads a char from a file and echoes it on the screen...  Maybe I missed something or it is just a old unfixed bug.

[+OLD CS1]

Good question.  That gets over my head and I stopped using Apple ages ago (mostly in school.)  Maybe there is a difference between AppleSoft BASIC and Integer BASIC.  Also, is that DOS or ProDOS?

[nick3092]

Seems to work fine on real hardware using PD 2.0.3/basic 1.5. Don't have a 3.3 boot disk handy to test right now. 

 

 

[vol]

@OLD CS1 I directly mentioned DOS afore. 😉 It seems PD works without quirks - thanks to @nick3092.

[nick3092]

I can confirm that the get method does fail under dos 3.3 on real hardware. However, using input to read the whole string and getting rid of the loop of reading and printing one character at a time works fine under 3.3. And slightly more efficient. 

 

 

Edited May 10, 2023 by nick3092

[+OLD CS1]

7 hours ago, nick3092 said:

I can confirm that the get method does fail under dos 3.3 on real hardware. However, using input to read the whole string and getting rid of the loop of reading and printing one character at a time works fine under 3.3. And slightly more efficient.

I wonder if the difference is INPUT completes a full field or record, whereas GET does not.

[vol]

19 hours ago, nick3092 said:

I can confirm that the get method does fail under dos 3.3 on real hardware. However, using input to read the whole string and getting rid of the loop of reading and printing one character at a time works fine under 3.3. And slightly more efficient. 

 

 

Thank you but please check the original code because INPUT can't help to read an arbitrary text file.

[vol]

@nick3092 Sorry I was in hurry and missed that you actually answered my question. Thank you very much. It is sad that I can't remove my previous post.

However we have discovered a very old bug!