Talk:Applesoft BASIC

Untitled

In the main article, a reference to "single-precision" floating point is made, combined with an 8 bit exponent.

What is meant by this?

Does it mean that the mantissa is 8 bits long, and the exponent is another 8 bits long?

I'd guess that the mantissa is normalized (with the series of bits shifted to the left, once for each time the exponent is diminished by one, until the leftmost bit is a '1' instead of a '0') but the main article leaves this completely to the imagination of the reader. Is there any way the main article could be straightened out, and the ambiguity resolved?

Single precision floating point numbers are usually 32 bit while double precision are 64 bit. Unlike some other 6502 Microsoft written BASIC interpreters (eg OSI BASIC which uses 32 bit fp numbers), Applesoft uses 40 bit floating point numbers - 8 bit exponent, 1 bit sign and 31 bit mantissa (with implied leading '1' bit). I will have a look at the main page and see if I can improve it. --TheGiantHogweed 09:47, 28 July 2006 (UTC)

The version of Applesoft found in the Apple IIc does add support for double-lores graphics but has a bug in the SCRN() function when used in double-lores mode - see page 43 of Open Apple Volume 1, June 1985. --TheGiantHogweed 09:47, 28 July 2006 (UTC)

I was disappointed by the lack of dates in the article.

What?

"Machine-language routines could be attached to the ampersand and USR hooks in the computer's memory and call Applesoft ROM code to retrieve the values of parameters that followed them."

This is pretty nonsensical could someone clean it up? --72.39.35.178 (talk) 05:21, 24 September 2008 (UTC)

It makes perfect sense if you already know what it means and remember how to do it:) Okay, so I rewrote that paragraph. Let me know if it's better and what if any is still unclear. DMacks (talk) 16:29, 24 September 2008 (UTC)

Ok but if all you mean when you say "extending" is the ability to transfer control to machine-language you can use CALL for that as well as & and USR(). And you can pass and retrieve data with POKE and PEEK. Why did you leave them out? Are you confusing modifying the interpreter itself (hooking) with a simple machine-language subroutine or what is it I'm missing? --72.39.35.178 (talk) 18:12, 25 September 2008 (UTC)

They make it possible to avoid the multi-step technique of POKE input-data, CALL routine, PEEK results, allowing the process to be carried out in a single step. And, to clarify: & and USR() work with "hooks" -- locations that store the addresses to be called when they (& or USR) are invoked. As I wrote (since the earlier question) in the article, "&" is indeed just a shorthand for CALL. Unlike PEEK and POKE, though, "&" USR() and CALL all execute specified machine language ROUTINES. Further, USR() is a FUNCTION that can appear within numerical (or even string) expressions/formulas. It returns a value that is integrated into the expression calculation. The syntax of USR() includes one numerical argument passed to the machine-routine. The value of the argument is stored in the "floating-point accumulator" (FAC) at zero-page locations $9D to $A2. This value can be converted to a (one- or) two-byte integer by having the machine-routine call (JSR) an Applesoft ROM routine; for example, JSR E752 converts it into a two-byte integer stored in locations $50-$51, as well as in the 6502 registers A (high byte) and Y (low byte). Then, for further example, the machine-routine could then calculate the factorial of the argument, and store the result back in the FAC, where, upon exiting via RTS, the value there would be the value returned by USR() in the expression. Thus, USR(7) would return 5040, and the statement X = USR(7) * 3 would store 15120 in X.

But USR() could be further "extended" with additional Applesoft ROM calls. Suppose you didn't want merely to calculate a factorial; suppose you wanted to compute "combinations", which is based on two arguments. With the aforementioned JSR E752, you could then push the integer value (from A and Y) onto the stack: PHA TYA PHA, and then call Applesoft ROM to read a second argument to USR(), by JSR DD67, followed by JSR DEB8 to look for ")" (for workable, albeit overall rather odd, expression syntax), and JSR E752 again to convert the NEW argument to integer in $50-$51, and PLA TAY PLA to pop the FIRST argument off the stack, back into registers A and Y. Thus, with the first argument in A and Y, and the second in $50-$51, you could calculate "combinations" for them, leaving the result in FAC, to be returned as the value of USR(). So USR(12)5) could return 792, and the statement X = USR(12)5) / USR(9)2) would store 22 in X. Of course, these examples all used plain numbers as arguments, but variables or complex expressions could also be used. At any rate, using the old POKE-CALL-PEEK method, with a routine stored at 768 (a common location to store small routines), carrying out the last example would've required code something like this:

POKE 6,12

POKE 7,5

CALL 768

X = PEEK(9) * 256 + PEEK(8)

