Compiled BASICs using labels?

[cbmeeks]

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

[+jedimatt42]

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@

[+jedimatt42]

TidBit: http://atariage.com/forums/topic/172765-basic-xb-translator-tidbit/

 

-M@

[+jedimatt42]

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@

[RXB]

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.

[Airshack]

Here's a demo using TIdBiT and coding BASIC on a TI-99/4A without line numbering:

 

 

[RXB]

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

[RXB]

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

[Airshack]

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.

[RXB]

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.

[senior_falcon]

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.)

[LASooner]

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.

[+Vorticon]

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. 

[RXB]

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...

[jrhodes]

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

[Opry99er]

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

[+TheBF]

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) 

[Opry99er]

Nice.