Jump to content
IGNORED

Long ago, I have found a bug in Extended Basic


sverrips

Recommended Posts

In 1985, I type a program on the Ti-99/4a and make a mistake. There was a bug in de Extended Basic Rom module and I have make a youtube movie to let see it. It's go wrong, if you choose for extended basic and type:

 

It's easy to say, but it somehow rings a bell ...

Link to comment
Share on other sites

In 1985, I type a program on the Ti-99/4a and make a mistake. There was a bug in de Extended Basic Rom module and I have make a youtube movie to let see it. It's go wrong, if you choose for extended basic and type:

 

10 print

list

accept a

 

See it in action,

 

https://youtu.be/G8VKeentObk

 

 

Ok as the guy that has written and debugged XB for over 30 years I have to explain that is not really a bug.

 

Page 47 of XB Manual quote:

 

Description

The ACCEPT statement suspends program execution until data is entered from the keyboard.

 

In a nutshell you are using a PROGRAM COMMAND in EDIT MODE. (It does not error out because of a bug missing a check)

 

Now the reason INPUT A does not do the same thing is as ACCEPT A is it does not use Assembly ROMs like Accept does.

I can show you the GPL and Assembly code but take my word for it that this is easy to fix.

 

I will even fix this in RXB as just change the lines in GPL from

XML SPEED

BYTE PARCOM

 

to

 

CALL COMB

  • Like 1
Link to comment
Share on other sites

The interesting thing with this is that seems to only be triggered by LIST, followed immediately by ACCEPT A. If you enter Extended BASIC and then immediately issue ACCEPT A, it works without issue. It's also no problem if you RUN, or if you LIST, then RUN, and then do the ACCEPT. If you do the ACCEPT after LIST and the cursor is in the lower right, and you then just hit Enter, it even will display *WARNING INPUT ERROR and give you another try before crashing Extended BASIC.\\

 

At one time many years ago, I had a black V110 Extended BASIC cartridge that this program would get it stuck in an error message loop:

10 CALL A

20 SUB A

30 CALL B

40 SUBEND

50 SUB B

60 CALL A

70 SUBEND

 

One of my Extended BASIC modules would correctly issue the RECURSIVE SUBPROGRAM CALL error, but this black Extended BASIC module would display something like:

* MEMORY FULL IN 20

CALLED FROM A

CALLED FROM B

CALLED FROM A

CALLED FROM B

repeating forever.

 

Thierry captured this on his TI Tech Pages and explained how a developer used this to his advantage, and didn't realize at the time that not all Extended BASIC cartridges behaved this way.

Link to comment
Share on other sites

I will have to double check the ROM for LIST, but a bit might be getting set that should not be set.

 

Also it should not be working anymore then INPUT A does. Both are only supposed to be usable from PROGRAM MODE!

Link to comment
Share on other sites

  • 2 months later...

I went back to this as I was perusing some older threads and did some testing. RXB 2015 exhibits the same behavior (it will crash if you do the steps in the first post). Every version of Extended BASIC available in MAME seems to behave exactly the same way. TI Extended BASIC II in the 99/8 (at least the one we have emulation of in MAME) does not crash when doing this. It still allows you to do ACCEPT from the command line, but the cursor doesn't show up in the wrong place and the statement works correctly. So we know this was at least fixed by TI, even if the fix was never released.

Link to comment
Share on other sites

Again right out of XB manual:

 

Page 47 of XB Manual quote:

Description

The ACCEPT statement suspends program execution until data is entered from the keyboard.

In a nutshell you are using a PROGRAM COMMAND in EDIT MODE. (It does not error out because of a bug missing a check)

Look if no program is running and you use from EDIT MODE how can it suspend a program by setting a flag that is already set because it is NOT IN PROGRAM MODE????

Basically the impossible is being asked and XB Manual already explains this!

Link to comment
Share on other sites

This is an odd one. INPUT gives an error message as it should; ACCEPT does not. So clearly TI forgot to check whether a program is running when ACCEPT is used. If you type ACCEPT A and enter 123, you can then PRINT A and 123 is printed

 

The second bug is the goofy cursor position with ACCEPT after LIST. >02FE is out of the normal boundaries for the line editor. so some interesting things happen when you press ENTER. If you ACCEPT A$ you can enter ABC as a string but if you type LEN(A$) you get a length of 4. There is an extra byte after ABC.

 

Anyhow, this behavior is odd but the fix is simple enough: If you find yourself in this situation just press F4 so the interpreter thinks the program is halted and all will return to normal. (Unless there is yet another bug to be discovered!)

 

