Re: AppleSoft Basic to text-- BASIC xfer

[Rubywand <rubywand@swbell.net>]

Jeff Blakeney writes ...
> 
> On Mon, 12 Jun 2000 22:26:23 -0500, Rubywand <rubywand@swbell.net>
> wrote:
 ....

>>o- Enter this program and save it as LISTOUTBASIC on the diskette
>>
>> 100  ONERR  GOTO 200
>> 110  PRINT  CHR$ (4)"OPEN BASTXT"
>> 120  REM  SET OUTPUT PORT
>> 130  PRINT  CHR$ (4)"PR#1"
>> 140  PRINT  CHR$ (4)"READ BASTXT"
>> 150  FOR I = 0 TO 999999: GET C$
>> 160  REM  MAX TT VAL SETS LINE DELAY (1333 FOR 2.8MHZ GS)
>> 170  IF  ASC (C$) < 32 THEN  PRINT : FOR TT = 0 TO 1333: NEXT TT: GOTO >>      190
>> 180  PRINT C$;
>> 190  NEXT I
>> 200  PRINT  CHR$ (4)"PR#0"
>> 210  PRINT : PRINT  CHR$ (4)"CLOSE"
>> 220  END
>>
 ....

> I thought the reason he wanted to print to the IIe from his IIgs was
> to keep him from having to switch back and forth between ProDOS 8 and
> GS/OS.  Your program requires him to do the switch.

     Mainly, it seems like Rich wanted to get the Text in program form to his
IIe (to avoid having to add the read-Text/LIST line and do an EXEC);  and, he
was interested in using a serial connection for transfer.

     Dropping out of Shadowrite and starting the program to do the transfer
is fairly speedy. Still, yes, you would have the delay Rich mentions to
remount drives when going back to the GS System Finder and restarting
Shadowrite. Using one of several ProDOS8-based Text editors instead of
Shadowrite would eliminate that delay in the Edit - Tryout - Edit - ...
cycle.

     We agree that using Program Writer on the IIe is best-- except, we do
not know that his IIe is enhanced and has the 128k RAM required for Program
Writer. PW on the IIgs and moving stuff on diskette seems next best.

     Even so, the 'customer' suggested an approach he wanted to try. It was,
basically, doable; so, a way to do it was described.


> Besides, if you
> are going to drop into ProDOS 8 to run your program, I'd think it
> would be easier to set the printer control panel to the values you
> want, start BASIC.SYSTEM, exec your listing, do a PR#1 and then type
> LIST.

     Me, too-- even had the suggestion written up in a posting. But, since a
LIST allows no delay for the IIe to process BASIC lines as they are sent, it
seemed like a good idea to do a test. It did not work.


> 
> Now, about your program.  First off your program should have a POKE
> 216,0 in it, preferably at line 200, to disable the ONERR GOTO
> statement so that any subsequent errors will be handled by Applesoft's
> internal error handlers.  You should also have a CALL -3288 in there
> to clean up the error information off the control stack.

     A POKE 216,0 was included in an earlier version but omitted to shorten
the program. By Line 200 the program is beyond any likely error points and
about done. Both POKE 216,0 and the clean-up CALL would have been include,
maybe with error type branching, in a larger program which is expected to
continue execution.


> 
> Second, you probably shouldn't be using a FOR/NEXT loop.  You are
> limiting yourself to 999,999 characters of text for your program.
> Mind you, this should be enough for most Applesoft programs seeing as
> a tokenized program can only be about 32K but a non-tokenized version
> will be quite a bit larger.

     Yes; in many cases it is better to use a different kind of loop. In this
application, FOR-NEXT gets the job done in a fairly compact way.



> You've allowed for at least a 30 times
> increase by using that number.

LOL! Agree, 999999 bytes max is probably over-kill for programming a robot
card from a IIe. (Of course, if Rich has an extra MB plugged into his IIe and
is programming a very smart robot module, the 999999 bytes limit might need
to be increased.)


> The catch comes when you consider the
> fact that one of the nice things about using this method to edit your
> programs is that your REM statements don't need to have line numbers.
> This means that when you exec the program you end up with a tokenized
> program with no REM statements wasting memory but your source code is
> still nicely commented.  This might end up pushing the size of the
> source code to a size larger that 999,999 characters.  You'd be better
> off using a infinite loop for copying the file and have the ONERR GOTO
> pull you out of it when you get to the end of the file.
>

     An infinite loop would have been fine here. (999999 was supposed to be,
practically speaking, "infinite".)  As you say, the ONERR GOTO is expected to
be the loop terminating mechanism (i.e. you run out of chars and get an
error).

 
> Third, you are assuming that the only control character that will
> appear in the source code is a carriage return.  This may not be true
> and the user might actually want control characters to be sent
> through.  You should only test for a carriage return if you want to
> put in an end of line delay.

     For transfer of the pure Text 'source' of an Applesoft BASIC program,
the CR character seems to be the only Control character one encounters.
However, if any others occur (e.g. LF's, etc. added by the particular Text
editor) they are not BASIC and should be screened out, too. This is the
reason for the IF  ASC (C$) < 32 THEN test.


> 
> So, I would change your program to look like this:
> 
> 100 ONERR GOTO 200
> 110 PRINT CHR$(4);"OPEN BASTXT"
> 120 REM SET OUTPUT PORT
> 130 PRINT CHR$(4);"PR#1"
> 140 PRINT CHR$(4);"READ BASTXT"
> 150 GET C$
> 160 REM MAX TT VAL SETS LINE DELAY (1333 FOR 2.8MHZ GS)
> 170 IF ASC(C$) = 13 THEN PRINT:FOR TT = 0 TO 1333: NEXT TT: GOTO 150
> 180 PRINT C$;
> 190 GOTO 150
> 200 POKE 216,0: CALL -3288
> 210 PRINT CHR$(4);"PR#0"
> 220 PRINT : PRINT CHR$(4);"CLOSE"
> 230 END
>

     Yes; the pure infinite loop is a definite improvement and it gains
compactness. The IF ASC(C$) = 13 is okay; but, IF  ASC (C$) < 32 is safer.


> By the way, the first PRINT in line 220 I don't really think is
> necessary but I left it in because it won't hurt and line 230 isn't
> necessary either but I left it in anyways as it is good programming
> style.  You should also be able to change lines 170 and 180 to this:
> 
> 170 PRINT C$;
> 180 IF ASC(C$) = 13 THEN FOR TT = 0 TO 1333: NEXT TT
> 
> but as I haven't tested it I figured it would be best to leave it like
> it was.
>

     If you could be certain that $0D (CR) is the only Ctrl character in the
BASIC Text from an editor, then, allowing all chars in the Text to be sent
and doing the Line entry test/delay after the send would be an improvement.

 
> However, even after all this, I still think his best bet is to use a
> communications program on his IIgs to edit his source code and send it
> to his IIe.
 ....

     It's an option; but, in this situation, starting up a comm program (on
both computers) and EXECing the Text would probably involve more delay and
diddling than using the transfer program.



Rubywand