Message-ID: <596@burl.UUCP>
Date: Tue, 4-Dec-84 09:46:40 EST
Article-I.D.: burl.596
Posted: Tue Dec  4 09:46:40 1984
Date-Received: Wed, 5-Dec-84 00:18:02 EST
Organization: AT&T Technologies; Burlington, NC
Lines: 49

--
My nephew has a VIC20, and I am (shudder) trying to teach him some
fundamentals of programming in BASIC.  There is a problem: his
machine isn't acting right.  Now I'll admit to not being terribly
familiar with the language (I play with my C64 in assembler), but
what would you expect the following code to do?

110 PRINT"THIS IS A PRINT STATEMENT"
120 PRINT"THIS IS ANOTHER PRINT STATEMENT"
130 PRINT"THIS IS YET ANOTHER PRINT STATEMENT"
140 PRINT
150 INPUT"WHAT DO YOU SAY TO THAT";I$
160 IF I$ = "" THEN 150
170 PRINT I$

My C64 executes this the way I'd expect; if the return is pressed
after "WHAT DO YOU SAY TO THAT?" without entering at least one
character, line 150 is executed again, prompting the user with
another "WHAT DO YOU SAY TO THAT?" and so on until the user finally
enters something.

But on my nephew's VIC20, if the return is pressed without typing
anything else, the machine produces the following session:

THIS IS A PRINT STATEMENT
THIS IS ANOTHER PRINT STATEMENT
THIS IS YET ANOTHER PRINT STATEMENT

WHAT DO YOU SAY TO THAT?

WHAT DO YOU SAY TO THAT?
READY

My nephew has told me over the phone that he thinks all the GOTO's
are working like that; if the instruction pointer is at line 40,
which says GOTO 10, my nephew predicts that 10 will be executed and
then line 50 will be executed.  I have not had an opportunity to
test this hypothesis myself.  Need I say that I am annoyed and
perplexed?  I figured there were two possiblities; either his
keyboard is broken in some strange way, or he has an absolutely
bizarre implementation of BASIC.  I thought I'd rather quiz the net
first (as opposed to quizzing a $repairman$); has anybody ever seen
anything like this?

All replies welcomed.
-- 

				--Bill Buie
adTHANKSvance

Message-ID: <309@sdchema.UUCP>
Date: Thu, 6-Dec-84 18:24:52 EST
Article-I.D.: sdchema.309
Posted: Thu Dec  6 18:24:52 1984
Date-Received: Sat, 8-Dec-84 04:47:53 EST
References: <596@burl.UUCP>
Reply-To: jmw@sdchema.UUCP (John M. Wright)
Organization: U.C. San Diego Chemistry Dept
Lines: 21
Summary: 

I just tried it out; my VIC20 behaves the same way.  It's not
a problem with IF or GOTO; apparently, when inputting a string,
the VIC20 gets everything on the logical line, INCLUDING THE 
PROMPT PRINTED BY THE INPUT STATEMENT!  Changing your statement
150 INPUT"WHAT DO YOU SAY TO THAT";I$
to
150 PRINT"WHAT DO YOU SAY TO THAT":INPUT I$
makes it behave OK (although of course it doesn't look as neat,
since the "?" appears on a line of its own.  (It evidently knows
enough not to count the "?" by itself as part of the input string.)
Changing the statement to
150 PRINT"WHAT DO YOU SAY TO THAT";:INPUT I$
causes it to behave exactly like your original version, picking
up the prompt as part of the input.
It seems to handle inputting numeric data OK.

Interesting "feature"!

John Wright
Chem. Dept.
UCSD

Message-ID: <259@utcs.UUCP>
Date: Sun, 9-Dec-84 01:09:19 EST
Article-I.D.: utcs.259
Posted: Sun Dec  9 01:09:19 1984
Date-Received: Sun, 9-Dec-84 01:40:45 EST
References: <596@burl.UUCP> <309@sdchema.UUCP>
Reply-To: wjr@utcs.UUCP (William Rucklidge)
Organization: University of Toronto - General Purpose UNIX
Lines: 60
Summary: 

> I just tried it out; my VIC20 behaves the same way.  It's not
> a problem with IF or GOTO; apparently, when inputting a string,
> the VIC20 gets everything on the logical line, INCLUDING THE 
> PROMPT PRINTED BY THE INPUT STATEMENT!  Changing your statement
> 150 INPUT"WHAT DO YOU SAY TO THAT";I$
> to
> 150 PRINT"WHAT DO YOU SAY TO THAT":INPUT I$
> makes it behave OK (although of course it doesn't look as neat,
> since the "?" appears on a line of its own.  (It evidently knows
> enough not to count the "?" by itself as part of the input string.)
> Changing the statement to
> 150 PRINT"WHAT DO YOU SAY TO THAT";:INPUT I$
> causes it to behave exactly like your original version, picking
> up the prompt as part of the input.
> It seems to handle inputting numeric data OK.
> 
> Interesting "feature"!
> 
> John Wright
> Chem. Dept.
> UCSD


This is not a bug in BASIC per se, rather it is a bug in the operating
system (the Kernal), involving the CHRIN ($FFCF) routine. The process
involved is the following:
1) When this routine is called, the cursor is activated, and characters
   typed begin to appear on the screen. The current cursor position is
   saved.
2) If input is typed normally, the line is read, and all characters before
   the saved cursor position are discarded. Thus, the prompt is stripped
   away from the string that is returned.
