From Newsgroup: comp.sys.apple2

Is there a more elegant way to display text files in Applesoft besides:

10 onerr goto 100
20 input fn$
30 ?chr$(4);"open ";fn$
40 ?chr$(4);"read ";fn$
50 input a$
60 print a$
70 goto 50
100 ?chr$(4);"close"

Waiting for an error seems....not the best way.
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

If only you knew how many characters were in the text file beforehand. Error handling is inelegant. Gracefully handle the End Of File (EOF)

0 D$ = CHR$(4)
REM 10 PRINT D$"NOMONC,I,O"
20 INPUT F$
30 PRINT D$"VERIFY"F$
40 M$ = CHR$(13)
50 PRINT D$"OPEN"F$M$D$"READ"F$
60 ONERR GOTO 100
70 GET C$
80 PRINT M$C$;
90 GOTO 70
100 POKE 216,0
120 EOF = PEEK(222) = 5
130 IF NOT EOF THEN RESUME
140 PRINT D$"CLOSE"

FN is a keyword.
INPUT won't handle long lines.
INPUT will ignore extra characters from where a comma or a colon starts in
the line.
PRINT M$C$; might be a DOS 3.3 thing, I didn't test this in ProDOS.


--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

Is there a more elegant way to display text files in Applesoft besides:

10 onerr goto 100
20 input fn$
30 ?chr$(4);"open ";fn$
40 ?chr$(4);"read ";fn$
50 input a$
60 print a$
70 goto 50
100 ?chr$(4);"close"

Waiting for an error seems....not the best way.

A couple of other methods come to mind. There are commands which can be installed into either DOS or ProDOS, such that one can just use: ? CHR$(4)"TYPE textfilename".

Under ProDOS one can also just use BLOAD, as in:

LN = ?? : REM enter length of text file when doing a CATALOG or get length from Basic.System
? CHR$(4)"BLOAD textfile,TTXT,A$2000" : FOR I=0 to LN-1: ? PEEK(8192+I);:NEXT

I think there is also a way to BLOAD a textfile under DOS 3.3 but it has been too long.

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

On Monday, April 12, 2021 at 11:45:36 PM UTC-4, mmphosis wrote:

If only you knew how many characters were in the text file beforehand. Error handling is inelegant. Gracefully handle the End Of File (EOF)

0 D$ = CHR$(4)
REM 10 PRINT D$"NOMONC,I,O"
20 INPUT F$
30 PRINT D$"VERIFY"F$
40 M$ = CHR$(13)
50 PRINT D$"OPEN"F$M$D$"READ"F$
60 ONERR GOTO 100
70 GET C$
80 PRINT M$C$;
90 GOTO 70
100 POKE 216,0
120 EOF = PEEK(222) = 5
130 IF NOT EOF THEN RESUME
140 PRINT D$"CLOSE"

FN is a keyword.
INPUT won't handle long lines.
INPUT will ignore extra characters from where a comma or a colon starts in the line.
PRINT M$C$; might be a DOS 3.3 thing, I didn't test this in ProDOS.

I'm using Prodos, and I could know how many characters are in the file as it will be a fixed help menu. If I know ahead of time would I just use a for next loop?

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

On Monday, April 12, 2021 at 11:47:11 PM UTC-4, g...@sasktel.net wrote:

Is there a more elegant way to display text files in Applesoft besides:

10 onerr goto 100
20 input fn$
30 ?chr$(4);"open ";fn$
40 ?chr$(4);"read ";fn$
50 input a$
60 print a$
70 goto 50
100 ?chr$(4);"close"

Waiting for an error seems....not the best way.

A couple of other methods come to mind. There are commands which can be installed into either DOS or ProDOS, such that one can just use: ? CHR$(4)"TYPE textfilename".

Under ProDOS one can also just use BLOAD, as in:

LN = ?? : REM enter length of text file when doing a CATALOG or get length from Basic.System
? CHR$(4)"BLOAD textfile,TTXT,A$2000" : FOR I=0 to LN-1: ? PEEK(8192+I);:NEXT

I think there is also a way to BLOAD a textfile under DOS 3.3 but it has been too long.

I am using Prodos, and I'm seen the addons. I already have an add on installed, and I'm using the hires page. Is there a good way to find the free memory space to bload to? I know you can check the length of an Applesoft program, but then variable space, and the Prodos buffers and addons....
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

mmphosis wrote:

If only you knew how many characters were in the text file beforehand.
Error handling is inelegant. Gracefully handle the End Of File (EOF)

