BASIC's question mark and PRINT

[Jim Battle]

Allison wrote:

> Jim Battle wrote:
> 
>> Allison wrote:
>>
>>>> Subject: Re: BASIC's question mark and PRINT
>>>>  From: Jim Battle <frustum at pacbell.net>
>>>>  Date: Mon, 21 Nov 2005 13:03:31 -0600
>>>>    To: General Discussion: On-Topic and Off-Topic Posts 
>>>> <cctalk at classiccmp.org>
>>>>
>>>> tim lindner wrote:
>>>>
>>>>> In BASIC, where did the short cut of '?' for PRINT originate?
>>>>>
>>>>> After following a discussion on the CoCo list I thought I'd ask here.
>>>>>
>>>>
>>>> Here are some bounds and data points.
>>>>
>>>> The Dartmouth BASIC specification does not have ? as an abbrevation 
>>>> (circa 1964).
>>>>
>>>> I think all versions of Microsoft BASIC have this shortcut (circa 
>>>> 1975).
>>>>
>>>> Palo Alto Tiny BASIC (li chen wang) didn't use this convention -- 
>>>> instead it used "P.".
>>>>
>>>> Wang BASIC (circa 1972) didn't use this convention.
>>>>
>>>> From what I can tell, DEC BASIC didn't use this abbreviation.
>>>
>>>
>>>
>>>
>>> The ? was adopted by convention from the fact that early MS basic 
>>> (MITS BASIC) the ? was also the same value as the token for print.
>>> Most of the non-compiled 8bit basics were tokenized in memory for 
>>> execution and storage and when "LIST"ed were detokenized to list as 
>>> Basic we know.
>>>
>>> Allison
>>
>>
>>
>> Allison, that seems unlikely.  Later versions of microsoft basic 
>> certainly didn't use any value lower than 0x80 for tokens.  Even if 
>> you could find a few characters in the "live" portion of the ascii 
>> table that didn't lead to ambiguous parsing, I can't think of a good 
>> reason why they'd do it -- there was enough room at 0x80 and above, 
>> and not enough unused values below 0x80, so why have two lookup tables 
>> when one would do?
>>
>> It would seem much easier to have special case where '?' got mapped to 
>> the token for PRINT.
>>
>> OK, trying to be less speculative, I looked at the binary for
>>
>>     ALTAIR BASIC VERSION 3.2 [EIGHT-K VERSION]
>>
>> that is included with Rich Cini's Altair emulator.  At the end is the 
>> list of the statement keywords.  In memory each keyword abuts the 
>> next, and the boundary between keywords is marked by setting the msb 
>> of the byte.  Here is the table in order:
>>
>> END
>> FOR
>> NEXT
>> DATA
>> INPUT
>> DIM
>> READ
>> LET
>> GOTO
>> RUN
>> IF
>> RESTORE
>> GOSUB
>> RETURN
>> REM
>> STOP
>> OUT
>> ON
>> NULL
>> WAIT
>> DEF
>> POKE
>> PRINT
>> CONT
>> LIST
>> CLEAR
>> CLOAD
>> CSAVE
>> NEW
>> TAB(
>>
>> Since there no room for storing a token value after each item (I know 
>> it is possible that that mapping is held elsewhere, but it seems 
>> unlikely), these keywords very likely have consecutive token values.
>>
>> Elsewhere in the binary, near the beginning, is a similar table for 
>> the functions (FN, SPC, NOT, AND, OR, VAL, CHR, LEFT, RIGHT, MID, FRE, 
>> SIN, COS, TAN, PEEK, etc, but also including THEN, STEP).
> 
> 
> Ever look at the saved files or in memory programs?

I tried using Rich that 3.2 version of basic on Altair32 but I wasn't able to 
figure out how to get it to run (just like the real hardware, I'm sure!).  I 
then tried a somewhat later version of MS basic, version 4.7, on my Sol.  The 
in-memory token for PRINT is 164, or 0xA4.

How I determined that was as follows:

10 PRINT "aqzy"
20 FOR I=0 to 50000
30 IF PEEK(I)<>ASC("a") THEN 100
40 IF PEEK(I+1)<>ASC("q") THEN 100
50 IF PEEK(I+2)<>ASC("z") THEN 100
60 IF PEEK(I+3)<>ASC("y") THEN 100
70 FOR J=-6 TO 5
80 PRINT I+J, PEEK(I+J), CHR$(PEEK(I+J))
90 NEXT J:STOP
100 NEXT I

It finds itself and then prints the bytes of the line.  The string may appear in 
memory more than once due to the fact it might appear in an edit buffer or some 
scratch space in addition to its program location.

Rich, if you can get your version 3.2 MS BASIC running on your Altair32 emulator 
perhaps you can run the program and report what token is used for PRINT.