Jump to content

Photo

Long ago, I have found a bug in Extended Basic

Bug Extended Basic

43 replies to this topic

#26 TheMole ONLINE  

TheMole

    Dragonstomper

  • 766 posts
  • Location:Belgium

Posted Fri Sep 15, 2017 7:06 AM

Rich, this is clearly a bug. Other routines that are not available in edit mode return an error message (like INPUT), ACCEPT does not. That is a bug. If none of the routines did it, you could argue that it is just bad design, but clearly the programmers at TI thought it important to provide an error message when a program mode only routine is used in edit mode (they were right) and they simply forgot to do the same for ACCEPT. I'm pretty sure the original programmers would consider this a bug as well.



#27 apersson850 ONLINE  

apersson850

    Moonsweeper

  • 450 posts

Posted Fri Sep 15, 2017 7:43 AM

My definition is that something that goes wrong, because somebody didn't think about it, or did think but fixed it in a way that doesn't work, that's a bug.

On the other hand, something you can't do because the designer thought that it shouldn't be possible (even if you would want it to be possible), that's by design, so not a bug.

 

By this standard, what's described here is a bug. Somebody didn't think about that if you use ACCEPT like this, you get a fault, instead of a message like * COMMAND ONLY ALLOWED IN A PROGRAM.

But that CALL SPRITE doesn't work if you give it as an immediate command, that's not a bug. That's how they intended it to work, so the computer can clean up all definitions and states that may garble the screen when a program isn't running. So this is by design. Even if you want sprites to fly around when the program is stopped.

 

I've noticed before, when discussing with Rich, that he has an inverted opinion about what's a bug and what's by design.



#28 RXB OFFLINE  

RXB

    River Patroller

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

Posted Fri Sep 15, 2017 8:36 AM

Rich, this is clearly a bug. Other routines that are not available in edit mode return an error message (like INPUT), ACCEPT does not. That is a bug. If none of the routines did it, you could argue that it is just bad design, but clearly the programmers at TI thought it important to provide an error message when a program mode only routine is used in edit mode (they were right) and they simply forgot to do the same for ACCEPT. I'm pretty sure the original programmers would consider this a bug as well.

I know the GPL code used by Accept and Input. I even know why the flag is not set the same in both. Problem resides in XB ROMs.

 

See XB ROMs sees the Program is no longer in Program Mode but Edit mode. This is what crashes XB, and why the GPL Input version does not crash.


Edited by RXB, Fri Sep 15, 2017 8:41 AM.


#29 --- Ω --- OFFLINE  

--- Ω ---

    TI-Runner

  • 10,956 posts

Posted Fri Sep 15, 2017 8:49 AM

(sigh)

#30 RXB OFFLINE  

RXB

    River Patroller

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

Posted Fri Sep 15, 2017 8:53 AM

Well if you guys are so smart you fix XB! You seem to know more about it them me right?



#31 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,516 posts
  • Location:Silver Run, Maryland

Posted Fri Sep 15, 2017 12:04 PM

Well if you guys are so smart you fix XB! You seem to know more about it them me right?

 

We all recognize your superior knowledge of GPL and do not doubt you could fix this bug, Rich. At this juncture however, nobody really cares whether you think this bug is really a bug. What we care about is that you persist in arguing off the point. It does not require the useful ability to figure out what GPL code is causing the problem to know that we are dealing with a bug.

 

...lee



#32 RXB OFFLINE  

RXB

    River Patroller

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

Posted Fri Sep 15, 2017 9:27 PM

 

We all recognize your superior knowledge of GPL and do not doubt you could fix this bug, Rich. At this juncture however, nobody really cares whether you think this bug is really a bug. What we care about is that you persist in arguing off the point. It does not require the useful ability to figure out what GPL code is causing the problem to know that we are dealing with a bug.

 

...lee

Lee this problem exists because of the TI Assembly programmers that never talked to the GPL programmers at TI.

 

Numerous examples exist that I have shown such as Assembly routings in XB ROMs that do exactly what GPL does but sometimes slower or same speed as GPL, a few that are faster then GPL, but take much memory.

 

Others like this oddball crash from XB ROMs of ACCEPT that is why it goes off into LA LA Land vs GPL version INPUT that does not crash.

 

Like I said you can hammer in a nail with a wine bottle, does not mean you should do that. Doing something stupid then claim it is a bug is hard to agree with for me.

 

