These lines are just too long (for Color BASIC)!

These lines are just too long!

– Me at Walt Disney World

There is a limit to how long of a line you can type in Color BASIC, whether that be entering a program line, or typing at an INPUT prompt. The input buffer is defined as 251 bytes, as shown in the Color BASIC Unraveled book:

LINBUF is defined as 250.

So of course, as you type in really long lines, it stops after the … 249th character. The reason why is beyond the scope of this posting, but this topic will be discussed in an upcoming article series.

Here is an example:

The same is true for using the LINE INPUT command.

Even if the input buffer were larger, the largest string variable you can have is 255 characters, so that would be the maximum input size to avoid an ?LS ERROR (length of string). Here’s a short program to verify that, which uses the STRING$() function to create a string of a specified length containing a specified character.

CLEAR 300
A$=STRING$(255,"X")
A=A$+"X"
?LS ERROR

Something I had not thought about until today was that this length impacts anything that INPUTs, whether it is from the user typing on the keyboard, or reading data from a file.

When reading from a tape or disk file, INPUT and LINE INPUT expect to see zero or more characters with an ENTER at the end. But when creating a file, you can make a line as long as you want simply by using the semi-colon at the end of a PRINT command so it does not output an ENTER. Consider this example that prints a 510 character string with an ENTER at the end:

10 OPEN "O",#1,"510LINE"
20 PRINT #1,STRING$(255,"X");STRING$(255,"X")
30 CLOSE #1

That works fine, but how do you read it back? The string is now too long to be read in to INPUT or LINE INPUT. What will it do?

10 OPEN "I",#1,"5120LINE"
20 LINE INPUT #1,A$:PRINT A$
30 CLOSE #1

In this case, the disk input routine reads as much data as will fill the input buffer, then keeps scanning forward looking for the ENTER. The rest of the data on that string appears to be discarded.

If you were to count the Xs, or just PRINT LEN(A$), you would see that A$ contains the first 249 characters of the 510 string that was written to the file.

But what if the ENTER was not at the end? By adding a semi-colon to the end of the PRINT:

10 OPEN "O",#1,"510LINE"
20 PRINT #1,STRING$(255,"X");STRING$(255,"X");
30 CLOSE #1

…what would the input program do? (Same code as before, just now it’s reading from a file that has a 510 character line with no ENTER at the end.)

10 OPEN "I",#1,"5120LINE"
20 LINE INPUT #1,A$:PRINT A$
30 CLOSE #1

…the behavior will change. We will now get an ?IE ERROR (Input Past End of File). The INPUT and LINE INPUT routines need an ENTER, so while it scans forward looking for the end of the line, it hits the end of file before an ENTER, and that’s what it reports.

This tells us two things:

  1. Always have an ENTER at the end of a line.
  2. Don’t have the line longer than 249 bytes or any characters after it will be ignored.

Here is an example that creates a file with a 250-character line that contains 248 “X” characters followed by “YZ”. When read back, it only gets up to the Y (249 characters):

5 CLEAR 300
10 OPEN "O",#1,"250LINE"
20 PRINT #1,STRING$(248,"X");"YZ"
30 CLOSE #1
40 OPEN "I",#1,"250LINE"
50 LINE INPUT #1,A$:PRINT A$
60 CLOSE #1

And, since BASIC appears to keep scanning INPUT looking for an ENTER, you could make your tape or disk I/O take a really long time if you created some really huge line with no ENTER at the end, then tried to read it later.

Here is a program that writes 65,025 “X”s to a file with no ENTER at the end, and then tries to read it back:

0 'LINE2BIG.BAS
10 CLEAR 300
20 PRINT "WRITING FILE..."
30 OPEN "O",#1,"LINE2BIG"
40 FOR I=1 TO 255
50 PRINT I;
60 PRINT #1,STRING$(255,"X");
70 NEXT
80 CLOSE #1
90 PRINT:PRINT "READING FILE..."
100 OPEN "I",#1,"LINE2BIG"
110 LINE INPUT #1,A$:PRINT A$
120 CLOSE #1

If you run that, it will eventually try to read (and take a really long time) before erroring out with ?IE ERROR. Add “75 PRINT #1” to insert an ENTER at the end of the PRINT loop, and then it will just take a really long time trying to read, and print the first 249 characters of that 65,025 character string.

And that’s it for today, but I hope you took notes. LINBUF will return.

Until then…

2 thoughts on “These lines are just too long (for Color BASIC)!

    1. Allen Huffman Post author

      I … would assume that to be true, as well. Word processors surely would have had to only work in direct access if they wrote things out as paragraphs, I suspect.

      Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.