Jump to content

Photo

Bug found in Extended BASIC


17 replies to this topic

#1 senior_falcon OFFLINE  

senior_falcon

    Dragonstomper

  • 960 posts
  • Location:Lansing, NY, USA

Posted Wed Nov 22, 2017 11:19 AM

Last night I discovered a new bug in TI XB.  From the immediate mode type CALL INIT(  and the computer locks up.  Also with CALL INIT) and CALL INIT. and CALL INIT# and many others.  CALL CLEAR) or CALL CLEAR. give the expected "Syntax Error".  Funny that XB doesn't pick up the error with CALL INIT


Edited by senior_falcon, Wed Nov 22, 2017 11:19 AM.


#2 Airshack OFFLINE  

Airshack

    Dragonstomper

  • 550 posts
  • Location:Phoenix, AZ

Posted Wed Nov 22, 2017 1:23 PM

I hear that’s an issue with RXB as well.


Sent from my iPhone using Tapatalk Pro

#3 Airshack OFFLINE  

Airshack

    Dragonstomper

  • 550 posts
  • Location:Phoenix, AZ

Posted Wed Nov 22, 2017 1:24 PM

Just kidding Rich! I crack myself up.


Sent from my iPhone using Tapatalk Pro

#4 ramidavis OFFLINE  

ramidavis

    Chopper Commander

  • 105 posts

Posted Wed Nov 22, 2017 1:36 PM

I hear that’s an issue with RXB as well.


Sent from my iPhone using Tapatalk Pro

 

Just kidding Rich! I crack myself up.


Sent from my iPhone using Tapatalk Pro

Rxb 2015 that comes with classic99 looks pretty locked up to me.

So how is it not a issue?

Now before i get blasted, i am not blaming rxb.

I am just saying that yes this issue does effect rxb(at least the version i had access to at the moment), the same as it does xb.

Attached Files


Edited by ramidavis, Wed Nov 22, 2017 1:50 PM.


#5 Schmitzi OFFLINE  

Schmitzi

    River Patroller

  • 3,912 posts
  • ToXiC
  • Location:Germany

Posted Wed Nov 22, 2017 3:05 PM

My workaround is not to enter these things :-D



#6 OLD CS1 OFFLINE  

OLD CS1

    River Patroller

  • 4,066 posts
  • Technology Samurai
  • Location:Tallahassee, FL

Posted Wed Nov 22, 2017 3:16 PM

My workaround is not to enter these things :-D

 

Indeed, BUT it does make one curious as to the special case of CALL INIT and why it, unlike other subprograms which do not use arguments, behaves as such.

 

Patient: Doctor, it hurts when I do this.

Doctor: Well, stop doing that!



#7 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,851 posts
  • HarmlessLion
  • Location:BUR

Posted Wed Nov 22, 2017 4:03 PM

It's interesting, it breaks things in the middle of a GPL MOVE instruction such that it gets stuck in the interrupt routine. R14 in the GPLWS gets corrupted and it thinks the VDP interrupt is a cassette interrupt, but the 9901 timer doesn't run down, so it loops forever.

#8 senior_falcon OFFLINE  

senior_falcon

    Dragonstomper

  • Topic Starter
  • 960 posts
  • Location:Lansing, NY, USA

Posted Wed Nov 22, 2017 9:37 PM

Earlier I said "CALL CLEAR) or CALL CLEAR. give the expected "Syntax Error".   Turns out that CALL CLEAR actually does happen and only then do you get the syntax error when the interpreter comes to the parenthesis.  This also happens in TI BASIC when you CALL CLEAR(

It looks like both interpreters look for certain non alphabetic characters (or a space) to denote the end of the subprogram name. I've been trying to figure out a way to do something useful with this but haven't found it yet!

 

Schmitzi said: "My workaround is not to enter these things"

That's my normal way of working as well, but sometimes my fingers get rebellious and don't do what my head tells them to!


Edited by senior_falcon, Wed Nov 22, 2017 9:41 PM.