As for fixing XB I have stated NUMEROUS TIMES that I have a note to repair this, but that just keeps getting ignored to troll me on agreeing doing something stupidly wrong is a bug?

 

This strikes me the same a complaints that the wine bottle is chipped after using it to hammer a nail....ignoring the stupid premise that you should never have done this.

 

You could use the same argument for using a random CALL LOAD(any address, any value) is a bug! Same logic applies....



#33 ramidavis OFFLINE  

ramidavis

    Chopper Commander

  • 119 posts

Posted Fri Sep 15, 2017 9:40 PM

RXB, i am not wanting to get into the bug or not debate, but i have a suggestion:

Make the behavior of ACCEPT toggle with a CALL LOAD.

Default would be your fixed behavior, but user could issue a specific CALL LOAD to use the TI-XB behavior.

Just something to think about?



#34 RXB OFFLINE  

RXB

    River Patroller

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

Posted Fri Sep 15, 2017 11:03 PM

RXB, i am not wanting to get into the bug or not debate, but i have a suggestion:

Make the behavior of ACCEPT toggle with a CALL LOAD.

Default would be your fixed behavior, but user could issue a specific CALL LOAD to use the TI-XB behavior.

Just something to think about?

Oddly the FLAG in ACCEPT is the same flag (PROGRAM/EDIT FLAG) as in INPUT,

the problem is ASSEMBLY in the XB ROMs does not check the flag is in PROGRAM MODE or EDIT MODE  like INPUT in GPL does and Assembly XB ROMs crashes the system.

 

The solution is a flag check in GPL so it never gets to Assembly XB ROMs, and thus crashes.

And is not a bug as who the hell attempts to run PROGRAMs in EDIT MODE? (And be surprised about it crashing?)

 

Anyway as stated many many times now I have a fix for it.

 

P.S: RXB has CALL USER that allows EDIT MODE to RUN PROGRAMS and return to EDIT MODE in a BATCH TEXT FILE every time.


Edited by RXB, Fri Sep 15, 2017 11:05 PM.


#35 sometimes99er OFFLINE  

sometimes99er

    River Patroller

  • 4,067 posts
  • Location:Denmark

Posted Sat Sep 16, 2017 2:17 AM

Oddly the FLAG in ACCEPT is the same flag (PROGRAM/EDIT FLAG) as in INPUT,

the problem is ASSEMBLY in the XB ROMs does not check the flag is in PROGRAM MODE or EDIT MODE  like INPUT in GPL does and Assembly XB ROMs crashes the system.

 

The solution is a flag check in GPL so it never gets to Assembly XB ROMs, and thus crashes.

And is not a bug as who the hell attempts to run PROGRAMs in EDIT MODE? (And be surprised about it crashing?)

 

Anyway as stated many many times now I have a fix for it.

 

P.S: RXB has CALL USER that allows EDIT MODE to RUN PROGRAMS and return to EDIT MODE in a BATCH TEXT FILE every time.

 

It's a bug. XB ROM should have checked MODE flag. Shame on those responsible for XB ROM, namely TI Assembly programmers that never talked to the TI GPL programmers, who in contrast got it right - pretty much most of the time. Oh wait, it's not a bug, it's clearly a problem with the management, - GPL and Assembly programmers should have been allowed to eat lunch together. Let the secretaries take messages. End of story. Makes me think of Marketing and Microsoft ... Argh, to hell with it.
 

Why are PCs like air conditioners? They stop working properly if you open Windows ...


#36 RXB OFFLINE  

RXB

    River Patroller

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

Posted Sat Sep 16, 2017 5:27 AM

 

 

It's a bug. XB ROM should have checked MODE flag. Shame on those responsible for XB ROM, namely TI Assembly programmers that never talked to the TI GPL programmers, who in contrast got it right - pretty much most of the time. Oh wait, it's not a bug, it's clearly a problem with the management, - GPL and Assembly programmers should have been allowed to eat lunch together. Let the secretaries take messages. End of story. Makes me think of Marketing and Microsoft ... Argh, to hell with it.
 

Why are PCs like air conditioners? They stop working properly if you open Windows ...

 

LOL did you know that this works perfectly?

10 FOR I=1 TO 1000::NEXT I
20 ACCEPT AT(24,1):A::PRINT A

See the PROGRAM FLAG is checked if there is a AT(row,col) but as this excluded it never gets there and jumps past the check for PROGRAM/EDIT MODE FLAG.



#37 sometimes99er OFFLINE  

sometimes99er

    River Patroller

  • 4,067 posts
  • Location:Denmark

