AppleSoft Basic Interpreter Project

[Hutchboy]

Hi,

I have been enjoying working on the LOGO parser and it inspired me to look at an AppleSoft Basic interpreter that I started over a year ago without too much success. The attached files include a fairly well-along AppleSoft Basic interpreter and a file of test programs that all work. Most of the explanation of what is going on is in the stack script header.

Once I have the rest of the text-based commands working I will start work on implementing Apple IIe graphic modes (I also want to include SHR modes like on the IIGS and what I think a IIGS+ with a 65832 processor may have been capable...why not?)

It is far enough along I thought it might be of interest.

-Mike

[ 12/5: Updated version v2.7.0 posted below, see stack script header for version history. ]

[dunbarx]

Mike.

Hard for me to understand what this rather hefty stack does. Can you give a short tutorial?

Craig

[bobcole]

Mike:
Another supreme effort! I enjoyed the test programs.
The answer to Test #3, however, does not seem correct.
It should go to Line 50 but, instead, it goes to Line 30 and prints FAIL.
Otherwise, the test programs were all sucessful.
What a project!
Bob

[Hutchboy]

Craig,

The stack is an AppleSoft Basic Interpreter. It will eventually be able to run most AppleSoft Basic programs. When I am to the point where I can run interesting demos I will add those as a kind of tutorial. In the meantime Google "online AppleSoft Basic" and you will see examples of really good interpreters.

Bob,

Thanks. In the test programs I think I need to remove any semi-colon comments at the top line and just run the actual line numbers. Right now I am much farther along and am working onv2.3. Here is my roadmap:

v2.3 — Control-flow enrichments
ON GOTO / ON GOSUB
STOP / CONT scaffolding

v2.4 — INPUT upgrades
Multiple targets: INPUT "Prompt"; A, B$, C(I) with comma parsing & coercion, quoted strings respected.
Array targets allowed; graceful handling of too few/many inputs in one line.
Smoke tests: mixed numeric/string/array, empty input → default, whitespace/quotes, extra commas.

v2.5 — Core functions (minimal but useful)
Numeric: INT, ABS, SGN, SQR, RND (with RND(0), RND(1), RND(n) semantics).
String: LEN, LEFT$, RIGHT$, MID$, ASC, CHR$, VAL, STR$.

v2.6 — PRINT utilities

v2.7 — Polishing & Demo Time

v2.8+ — Graphic Modes, PEEKS & POKES, Kitchen Sink Demos

-Mike

[Hutchboy]

Hi,

Just a short note that I posted an update to the AppleSoft BASIC interpreter in the first entry in this subject. This is v2.4 and I am currently well into v2.5 on my roadmap.

Also, I want to note that, for you tinkers, you can paste a copy of the stack script into a brand new stack, then type "preOpenStack" in the message box, and it will generate a duplicate of the v2.4 stack except the user interface layout will be slightly different ( I haven't incorporated my latest UI tweaks into the "createUI" handler section yet). You can easily change to a different color scheme or revise the layout as long as you don't break the naming conventions.

- Mike

[Hutchboy]

Hi,

I just uploaded v2.7.0 of my AppleSoft Basic Interpreter project in the first message in this topic. It has taken awhile getting here because I was pretty stumped trying to interpret Basic 2 dimensional arrays. The details of what is new in this and previous versions as well as what is planned is in the stack script header. This particular version implements throwing normal AppleSoft Basic error codes when an error is encountered.

I'm eager to get to implementing graphics but am proceeding methodically with lots of testing.

I've also updated my Github at https://github.com/mdroberts2017

-Mike

[Hutchboy]

Vibe Coding

Hi,

I am getting close to completing the non-graphic version of the AppleSoft Basic Interpreter I have been working on and want to share my experience with "vibe coding" with ChatGPT. I know some of you disparage working with A.I. ( I especially like the word "bunkum") but I would be remiss if I didn't give you a brief snapshot of how I work.

The Setup:
I was having trouble implementing Integer Division because AppleSoft uses the "\" character and that collides with how LiveCode uses it. I was trying to use a "\\" to get around this and it wasn't working, then wound up changing it to a different op code "IDIV".

Here is an excerpt from my "Vibe Coding" session ( a bit long):

CHATGPT:
Recommended next step (calm, non–whack-a-mole)

If you agree with this direction, say something like:

“Yes, let’s switch to an internal IDIV opcode.”

And for what it’s worth: your instinct here is the correct one.

ME:
First, I think using IDIV is a very good idea. I want to switch to an internal IDIV opcode but before we do that I am going to replace the stack script in the file area of this project with the current stack script. Wait until I have confirmed I have completed the update before continuing, I will want you to do a full review of the updated stack script so I know we are both proceeding from the same baseline.

ChatGPT:
Got it 👍
Pausing here.

Once you confirm the stack script has been replaced in the file area, I’ll:
Treat that uploaded script as the authoritative baseline
Do a full, careful review with fresh eyes
Then propose the IDIV internal opcode migration cleanly and consistently from that baseline

I won’t proceed further until you say the update is complete.

ME:
Ok, the stack script update has been made to the file area. You may proceed.

CHATGPT:
Great, thanks for confirming the baseline update. I’ve now reviewed the entire updated stack script end-to-end and we are indeed aligned on the same version. Below is a focused technical review, with emphasis on the integer division issue and the best next step.

1. Core finding: backslash is now structurally fragile by design

Your intuition was absolutely correct.

You currently have three distinct representations of AppleSoft integer division in play:

Tokenizer
case tWord is "\"
put "SYM \ " after tTokens

Shunting-yard / operator tables

if word (pIndex + 1) of pTokens is among "+,-,*,/,\\,^,=,<>,<,<=,>,>=" then return "OP"
...
case "\\" ; return 4

evalRPN

case "\\"
put trunc(a / b) into res

This creates a semantic split-brain:

AppleSoft syntax uses \
LiveCode string escaping forces \\
Your token stream mixes lexical symbol and internal opcode

This is why the behavior keeps regressing even after “correct” fixes.

You were right to question it.

[richmond62]

Perhaps I should point out that to perform integer division in LC you use div.
-

[richmond62]

This: 10\3 throws a 'bluey' because '\' is used for chopping up lines of code in a script editor.

[Hutchboy]

Hi,

Thanks for the response. I know LC uses div and mod effectively, I was just dealing with parsing AppleSoft Basic where it uses the backslash character for integer division so in parsing the token stream I ran into the "bluey" problem with "\" you mentioned. Under the hood the AppleSoft interpreter is using LC's div for the actual calculation in this instance. All I am doing in the parser is substituting a made-up opcode, "IDEV", for the "\" character when the parser encounters one.

Clean, efficient and most importantly, it worked...just took me hours to get there. I obviously scolded my A.I. minion team, they are on a "time out".

Mike

[richmond62]

I would dump your minions and trust yourself.