Jump to content
Sign in to follow this  
cbmeeks

Compiled BASICs using labels?

Recommended Posts

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

Share this post


Link to post
Share on other sites

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

 

[email protected]

  • Like 1

Share this post


Link to post
Share on other sites

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.

  • Like 2

Share this post


Link to post
Share on other sites
Posted (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 by RXB

Share this post


Link to post
Share on other sites
Posted (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 by RXB

Share this post


Link to post
Share on other sites

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.

  • Like 7

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites
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.)

  • Like 3

Share this post


Link to post
Share on other sites

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.

  • Like 3

Share this post


Link to post
Share on other sites
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. 

  • Thanks 1

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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 by jrhodes
  • Like 2

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...