Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Applesoft syntax

65 views
Skip to first unread message

Deckard

unread,
Feb 5, 2012, 5:58:26 PM2/5/12
to
How do you check the syntax of a big Applesoft basic program without
running it?
Is there vintage or modern tools for that?

JM

magnusfalkirk

unread,
Feb 5, 2012, 6:52:02 PM2/5/12
to
Not sure if it will do what you want or not but I'd suggest trying
Beagle Bros Program Writer on whatever Apple II you're using.

Dean

BLuRry

unread,
Feb 6, 2012, 1:02:02 AM2/6/12
to
I would think that you should be able to enter in the program, then use a basic disassembly (or listing) to confirm that the disassembled version matches up. This won't catch everything, but it could at least call out any tokenization issues.

A long while back I started implementing an applesoft grammar parser, with the hope of going beyond that. Though I didn't implement a tokenizer, I did write a disassembler that can take a binary basic file and render it back to ascii text. The code for this is buried in the jace.appelesoft package of the JACE codebase -- and it's what I used to disassemble lemonade stand and convert everything to lowercase. For retokenization, I'm currently going the slow route: Copy all to clipboard and then from the basic prompt press ctrl+ins to paste it in line by line for applesoft interpretation. Not exactly ideal, but a start...

-B

Joshua Bell

unread,
Feb 6, 2012, 3:06:36 AM2/6/12
to
Running the source through a BASIC compiler would check that the
syntax is correct, since that would do a full token lex/grammar parse
of the program.

My "Applesoft in JavaScript" page http://calormen.com/applesoft does
this - it compiles each statement into JavaScript before the program
starts, so it will catch syntax errors even in lines that will never
execute. (Which could be considered a bug!) So you could copy/paste
your source into that page and try running it.

You may hit bugs in my code, of course, or limits of the execution
environment since it is not a full emulator.

Deckard

unread,
Feb 6, 2012, 6:41:06 PM2/6/12
to
A great tool Joshua. Thank you.

Unfortunately, my program has a lot of commands which refer to
assembly routines (poke, peek, call) and the compilation stops after
the first "call" with message "Unsupported POKE location".
And as a lot of applesoft basic program, the program also has extended
commands which begin with ampersand and produce the message
"ParseError: Native interop statement not supported: & in line xyz"

I've notice a strange thing:

when I try to run the following pgm, a message is displayed with a bad
number line: ParseError: Native interop statement not supported: & in
line 30

10 print "A"
20 &
30 print "B"

On an Apple IIe computer, this program works.

JM

Deckard

unread,
Feb 6, 2012, 7:01:34 PM2/6/12
to
> Not sure if it will do what you want or not but I'd suggest trying
> Beagle Bros Program Writer on whatever Apple II you're using.

Program Writer is a powerful applesoft basic program editor with a lot
of features (macros, renumber, insert control characters, copy/paste,
40/80c switch, list all the variables in the program, search&remplace,
mouse support, insert/delete/find/split line into 2 lines/combine
lines/convert to upper or lower case, ...)

But like a word processor, it doesn't check the syntax of the basic
program.

And no luck, my program has large lines which are not displayed:
According to the manual, "a program may contain lines that are too
long to edit. Normally lines this long can only be obtained by using a
program that compacts a BASIC program to its smallest size by
concatenating lines. A line that is too long to edit from the keyboard
is shown by the editor as a single asterisk (*) following the line
number. Most programmers will never see this".
My program was compacted and I've a lot of lines with asterisks :-(

JM

Joshua Bell

unread,
Feb 7, 2012, 12:31:29 AM2/7/12
to
On Feb 6, 3:41 pm, Deckard <boutil...@free.fr> wrote:
> A great tool Joshua. Thank you.
>
> Unfortunately, my program has a lot of commands which refer to
> assembly routines (poke, peek, call) and the compilation stops after
> the first "call" with message "Unsupported POKE location".

Actually, if it makes it that far, it's done compiling and trying to
execute. Try this:

10 PRINT "Hello World!"
20 END
30 POKE 0,0

This is syntactically correct, but 0 is not a supported POKE location.
It will run without reporting any errors, unless you remove line 20.

So, as far as my page is concerned, your code is syntactically
correct.

> And as a lot of applesoft basic program, the program also has extended
> commands which begin with ampersand and produce the message
> "ParseError: Native interop statement not supported: & in line xyz"