#9 RXB OFFLINE  

RXB

    River Patroller

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

Posted Thu Nov 23, 2017 12:06 AM

Earlier I said "CALL CLEAR) or CALL CLEAR. give the expected "Syntax Error".   Turns out that CALL CLEAR actually does happen and only then do you get the syntax error when the interpreter comes to the parenthesis.  This also happens in TI BASIC when you CALL CLEAR(

It looks like both interpreters look for certain non alphabetic characters (or a space) to denote the end of the subprogram name. I've been trying to figure out a way to do something useful with this but haven't found it yet!

 

Schmitzi said: "My workaround is not to enter these things"

That's my normal way of working as well, but sometimes my fingers get rebellious and don't do what my head tells them to!

LOL you found a ERROR buddy!

 

Here is the issue problem they screwed up at TI they used the CALL LOAD("DISKFILENAME") error that closed all open files and does a DSR close and reset DSR flags in CALL INIT

 

BR LDRTN2  is the last GPL command in CALL INIT to return to XB, but LDRTN2 calls CLSNOE that is for CALL LOAD("DISKFILENAME") 

 

The fix is not to call the CLSNOE but just jump to next line and use ERRSYN instead of ERRSY1 that was used by CALL LOAD and CALL INIT

********************** CLSNOE *****************************
* Try to close the current file
* Ignore any errors from the closing of the file.
* Since the PAB is not in the normal PAB list
*  then we have to close the file in the load routine.
* ERRZZ will close the rest of the files.
*
** CLOSE IT ONLY IF IT HAS BEEN OPENED
CLSNOE DCEQ 1,@CHKSUM         Check file flag
       BS   GC2B9
       ST   1,V*SREF          Store close file code
       DST  @SREF,@FAC12      Compute start address of spec
       DADD NLEN,@FAC12       Ready to CALL DSR
       CALL DSR               CALL DSR through program link
       BYTE 8               * "8" is type of DSR
GC2B9  RTN
***********************************************************

Edited by RXB, Thu Nov 23, 2017 12:07 AM.


#10 RXB OFFLINE  

RXB

    River Patroller

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

Posted Thu Nov 23, 2017 1:05 AM

It's interesting, it breaks things in the middle of a GPL MOVE instruction such that it gets stuck in the interrupt routine. R14 in the GPLWS gets corrupted and it thinks the VDP interrupt is a cassette interrupt, but the 9901 timer doesn't run down, so it loops forever.

WOW THIS WAS MORE OF A ISSUE THEN I THOUGHT IT WAS TO FIX:

 

I had to totally replace the original code to fix this issue.

***********************************************************
* INIT                        JDH   9/02/80
***********************************************************
* Check if expansion RAM present
* Load support into expansion RAM from GROM
INIT   CZ   @RAMTOP           If no ERAM, SYNTAX ERROR
       BS   ERRSYN
** Load Assembly header, support routines **
* GKXB Correct INIT routine.
       MOVE >04EA,G@ALCEND,@>2000
       B    ECRTN
***********************************************************
* RXB COPY OF CHKEND FROM GROM 4 FOR CALL INIT ERROR
***********************************************************
* If it's no DISPLAY keyword ( AT, SIZE, BEEP or USING) it
* has to be a print separator or colon ":"
* If anything is specified is has to be a colon or end of
* line... for end-of-line output current record
* Check for end of statement
ENDCHK CLOG >80,@CHAT
       BS   ECSET
       CHE  TREMZ+1,@CHAT
       BR   ECSET2
ECSET  CZ   @CHAT         Set COND according to CHAT
       RTNC
ECSET2 CEQ  @>8300,@>8300     Force COND to "SET"
       RTNC                   Exit with no COND change
***********************************************************
ECRTN  CALL ENDCHK        Use this CHKEND instead NORMAL
       CALL RETURN
***********************************************************