(Edit) It turns out this could actually be a problem. Consider this program:

1 FOR I=1 TO 1000 :: NEXT I
2 ACCEPT A$ :: PRINT A$
Type RUN, then hit F4 before the program comes to line 2. Then LIST, then CON and when it hits line 2 you will get the cursor position in the lower right.
Edited by senior_falcon
  • Like 2
Link to comment
Share on other sites

LOL REPEAT:

 

read it slowly people!

 

Again right out of XB manual:

Page 47 of XB Manual quote:

Description

The ACCEPT statement suspends program execution until data is entered from the keyboard.

ACCEPT AT WAS NEVER DESIGNED TO BE USED IN EDIT MODE.....EVER! This is not a bug as stated in the manual if you read it.

Just to clarify this point. Edit mode has no program running which is why it is called EDIT MODE not PROGRAM MODE.

(Note: INPUT has the same note as neither was designed to be used from EDIT MODE.)

Look you can use a wine bottle as a hammer, does not mean something is wrong with Wine bottles because you can hammer nails with it.

Edited by RXB
Link to comment
Share on other sites

 

This is an odd one. INPUT gives an error message as it should; ACCEPT does not. So clearly TI forgot to check whether a program is running when ACCEPT is used. If you type ACCEPT A and enter 123, you can then PRINT A and 123 is printed

 

The second bug is the goofy cursor position with ACCEPT after LIST. >02FE is out of the normal boundaries for the line editor. so some interesting things happen when you press ENTER. If you ACCEPT A$ you can enter ABC as a string but if you type LEN(A$) you get a length of 4. There is an extra byte after ABC.

 

Anyhow, this behavior is odd but the fix is simple enough: If you find yourself in this situation just press F4 so the interpreter thinks the program is halted and all will return to normal. (Unless there is yet another bug to be discovered!)

 

(Edit) It turns out this could actually be a problem. Consider this program:

1 FOR I=1 TO 1000 :: NEXT I
2 ACCEPT A$ :: PRINT A$
Type RUN, then hit F4 before the program comes to line 2. Then LIST, then CON and when it hits line 2 you will get the cursor position in the lower right.

 

Hmm once you hit FNCT 4 it kills off all initialized character definitions and Sprites.

So if you are thinking the old Text only Basic's this make sense but as it kills off graphics for game or applications why would you do this with XB?

 

Do you also expect all Character Definitions to be saved somewhere also?

 

Your expecting something that was never to be done, like I said previously much like using Wine Bottles as a hammer, you can do it, but do not expect perfect result with wrong tools.

Edited by RXB
Link to comment
Share on other sites

Rich, there are two bugs.

 

ACCEPT should behave like INPUT. It does not. INPUT gives an error message when you try to use it in the edit mode. ACCEPT does not. That is definitely a bug.

 

The bigger bug is the misplaced cursor after LIST. You can say that XB is not designed to be used that way, but which of us has not broken a program and listed it to see what is going on, then typed CON. No question that this situation is unlikely, especially the use of ACCEPT without AT. Regardless of that, BASIC and XB are expected to behave predictably regardless of what the user does. I can guarantee you that the developers of XB did not intend for XB to ever place the cursor out of bounds like it does here.

 

This is undoubtedly a bug and for the life of me I don't know why you have so much trouble admitting that.

  • Like 3
Link to comment
Share on other sites

Rich, there are two bugs.

 

ACCEPT should behave like INPUT. It does not. INPUT gives an error message when you try to use it in the edit mode. ACCEPT does not. That is definitely a bug.

 

The bigger bug is the misplaced cursor after LIST. You can say that XB is not designed to be used that way, but which of us has not broken a program and listed it to see what is going on, then typed CON. No question that this situation is unlikely, especially the use of ACCEPT without AT. Regardless of that, BASIC and XB are expected to behave predictably regardless of what the user does. I can guarantee you that the developers of XB did not intend for XB to ever place the cursor out of bounds like it does here.

 

This is undoubtedly a bug and for the life of me I don't know why you have so much trouble admitting that.

Well for one thing I know the GPL code much better than anyone else.

And no one would assume to run a INPUT or ACCEPT from EDIT mode, after if you read what the manual says it is clear.

 

 

Description

The ACCEPT statement suspends program execution until data is entered from the keyboard.

 

So program is already suspended by ACCEPT and you push FCTN 4 expecting some magical behavior.

 

