wjb@burl.UUCP (Bill Buie) (12/04/84)
-- 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
dwl10@amdahl.UUCP (dwl10) (12/06/84)
> -- > 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 <may> be those of the author and not necessarily those of his most eminent employer. ]
jmw@sdchema.UUCP (John M. Wright) (12/07/84)
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
anthro@ut-ngp.UUCP (Michael Fischer) (12/08/84)
<> 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
wjr@utcs.UUCP (William Rucklidge) (12/09/84)
> 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 <RETURN>, the saved cursor position is discarded, and all the text on the line on which <RETURN> 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
engle@loral.UUCP (Jack Engle) (12/10/84)
> > 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 <RETURN>, the saved > cursor position is discarded, and all the text on the line on which > <RETURN> 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."