Jump to content

Photo

Long ago, I have found a bug in Extended Basic

Bug Extended Basic

39 replies to this topic

#1 sverrips OFFLINE  

sverrips

    Combat Commando

  • 1 posts

Posted Wed Jun 14, 2017 7:36 AM

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,

 

 

 



#2 save2600 ONLINE  

save2600

    Quadrunner

  • 14,026 posts
  • Location:Wisconsin

Posted Wed Jun 14, 2017 8:29 AM

You have win the internet for today! :lol:

#3 mizapf OFFLINE  

mizapf

    River Patroller

  • 2,515 posts
  • Location:Germany

Posted Wed Jun 14, 2017 9:12 AM

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 ...



#4 RXB OFFLINE  

RXB

    River Patroller

  • 2,726 posts
  • Location:Vancouver, Washington, USA

Posted Wed Jun 14, 2017 10:49 AM

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,

 

 

 

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



#5 PeBo OFFLINE  

PeBo

    Dragonstomper

  • 885 posts
  • Location:Toronto, Canada

Posted Wed Jun 14, 2017 11:32 AM

Always wondered if there was a way to get my 4A high!



#6 Casey OFFLINE  

Casey

    Chopper Commander

  • 120 posts

Posted Wed Jun 14, 2017 5:30 PM

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.



#7 RXB OFFLINE  

RXB

    River Patroller

  • 2,726 posts
  • Location:Vancouver, Washington, USA

Posted Thu Jun 15, 2017 12:06 PM

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!



#8 Casey OFFLINE  

Casey

    Chopper Commander

  • 120 posts

Posted Tue Sep 12, 2017 6:42 PM

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.



#9 RXB OFFLINE  

RXB

    River Patroller

  • 2,726 posts
  • Location:Vancouver, Washington, USA

Posted Tue Sep 12, 2017 7:03 PM

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!



#10 senior_falcon OFFLINE  

senior_falcon

    Dragonstomper

  • 913 posts
  • Location:Lansing, NY, USA

Posted Tue Sep 12, 2017 8:42 PM

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, Tue Sep 12, 2017 8:54 PM.


#11 RXB OFFLINE  

RXB

    River Patroller

  • 2,726 posts
  • Location:Vancouver, Washington, USA

Posted Wed Sep 13, 2017 6:24 AM

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, Wed Sep 13, 2017 6:30 AM.


#12 apersson850 OFFLINE  

apersson850

    Moonsweeper

  • 418 posts

Posted Wed Sep 13, 2017 6:30 AM

True, but many BASIC commands can be used in interactive mode as well. Those who can't usually signals this with the BÖÖP sound, but here it seems not to.



#13 RXB OFFLINE  

RXB

    River Patroller

  • 2,726 posts
  • Location:Vancouver, Washington, USA

Posted Wed Sep 13, 2017 6:42 AM

 

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, Wed Sep 13, 2017 6:45 AM.


#14 senior_falcon OFFLINE  

senior_falcon

    Dragonstomper

  • 913 posts
  • Location:Lansing, NY, USA

Posted Wed Sep 13, 2017 8:08 AM

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.



#15 mizapf OFFLINE  

mizapf

    River Patroller

  • 2,515 posts
  • Location:Germany

Posted Wed Sep 13, 2017 9:41 AM

I remember some more funny things with ACCEPT in command mode. In particular, FCTN-4 does not kill the sprites that have been created.

 

> CALL SPRITE(#1,42,10,10,10,20,20) :: ACCEPT A

 

Press FCTN-4, and watch the sprite continue running.



#16 RXB OFFLINE  

RXB

    River Patroller

  • 2,726 posts
  • Location:Vancouver, Washington, USA

Posted Wed Sep 13, 2017 10:16 AM

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.



#17 RXB OFFLINE  

RXB

    River Patroller

  • 2,726 posts
  • Location:Vancouver, Washington, USA

Posted Wed Sep 13, 2017 10:19 AM

You know I will look into doing something about it, if nothing else do like Basic and report you can not do that.

 

XB does not handle FNCT 4 the same way as Basic does as the ROMS are part of the issue.



#18 senior_falcon OFFLINE  

senior_falcon

    Dragonstomper

  • 913 posts
  • Location:Lansing, NY, USA

Posted Wed Sep 13, 2017 5:40 PM

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.



#19 Casey OFFLINE  

Casey

    Chopper Commander

  • 120 posts

Posted Wed Sep 13, 2017 7:35 PM

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. 


  • RXB likes this

#20 RXB OFFLINE  

RXB

    River Patroller

  • 2,726 posts
  • Location:Vancouver, Washington, USA

Posted Thu Sep 14, 2017 7:23 PM

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?



#21 senior_falcon OFFLINE  

senior_falcon

    Dragonstomper

  • 913 posts
  • Location:Lansing, NY, USA

Posted Thu Sep 14, 2017 9:32 PM

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, Thu Sep 14, 2017 9:35 PM.


#22 RXB OFFLINE  

RXB

    River Patroller

  • 2,726 posts
  • Location:Vancouver, Washington, USA

Posted Thu Sep 14, 2017 10:49 PM

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



#23 sometimes99er OFFLINE  

sometimes99er

    River Patroller

  • 3,910 posts
  • Location:Denmark

Posted Fri Sep 15, 2017 1:51 AM

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.



#24 senior_falcon OFFLINE  

senior_falcon

    Dragonstomper

  • 913 posts
  • Location:Lansing, NY, USA

Posted Fri Sep 15, 2017 5:45 AM

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.



#25 RXB OFFLINE  

RXB

    River Patroller

  • 2,726 posts
  • Location:Vancouver, Washington, USA

Posted Fri Sep 15, 2017 6:52 AM

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, Fri Sep 15, 2017 6:59 AM.






Also tagged with one or more of these keywords: Bug, Extended Basic

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users