Now when you type in EDIT mode CALL INIT( you get * SYNTAX ERROR exactly as it should do in RXB.



#11 RXB OFFLINE  

RXB

    River Patroller

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

Posted Thu Nov 23, 2017 1:55 AM

Just kidding Rich! I crack myself up.


Sent from my iPhone using Tapatalk Pro

You are correct but I fixed this issue today.



#12 RXB OFFLINE  

RXB

    River Patroller

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

Posted Thu Nov 23, 2017 1:56 AM

My workaround is not to enter these things :-D

Well just to repeat I have fixed this issue.



#13 RXB OFFLINE  

RXB

    River Patroller

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

Posted Thu Nov 23, 2017 1:57 AM

 

Indeed, BUT it does make one curious as to the special case of CALL INIT and why it, unlike other subprograms which do not use arguments, behaves as such.

 

Patient: Doctor, it hurts when I do this.

Doctor: Well, stop doing that!

You do it and it will not hurt in RXB 2017



#14 atrax27407 OFFLINE  

atrax27407

    Dragonstomper

  • 801 posts

Posted Thu Nov 23, 2017 8:40 AM

If you are going to release the next iteration of RXB in the next month, it will be "RXB 2017". Otherwise, it will be "RXB 2018" ;) 


  • RXB likes this

#15 RXB OFFLINE  

RXB

    River Patroller

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

Posted Thu Nov 23, 2017 12:28 PM

If you are going to release the next iteration of RXB in the next month, it will be "RXB 2017". Otherwise, it will be "RXB 2018" ;) 

Yea good point, I always name RXB per the year and not going to make it 2017

 

Just modified normal XB  CALL CHARSET  {characters 33 to 95} remains the same, 

 

so now you can do a CALL CHARSET(ALL)  {30 to 159} 

 

*Note in RXB you can use characters 30 to 159 but of course not at same time with Sprites, but you can mix and match in RXB to use some of both.



#16 Retrospect OFFLINE  

Retrospect

    Dragonstomper

  • 878 posts
  • Location:Wakefield, England

Posted Fri Nov 24, 2017 3:23 AM

I noticed some strange activity in XB once, not related to what you guys are talking about, but still a kind of bug ... I cannot remember what it was I did but I was playing the Extended Basic 16K version of Castle Conquer, using XB on the emulated TI99/4 (not A) and I think I broke out of the program at some point and was left with red characters/letters in Basic.  It's supposed to always go back to black, it's never happened on the 4A though. Think I was using version 110 XB too.

Edit: In fact I was emulating the /4 in MESS. Used the WAV version of Castle Conquer.  Just an ordinary XB game.


Edited by Retrospect, Fri Nov 24, 2017 3:27 AM.


#17 bfollett OFFLINE  

bfollett

    Dragonstomper

  • 516 posts

Posted Fri Nov 24, 2017 7:58 AM

Perhaps this is well know now, but I used to know an invalid command that if added to an extended basic program would actually drop you out of extended basic and into regular TI basic with the program still intact.  If the program had no extended basic commands it would happily now run under TI basic.  You would see garbage characters for any TI extended basic code and of course it wouldn't run .  I used to use that bug so I could code under the quicker extended basic and then switch to TI basic to do the final testing.

 

Bob


  • RXB likes this

#18 RXB OFFLINE  

RXB

    River Patroller

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

Posted Fri Nov 24, 2017 4:34 PM

Perhaps this is well know now, but I used to know an invalid command that if added to an extended basic program would actually drop you out of extended basic and into regular TI basic with the program still intact.  If the program had no extended basic commands it would happily now run under TI basic.  You would see garbage characters for any TI extended basic code and of course it wouldn't run .  I used to use that bug so I could code under the quicker extended basic and then switch to TI basic to do the final testing.

 

Bob

This is why I made RXB able to run TI Basic programs with no modifications. So far only a PRINT bug has shown up as a issue but no one uses this often so is very very rare.


Edited by RXB, Fri Nov 24, 2017 4:35 PM.





0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users