Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site loral.UUCP Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!sdcc6!loral!engle From: engle@loral.UUCP (Jack Engle) Newsgroups: net.micro.cbm Subject: Re: VIC20 BASIC bug (?) 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."