cbmeeks Posted May 10, 2019 Share Posted May 10, 2019 Are there any BASIC dialects out there for the TI that support labels? So, instead of "GOSUB 1000" it could be "GOSUB MYCOOLROUTINE"? Also, extra points if the BASIC approaches asm speeds for some things (like graphics). Thanks Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted May 10, 2019 Share Posted May 10, 2019 matthew180 created a pre-processor system (the name escapes me) that creates XB code with line numbers based on his structured basic dialect... And the output of that has been successfully used by people along with senior_falcon's basic compiler... -M@ 1 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted May 10, 2019 Share Posted May 10, 2019 TidBit: http://atariage.com/forums/topic/172765-basic-xb-translator-tidbit/ -M@ 1 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted May 10, 2019 Share Posted May 10, 2019 http://atariage.com/forums/topic/153704-ti-994a-development-resources/ ^--- look for ISABELLA in there for the compiler part. Or this thread discussing it: http://atariage.com/forums/topic/224905-xb-game-developers-package/page-27?do=findComment&comment=4262495 -M@ 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted May 11, 2019 Share Posted May 11, 2019 Extended Basic uses LABELS with a CALL SUB command. So yea it supports labels but not every line is labeled, just Subprograms for calls. Barry Traver made a ton of mostly CALL SUB routines that could do everything. 2 Quote Link to comment Share on other sites More sharing options...
Airshack Posted October 4, 2019 Share Posted October 4, 2019 Here's a demo using TIdBiT and coding BASIC on a TI-99/4A without line numbering: 1 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted October 4, 2019 Share Posted October 4, 2019 (edited) On 5/10/2019 at 10:24 AM, cbmeeks said: Are there any BASIC dialects out there for the TI that support labels? So, instead of "GOSUB 1000" it could be "GOSUB MYCOOLROUTINE"? Also, extra points if the BASIC approaches asm speeds for some things (like graphics). Thanks Not compiled but XB (RXB also) has CALL nameofsubroutine that is pretty close to what you want. My biggest problem with compiled programming is testing is twice or three times longer. XB: Write a program test it on spot, fix it on the spot. COMPILED XB: Write Text, compile it, test it, go back and fix Text, compile it, test it. Way longer to write, debug and test. Edited October 4, 2019 by RXB Quote Link to comment Share on other sites More sharing options...
RXB Posted October 4, 2019 Share Posted October 4, 2019 (edited) 13 hours ago, Airshack said: Here's a demo using TIdBiT and coding BASIC on a TI-99/4A without line numbering: Cool but doing all of this on a TI99/4A would be a labor of true love with insane amount of tolerance for number of steps. Edited October 4, 2019 by RXB Quote Link to comment Share on other sites More sharing options...
Airshack Posted October 4, 2019 Share Posted October 4, 2019 Uh....it’s not that bad once you get it down. The main dig against XB is speed. What good are fast moving sprites without accurate collision detection? The compiler addresses this main issue. Benefits I discovered with this workflow include: modern coding style w labels, no line numbering, readable comments and indentation, code portability, 20+ times faster than XB, compiled code “slimmer” than BASIC thus large BASIC (>24k) fit into 24k, modern editing on modern hardware, not tied to real iron during development, compiled code able to be converted to run on FlashROM and FlashGROM, or on emulator as a binary. From what I experienced it’s a great way to create speedy BASIC games. Once you get the flow down it’s not difficult. Credit to Sinphaltimus for showing me how it all worked through his posts. Added Bonus: Helps in the transition from BASIC to Assembly programming by building familiarization with Code-Compile-Load-Run process. A nice bridge to cross....Assembly training wheels. 7 Quote Link to comment Share on other sites More sharing options...
RXB Posted October 5, 2019 Share Posted October 5, 2019 To bad no RXB assembly compiler as many of the RXB commands are very cool to use. Like CALL HPUT vs DISPLAY AT as HPUT uses entire screen not just rows 3 to 30 like DISPLAY or PRINT does. Or CALL HGET vs CALL GCHAR as HGET will get a string not just a single character. Or GMOTION that returns the Motion of a sprite. Or RMOTION that reverses a Sprite motion. Or CALL IO that fetches CRU bits or sends CRU bits. Or CALL MOVES that will move any type of any size memory to any type or any size memory, i.e. RAM, VDP, or GROM or GRAM. 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted October 6, 2019 Share Posted October 6, 2019 On 10/4/2019 at 10:51 AM, RXB said: My biggest problem with compiled programming is testing is twice or three times longer. XB: Write a program test it on spot, fix it on the spot. COMPILED XB: Write Text, compile it, test it, go back and fix Text, compile it, test it. Way longer to write, debug and test. I just had a thought! Why not do it this way: XB: Write a program test it on spot, fix it on the spot. COMPILED XB: Write Text, compile it, test it, go back and fix Text, compile it, test it. Write a program (in XB) test it on spot (in XB), fix it on the spot(in XB). Iterate until happy with the program just like you would do in XB. Only when the XB program is debugged and complete would you compile it. (Realistically you would probably have to do some adjustment to timings which means compiling a couple of times) Way longer to write, debug and test. Just a tiny bit of added time when you do the compilation at the end. (Actually, this is described in the manual, and so is not a new thought.) 3 Quote Link to comment Share on other sites More sharing options...
LASooner Posted October 7, 2019 Share Posted October 7, 2019 I use TIdBit for everything. Use it on your computer locally. With a batch file it's super fast to test in classic 99 emulator. This is what I used when I was making Night Stalker, I saved the file nightstalker.xb that was written in TIdBit code, I then run this batch file it converts the TIdBit code to standard Extended Basic code and saves it to a file called nightstalker-compiled.xb, it then copies that file into clipboard, with classic 99 already open, it brings it into focus and all you have to do is paste extended basic (which I wish had a hot key command), but the whole process takes seconds from save to paste, so iteration is really fast. Once you're happy with it, compiling and running it goes pretty fast too. C:\TI_DEV\php\php C:\TI_DEV\tidbit\tidbit_cmd.php X:\TI994a\Development\NightStalker\nightstalker.xb 100 10 X:\TI994a\Development\NightStalker\nightstalker-compiled.xb clip < "X:\TI994a\Development\NightStalker\nightstalker-compiled.xb" call sendkeys.bat "Classic99" "" WshShell.Sendkeys "%e" WshShell.Sendkeys “p” WshShell.Sendkeys "{Enter}" I typically have all my development files on 1 server and I map the same drive letter on my laptop and desktop so I can run the scripts on either, hence the X drive listed in the script. 3 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted October 7, 2019 Share Posted October 7, 2019 17 hours ago, senior_falcon said: I just had a thought! Why not do it this way: XB: Write a program test it on spot, fix it on the spot. COMPILED XB: Write Text, compile it, test it, go back and fix Text, compile it, test it. Write a program (in XB) test it on spot (in XB), fix it on the spot(in XB). Iterate until happy with the program just like you would do in XB. Only when the XB program is debugged and complete would you compile it. (Realistically you would probably have to do some adjustment to timings which means compiling a couple of times) Way longer to write, debug and test. Just a tiny bit of added time when you do the compilation at the end. (Actually, this is described in the manual, and so is not a new thought.) Exactly. The compiler should not be used until the program is already fully functional in straight XB. 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted October 7, 2019 Share Posted October 7, 2019 The routines I added to RXB makes some of the standard XB routines look really assbackwards and silly to use. Like CALL GCHAR can only get 1 character at a time? (So RXB has CALL HGET for string of characters.) Or CALL INIT has to be called before you can do a CALL LOAD??? (That one really bothered me as just STUPID!) Or DISPLAY AT that does not use full screen, so I wrote CALL HPUT or CALL VPUT to fix it. Or added string check with a IF string THEN next ELSE loop to CALL KEY Or later ON KEY GOTO line number with CALL ONKEY Or CALL IO that allows playing VDP or GROM Sound lists automatically see my game IN THE DARK for an example. Or CALL IO to talk to devices like RS232 Weather station or keyboard directly. And many more... Quote Link to comment Share on other sites More sharing options...
jrhodes Posted October 7, 2019 Share Posted October 7, 2019 (edited) 8 hours ago, RXB said: The routines I added to RXB makes some of the standard XB routines look really assbackwards and silly to use. Like CALL GCHAR can only get 1 character at a time? (So RXB has CALL HGET for string of characters.) How about getting a vertical section of characters from the screen; CALL VGET, starts at the position requested, and reads x# of chars downward (or upwards if number of chars to read is specified as a negative number)? Just a idea.... Never mind, i see you already have a CALL VGET, i over looked that. Edited October 7, 2019 by jrhodes 2 Quote Link to comment Share on other sites More sharing options...
Opry99er Posted November 4, 2019 Share Posted November 4, 2019 (edited) Been using TIdBiT for the better part of a decade... Will never go back to regular line numbered BASIC coding. With labels and no line numbers, code becomes extremely "readable." . . . IF LIVES<1 THEN GOTO DeathScreen . . . DeathScreen: CALL CLEAR :: CALL SCREEN(8) PRINT "YOU'RE DEAD" GOTO GameStart Edited November 4, 2019 by Opry99er 1 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted November 4, 2019 Share Posted November 4, 2019 40 minutes ago, Opry99er said: Been using TIdBiT for the better part of a decade... Will never go back to regular line numbered BASIC coding. With labels and no line numbers, code becomes extremely "readable." . . . IF LIVES<1 THEN GOTO DeathScreen . . . DeathScreen: CALL CLEAR :: CALL SCREEN(8) PRINT "YOU'RE DEAD" GOTO GameStart Been using Forth for the better part of three decades ... Will never go back to regular line numbered BASIC coding. With labels and no line numbers, code becomes extremely "readable." . . . LIVE 1 < IF DeathScreen ENDIF . . . : DeathScreen CLEAR 8 SCREEN CR ." YOU'RE DEAD" GameStart ; ? (I couldn't resist) 1 1 Quote Link to comment Share on other sites More sharing options...
Opry99er Posted November 5, 2019 Share Posted November 5, 2019 Nice. 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.