[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AppleSoft Basic to text-- BASIC xfer
On Tue, 13 Jun 2000 18:36:45 -0500, Rubywand <rubywand@swbell.net>
wrote:
> 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.
Ah. True. My brain gapped and I forgot about the ProDOS 8 editors.
That would definitely help in this case.
> 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.
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.
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.
> 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.
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.
> 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.
You are correct about line feeds though and maybe there should be a
check to not send them but I don't know of any Apple II text editor
that will add line feeds after carriage returns so I think we're
pretty safe.
> 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.
I didn't say to start a comm program on both machines. Just on the
IIgs. The IIe just needs to be at an Applesoft prompt and you type
IN#2 on it before doing an ASCII send of the IIgs comm program's
editor text.
In essence, when you do the ASCII send this way you are automatically
exec'ing the program on the IIe. Once the send is done you type PR#0
on the IIgs (or put that as the last line in your source code with no
line number) and then you can save the program to disk on the IIe.
+------------------------------------------------------------------------+
| Jeff Blakeney - Dean of the Apple II University in A2Pro on Delphi |
| Delphi Apple II Forums Web Pages |
| A2: http://www.delphi.com/apple2 A2Pro: http://www.delphi.com/a2pro |
+------------------------------------------------------------------------+