0 D$ = CHR$(4)
REM 10 PRINT D$"NOMONC,I,O"
20 INPUT F$
30 PRINT D$"VERIFY"F$
40 M$ = CHR$(13)
50 PRINT D$"OPEN"F$M$D$"READ"F$
60 ONERR GOTO 100
70 GET C$
80 PRINT M$C$;
90 GOTO 70
100 POKE 216,0
120 EOF = PEEK(222) = 5
130 IF NOT EOF THEN RESUME
140 PRINT D$"CLOSE"

FN is a keyword.
INPUT won't handle long lines.
INPUT will ignore extra characters from where a comma or
a colon starts in the line.
PRINT M$C$; might be a DOS 3.3 thing, I didn't test this in ProDOS.

That makes each character appear on its own line. Also:

PRINT D$"OPEN"F$M$D$"READ"F$

doesn't work in ProDOS; each command must be a separate PRINT:

PRINT D$"OPEN"F$ : PRINT D$"READ"F$

(which, happily, isn't any bigger in memory.)

I've often wished that AppleSoft had A RESUME NEXT feature that went to
the instruction after the error, instead of repeating the erring
instruction. This would allow effectively making the interpreter ignore certain errors, letting you check for them after the relevant command
(in this case after the GET instruction).
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

Brian Patrie <bpatrie@bellsouth.spamisicky.net> wrote:

mmphosis wrote:

If only you knew how many characters were in the text file beforehand.
Error handling is inelegant. Gracefully handle the End Of File (EOF)

0 D$ = CHR$(4)
REM 10 PRINT D$"NOMONC,I,O"
20 INPUT F$
30 PRINT D$"VERIFY"F$
40 M$ = CHR$(13)
50 PRINT D$"OPEN"F$M$D$"READ"F$
60 ONERR GOTO 100
70 GET C$
80 PRINT M$C$;
90 GOTO 70
100 POKE 216,0
120 EOF = PEEK(222) = 5
130 IF NOT EOF THEN RESUME
140 PRINT D$"CLOSE"

FN is a keyword.
INPUT won't handle long lines.
INPUT will ignore extra characters from where a comma or
a colon starts in the line.
PRINT M$C$; might be a DOS 3.3 thing, I didn't test this in ProDOS.

That makes each character appear on its own line. Also:

PRINT D$"OPEN"F$M$D$"READ"F$

doesn't work in ProDOS; each command must be a separate PRINT:

PRINT D$"OPEN"F$ : PRINT D$"READ"F$

(which, happily, isn't any bigger in memory.)

I've often wished that AppleSoft had A RESUME NEXT feature that went to
the instruction after the error, instead of repeating the erring instruction. This would allow effectively making the interpreter ignore certain errors, letting you check for them after the relevant command
(in this case after the GET instruction).

And no error occurs if the file is BLOADed, since the program can easily
PEEK the length of the file after the BLOAD.

I use this technique for processing most TXT files, since it does not rely
on GET or INPUT with their limitations.

If the file is too large to BLOAD in its entirety, it can be loaded in
chunks.

--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

And no error occurs if the file is BLOADed, since the program can easily PEEK the length of the file after the BLOAD.

I use this technique for processing most TXT files, since it does not rely on GET or INPUT with their limitations.

If the file is too large to BLOAD in its entirety, it can be loaded in chunks.

--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com

Can you call GETBUFR from basic.system to allocate a space to put your data? I'm leaning towards the bload because it just seems better, but my program loads an helper command, and I'm using Program Writer while I'm developing it, so HIMEM is all over the place depending on what's going on. I could possibly use Hires Page 2, but I read in one of the books that you can't directly bload to Hires Page 2 on a //e or something....
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

duhas...@gmail.com wrote:

And no error occurs if the file is BLOADed, since the program
can easily PEEK the length of the file after the BLOAD.

I use this technique for processing most TXT files, since it does
not rely on GET or INPUT with their limitations.

If the file is too large to BLOAD in its entirety, it can be
loaded in chunks.

--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com

Can you call GETBUFR from basic.system to allocate a space to put
your data? I'm leaning towards the bload because it just seems
better, but my program loads an helper command, and I'm using
Program Writer while I'm developing it, so HIMEM is all over the
place depending on what's going on. I could possibly use Hires
Page 2, but I read in one of the books that you can't directly
bload to Hires Page 2 on a //e or something....

Yes, you can bload directly to HGR page 2 ($4000..5FFF). (It's *auxmem*
HGR page 2 that you can't bload directly to, because there's no way to
write enable it, without write enabling the whole $200..BFFF section of auxmem--which would upset some things.)
--- Synchronet 3.18b-Win32 NewsLink 1.113