Yeah, my page is not an emulator so it's not going to be able to
validate that the runtime POKE, CALL or &--routines are valid. But
then again, there's provably no way to do that for arbitrary code
without running it, so I don't feel too bad. :)

(Back in the day, I don't think I ever used & routines. Possibly, if I
had, I never would have put that page together.)

> I've notice a strange thing:
>
> when I try to run the following pgm, a message is displayed with a bad
> number line: ParseError: Native interop statement not supported: & in
> line 30
>
> 10 print "A"
> 20 &
> 30 print "B"

Thanks, it should be reporting the parse error in line 20, of course.
I see the bug in the code (token lookahead is conflicting with the
line reporting), and I'll try to fix it soonish.

> On an Apple IIe computer, this program works.

My page flags unsupported commands (&, WAIT, HIMEM, etc) as errors at
parse time rather than runtime. It could arguably do it at runtime for
WAIT, HIMEM and so on, but IIRC I don't believe I could do so for & in
the non-trivial case since the parsing of tokens after the & is under
the control of the assembly routine and anything up the next line
number (or beyond, technically) could have a nonstandard meaning. That
said, I prefer the early errors for my use cases, so I'm not planning
on changing it. There are plenty of true emulators out there.

(I'm very much looking forward to BLuRry giving JavaScript and WebGL a
try. JSACE, anyone?)

Michael J. Mahon

unread,
Feb 8, 2012, 2:28:21 PM2/8/12
to
I'm curious--why would you want to use something other than
Applesoft itself to check a program?

I've always thought of syntax checking as a (very) preliminary
step to actual debugging/testing, which will result in Applesoft
doing a complete syntax check, assuming good test coverage.

-michael

NadaNet 3.1 for Apple II parallel computing!
Home page: http://home.comcast.net/~mjmahon/

"The wastebasket is our most important design
tool--and it's seriously underused."

Antoine Vignau

unread,
Feb 8, 2012, 3:07:34 PM2/8/12
to
Can't LIST and one's eyes be the perfect debugging tool for Applesoft
programs?
Antoine

David Schmidt

unread,
Feb 8, 2012, 3:30:56 PM2/8/12
to
On 2/8/2012 3:07 PM, Antoine Vignau wrote:
> Can't LIST and one's eyes be the perfect debugging tool for Applesoft
> programs?

Yes, of course. CiderPress and AppleCommander have Applesoft listers -
if it comes out correctly (i.e. no strange nonsense "code" in the middle
of a line because of strange tokens) then the code is demonstrably
syntactically correct.

I suspect Deckard wanted to know about semantic correctness, though. I
seem to remember a static analyzer out there that considered dangling
line references and other low-hanging fruit. A line renumberer would
have the kind of framework in place to check for some referential
correctness.

Deckard

unread,
Feb 8, 2012, 4:40:14 PM2/8/12
to
On 8 fév, 20:28, "Michael J. Mahon" <mjma...@aol.com> wrote:
> I'm curious--why would you want to use something other than
> Applesoft itself to check a program?

The full story:

More than 20 years ago, I wrote a rpg game with a friend.
I've resurrected it and I'm playing the game to take snapshots.

The "conflict" program is written in basic with 2 kind of & routines
(games functions and I/O access with a patched RDOS).
And this program is ... a nightmare (spaghetti code).
With "conflicts", there are a lot of combinations (various monsters
reactions, user's actions, and a lot of other parameters). So it's
hard to test all the cases.

I had a crash last week:
http://boutillon.free.fr/Forum/m2/m2_crash_conflict_p01.png
A ":" was missing in a line 20710:
http://boutillon.free.fr/Forum/m2/m2_crash_conflict_p02.png

And I'd like to know is there are other similar bugs or bad applesoft
syntax sentences which have not been tested.
I don't think I can run every line of code when I'm playing the game.
So I'm looking for a way to have a first check.

If Antoine has a hawk's eye, the program is here (extracted with
CiderPress):
http://boutillon.free.fr/Forum/m2/Conflict.txt
The packed version which is used by the game is here:
http://boutillon.free.fr/Forum/m2/Conflict_packed.txt

And a dsk with both:
http://boutillon.free.fr/Forum/m2/Conflict_dos3_3.dsk