3) If the cursor is moved vertically before hitting , the saved
   cursor position is discarded, and all the text on the line on which
    is finally pressed is read in. This is a feature involving
   full-screen action: if you move over to another line on the screen,
   you don't want it to attempt to discard the (nonexistant) prompt.
   It is in this feature that the problem lies: if the input line
   (including the prompt) is longer than 40 characters (22 on the VIC), it
   thinks that the cursor has moved vertically and does not strip away the
   prompt, which is then returned along with the actual text. Thus, if the 
   final input line occupies more than one screen line, the entire line
   is returned and the computer behaves as described. This can be due to
   the prompt being longer than 40 (22) columns, as in the example, or to
   the user typing enough input that the line becomes longer than 40 (22)
   characters.

I believe that this problem has been fixed in the newer C64's.
Since lines are so much shorter on the VIC than on the C64, this problem
is much more prevalent, though it will not usually show up with short
prompts (as in the example above: the prompt was only '? '). The
only solution is to use such short prompts, or no prompts at all, with
any information being presented on the line above.

-- 

"You can always put something in a box."
This message brought to you with the aid of the Poslfit Committee.
William Rucklidge	University of Toronto Computing Services
{decvax,ihnp4,utcsrgv,{allegra,linus}!utzoo}!utcs!wjr

Message-ID: <684@amdahl.UUCP>
Date: Thu, 6-Dec-84 09:47:12 EST
Article-I.D.: amdahl.684
Posted: Thu Dec  6 09:47:12 1984
Date-Received: Sun, 9-Dec-84 03:11:45 EST
References: <596@burl.UUCP>
Organization: Amdahl Corp, Sunnyvale CA
Lines: 55

> --
> My nephew has a VIC20, and I am (shudder) trying to teach him some
> fundamentals of programming in BASIC.  There is a problem: his
> machine isn't acting right.  Now I'll admit to not being terribly
> familiar with the language (I play with my C64 in assembler), but
> what would you expect the following code to do?
> 
> 110 PRINT"THIS IS A PRINT STATEMENT"
> 120 PRINT"THIS IS ANOTHER PRINT STATEMENT"
> 130 PRINT"THIS IS YET ANOTHER PRINT STATEMENT"
> 140 PRINT
> 150 INPUT"WHAT DO YOU SAY TO THAT";I$
> 160 IF I$ = "" THEN 150
> 170 PRINT I$
> 
> My C64 executes this the way I'd expect; if the return is pressed
> after "WHAT DO YOU SAY TO THAT?" without entering at least one
> character, line 150 is executed again, prompting the user with
> another "WHAT DO YOU SAY TO THAT?" and so on until the user finally
> enters something.
> 
> But on my nephew's VIC20, if the return is pressed without typing
> anything else, the machine produces the following session:
> 
> THIS IS A PRINT STATEMENT
> THIS IS ANOTHER PRINT STATEMENT
> THIS IS YET ANOTHER PRINT STATEMENT
> 
> WHAT DO YOU SAY TO THAT?
> 
> WHAT DO YOU SAY TO THAT?
> READY
> 
This is a known Commodore Basic bug. If the prompt from an INPUT
statement wraps on the screen, then that prompt will be included
in the input. In your example, since you typed nothing, then
the input variable, I$, contained only the input prompt. If you
had entered ABC as your reply, then I$ would be equal to :
WHAT DO YOU SAT TO THAT? ABC

