senior_falcon Posted November 22, 2017 Share Posted November 22, 2017 (edited) 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 2 Quote Link to comment Share on other sites More sharing options...
Airshack Posted November 22, 2017 Share Posted November 22, 2017 I hear that’s an issue with RXB as well. Sent from my iPhone using Tapatalk Pro Quote Link to comment Share on other sites More sharing options...
Airshack Posted November 22, 2017 Share Posted November 22, 2017 Just kidding Rich! I crack myself up. Sent from my iPhone using Tapatalk Pro 3 Quote Link to comment Share on other sites More sharing options...
ramidavis Posted November 22, 2017 Share Posted November 22, 2017 (edited) ... Edited January 2, 2018 by ramidavis 1 Quote Link to comment Share on other sites More sharing options...
+Schmitzi Posted November 22, 2017 Share Posted November 22, 2017 My workaround is not to enter these things 5 Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted November 22, 2017 Share Posted November 22, 2017 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! 3 Quote Link to comment Share on other sites More sharing options...
Tursi Posted November 22, 2017 Share Posted November 22, 2017 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. 3 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted November 23, 2017 Author Share Posted November 23, 2017 (edited) 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 3 Quote Link to comment Share on other sites More sharing options...
RXB Posted November 23, 2017 Share Posted November 23, 2017 (edited) 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 Quote Link to comment Share on other sites More sharing options...
RXB Posted November 23, 2017 Share Posted November 23, 2017 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. 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted November 23, 2017 Share Posted November 23, 2017 Just kidding Rich! I crack myself up. Sent from my iPhone using Tapatalk Pro You are correct but I fixed this issue today. 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted November 23, 2017 Share Posted November 23, 2017 My workaround is not to enter these things Well just to repeat I have fixed this issue. 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted November 23, 2017 Share Posted November 23, 2017 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 1 Quote Link to comment Share on other sites More sharing options...
atrax27407 Posted November 23, 2017 Share Posted November 23, 2017 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" 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted November 23, 2017 Share Posted November 23, 2017 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. 1 Quote Link to comment Share on other sites More sharing options...
Retrospect Posted November 24, 2017 Share Posted November 24, 2017 (edited) 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 Quote Link to comment Share on other sites More sharing options...
bfollett Posted November 24, 2017 Share Posted November 24, 2017 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 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted November 24, 2017 Share Posted November 24, 2017 (edited) 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 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.