I'm going to test Blurry's disassembler with the 2 "raw" applesoft BAS
files which are here:
http://boutillon.free.fr/Forum/m2/Conflict.BAS
http://boutillon.free.fr/Forum/m2/Conflict_packed.BAS
but as Brendan said, it's a start.
I first have to remove the static hard coded filename (/home/brobert/
Documents/Personal/a2gameserver/lib/data/games/LEMONADE#fc0801) and
look what is done when & is met.
(Thanks Brandan for your java classes.)

JM



Anton Treuenfels

unread,
Feb 8, 2012, 8:43:51 PM2/8/12
to

"Deckard" <bout...@free.fr> wrote in message
news:89aca5f9-7923-41cf...@k10g2000yqk.googlegroups.com...
You might find "Applesoft Programming Helper" by Grant Stevens in "Applesoft
Power Tools" (Nibble Publications, 1987) to be what you're looking for. It's
provided as an assembly language listing. It performs a static syntax check
of an Applesoft program in memory.

To check your running program you might find "Microscope" by Ong Tee Yong in
the same book to be helpful. It's also provided as an assembly language
listing. Single step, set breakpoints, etc.

MicroSPARC is pretty huffy about letting anyone other than the purchaser of
the book use anything in it, though. Says so at the front of the book. They
don't even want to let it be reproduced by any means "...now known or
hereafter invented..." without their explicit permission.

Wonder if they even exist anymore. They certainly don't show up on the first
page of Google.

- Anton Treuenfels

Jerry

unread,
Feb 8, 2012, 11:19:13 PM2/8/12
to
There were some Nibble programs from ~1982 that did some stuff like
this: Line Cruncher and Variable cruncher by Alan & Valerie Floeter,
IIRC. I don't think they really checked semantic correctness, but they
might have been able to spot dangling GOTOs.

The PDFs of the magazines are for sale from the original publisher, but
he has disk images of many of his programs available free on his site:
http://www.nibblemagazine.com.



--
--
Jerry awanderin at yahoo dot ca

BLuRry

unread,
Feb 9, 2012, 1:49:01 AM2/9/12
to
You're very welcome. :-) I seem to recall that everything after & is interpreted as a string (perhaps?) though it is possible that the stuff inside the ampersand command portion also gets tokenized. The ampersand routine is passed a pointer to where the command itself starts in memory, and then it has to finish out the parsing on its own. This is nice in that it makes it very flexible, but from a grammar validation standpoint this is awful because you have no way of knowing something is valid until it works or it fails.

Michael J. Mahon

unread,
Feb 9, 2012, 3:41:07 AM2/9/12
to
BLuRry wrote:
> You're very welcome. :-) I seem to recall that everything after & is interpreted as a string (perhaps?) though it is possible that the stuff inside the ampersand command portion also gets tokenized. The ampersand routine is passed a pointer to where the command itself starts in memory, and then it has to finish out the parsing on its own. This is nice in that it makes it very flexible, but from a grammar validation standpoint this is awful because you have no way of knowing something is valid until it works or it fails.

The only things in Applesoft program that don't get tokenized are
strings (and possibly DATA statements--I've never looked ;-).

Tokenization doesn't check syntax, nor does listing a tokenized
program check syntax. POKE POKE POKE tokenizes perfectly and
lists fine, but it isn't good syntax and obviously won't execute.

Correct syntax is a *very* weak test for program correctness, since
astronomically many semantic errors can exist without any syntax
errors.

No static analysis of a program can ever determine that it is free
from errors--that's the "stopping problem".

And while dynamic analysis can, in principle, determine that a
program is free from errors, in practice, any program complex
enough to be interesting is almost certainly beyond being able to
try all permutations of data values and flows in a practical time.

Debugging/testing is intrinsically hard, but it's the best we
have. Analysis tools can help, but not as much as one would hope.

Deckard

unread,
Feb 9, 2012, 5:08:38 PM2/9/12
to
Thank you Anton and Jerry.

According to the Nibble Program Index, theses programs were first
printed in the nibble magazines.

"Applesoft Programming Helper" by Grant Stevens => volume 4 number 7
(1983)
"Microscope" by Ong Tee Yong => june 1986

I have the both magazines (and the dvd I bought long time ago), so I'm
going to read them to see what they can really do.

JM

Joshua Bell

unread,
Feb 9, 2012, 11:56:31 PM2/9/12
to
On Feb 9, 12:41 am, "Michael J. Mahon" <mjma...@aol.com> wrote:
>
> The only things in Applesoft program that don't get tokenized are
> strings (and possibly DATA statements--I've never looked ;-).

From my testing, DATA statements do get tokenized. Quoting is optional
but needed to avoid reserved word handling. So IIRC (no emulator
handy) this:

10 DATA a,b,c : FOR I = 1 TO 3 : READ A$: PRINT A$ : NEXT

will print:

a
b
c

... but you almost always want to quote strings to avoid reserved word
tokenization.

And don't forget REM statements, which are not tokenized, including
any colons!


Jerry

unread,
Feb 10, 2012, 3:43:13 AM2/10/12
to
Nope, DATA statements are not tokenized. They are copied as-is until
the next colon that is not part of a token.

Example:

]10datatext,hgr,lomem::text
]list

10 DATA text,hgr,lomem:: TEXT

Vladimir Ivanov

unread,
Feb 10, 2012, 5:04:43 AM2/10/12
to

Hi J-M,

On Thu, 9 Feb 2012, Deckard wrote:

> According to the Nibble Program Index, theses programs were first
> printed in the nibble magazines.
>
> "Applesoft Programming Helper" by Grant Stevens => volume 4 number 7
> (1983)
> "Microscope" by Ong Tee Yong => june 1986

I have used a lot a BASIC optimizer/compacter, whose name I can't remember
right now. I think it was 35 sectors in size, was operated by & commands
(like &OPT ??), and was probably Beagle Bros product. It allowed creating
longer BASIC lines than with manual entering because of the limitation of
the input buffer.

Does that ring a bell?

Deckard

unread,
Feb 11, 2012, 5:55:03 PM2/11/12
to
On 9 fév, 23:08, Deckard <boutil...@free.fr> wrote:

> so I'm going to read them to see what they can really do.

"Applesoft Programming Helper" by Grant Stevens is the program I was
looking for.
I had to add a small patch for the ampersand keyword subroutine but
now it works fine.
It has found the syntax error in the line where a ":" was missing and
2 other lines with undef's statement err.

Thank you very much for you help.

JM

Deckard

unread,
Feb 11, 2012, 6:16:14 PM2/11/12
to
On 10 fév, 11:04, Vladimir Ivanov <vlad...@XXXyahooXXX.com> wrote:

> I have used a lot a BASIC optimizer/compacter, whose name I can't remember
> right now. I think it was 35 sectors in size, was operated by & commands
> (like &OPT ??), and was probably Beagle Bros product. It allowed creating
> longer BASIC lines than with manual entering because of the limitation of
> the input buffer.
>
> Does that ring a bell?

Hi Vlad,

Beagle Bros D CODE's COMPACT program?

JM

finksterj

unread,
Feb 11, 2012, 7:58:19 PM2/11/12
to
On Feb 5, 4:58 pm, Deckard <boutil...@free.fr> wrote:
The best program I found for this is the D.Bug program from the Beagle
Bros D.Code disk.

In the past I also used the Applesoft Programming Helper from Nibble -
but D.Bug is a superior program IMHO.

Vladimir Ivanov

unread,
Feb 12, 2012, 4:57:52 AM2/12/12
to

Hi J-M,
I was mistaken of the Beagle Bros origin - it's actually B.E.S.T. LONG by
Precision Microware. I found localized version in my archives, but here's
the original:

ftp://ftp.apple.asimov.net/pub/apple_II/images/programming/basic/basic_enhanced_software_tools.dsk.gz

ftp://ftp.apple.asimov.net/pub/apple_II/images/programming/basic/BEST15.dsk


Give it a try if possible, I'm curious whether it could help.

Deckard

unread,
Feb 12, 2012, 4:02:29 AM2/12/12
to
On 12 fév, 01:58, finksterj <fink...@yahoo.com> wrote:

> The best program I found for this is the D.Bug program from the Beagle
> Bros D.Code disk.
>
> In the past I also used the Applesoft Programming Helper from Nibble -
> but D.Bug is a superior program IMHO.

You've right.
I've got the same result with D.Bug:
http://boutillon.free.fr/Forum/m2/m2_beagle_bros_dbug.png
But HELPER's source code is available.

JM
0 new messages