Line Too Long

[senior_falcon]

Here is an odd one. CONCERTO3 is an XB music program written by ??? (Corey, age 12, Framingham Mass.) and modified by Ollie Hebert. It consists mostly of DATA statements. I found that if you change any digit in line 310 (without changing the length) and try to enter it, you get a "Line Too Long" error message. Or you can delete a digit and enter the line. Then if you try to put that digit back in, you get the "Line Too Long" message.

The person who wrote this was an XB programmer, so presumably this was entered normally from the keyboard. So how was he able to enter this line?

CONCERTO3 is the full program, and CONBUG is just line 310.

 

CONCERTO3

CONBUG

Edited May 8, 2022 by senior_falcon

[ti99iuc]

I remember that there was a tricks for this in BASIC/Extended Basic to add a fifth line at least. 
It was working editing the line in someway but I don't remember details at the moment, damn, i am getting older 

It was like insert a full line with 4 rows and press ENTER

then call again the line with the EDIT command and insert the remainings datas.

Edited May 7, 2022 by ti99iuc

[SteveB]

I tried every trick I could remember .. to no avail.

• Fctn-8 editing didn't work.
• 310 <Ctrl-S> 784,587,1,880,3E4,1,740,3E4,1,740,3E4,1,740,880,1,1175,587,1,1175,440,1,3E4,740,1,3E4,784,1,1109,880
• 310 REM 784,587,1,880,3E4,1,740,3E4,1,740,3E4,1,740,880,1,1175,587,1,1175,440,1,3E4,740,1,3E4,784,1,1109,880   and then edit to DATA
• 310 REM 784,587,1,880,3E4,1,740,3E4,1,740,3E4,1,740,880,1,1175,587,1,1175,440,1,3E4,740,1,3E4,784,1,1109,880   and then patch the file to DATA >9a to >93

My tokenizer in TiCodEd is capable of writing the exact TIFILE for the text-input, but I doubt that this has been used. Perhaps the tokenizer of Ralph Benzinger? Or the TIFILES download of Mathew's https://tidbit99.com/ ? 

 

I assume, this file was creates outside of the TI environment.

 

[+mizapf]

4 hours ago, ti99iuc said:

I remember that there was a tricks for this in BASIC/Extended Basic to add a fifth line at least.

Enter a line with its line number (e.g. 100). You can use 5 screen lines.

Enter 100 FCTN-X. Press Enter. Press REDO. You get another line.

[ti99iuc]

25 minutes ago, mizapf said:

Enter a line with its line number (e.g. 100). You can use 5 screen lines.

Enter 100 FCTN-X. Press Enter. Press REDO. You get another line.

I have tried your method in XB with the program from Senior_Falcon, but still not success

 

also I am sure the 5th line addition can be done also in TI-BASIC because the game Morphy also have some 5 screen line in its listing.

 

here says:"To limit the memory occupation some lines exceed the length of 4 screen lines; to insert them you must type characters until the four lines are completely filled, press ENTER, recall the line with EDIT and add what is left."

 

and... damn, all italians done this to digit the listings ?

 

EDIT:

---------
It worked with a new line at all instead:

Edited May 7, 2022 by ti99iuc

[SteveB]

25 minutes ago, ti99iuc said:

It worked with a new line at all instead:

But try this with the DATA line given ... did not work for me. Works fine when you substitute DATA for REM, but not with the DATA statement.

 

Perhaps the amount of tokens get too much? Unquoted-String, Comma, ...

[HOME AUTOMATION]

I was looking at the commas too...

...got to 39.

[fabrice montupet]

I massively use the 5th line trick in my XB programs to gain memory, it became a habit since years 80. The only problem with it is that is one wants to change the line number of a such line by editing it then pressing  the "ENTER" then "FCTN 8" keys, the line is truncated and the 5th line is missing. That said, it's a minor problem compare to the advantage of the 5th line.

 

[ti99iuc]

37 minutes ago, HOME AUTOMATION said:

I was looking at the commas too...

...got to 39.

interesting!
I also checked better the lines in MURPHY and, indeed, them are DATA lines without commas.

The line 310 mentioned on the first post has commas and them are 28.

It is really strange because it has less than 4 not complete lines and if you try also to change only a number without add anything it give the error,
for example I have just exchanged the first number '7' with a '6' ?
 

really curious!

[senior_falcon]

1 hour ago, fabrice montupet said:

I massively use the 5th line trick in my XB programs to gain memory, it became a habit since years 80. The only problem with it is that is one wants to change the line number of a such line by editing it then pressing  the "ENTER" then "FCTN 8" keys, the line is truncated and the 5th line is missing. That said, it's a minor problem compare to the advantage of the 5th line.

 