POKE 6,9

POKE 7,2

CALL 768

X = X / (PEEK(9) * 256 + PEEK(8))

Similarly, although CALL and & do not return values, they could be programmed to take arguments; for example, the routine for a CALL could JSR to the Applesoft routine to check for a comma (DEBE) after the CALL address, and then receive a two-byte integer argument with JSR DD67 and JSR E752; so a routine stored at 768, that takes one argument, could be invoked by CALL 768,Y * 3 - K

70.17.167.90 (talk) 23:58, 28 February 2013 (UTC)

Slow or fast, it's all relative

The main page of this article has references deprecating the speed of Applesoft BASIC. Is that sort of thing appropriate in Wikipedia?

Regardless if you think it is slow or fast, there are ways of describing its performance objectively. In the early 1980s, there was a magazine or periodical called Computer Shopper that published comparisons of the various species of BASIC. This article could be improved if you cited the page and issue where someone came to the conclusion it was "slow" (or "fast" or whatever it was). Dexter Nextnumber (talk) 02:58, 28 May 2010 (UTC)

Or you could simply provide example code for a benchmark that can be run on real systems or emulators limited to original speed. Actually, the speed difference is relative, so even fast(unlimited) emulators could be used. I'll leave this as homework for all the would-be editors who want to specify a real ratio.

For j = 0 to 10000: For i = 0 to 10000: Next i: Print j: Next j

A slightly more realistic benchmark would do something like this: k=0: For j = 0 to 10000: For i = 0 to 20000: k=k+i-j: k=k-i+j: Next i: Print j: Next j

73.3.211.0 (talk) 17:16, 18 January 2015 (UTC)

Preserving Trivia points

If no one comes forward to provide citations for these "Trivia points" that an editor removed, I don't want them to become "buried" over time, so I'm putting a copy of them here for handy reference, as I believe they are useful:

• Applesoft's garbage collector was notoriously slow (O(n²)). If a program had a large number of string variables, garbage collection, which occurred when the interpreter ran out of memory for a new string allocation, could seemingly lock up the computer for several minutes. Since users could not know when the computer was running low on string memory, these pauses seemed random and inexplicable. Though third parties provided some improvements, Apple did not truly fix the problem until ProDOS, which included a new garbage collector that did the same job in seconds as part of BASIC.SYSTEM.
• Neither Apple nor Microsoft ever made source code for Applesoft BASIC available. However, Glen Bredon included a program with his Merlin assembler that would generate a commented copy of the disassembled machine language sources for the Applesoft interpreter. To avoid violating copyright, the source disassembler was encrypted using the compiled Applesoft program code, which was stored on the computer's ROMs. Thus, a person needed to have a functioning ROM copy of Applesoft in order to use the disassembler to see the source code.
• Due to Applesoft BASIC's slow performance, BASIC compilers were much sought-after tools for BASIC programmers. The first, Microsoft's The AppleSoft Compiler (TASC), was actually written in Applesoft and then used to compile itself. A later product, the Einstein Compiler, was somewhat more sophisticated and offered better performance both in compilation and in execution. The last major BASIC compiler was the Beagle Compiler, written by Alan Bird and published by Beagle Bros: it integrated closely with ProDOS (the current Apple II OS at the time of its release), compiled programs in seconds rather than minutes, and achieved superior code execution performance by optimizing integer math and pre-computing addresses of GOTO targets, among other tricks. Unlike previous compilers, the Beagle Compiler did not truly compile BASIC programs to machine code, but rather converted them to a highly optimized bytecode that was interpreted by a runtime module, much like the UCSD p-System.

Help Me Please!

I REALLY want to learn Applesoft BASIC programing, but I'm not old enough to take a course on it, and I can't find anything online that will teach me much more than the hello world program.--DianaFowl (talk) 21:09, 22 November 2011 (UTC)

Hi. Looking around for some possible sources for this article, I have come across these, which may also help you, as of 2011:

• Apple2Online's Applesoft section has a few reference guides and tutorials.
• The CSA2 FAQ has some questions and tips about Applesoft.

Note that, when looking at information, "Apple II Basic" often refers to Integer BASIC, which is a bit older than Applesoft. Integer BASIC (INT) is the one that came stock on the first Apple II; Applesoft (FP) is the one that came stock on all the other Apple II computers (Apple II Plus and later). Also, Applesoft works under both Apple DOS 3.3 and ProDOS; a few of the disk commands are different depending on which one of those you're using. --Closeapple (talk) 03:57, 24 November 2011 (UTC)

Tense in article

