pixelpedant Posted May 29, 2021 Share Posted May 29, 2021 In the weekly Zoom meeting today, I was chatting about the source for Legends 1 and 2, the code for which is fairly annoying to decipher, given its use of 1 and 2 character largely unmeaningful and sometimes non-alphanumeric variable names (called things like _, @, _1, _2, _3 and_4) and immensely complicated collection of ON GOTOs and ON GOSUBs. Anyway, I was thinking it might be fun to take a few lessons from this piece of code, and apply them to an important problem in TI BASIC programming: How can a compact and functional, yet utterly confusing, obscure, and inaccessible TI-99 BASIC or Extended BASIC program best be designed, for maximum incomprehensibility? Obfuscated programming competitions have obviously been a fun little sideshow elsewhere in the coding world. And I'm sure BASIC has received some attention now and again. But it'd be fun to see what the "worst" is that can be done, on the TI-99. Either in console BASIC or Extended BASIC. Potentially a nice opportunity to dig in to or exemplify some weirder or unintended behaviour. Anybody else interesting? I figure I'll give it a shot. But some of you folks pretty much know the interpreter inside and out, and so are better equipped I think to misuse it to maximum effect. Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted May 29, 2021 Share Posted May 29, 2021 How about self-modifying code? Avoid ON GOTO, just use GOTO! Quote Link to comment Share on other sites More sharing options...
pixelpedant Posted May 30, 2021 Author Share Posted May 30, 2021 Yeah, definitely once you get to directly modifying the program in memory, a lot of options open up. But here's what I suppose is a more orthodox and very short example of something utterly asinine, which 1) When run, actually performs an easily observed function 2) While achieving this in the most abstruse and idiotic way possible (among those which occur to me, at the moment) 3) Via a sequence of statements all of which are valid TI BASIC or Extended BASIC statements. 10 [=[-]=] 20 ]\]=[/[ 75 ON ERROR 75 :: [=[-[_-_]-] :: CALL ERR([_,_,_,_]) :: CALL SOUND(]\],]-[,[/[) :: IF ]\]*]-[*[/[ < [_*_] THEN 75 2 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted June 1, 2021 Share Posted June 1, 2021 A good job of obfuscation! Quote Link to comment Share on other sites More sharing options...
Asmusr Posted June 1, 2021 Share Posted June 1, 2021 All BASIC code looks like that to me ? 2 5 Quote Link to comment Share on other sites More sharing options...
+9640News Posted June 1, 2021 Share Posted June 1, 2021 On 5/30/2021 at 5:44 PM, pixelpedant said: 10 [=[-]=] 20 ]\]=[/[ 75 ON ERROR 75 :: [=[-[_-_]-] :: CALL ERR([_,_,_,_]) :: CALL SOUND(]\],]-[,[/[) :: IF ]\]*]-[*[/[ < [_*_] THEN 75 Might be nice if someone translated that to more readable line statements....... Quote Link to comment Share on other sites More sharing options...
pixelpedant Posted June 1, 2021 Author Share Posted June 1, 2021 Well, "unreadable" was kind of the whole premise. Obfuscated programming is pretty nearly "worst practices in programming" combined with a little aesthetic flavour. In effect, people asking "what is the least maintainable, least readable code we can generate, if we really dig in our heels, and how can we make it look cool?" There's only so much you can do in BASIC. PERL or C is far better suited to making completely opaque blocks of unreadable code. But there are a couple tools available, it seems to me, even in XB. First of all, ON ERROR is appealing for handling all control flow. That's desirable, as this allows for the possibility of control redirecting from one line to another with no indication at either of these two lines that this behaviour occurs, or under what conditions. It allows for the creation of complex jump conditions (when variable values, for example, create an error state once they go out of range) which are impossible to identify by cursory observation of the code. And CALL ERR is also quite valuable, as it allows for assignment of values to integer variables based on line number and error code, but again, this line number is the line number on which an error has occurred, and so cursory observation does not necessarily inform the reader as to where a variable acquired its value, other than "from an error somewhere at some point". The above was a very trivial example. Something much more interesting could be done. CALL SPGET might also be useful, as it allows for access to a large volume of string data (some of which is printable characters). So this is potentially another good way to non-explicitly acquire unexpected variable data, and particularly string data. 2 Quote Link to comment Share on other sites More sharing options...
pixelpedant Posted June 2, 2021 Author Share Posted June 2, 2021 More ridiculous garbage, further plumbing the depths of worst practices in Extended BASIC programming. I feel like running literally everything off errors is thematically appropriate to this endeavour. So that's what I did. This doesn't play any sounds. 5 ON WARNING NEXT 10 ]\]=[/[ 15 [=[-]=] 20 DEF ]\(_)=(_)/[ 21 CALL CLEAR::ON ERROR 81::CALL SOUND(]\(),[\],]\],]\]) 22 CALL ERR([\,[\],[\],\]) 23 CALL HCHAR(]\([\])/[--[\],]\([\])/[--[\],\]-[\)::ON ERROR 22::PRINT::RETURN NEXT 81 ON ERROR 22 82 CALL SOUND(]\(),[\],]\],]\]) 119 CALL SOUND(]\(),[\],]\],]\]) 128 CALL SOUND(]\(),[\],]\],]\]) 130 CALL SOUND(]\(),[\],]\],]\]) 135 CALL SOUND(]\(),[\],]\],]\]) 139 CALL SOUND([-],[/[,[/[,]) 141 CALL SOUND([-],[/[,[/[,]) 147 CALL SOUND([-],[/[,[/[,]) 180 CALL SOUND([-],[/[,[/[,]) 188 CALL SOUND([-],[/[,[/[,]) 190 CALL SOUND([-],[/[,[/[,]) It does a little vertical text scroll containing this text: 2 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted June 2, 2021 Share Posted June 2, 2021 Another way to do this is might be to write a different interpreter in BASIC and then write the program in that new language. 2 Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted June 2, 2021 Share Posted June 2, 2021 6 hours ago, TheBF said: Another way to do this is might be to write a different interpreter in BASIC and then write the program in that new language. Kinda defeats the spirit. Quote Link to comment Share on other sites More sharing options...
+TheBF Posted June 2, 2021 Share Posted June 2, 2021 1 hour ago, OLD CS1 said: Kinda defeats the spirit. ok 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.