This is akin to entering another error into the program and expecting it to report both the original error and the new generated one that bypassed the original by your FCNT 4?

 

Really how many times is ANYONE going to do something so silly, not to mention no one has ever complained about this ever in 30 years till now.

 

Description

The ACCEPT statement suspends program execution until data is entered from the keyboard.

Link to comment
Share on other sites

And no one would assume to run a INPUT or ACCEPT from EDIT mode, after if you read what the manual says it is clear.

 

Let's say you are typing in a program. It's a long one and you decide it would be a good idea to LIST it for a closer look. Looks good, so you decide to enter the next line: 2340 ACCEPT A. But being human you forget the line number and just type ACCEPT A. Oh no, now the computer is acting strangely; why is the cursor in the lower right? You can't seem to get it out of that funny mode. Oh no, now it crashed. Crap, now you have to type in the program again, and with every keystroke you curse TI for not finding that bug.

  • Like 2
Link to comment
Share on other sites

Really how many times is ANYONE going to do something so silly, not to mention no one has ever complained about this ever in 30 years till now.

 

Because it is interesting to know the little quirks that make our computer tick. Personally, I like finding strange things like this and I like the discussion around them. Requoting the text for the appropriate use of the ACCEPT command is nice, but why not let people discuss it rather than berate them for doing something the manual says you can't?

 

Side note, after I put my first TI 99/4A in the closet, I was given a Commodore 128. It had several oddities in the first release of the ROM. Commodore computers prior to the 128 had a Shift-Lock key that did exactly as its name suggested - it wasn't an Alpha Lock, it shifted everything. The 128 had a separate Caps Lock key that just shifted the letters.... except the letter Q. You could not get a capital Q even with Caps Lock engaged unless you hit the Shift key. Bug in the OS ROM.

 

2 commands were valid commands to the interpreter that did nothing. Type in OFF or QUIT and you got ?UNIMPLEMENTED COMMAND ERROR.

  • Like 1
Link to comment
Share on other sites

Let's say you are typing in a program. It's a long one and you decide it would be a good idea to LIST it for a closer look. Looks good, so you decide to enter the next line: 2340 ACCEPT A. But being human you forget the line number and just type ACCEPT A. Oh no, now the computer is acting strangely; why is the cursor in the lower right? You can't seem to get it out of that funny mode. Oh no, now it crashed. Crap, now you have to type in the program again, and with every keystroke you curse TI for not finding that bug.

Hmm you would not lose the program in memory from this?

 

I actually tested this and never lost the program in memory unless you turn off the computer or just a simple fix hit any number key and Enter.

 

Why would you lose the program? How?

Link to comment
Share on other sites

gallery_34177_1071_10790.gif

This is the reason you might have a little trouble retrieving your program. Not all numbers crash the program, and it may be that the number I provided in my earlier example does not cause a crash but you can see the potential for problems.

Most people would think of this as a bug, but it you want to think it isn't then it's OK with me.

Edited by senior_falcon
Link to comment
Share on other sites

Well you are using a PROGRAM ONLY SUBROUTINE in EDIT MODE, so crashing is pretty much a given result.

 

I would like think that TI strongly intended and mostly succeeded implementing, that "PROGRAM ONLY SUBROUTINE in EDIT MODE" do not crash the machine. So I would definitely say it's pretty much NOT "a given result".

 

A few bugs led to nice discoveries. Early on you could get a sprite to show up in TI BASIC (unexpanded console). And recently we have user machine code running from TI BASIC (again unexpanded console), known as Playground.

Link to comment
Share on other sites

Well you are using a PROGRAM ONLY SUBROUTINE in EDIT MODE, so crashing is pretty much a given result.

10 FOR I=1 TO 1000::NEXT I

20 ACCEPT A::PRINT A

 

RUN and then break the program before it gets to line 20. Type LIST and then type CON. When you get the cursor press 1 and ENTER and it crashes while running in a program.

 

It is obvious that you just want to argue. I am done feeding this troll.

Link to comment
Share on other sites

Well you are using a PROGRAM ONLY SUBROUTINE in EDIT MODE, so crashing is pretty much a given result.

 

It is a PROGRAM ONLY SUBROUTINE and you break it on purpose than complain it is broken when you broke it?

 

Who is the Troll here?

 

(By the way if you wait till ACCEPT has a ? and break the program it works fine.)

 

I have a note to reset the Cursor Location, but it would very slightly slow XB doing this a it adds a routine that never was there before, but doable.

Edited by RXB
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...