Per WP:TENSE, the tense in this article as a technological historical item should be in the past tense (given that there is no new equipment that features it). An edit-warring IP editor 75.162.179.246 is repeatedly restoring the text to the present tense having first changed it on the 14th November (currently at 6RR though not in 24 hours, but it is still a slow motion edit war).

This editor is attempting to use the justification that [a few] other such articles are fully or partly in the present tense. I do not believe that another article in the wrong tense is justification for going against the MOS. The editor cites Phonograph cylinder and Wire recording as his justification. Phonograph cylinder is written in the past tense apart from one present tense in the lede, "Phonograph cylinders are the earliest commercial medium for recording and reproducing sound". Present tense would be acceptable for that statement as Phonograph cylinders [still] are the earliest commercial medium for recording and reproducing sound. Past tense here would imply that an earlier medium had been uncovered. As for Wire Recording, it is mostly in the past tense, but there are parts in the present. The article does require copy editing to make the tense consistent throughout (and past tense as it is historical, there being no wire recorders made today.

In addition, it seems to me that this editor has a long history of disruptive editing and edit warring elsewhere. I also not that this editor lacks any consistency because although this editor is insisting that this article be put into the present tense, I note that the same editor has also changed the similarly historical article on Droid 4 from the present tense to the past tense. –LiveRail < Talk > 17:02, 16 November 2014 (UTC)

If I'm supposedly "edit-warring" by matching an article to my good-faith interpretation of the rule, then YOU are also edit-warring by reverting my editions back, according to what you think is your "good-faith" interpretation of the rule. So he who edits with one supposed "warrior" is also a warrior. He who edits in that case and reports that supposed "warrior" is also reporting himself. If you were correcting vandalism, then this would not be the case. But since this is not vandalism, then your editions are just as much warring as you think mine are.

Good-faith editions are not "disruptive editing," so you lied about that.

The two examples I gave aren't the only ones that were written in present-tense without my help. Try looking at some other articles, such as some of the Commodore computer articles that were already present-tense before I came along (as if those writings count but mine "don't" for some unknown reason). I'll try to think of some other discontinued things that were written that way without my help and then bring them here.

Oh, you so badly want this article written in past-tense, but then you complain when I try to conform a different article of a discontinued model to *fit* your and Die's interpretations of the rule just to go along with what you guys are trying to enforce? Geesh, make up your mind!

75.162.179.246 (talk) 17:39, 16 November 2014 (UTC)

Note: The above IP address editor was subsequently blocked for disruptive editing and edit warring of his continued changes to the tense of articles. –LiveRail < Talk > 16:25, 17 November 2014 (UTC)

Atomic strings - misleading sentence

"Atomic strings: A string is no longer an array of characters (as in Integer BASIC and C); it is instead a garbage-collected object (as in Scheme and Java). This allows for string arrays; DIM A$(10) resulted in a vector of eleven string variables numbered 0–10." The second sentence is mostly irrelevant and misleading, as C also allows arrays of finite-length 'strings' (called 'char arrays'. This would be 2-dimensional with one being the length and the other being how many of that finite-length object it could hold. The writer seems to be having confusion over the difference between DIMension and variable-length strings. These 2 features both came into play when moving to a newer BASIC. 73.3.211.0 (talk) 19:44, 18 January 2015 (UTC)

They weren't my sentences, but an explanation of strings in Integer BASIC may be helpful (or not, but I'll give it a shot). In Integer BASIC, string variables (simple variables, not arrays) required a DIM statement to declare how many characters they could hold. DIM B$(30) creates the single string variable B$ that can hold up to 30 characters. There could not be arrays of string variables in Integer BASIC. Applesoft differed from this in that the same statement in Applesoft would create an array B$ of string variables, numbered 0 to 30. I don't know if this really helps, but it couldn't hurt. 67.186.19.151 (talk) 11:09, 23 May 2015 (UTC)

Syntax highlighting

The two snippets of Applesoft BASIC code in the article are nicely formatted and look great, and it seems like the standard "basic" language definition in SyntaxHighlight works quite well. I was just drafting a slightly longer passage of code for possible inclusion, and the only thing I noticed that it wasn't handling properly was REM statements. Does anyone know of any other challenges with using the standard "basic" language as a stand-in for true Applesoft BASIC?

Also, I see Pygments says that "if a lexer for your favorite language is missing in the Pygments package, you can easily write your own and extend Pygments." Might someone be willing/able to craft a variant lexer for Applesoft BASIC? (It seems like the standard "basic" is already quite close.) If not, I'm certainly willing to see what I can figure it out, though I'm afraid I'm unfamiliar with the process. Thanks! ╠╣uw [talk] 15:02, 16 September 2019 (UTC)