Both XB 2.9 G.E.M. and RXB allow you to enter additional lines without using the Fctn 8 trick.

But that's not what's causing this problem.

[SteveB]

1 hour ago, HOME AUTOMATION said:

...got to 39.

There seems to be a buffer limit or something. Each entry after the DATA gets

• >C8 - Unquoted Stríng
• Length byte
• the actual value
• >B3 - Comma

Quite some overhead. 158 byte after the DATA in the original example, 155 in your example (39*4-1, the trailing comma). That is way more than the actual text input and perhaps more than TI expected to be entered on a line.

[senior_falcon]

The crunch buffer is 160 bytes long, and the tokenized line has to fit in that space.

In an XB line number table, the first 2 bytes are the line number, the next two point to the actual code. Before the first byte of code there is a length byte and for line 310 it is >A0. But you cannot enter a line that is any longer than >9F from the editor, as we are all finding out.

Ollie modified the program in 1987, so none of the newer developments could have been used. So my question is still "how were they able to input a line that is too long for the editor to accept"?

[+Ksarul]

Maybe he edited it on disk to add the last few characters and updated the pointer to A0 to reflect the changes properly. A lot of the old school XB programmers had a visceral knowledge of the formatting of a BASIC program file on the disk.

[RXB]

2 hours ago, senior_falcon said:

The crunch buffer is 160 bytes long, and the tokenized line has to fit in that space.

In an XB line number table, the first 2 bytes are the line number, the next two point to the actual code. Before the first byte of code there is a length byte and for line 310 it is >A0. But you cannot enter a line that is any longer than >9F from the editor, as we are all finding out.

Ollie modified the program in 1987, so none of the newer developments could have been used. So my question is still "how were they able to input a line that is too long for the editor to accept"?

Well the issue is that the Crunch Buffer is 160 tokens long but the Edit Buffer is only 152 tokens in size.

My solution was use CALL USER("DSK#.FILENAME") as the line could be the max without bumping into the Edit Buffer issue.

I had a line in RXB 2001 to 2012 that was just 

1 PRINT :: PRINT :: PRINT :: PRINT :: PRINT :: PRINT :: PRINT :: PRINT     and so on...

up to 159 tokens of course you have to account for the Length byte after line 1 

 

You can still do that with RXB 2022 but again only works with USER but up shot is there is not limit of the file size.

[fabrice montupet]

3 hours ago, senior_falcon said:

Both XB 2.9 G.E.M. and RXB allow you to enter additional lines without using the Fctn 8 trick.

But that's not what's causing this problem.

Good news for the XB 2.9 G.E.M! My last program was made using the Jewel version. As I have to upgrade it, from on now I will use XB 2.9 GEM especially it offers even more so great (and useful) new features.  ?

 

[senior_falcon]

4 hours ago, Ksarul said:

Maybe he edited it on disk to add the last few characters and updated the pointer to A0 to reflect the changes properly. A lot of the old school XB programmers had a visceral knowledge of the formatting of a BASIC program file on the disk.

That seems like a lot of trouble to go to when all Corey (age 12) had to do was add another DATA line. Still, at this point I cannot think of another explanation that makes any more sense.

[Ed in SoDak]

Perhaps when Ollie did his mods he used one of the Compress XB utilities. Save your program in MERGE format, then run it through Compress, which has options for shortening variable names and other memory-saving tricks. The option that combines lines would be the one that might be able to pull this off.

 

You'll find Compress in my post here:

 

 

Edited May 8, 2022 by Ed in SoDak

[senior_falcon]

On 5/7/2022 at 8:26 PM, RXB said:

Well the issue is that the Crunch Buffer is 160 tokens long but the Edit Buffer is only 152 tokens in size.

My solution was use CALL USER("DSK#.FILENAME") as the line could be the max without bumping into the Edit Buffer issue.

I had a line in RXB 2001 to 2012 that was just 

1 PRINT :: PRINT :: PRINT :: PRINT :: PRINT :: PRINT :: PRINT :: PRINT     and so on...

up to 159 tokens of course you have to account for the Length byte after line 1 

 

You can still do that with RXB 2022 but again only works with USER but up shot is there is not limit of the file size.

So it sounds like this line could be entered using RXB.

[RXB]

23 hours ago, senior_falcon said:

So it sounds like this line could be entered using RXB.

Yes that is shown in the 2011 DEMO Video at 7:20 into video shows it:

 

RXBDEMO1.mov - YouTube

 

Hmmm the video is old I re-installed the REDO Buffer and fixed it to also work with  CALL USER

Since 2011 RXB has always been updated.

 

[senior_falcon]

