Bug found in Extended BASIC

[senior_falcon]

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 November 22, 2017 by senior_falcon

[Airshack]

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

 

 

Sent from my iPhone using Tapatalk Pro

[Airshack]

Just kidding Rich! I crack myself up.

 

 

Sent from my iPhone using Tapatalk Pro

[ramidavis]

...

Edited January 2, 2018 by ramidavis

[+Schmitzi]

My workaround is not to enter these things

[+OLD CS1]

My workaround is not to enter these things

 

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!

[Tursi]

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.

[senior_falcon]

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 November 23, 2017 by senior_falcon

[RXB]

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 November 23, 2017 by RXB

[RXB]

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.

[RXB]

Just kidding Rich! I crack myself up.

 

 

Sent from my iPhone using Tapatalk Pro

You are correct but I fixed this issue today.

[RXB]

My workaround is not to enter these things

Well just to repeat I have fixed this issue.

[RXB]

 

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

[atrax27407]

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]

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.

[Retrospect]

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 November 24, 2017 by Retrospect

[bfollett]

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]

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 November 24, 2017 by RXB