TheMole Posted September 15, 2017 Share Posted September 15, 2017 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. 2 Quote Link to comment Share on other sites More sharing options...
apersson850 Posted September 15, 2017 Share Posted September 15, 2017 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. 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted September 15, 2017 Share Posted September 15, 2017 (edited) 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 September 15, 2017 by RXB Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted September 15, 2017 Share Posted September 15, 2017 (sigh) Quote Link to comment Share on other sites More sharing options...
RXB Posted September 15, 2017 Share Posted September 15, 2017 Well if you guys are so smart you fix XB! You seem to know more about it them me right? Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted September 15, 2017 Share Posted September 15, 2017 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 6 Quote Link to comment Share on other sites More sharing options...
RXB Posted September 16, 2017 Share Posted September 16, 2017 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.... Quote Link to comment Share on other sites More sharing options...
ramidavis Posted September 16, 2017 Share Posted September 16, 2017 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? 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted September 16, 2017 Share Posted September 16, 2017 (edited) 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 September 16, 2017 by RXB Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted September 16, 2017 Share Posted September 16, 2017 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 ... 2 Quote Link to comment Share on other sites More sharing options...
RXB Posted September 16, 2017 Share Posted September 16, 2017 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. 1 Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted September 16, 2017 Share Posted September 16, 2017 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. 2 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted September 16, 2017 Share Posted September 16, 2017 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. I bow to the master. You are much better at this game than I. ...lee 1 Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted September 16, 2017 Share Posted September 16, 2017 I bow to the master. You are much better at this game than I. ...lee It ain't over till the fat lady sings. Quote Link to comment Share on other sites More sharing options...
Sinphaltimus Posted September 16, 2017 Share Posted September 16, 2017 Quote Link to comment Share on other sites More sharing options...
palmheads Posted September 28, 2017 Share Posted September 28, 2017 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 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted September 28, 2017 Share Posted September 28, 2017 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. Quote Link to comment Share on other sites More sharing options...
Casey Posted January 20, 2018 Share Posted January 20, 2018 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. 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted January 20, 2018 Share Posted January 20, 2018 (edited) 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 January 20, 2018 by RXB 3 Quote Link to comment Share on other sites More sharing options...
atrax27407 Posted February 9, 2018 Share Posted February 9, 2018 Is this your "lost" XB code? TIXBROMS.ARC 4 Quote Link to comment Share on other sites More sharing options...
RXB Posted February 9, 2018 Share Posted February 9, 2018 OMG thanks! And yes these are exactly the originals I up loaded to GENIE BBS. 2 Quote Link to comment Share on other sites More sharing options...
atrax27407 Posted February 10, 2018 Share Posted February 10, 2018 Don''t know if these files are the same (identical) but here is another set. XBROM110.ARC 3 Quote Link to comment Share on other sites More sharing options...
sverrips Posted May 23, 2018 Author Share Posted May 23, 2018 Another one: https://youtu.be/dWuu8a88MwI 10 rem (Press CTRL + KEY H to the end of the line) Press enter Type Edit 10 Press any key 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted May 24, 2018 Share Posted May 24, 2018 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. The more I look at this list the more it is clear that they are INPUT commands not ACCEPT commands. The problem is GPL should see this command and with no AT(row,col) should switch to to INPUT or crash. But as ACCEPT and INPUT both use the same GPL code you can confuse the two of them into behaving like the other. 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted May 24, 2018 Share Posted May 24, 2018 Another one: https://youtu.be/dWuu8a88MwI 10 rem (Press CTRL + KEY H to the end of the line) Press enter Type Edit 10 Press any key This is a case of the GPL uses TOKENS to save the code of a TI Basic or XB program. Thus you exploited this to use a Token to take the place of that command. When you list it looks for tokens and prints or lists out those commands instead of the TOKENS. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.