Re: AppleSoft Basic to text-- BASIC xfer

[Rubywand <rubywand@swbell.net>]

Jeff Blakeney wrote:
> 
> On Tue, 13 Jun 2000 18:36:45 -0500, Rubywand <rubywand@swbell.net>
> wrote:
> 

> 
> > 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.
> 
> What speed did you try sending at?  I don't have a IIe set up right
> now to try this with otherwise I'd try it myself too.
> 

     Tried 300 baud. This gives the IIe something less than roughly 500
micro-seconds to enter a BASIC line and update the display-- not nearly
enough time. The SPEED command could slow the LIST so that the char send rate
would allow time for reliable line entry on the IIe; but, sending a file
would take forever.




> By the way, this is another reason why a communications program would
> work well.  You get a good full screen editor with cut/copy/paste
> support and such and you can send the end of line delay for ASCII
> transfers.  You'd never need to switch between an editor and a
> transfer program.
>

     That sounds like a good solution! You'd be able to stay in the comm
program and diddle variations until the results as tested out on the IIe were
what you wanted.


 
> > 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.
 ....
> 
> Unless you plan to reset the computer after running your transfer
> program, you definitely need the POKE 216,0 and the CALL -3288.  The
> POKE turns off your custom error handler and I'm not sure what happens
> if you do a syntax error at the Applesoft prompt with a custom error
> handler still in effect.  More importantly, though, the CALL cleans up
> the control stack which will definitely cause problems if you don't
> clean it up.  I'm unsure of whether the control stack uses the 65xxx's
> actual stack for storing this information or not but if it does, your
> computer will crash at some point if you don't clean it up properly.
>

     Did a few tests and it looks like everything gets reset when a new
program is loaded or a change is made to the current program. For instance,
after running a program with an unterminated ONERR GOTO, you get the usual
DIVISION BY ZERO error message for entering PRINT 9/0 at the Applesoft
prompt.

     Even so, there is no disagreement that correctly terminating an ONERR
GOTO is good practice. Including the POKE 216,0 and CALL -3288 is probably a
good idea in an example program.


 
> > 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.
> 
> I'm thinking that the editor they use might allow them to embed CTRL-D
> in a string, a CTRL-I in a printer init string, a CTRL-A for a modem
> program or a CTRL-G to make the computer beep.  Mind you, they should
> be using CHR$(4), CHR$(9), CHR$(1) and CHR$(7) respectively for these
> but you never know.
 ....

     Bob made the same observation. If Rich's programs routinely include
embedded in-line control chars, then, your idea of passing all control
characters and doing the line entry delay for CR's would be the way to go as
long as the Text editor creates pure Text.





Rubywand