The solution is:
   1 - Limit your prompts to less than 22 characters
                    or
   2 - PRINT your prompt and then do the INPUT without any prompt.

-- 
-----------------------------------------------------------------------
                               Dave Lowrey

"GORT...Klatu borada niktow"

                               ...{amd,hplabs,ihnp4,nsc}!amdahl!dwl10

[ The opinions expressed  be those of the author and not necessarily
  those of his most eminent employer. ]

Message-ID: <1113@ut-ngp.UUCP>
Date: Sat, 8-Dec-84 03:34:28 EST
Article-I.D.: ut-ngp.1113
Posted: Sat Dec  8 03:34:28 1984
Date-Received: Mon, 10-Dec-84 02:15:52 EST
References: <596@burl.UUCP>, <309@sdchema.UUCP>
Organization: U.Texas Computation Center, Austin, Texas
Lines: 10

<>

The bug (prompt appearing as part of string on INPUT) is a 'feature' of
all CBM machines back to the 2001.  The INPUT routine marks the cursor
position after the prompt, but the screen editor clears it if printing
causes a wrap to the next line, although it includes the previous line,
unfortunately all of it.  This is one of the reason people use the
GET constructed INPUT.  I never found a fix.

Mike Fischer   anthro@utngp

Message-ID: <703@loral.UUCP>
Date: Mon, 10-Dec-84 13:48:04 EST
Article-I.D.: loral.703
Posted: Mon Dec 10 13:48:04 1984
Date-Received: Wed, 12-Dec-84 04:02:31 EST
References: <596@burl.UUCP> <309@sdchema.UUCP> <259@utcs.UUCP>
Organization: Loral Instrumentation, San Diego
Lines: 57

> > I just tried it out; my VIC20 behaves the same way.  It's not
> > a problem with IF or GOTO; apparently, when inputting a string,
> > the VIC20 gets everything on the logical line, INCLUDING THE 
> > PROMPT PRINTED BY THE INPUT STATEMENT!  Changing your statement
> > 150 INPUT"WHAT DO YOU SAY TO THAT";I$
> > to
> > 150 PRINT"WHAT DO YOU SAY TO THAT":INPUT I$
> > makes it behave OK (although of course it doesn't look as neat,
> > since the "?" appears on a line of its own.  (It evidently knows
> > enough not to count the "?" by itself as part of the input string.)
> > Changing the statement to
> > 150 PRINT"WHAT DO YOU SAY TO THAT";:INPUT I$
> > causes it to behave exactly like your original version, picking
> > up the prompt as part of the input.
> > It seems to handle inputting numeric data OK.
> > 
> > Interesting "feature"!
> > 
> > John Wright
> > Chem. Dept.
> > UCSD
> 
> 
> This is not a bug in BASIC per se, rather it is a bug in the operating
> system (the Kernal), involving the CHRIN ($FFCF) routine. The process
> involved is the following:
> 1) When this routine is called, the cursor is activated, and characters
>    typed begin to appear on the screen. The current cursor position is
>    saved.
> 2) If input is typed normally, the line is read, and all characters before
>    the saved cursor position are discarded. Thus, the prompt is stripped
>    away from the string that is returned.
> 3) If the cursor is moved vertically before hitting , the saved
>    cursor position is discarded, and all the text on the line on which
>     is finally pressed is read in. This is a feature involving
>    full-screen action: if you move over to another line on the screen,
>    you don't want it to attempt to discard the (nonexistant) prompt.
>    It is in this feature that the problem lies: if the input line
>    (including the prompt) is longer than 40 characters (22 on the VIC), it
>    thinks that the cursor has moved vertically and does not strip away the
>    prompt, which is then returned along with the actual text. Thus, if the 
>    final input line occupies more than one screen line, the entire line
>    is returned and the computer behaves as described. This can be due to
>    the prompt being longer than 40 (22) columns, as in the example, or to
>    the user typing enough input that the line becomes longer than 40 (22)
>    characters.
> 
> I believe that this problem has been fixed in the newer C64's.
> Since lines are so much shorter on the VIC than on the C64, this problem
> is much more prevalent, though it will not usually show up with short
> prompts (as in the example above: the prompt was only '? '). The
> only solution is to use such short prompts, or no prompts at all, with
> any information being presented on the line above.
> 
> -- 
> 
> "You can always put something in a box."