Posted Sat Sep 16, 2017 5:47 AM

LOL did you know that this works perfectly?

10 FOR I=1 TO 1000::NEXT I
20 ACCEPT AT(24,1):A::PRINT A

See the PROGRAM FLAG is checked if there is a AT(row,col) but as this excluded it never gets there and jumps past the check for PROGRAM/EDIT MODE FLAG.

 

I could have slipped on that one too (as a system software developer), - forgetting that someone would definitely come along and try to use ACCEPT without the AT.  :-D



#38 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,516 posts
  • Location:Silver Run, Maryland

Posted Sat Sep 16, 2017 6:49 AM

 

I could have slipped on that one too (as a system software developer), - forgetting that someone would definitely come along and try to use ACCEPT without the AT.  :-D

 

I bow to the master. You are much better at this game than I.  :)

 

...lee


  • RXB likes this

#39 sometimes99er OFFLINE  

sometimes99er

    River Patroller

  • 4,067 posts
  • Location:Denmark

Posted Sat Sep 16, 2017 8:46 AM

 

I bow to the master. You are much better at this game than I.  :)

 

...lee

 

It ain't over till the fat lady sings.  :party:



#40 Sinphaltimus OFFLINE  

Sinphaltimus

    River Patroller

  • 2,135 posts
  • Distracted at the Keyboard
  • Location:Poconos, PA

Posted Sat Sep 16, 2017 1:07 PM

Attached File  fatlady.jpg   10.17KB   3 downloads



#41 palmheads OFFLINE  

palmheads

    Chopper Commander

  • 190 posts
  • Location:Christchurch, New Zealand

Posted Wed Sep 27, 2017 9:26 PM

Found this while looking thru WHT FTP - you guys probably already know about it

 

ftp://ftp.whtech.com/programming/Extended%20Basic/exbasicv100%20bugs.pdf

 

A bunch of bugs found in XB v100 (?) in 1981 ish


  • RXB likes this

#42 RXB OFFLINE  

RXB

    River Patroller

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

Posted Thu Sep 28, 2017 8:21 AM

Found this while looking thru WHT FTP - you guys probably already know about it

 

ftp://ftp.whtech.com/programming/Extended%20Basic/exbasicv100%20bugs.pdf

 

A bunch of bugs found in XB v100 (?) in 1981 ish

Yea if you look at the RXB source i did not remove any of  these fixes in the source and when they were done. 

 

I also mark the places where RXB patches or eliminates code but just make it commented so no original code is removed just place marked as text source comments.

 

Thanks for the post I will look it over for references.



#43 Casey OFFLINE  

Casey

    Chopper Commander

  • 174 posts

Posted Fri Jan 19, 2018 8:56 PM

Perusing some old topics, I went back to this and played around with this ACCEPT behavior.

 

* ACCEPT ERASE ALL:A works correctly.

* ACCEPT BEEP:A puts the cursor in the wrong place and crashes.

* ACCEPT VALIDATE(DIGIT):A also fails.

* ACCEPT SIZE(1):A skips an extra line and then works correctly, however PRINT A displays the value 1 space further to the right than it should be.  Using A$ instead of A, following by PRINT A$ - the result prints where it should.

* ACCEPT BEEP SIZE(1):A beeps, skips an extra line, and then works correctly.

 

Certainly not earth shattering stuff, but interesting to see the quirkiness of it.


  • RXB likes this

#44 RXB OFFLINE  

RXB

    River Patroller

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

Posted Sat Jan 20, 2018 6:57 AM

Perusing some old topics, I went back to this and played around with this ACCEPT behavior.

 

* ACCEPT ERASE ALL:A works correctly.

* ACCEPT BEEP:A puts the cursor in the wrong place and crashes.

* ACCEPT VALIDATE(DIGIT):A also fails.

* ACCEPT SIZE(1):A skips an extra line and then works correctly, however PRINT A displays the value 1 space further to the right than it should be.  Using A$ instead of A, following by PRINT A$ - the result prints where it should.

* ACCEPT BEEP SIZE(1):A beeps, skips an extra line, and then works correctly.

 

Certainly not earth shattering stuff, but interesting to see the quirkiness of it.

Thanks I will update a further not on this for XB bugs to fix in RXB.

 

But honestly the best way to fix all these issues is do what should have been done....do any of these and you get:

 

* ERROR ONLY LEGAL IN PROGRAM MODE *


Edited by RXB, Sat Jan 20, 2018 7:07 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