Re: Two friendly questions to Apple II users...

[Fabrice Frances <frances@ensica.fr>]

Goody, the answers I received are very interesting and I guess it could
be
of interest to others, so here is a summary. Just a note for Apple users
who don't know Oric : Oric-1, Atmos and Telestrat (aka Stratos or IQ64) 
are the 3 Oric computers, they are based on a 6502 cpu. The reason for
my questions is that Tangerine, the company which copyrighted Oric's
Basic,
never officially said its Basic was a Microsoft (no Microsoft copyright,
nothing...). I'm far from being a Microsoft fan (it's quite the
opposite),
but I wanted to know the truth.

> From : Nathan Mates <nathan@visi.com>
> 1)    There were two major variants of Basic for Apple IIs: Integer
> Basic, done inhouse by Steve Wozniak, and Applesoft Basic, mostly done
> by Microsoft. [I think some of the hires stuff may have been finished
> at Apple]. Integer Basic, as the name implies, is integers (and
> strings) only; Applesoft added the ability to use reals. Those reals
> use 5 bytes apiece for storing their content in memory (plus overhead
> for variable names, etc, but the highest bit (sign) is expanded off to
> a sixth byte when loading the floating pt accum for math stuff, if I
> recall correctly).

Ok, so I'm very interested in the comparison of Oric Basic and
Applesoft.
The floating point values are handled exactly the same (the floating
point accumulators in page zero expands the sign bit in a sixth byte)

> From : Neil Parker <nparker@cie-2.uoregon.edu>
> 2) Yes, this is indeed the case.  There are a handful of internal operations
> that Apple BASIC performs with integer arithmetic (parsing line numbers,
> for example), but all user-visible arithmetic is done in floating-point,
> even on integer variables.  Because of the extra overhead associated with
> converting integers to floating-point before use and back to integers
> after, integer variables are really only useful for compact storage (an
> integer array takes up less memory than the corresponding floating-point
> array).

Goody, second striking similarity... 

> From : Bryan Dunphy <bdunphy@cityscape.net>
> 3) Half-right. Only the first two chars are significant is correct;
> however, var name were limited to 123 chars if you wanted to do
> anything with them by the 127 byte input buffer.

Ok, let's say I was right, there are always limits 8-)
The input buffer limit can surely be walked around (poking the tokenized
code, etc), then there may be the line size limit (near 250 bytes).
As a comparison, the input buffer on the oric is only 80 chars...

> From : David Empson <dempson@actrix.gen.nz>
> Correct.  The data structure used to hold a variable only stores the
> first two characters (bit 7 of each character is used to encode the
> variable type).  Variable names must therefore be unique in the first
> two letters.  Another limitation is that reserved words must not appear
> within variable names, because the parser will tokenise them.
> 
> Variables of different types may use the same name, e.g. AB$, AB, AB%,
> AB(n), AB$(n), AB%(n)

Same thing again with Oric Basic... I guess there is no need to ask
for the global memory map of Applesoft : program code, scalar variables
(including string variables, but only a pointer and a length is stored
here), array variables, heap (containing strings) ?

> From : David Empson <dempson@actrix.gen.nz>
> 4) Well, there are ten unused bytes immediately after the lookup table
> which is used to calculate SIN (TAN is done by calculating SIN and COS
> then dividing).

Oups, sorry, I didn't have the listing at hand. The polynomial
coefficients
are indeed those of SIN, and they come after the TAN routine (and 3
floating
values: PI/2, 2*PI and PI/4). Same for you ?-)

>  In order the bytes are:
> 
> A6 D3 C1 C8 D4 C8 D5 C4 CE CA
> 
> Exclusive-OR each byte with 87, and you get:
> 21 54 46 4F 53 4F 52 43 49 4D
> 
> Converting to ASCII:
> !TFOSORCIM
> 
> :-)
> 
> The XOR was an educated guess, from looking at the first byte!  I have
> no idea why 87 was picked as the mask.

Excellent ! Was this known in this newsgroup ?
On the oric, the bytes are :
A1 54 46 8F 13 8F 52 43 89 CD
so there isn't a single XOR decoding key, but some letters aren't
encoded,
and only bits 6 and/or 7 are changed in the other letters. It seems the
Microsoft programmers only wanted to make the bytes look like two
floating
point values after the other ones from the SIN polynomial...

With Oric Basic, this signature seems to mark the end of the Microsoft
code,
then we have the routines written by the Tangerine guys (tape routines,
graphic routines, etc). I guess it's the same scheme with Applesoft
Basic ?

Also, can you tell me if Apple went further than a first release of this
Basic ?
 
-- 
main(){char*s="@_DOONN_@AJQQDQA@AQQQDAA@OQOODAO@A_QEDAA@AQQIDQA@AQOQNN_";int
i,j,m,n,k;for(i=0;i<7;i++)for(j=0;m=j-6+i,j<55-i;j++)putchar(j==54-i?'\n':j<6-
i?32:s[n=i*8+m/6]&(k=1<<m%6)?(i==6||!(s[n+8]&k)?95:32):k/2&&(s[n]&k/2)?47:32);}