Does anyone know where I can get Steve Wozniaks original BASIC for the Apple-1 computer, also used in first Apple ][. Note:ONLY ORIGINAL APPLE ][ OR EARLIER!!!

Thanks!!! Bye,

I beleive you are looking for the Integer BASIC?

I did a quick search for some Apple 2 emulators. These usually have the original Apple ROM files that can be used or have some disk images that might include Integer BASIC.

Try this link out for starters:
http://www.cs.uu.nl/wais/html/na-dir/ap ... part1.html

Let me know if you need more help.

Daryl

Apple I BASIC and Apple II "Integer" BASIC are similar, but not the same thing. Most notably, Integer BASIC variables names can be any length (up to 125 characters, limited by the parser), whereas Apple I BASIC variables can be one or two characters long. Also, there are command name differences (SCR vs. NEW), and some minor syntax differences in a couple of places. Integer BASIC is just over 5k long, and has additional commands for things like graphics. It also makes use of several Apple II ROM routines, for input, output, reading the paddles/joystick, etc. Apple I BASIC is only 4k long, and interestingly, other than input and output instructions, is pretty much hardware independent. I ported it to an Apple II (so I could experiment with it) by patching only about a dozen or so bytes. I wrote down a list of only 7 or so rules/steps (that I have not tried) necessary for porting it to any 6502-based system, e.g. Daryl Rictor's SBC. It's not all that much more involved than porting Sweet 16, as Carsten Strotmann describes in his article in the source code repository.

I found a couple of copies of Apple I BASIC on the web at:

http://www.brouhaha.com/~eric/retrocomp ... le1/basic/
http://members.aol.com/MJMahon/

Naturally, the two are not identical. I believe the first one is correct (or at least closer to correct), but I have no way of confirming or denying this, as I do not own an Apple I or an actual copy of Apple I BASIC. There are at least one or two Apple I enthusiasts who are members of the 6502.org forum, but I don't know how often they check and/or read it. Also, note that the labels (in the first) can be a bit misleading. Anyway, I wrote a short program to extract the object code from the text file, and write a (4096-byte) binary file. You could use a perl script to do something similar, or to convert the syntax of the source code to the assembler of your choice.

A copy of the Apple I BASIC manual can be found at:

http://www.applefritter.com/apple1/

under "Documentation".

Integer BASIC (Apple II) can be found in the INTBASIC file on a DOS 3.3 System Master disk, if you can locate one. I still have a several copies of the System Master, so I've never searched the web for it. The Apple IIgs did not ship with a copy of the System Master, but many people used one to run Integer BASIC programs, so even back in the day, copies of the System Master floated fairly freely.

Anyway, if you have questions or want additional details, feel free to ask. The syntax table is a little strange, but its not too difficult to follow once you understand how it works.

If you want to talk strange, look at how Commodore BASIC's keyword scanning code works. Basically, each keyword's final character has its high-bit set, and the string comparison routine checked for the sign bit to end the string comparison.

Programmers could exploit this to use short-forms for commands. For example, instead of "list", you could type "lI" (L, shift-I). Or instead of "load", "lO". etc. This resulted in the ability to create remarkably compact, albeit hard to read, BASIC programs.

Well, the entire syntax table (including keyword names) is in reverse order and keywords (tokens) and syntax rules are juxtaposed. Keyword characters all have their high bit set, but " to _ (it's all uppercase) is $82-$BF and $C2-$FF rather than $A2-$DF (in the syntax table, space and ! are handled specially). So it's a little unusual.

Because it's a rule-based parser, Integer BASIC is pretty tolerant when it comes to variable names. PRINT PRINT is a valid statement. The first PRINT is a verb (token), the second is a variable name. PRINT=1 generates a syntax error, but LET PRINT=1 works. Even the following statement is perfectly valid and will not generate a syntax error (syntax checking is done at parse time):



Top that

Sorry -- way late in answering this, but I didn't see the response until now, while idling browsing the site during my lunch break.

I don't think that would even *RUN*, even if it does parse correctly. The first TO would be the variable for the FOR, but the NEXT isn't a "=" symbol, so that should generate a syntax error upon running.

Am I missing something?

BTW, BASICs that error out during program entry (as with AtariBASIC as well) should have become the norm -- it's so nice knowing that the entered program is that much more correct, especially when it doesn't adversely affect the size of the BASIC environment.

How does Apple I BASIC handle memory management? E.g., how does it allocate space for variables, and perhaps more importantly, how does it *reclaim* space for variables?

For example:

It will RUN, believe it not. Spaces (except within quotes, of course) are ignored by the parser, so the example as given is what would be entered; subsequently LISTing it would result in different spacing and is pretty much a dead giveaway as to how it was parsed. For example, if you entered:

1 PRINT PRINT ED PAGE

it would be LISTed as:

1 PRINT PRINTEDPAGE

One example of a valid PRINT statement is PRINT followed by a numeric expression. One example of a valid numeric expression is a variable name. So, after the first PRINT has been parsed and the parser is determining whether that which follows is valid, it is looking for an expression, not a statement. While parsing an expression, the word PRINT has no special meaning. A variable name consists of a letter optionally followed by zero or more letters or numbers. However, there is one other thing the parser must check at this time. I'll let you think about what that might be before posting the answer. (And no, I am not referring to the maximum variable name length; the limit there is when the parse buffer is full, which is handled in the parse routine itself and is common to everything in the syntax table, rather than being specific to variable names.) With this last piece of the puzzle, it's fairly straightforward to figure out how the earlier example is tokenized.

Anyway, after the first PRINT, the words PRINT ED PAGE satisfy the requirements for a valid numeric variable name (since spaces are ignored). LISTing it results in the spacing shown above, which makes it clearer that PRINTEDPAGE is actually a variable name.

I first encountered this when I entered a line like 1 PRINT PRINT having intended to put a colon between the two PRINTs. When I saw my mistake, I wondered why it hadn't resulted in a syntax error. LISTing the line gave the same spacing, so that wasn't particularly enlightening to me. Before making the correction, I ran it, and it printed 0, and that's when it dawned on me that the second PRINT was a variable name. I used the monitor to examine the contents of the memory where the tokenized program was stored, and that confirmed my suspicions, since that was indeed how the line had been tokenized.

Of course, the earlier example is just something intentionally ridiculous. Anyway, the syntax rule for a FOR statement is:

FOR <numeric variable name> = <numeric expression> TO <numeric expression>

optionally followed by:

STEP <numeric expression>

and as I alluded to above, that's ALMOST enough information to figure out how the earlier example is parsed...



Integer BASIC and Apple I BASIC use a pretty primitive scheme. Keep in mind that while both could be extended in a number of directions, they were ultimately written to fit in a small amount of ROM. The maximum length of a string is specified beforehand using the DIM statement, which allocates space. The maximum length can be a numeric expression (i.e. not just a constant, so it can be calculated), but there is no built-in way to change the maximum length later. (It wouldn't be that difficult to write a short routine in assembly to do this by shuffling things around in memory, though.) The only built-in way to reclaim space is by clearing all variables, e.g. with the CLR command. But this approach eliminated the need for garbage collection.

In your example, if you used DIM A$(5),B$(5),C$(11) the second B$=... would generate an error, but using DIM A$(5),B$(65),C$(11) would work. Most Integer BASIC programs tended to allocate more space than was absolutely necessary in the interests of expediency. DIM A$(10),B$(100),C$(20) would be more typical of an actual program.

Anyway, there's a pointer that is initialized to the start of unused (i.e. not containing the tokenized program) RAM. To allocate space for variables and arrays during run time it simply adjusts this pointer to reserve enough space for the name, the data, and some other overhead. If you want the exact details of the variable storage format and/or what happens when allocation occurs, I could post some examples. I was just going for more of an overview here.

Also, there are no temporary strings. PRINT A$+B$;LEN(C$+D$) can be replaced by PRINT A$;B$;LEN(C$)+LEN(D$) which is better anyway, since it eliminates the need for concatenation. The expression ASC(A$+B$) is rarely seen; it uses the first character of A$, unless A$ is an empty string, in which case it uses the first character of B$. For that expression you'd have to concatenate the two strings in a variable first, then use that as the argument for ASC.

There isn't a string concatenation operator, either; instead, the string is built up in space already allocated for a string variable by a DIM statement. Some BASICs allow the statement MID$(A$,3) = B$ as an alternative to A$ = LEFT$(A$,2) + B$. Integer BASIC and Apple I BASIC use a different syntax, but the same concept as former; the former is replaced by A$(3) = B$. A$ = A$ + B$ is replaced by A$(LEN(A$)+1) = B$ and A$ = "<" + A$ + ">" would be replaced by something like TEMP$ = A$: A$ = "<": A$(2) = TEMP$: A$(LEN(A$)+1) = ">". C has a similar issue, since its string operations are functions; there's no less functionality, its just clearer (IMO) to write a simple statement like IF A$ < B$ + C$ THEN D = 0 than to have several function calls or several statements to build a temporary string.

(By the way, if that syntax makes you wonder about string arrays, the answer is that there weren't any, but they could be -- and often were -- faked using substrings. Not wildly convenient, but not wildly inconvenient, either. There were numeric (16-bit signed integer) arrays, though.)

This is exactly like Python's syntax. It uses list subscription notation for nearly everything, and can even specify a specific range (e.g., Foo[3:6]).

Note that this is also how the Kemeny & Kurtz BASIC (the author's original language design) was implemented as I recall correctly.

I cannot, at this time, think of what other issue the FOR parser needs to consider though. The only thing I can think of is non-alnum characters like = or : in the character stream.

.. just gives a *** SYNTAX ERR

How do you get Apple integer BASIC to give a "TOO MANY PARENS" error? I think the code at $E710 should give this error but I also think the error message table index byte there is incorrect, the dump I have would give a "PPED AT " error if it ever got there.

Entering a line that has too many levels of parenthesis overflows the parser stack so gives a "TOO LONG" error and won't execute.

Also Apple 1 BASIC seems to be unfinished, there are commands and functions that exist in the syntax table but either don't do anything, do something other than what you'd expect or crash the interpreter.

Was it ever completed as a 4K integer BASIC?

Lee.

I have an Apple II Integer BASIC disassembly at
http://linux.cis.monroeccc.edu/~paulrsm/6502/

One of the few bugs is the "TOO LONG" error message
instead of the "TOO MANY PAREN" error message.
This is caused by the byte at $E478 (or close) pointing
to the wrong error message.

The code at $E710 is unused dead code.

I think this error happens when the syntax stack overflows during tokenisation, I've not traced that code through yet so don't have the full picture of what's going on. The message index byte is at $E47A.


It should be executed if the value stack overflows but I've yet to find BASIC code that will do that.

Lee.

You're on the right track. Non-alphanumeric characters terminate a variable name by not satisfying the "letter followed by zero or more alphanumeric characters" rule, but consider the following statement:

1 FOR I=A TO LL+Z

Once the parser gets past the equals sign, it is looking for an expression. If the rule were only "letter followed by zero or more alphanumeric characters", then A TO LL would be a valid variable name (since spaces are ignored), the plus sign is a valid operator, and Z is another valid variable name, and thus it would be past Z and then be looking for the TO keyword there.

So the answer is that there are a handful of keywords that terminate a variable name, and the parser must check for them. There are keywords that serve as delimiters, such as THEN, TO and STEP, and keywords that serve as operators, like AND, OR, and MOD. Since there is no valid syntax where a variable name would be immediately followed by a statement/command (such as IF, GOSUB, or PRINT) or a function (like ABS and LEN), these keywords do not terminate variable names and can be used within variable names freely. In fact, it could be even more lenient than it actually is. A FOR statement has no THEN clause, and an IF statement has no TO or STEP clause, so a statement such as IF CUSTOM=0 THEN PRINT could have been permitted. However, in the interests of expediency, the delimiter keywords always terminate a variable name (this is after all, a 5k BASIC interpreter), so PRINT STRENGTHEN gives a syntax error.

So the actual rule for a variable name is a letter, followed by zero or alphanumeric characters but also terminated by an operator or delimiter keyword. This means that TO and TON are valid variable names (since it doesn't check for keywords until the second character), but LAND is invalid. In a statement like FOR X = <expression> TO <expression>, the shortest valid expression containing a variable name is a variable name consisting of one letter, so the soonest that the TO keyword could appear is the second character of the variable name.

And this is enough information to figure out how the example above is parsed. SPOILERS FOLLOW!

1. First the FOR keyword is parsed.
2. Next, it parses a variable name. The first letter is T followed by the letters ONEXT. Since there are no (delimiter or operator) keywords within ONEXT, the loop (index) variable name is TONEXT.
3. Then the = is parsed as part of the FOR statement rule.
4. Then it parses a numeric expression. The expression doesn't start with NOT, and since there are no parentheses, it couldn't possibly be a function like ABS or SGN, so if it is valid, it must be variable name. The first letter is T, followed by O NEXT and FOR. There is an OR keyword at the end of FOR which terminates the variable name, so the variable name is TONEXTF, which is followed by an OR operator.
5. Continuing on with the expression, this will again be a variable name, starting with T followed by O FOR. The OR terminates this variable name, so the variable name is TOF, followed by an OR operator.
6. The expression continues with another variable name: S followed by TEP TO. The TO terminates this variable name. So the variable name is STEP.
7. Then the TO keyword is parsed as part of the FOR statement rule, concluding the starting index expression. It then parses another numeric expression (the ending index).
8. This expression begins with a variable also (big surprise): S followed by TEP FOR, with OR terminating the variable name, so the variable name is STEPF, followed by an OR operator.
9. This is followed by another variable name: T followed by O, so the variable name is TO.
10. This is followed by an = operator.
11. This is followed by a variable name: T followed by O FOR, so the variable name is TOF followed by an OR operator.
12. This is followed by a variable name: S followed by TEP FOR, so the variable name is STEPF, followed by an OR operator.
13. This is followed by a variable name: T followed by O STEP. The STEP keyword terminates this variable name, so the variable name is TO.
14. Then the optional STEP keyword is parsed as part of the FOR statement rule. We're entering the home stretch! It then parses another numeric expression, the step size.
15. This expression begins with a variable name: T followed by O NEXT FOR, so the variable name is TONEXTF followed by an OR operator.
16. This is followed by a variable name: S followed by TEP, so the variable name is STEP.
17. This is followed by an = operator
18. This is followed by a variable name: T followed by O FOR, so the variable name is TOF, followed by an OR operator.
19. This is followed by a variable name: S followed by TEP NEXT FOR, so the variable name is STEPNEXTF, followed by an OR operator
20. This is followed by a variable name: T followed by O, so the final variable is TO. 'bout time!

So the example will LIST as: (Keywords in bold. Words not in bold are variable names.)

1 FOR TONEXT=TONEXTF OR TOF OR STEP TO STEPF OR TO=TOF OR STEPF OR TO STEP TONEXTF OR STEP=TOF OR STEPNEXTF OR TO

Okay, that's still pretty ugly (and the Apple doesn't list keywords in bold, anyway ). The starting index (between = and TO) is the expression:

TONEXTF OR TOF OR STEP

the ending index (between TO and STEP) is the expression: (shown here with superfluous parentheses)

STEPF OR (TO=TOF) OR STEPF OR TO

and the step size (after STEP) is the expression:

TONEXTF OR (STEP=TOF) OR STEPNEXTF OR TO



Hmm...just to double check the explanation above, I tried it again, and didn't get an error (and it LISTed as described). I didn't transfer the example electronically (I wrote it down on piece of paper from the earlier post and retyped it), just now or even originally for that matter. If I've somehow gotten it wrong in my post, I'm just not seeing it, but stranger things have happened. If it's not a typo, some other possibilities might be:

1. It's Apple II Integer BASIC, not Apple I BASIC (the latter has restrictive variable names, but the former does not)
2. The whole thing is all one line, even though it is so long that the post wraps (at least on my browser).
3. There must be a line number. An immediate FOR is not valid syntax in Integer BASIC and will produce an error message at parse time.

If it not one of those, I'm stumped. It's not out of the question that there's some other assumption that I've taken for granted and failed to post, though.



You don't. That message is in the error message table, but it's not referenced anywhere! It's a semi-famous bug. There are only about a dozen bugs that I know of in Integer BASIC, most of them, like this one, minor.

The code at $E710 occurs when the run-time noun (data) stack overflows. This is different from the parse-time syntax stack overflowing, which is what is supposed to give a TOO MANY PARENS error. That code is at $E479. If you have Integer BASIC in Bank Switched (Language Card) RAM on an Apple, you can enter the monitor (with CALL-151) and patch the code with:

C083 C083 NE47A:1C

and then (14 sets of parenthesis, note that this and subsequent examples are all one liners):

1 PRINT ((((( ((((( (((( 0 ))))) ))))) ))))

will give you a TOO MANY PARENS at parse time. One of the numeric expression rules is:

( <numeric expression> )

And that is the only place where recursion occurs in the parse table, so while parsing other syntax will use some syntax stack space, syntax stack overflow would never occur without nested parentheses, which is why that is the error message that should be TOO MANY PARENS.

The TOO LONG error (also) occurs if the parse buffer overflows. If the input buffer (untokenized source) and the parse buffer (tokenized source) don't both fit in within page 2, then a TOO LONG error occurs, e.g.:

1 PRINT 0; 1; 2; 3; 4; 5; 6; 7; 8; 9; 10; 11; 12; 13; 14; 15; 16; 17; 18; 19; 20; 21; 22; 23; 24; 25; 26; 27; 28; 29; 30; 31; 32; 33; 34; 35; 36

(with or without spaces) will give a TOO LONG error, with or without the above patch, as will literal strings of at least 128 characters, e.g.:

1 PRINT "EVERY GENERATION BEARS A SOLDIER OF THE TRUTH WHO MARCHES THROUGH THE REALM SETTING FIRE TO EVERY ROOF YELLING THERE ARE NO RULES"

As for the $E710 code, that situation can occur when operators are in order of increasing precedence. Precedence is handled at run time, so with:

PRINT 1+2*3

1, 2 and 3 are all pushed onto the noun stack, then the * operator is executed (there is a separate operator stack, namely the 6502 stack), then the + operator is executed. However, with:

PRINT 1*2+3

1 and 2 are pushed onto the noun stack, the * operator is executed, then 3 is pushed onto the noun stack, and then the + operator is executed, so the noun stack doesn't get as deep. To see the $E710 code in action:

1 PRINT A=A+A*1^(B=B+B*1^(C=C+C*1^(D=D+D*1^(E=E+E*1^(F=F+F*1^(G=G+G*1^(H=H+H*1^I))))) ))

Notice that no error occurs during parse time. Now RUN it and voila! Also notice that parentheses are only nested 7 deep -- if you remove one pair of parentheses from the earlier example (leaving you with 13) it will parse and RUN without errors.

There aren't any other unreferenced error messages, so I'm not really sure what the intended error message was. My best guess is TOO LONG which would have been LDY #$06 instead of LDY #$66 (granted, it's not the sort of typo you'd normally see with an assembler, but Integer BASIC was hand assembled, so maybe...). Something like FORMULA TOO COMPLEX might have been a suitable error message for this situation.




Some of the Apple I folks can probably answer this far better than I, but my understanding is that work had already begun on the Apple II when BASIC was requested/needed for the Apple I. So Wozniak took the Apple II BASIC interpreter and modified it for the Apple I. Had it not been hand assembled, IF/ELSE/ENDIF directives probably would have been used and there likely would have been no traces of Apple II specific code in the Apple I interpreter and vice versa, even though there was a large amount of common code.

Since it was hand assembled, the changes were basically patched in. (Integer BASIC is located at $E000 to $F424, but there are several small unused sections. Some contain typical fill bytes, such as $00 and $FF, but there are several whose contents match what was found -- and used -- in the Apple I BASIC interpreter, so both really do contain traces of the other.) There are things that would be later used in Apple II Integer BASIC, such as COLOR= and PLOT. Evidently not everything unused got completely disabled, though. There were other examples of early Apple software that weren't exactly idiotproof, and would crash if you started venturing too far outside what was (lightly) documented in the manual (or sometimes even if you did follow the manual ). So, as far as I know, Apple I BASIC was as complete as far as Apple ever intended to make it.

You might also wish to surf some Apple history web sites.

I was trying it under Apple 1 BASIC which, I now realise, is limited to one alpha and an optional numeric character for variable names.


Yes that works. It does give the *** PPED AT ERR I expected.


Much like the string too complex error you get when the descriptor stack overflows in other BASICs. In this case though I think the *** TOO MANY PARENS is the best choice from the available messages and I can see how $1C could be mistaken for $66 in a poor print or scribbled code.

Ok so now I have a version of Apple 1 BASIC that seems to work as it should, overall I'm glad I never had to use it.

Lee.