1 hour ago, RXB said:

Yes that is shown in the 2011 DEMO Video at 7:20 into video shows it:

 

RXBDEMO1.mov - YouTube

 

Hmmm the video is old I re-installed the REDO Buffer and fixed it to also work with  CALL USER

Since 2011 RXB has always been updated.

 

Pronouns can be pesky critters. When I said "this line" I was referring to line 310 in my original post. The file CONBUG has just this one line, and it can be loaded from disk. But you cannot enter this line using standard XB. Can this line be entered from RXB, either directly from the keyboard or with CALL USER?

[RXB]

2 minutes ago, senior_falcon said:

Pronouns can be pesky critters. When I said "this line" I was referring to line 310 in my original post. The file CONBUG has just this one line, and it can be loaded from disk. But you cannot enter this line using standard XB. Can this line be entered from RXB, either directly from the keyboard or with CALL USER?

Again, no problem yes you can load your line using CALL USER!

If the number of Tokens is no longer then 159 characters yes it works fine.

 

Also no from Editor RXB works just like XB or any other Editor from Keyboard it will need the REDO buffer, but RXB CALL USER overrides this problem.

And the Video showed it being done back in 2011 but originally CALL USER was in RXB 2001 and I had a demo of it at the Chicago Fair.

[senior_falcon]

4 hours ago, RXB said:

Again, no problem yes you can load your line using CALL USER!

If the number of Tokens is no longer then 159 characters yes it works fine.

 

Also no from Editor RXB works just like XB or any other Editor from Keyboard it will need the REDO buffer, but RXB CALL USER overrides this problem.

And the Video showed it being done back in 2011 but originally CALL USER was in RXB 2001 and I had a demo of it at the Chicago Fair.

Here is the troublesome line. I cannot get this to work any better with RXB than it does with normal XB. Any ideas?

310 DATA 784,587,1,880,3E4,1,740,3E4,1,740,3E4,1,740,880,1,1175,587,1,1175,440,1,3E4,740,1,3E4,784,1,1109,880

 

[RXB]

15 hours ago, senior_falcon said:

Here is the troublesome line. I cannot get this to work any better with RXB than it does with normal XB. Any ideas?

310 DATA 784,587,1,880,3E4,1,740,3E4,1,740,3E4,1,740,880,1,1175,587,1,1175,440,1,3E4,740,1,3E4,784,1,1109,880

 

LOL this line is never going to fit!

In XB memory tokenized: 01 36 FF 49 9F 93 C8 03 37 38 34 B3 C8 03 35 33 37 B3 C8 01 31 B3 C8 and so on

DATA is a single Token

but for the rest of the line you have in memory >C8 the token for number token

the length byte for the number then the characters for the number like 784 is C8 03 37 38 34 that is 5 tokens for 784

then the B3 is the comma

 

This line is way past 160 tokens  the rest would bring it up to 19 tokens past 160 never going to fit.

 

I thought about adding a new command that would add a data block of numbers or characters.

It would just allot a section of memory for that block but problem is loading it and saving it.

CALL USER was the only approach I could come up with that worked easy.

[RXB]

15 hours ago, senior_falcon said:

Here is the troublesome line. I cannot get this to work any better with RXB than it does with normal XB. Any ideas?

310 DATA 784,587,1,880,3E4,1,740,3E4,1,740,3E4,1,740,880,1,1175,587,1,1175,440,1,3E4,740,1,3E4,784,1,1109,880

 

 

Make a single string line say like

X$="784,587,1,880,3E4,1,740,3E4,1,740,3E4,1,740,880,1,1175,587,1,1175,440,1,3E4,740,1,3E4,784,1,1109,880"

 

Now it fits in memory and extracting it is just a little slower then original.

 

LOL or just shorten the line and make more DATA lines...

 

[+Ksarul]

8 minutes ago, RXB said:

 

Make a single string line say like

X$="784,587,1,880,3E4,1,740,3E4,1,740,3E4,1,740,880,1,1175,587,1,1175,440,1,3E4,740,1,3E4,784,1,1109,880"

 

Now it fits in memory and extracting it is just a little slower then original.

 

LOL or just shorten the line and make more DATA lines...

 

That's an interesting workaround, Rich, but it totally fails to answer the original question: How did the guy who originally wrote this program get the line (exactly as written) into an Extended BASIC program in the first place? It is too long to enter it by any direct means we have been able to suss out so far--but if we can find the answer to the original question, we find another interesting and potentially useful trick that can be used elsewhere. This one is thorny. Who knows, maybe he did it using CALL LOAD to add the extra bit to the end of that line of the program and then continued typing in the rest of the program using the normal editor. . .