Jump to content
SteveB

Introducing Structured Extended BASIC and TiCodEd

Recommended Posts

I am preparing version 1.1 of TiCodEd based on your input. One new feature will be a "Standard Library" with useful functions (CALL/SUB, not GOSUB). 

 

Are there any routines you use in multiple programs which are generic enough to be included in that library? For example, I always prepare the screen and char color, but now with one CALL ScrInit(16,2), which will append 

SUB ScrInit(fg,bg)
  CALL SCREEN(bg)
  CALL DELSPRITE(ALL)
  CALL CLEAR
  FOR I=0 to 14 :: CALL COLOR(I,fg,1) :: NEXT I
SUBEND

to my program if and only if used, and only in the generated output, not cluttering my source. There will also be a User Library for your private code extensions working the same way.

 

Do you have any suggestions or XB code-donations? 

 

  • Like 2

Share this post


Link to post
Share on other sites
2 minutes ago, SteveB said:

I am preparing version 1.1 of TiCodEd based on your input. One new feature will be a "Standard Library" with useful functions (CALL/SUB, not GOSUB). 

 

Are there any routines you use in multiple programs which are generic enough to be included in that library? For example, I always prepare the screen and char color, but now with one CALL ScrInit(16,2), which will append 

SUB ScrInit(fg,bg)
  CALL SCREEN(bg)
  CALL DELSPRITE(ALL)
  CALL CLEAR
  FOR I=0 to 14 :: CALL COLOR(I,fg,1) :: NEXT I
SUBEND

to my program if and only if used, and only in the generated output, not cluttering my source. There will also be a User Library for your private code extensions working the same way.

 

Do you have any suggestions or XB code-donations? 

 

Well RXB you could do:

SUB ScrInit(fg,bg)

    CALL SCREEN(bg)

    CALL DELSPRITE(ALL)

    CALL CLEAR

    CALL COLOR(ALL,fg,1)

SUBEND

Share this post


Link to post
Share on other sites

I just uploaded version 1.1 of TiCodEd. I included much of your feedback for version 1.0. You can now change the font-size, there are some program statistics in the log and there is a help-menu.

 

The biggest change is the introduction of Libraries and Packages. There is one "Standard-Library" with additional, generic SUB routines and the option to use your own collection of SUB routines in a User-Library. Only the actually used routines will get included in the generated XB Code. 

 

With the Packages you can make simplified use of XB256 or T40XB. All CALL LINK routines are now available as direct CALLs, i.e.

CALL LINK("CHAR2",124,"FF55AA55FF")

in XB256 becomes 

CALL CHAR2(124,"FF55AA55FF") 

in SXB, less to type and easier to read. It is easy to define your own package if want to use another set of LINK-routines, the package definition is a simple text file.

 

TiCodEd tracks the usage of SUB-Routines and raises error-messages when a CALL is done and no corresponding SUB can be found. If you use another XB Version than V1.1 you can declare the additional routines in a package. For XB 2.7 and RXB 2020 packages are already included.

 

There are also additional examples provided and the manual has been extended. 

 

Enjoy and let me know what you think of the enhanced TiCodEd

Steve

 

PS: For version 1.2 I consider doing a double-double-colon check ... but I didn't want to introduce last-minute changes to the already thoroughly tested build.

  • Like 4
  • Thanks 2

Share this post


Link to post
Share on other sites

Two points:

1 - If I understand this right, in the example above you are adding the subroutine CHAR2 something like this:

10 CALL CHAR2(124,"FF55AA55FF")

10000 SUB CHAR2(X,A$)

10001 CALL LINK("CHAR2",X,A$)

1002 SUBEND

This does what you want, but there is a speed penalty. In this case it takes about 50% more time. You have to decide whether convenience or speed is more important. There is no right answer, but at least here both options are available.

 

2 - If you intend to compile the program, the two subprograms cannot have the same name (CALL LINK("CHAR2") and CALL CHAR2)

You should be OK if they have different names such as CALL LINK("CHAR2") and CALL CHARA2

 

  • Like 1

Share this post


Link to post
Share on other sites

I totally agree that this would be a dumb idea for the two reasons you give. And this is why I implemented it differently. It is part of the conversion from Structured Extended Basic to regular Extended Basic, it has no impact on the runtime, no need to choose speed vs. convenience, just have both.

 

Take a look at the XB256 demo included:

// prepare second screen
call scrn2
call screen2(2)
call color2(81,16,1)
call disply(12,12,"XB256")
call magnify(4)
call char(112,"00003E1108FF8047641820FF000000000000000080F0389C077C80")
call sprite(#1,112,7,60,1,1,8)

// Move around
repeat
  for i=1 to 5  :: call SCRLUP :: next i
  for i=1 to 10 :: call SCRLDN :: next i
  for i=1 to 5  :: call SCRLUP :: next i
  for i=1 to 5  :: call SCRLLF :: next i
  for i=1 to 10 :: call SCRLRT :: next i
  for i=1 to 5  :: call SCRLLF :: next i
  call position(#1,y,x)
until y>100
end                              

It gets translated to XB as:

100 CALL LINK("SCRN2")
110 CALL LINK("SCREEN",2)
120 CALL LINK("COLOR2",81,16,1)
130 CALL LINK("DISPLY",12,12,"XB256")
140 call magnify(4)
150 call char(112,"00003E1108FF8047641820FF000000000000000080F0389C077C80")
160 call sprite(#1,112,7,60,1,1,8)
170 for i=1 to 5  :: CALL LINK("SCRLUP") :: next i
180 for i=1 to 10 :: CALL LINK("SCRLDN") :: next i
190 for i=1 to 5  :: CALL LINK("SCRLUP") :: next i
200 for i=1 to 5  :: CALL LINK("SCRLLF") :: next i
210 for i=1 to 10 :: CALL LINK("SCRLRT") :: next i
220 for i=1 to 5  :: CALL LINK("SCRLLF") :: next i
230 call position(#1,y,x)
240 IF NOT (y>100) THEN 170
250 end

So no overhead with additional SUB routines. In the next step this XB program gets translated to XB token and exported as PROGAM an/or MERGE for direct use in a FIAD to run or compile. This step also fixes the lowercase. I did not want to overload the original posting with those details.

 

I would be honored if you give TiCodEd a try.

 

Steve

  • Like 1

Share this post


Link to post
Share on other sites
On 4/2/2021 at 5:58 AM, SteveB said:

I totally agree that this would be a dumb idea for the two reasons you give. And this is why I implemented it differently. It is part of the conversion from Structured Extended Basic to regular Extended Basic, it has no impact on the runtime, no need to choose speed vs. convenience, just have both.

 

Take a look at the XB256 demo included:

// prepare second screen
call scrn2
call screen2(2)
call color2(81,16,1)
call disply(12,12,"XB256")
call magnify(4)
call char(112,"00003E1108FF8047641820FF000000000000000080F0389C077C80")
call sprite(#1,112,7,60,1,1,8)

// Move around
repeat
  for i=1 to 5  :: call SCRLUP :: next i
  for i=1 to 10 :: call SCRLDN :: next i
  for i=1 to 5  :: call SCRLUP :: next i
  for i=1 to 5  :: call SCRLLF :: next i
  for i=1 to 10 :: call SCRLRT :: next i
  for i=1 to 5  :: call SCRLLF :: next i
  call position(#1,y,x)
until y>100
end                              

 

 

Looking at this code makes me want a non-translating compiler for this language.

 

Share this post


Link to post
Share on other sites
On 4/2/2021 at 5:58 AM, SteveB said:

So no overhead with additional SUB routines. In the next step this XB program gets translated to XB token and exported as PROGAM an/or MERGE for direct use in a FIAD to run or compile. This step also fixes the lowercase. I did not want to overload the original posting with those details.

 

I would be honored if you give TiCodEd a try.

That seems quite reasonable. i was going to suggest getting rid of the CALL so you would program something like CLEAR::HCHAR(1,1,42,32), etc.

But it turns out that CLEAR, HCHAR and all the rest can be used as variables as well!

 

I will give TICodEd a try at some point, but I do virtually no XB programming so it will be a while before I get around to it. Looks interesting!

  • Like 3

Share this post


Link to post
Share on other sites

From the brand new Jewel Beta docs:

Quote

When the compiler encounters any of the XB256 CALL LINK routines, it strips out the LINK and treats it like a CALL. For example, the compiler would treat CALL LINK(“DISPLAY”,1,1,”Hello World”) as if it were CALL DISPLAY(1,1,”Hello World”)

It is so funny for me to see that TiCodEd translates the CALL DISPLY to CALL INIT("DISPLY"...) just for the Compiler to translate it back to CALL DISPLY ... 

  • Like 2

Share this post


Link to post
Share on other sites

FWIW, on your code library example from February, this statement actually executes more quickly than the FOR/NEXT loop:

CALL COLOR(1,fg,bg,2,fg,bg,3,fg,bg,4,fg,bg,5,fg,bg,6,fg,bg,7,fg,bg,8,fg,bg,9,fg,bg,10,fg,bg,11,fg,bg,12,fg,bg,13,fg,bg,14,fg,bg)

While obviously not as pretty and will use up more memory just for the line, execution time is significantly less (twice as fast as the for loop.)

  • Like 3
  • Thanks 1

Share this post


Link to post
Share on other sites
On 2/15/2021 at 10:51 PM, SteveB said:

FOR I=0 to 14 :: CALL COLOR(I,fg,1) :: NEXT I

requires 34 bytes.

On 5/3/2021 at 9:23 PM, OLD CS1 said:

CALL COLOR(1,fg,bg,2,fg,bg,3,fg,bg,4,fg,bg,5,fg,bg,6,fg,bg,7,fg,bg,8,fg,bg,9,fg,bg,10,fg,bg,11,fg,bg,12,fg,bg,13,fg,bg,14,fg,bg)

requires 155 bytes. It is the usual time vs. space optimization. Each and every parameter is an unquoted string with a length byte. As a screen init usually isn't executed very often I've chosen the smaller variant.

On 2/15/2021 at 10:56 PM, RXB said:

CALL COLOR(ALL,fg,1)

Rich is clear winner, RXB only uses 19 bytes and is presumably the fastest, if you do not want to compile using ISABELLA/JEWEL.

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites
Posted (edited)

Potential user!?!?

OK, let meg give you my view of this...
What kind of user am I? I know Basic and Ex. Basic. I have played with Pascal, HTML and I understand in an overview way other ways to program. But I really know Basic and Ex Basic, in a low level way!

Is this interesting? YES!!! For sure yes! - But I will not use it? NO!

Why? Because you're so good at this, that I need to have your level of understanding, to be able to use it. (Don't even get the "GOTO" issue, hehehe)

I constantly refer back to "User's Reference Guide!", and "TI EXTENDED BASIC - FOR THE TI-99 4/A HOME COMPUTER", here I find all I wounder about in a TINY bite size, so that I can understand it. I find some programs to explain difficult stuff. This also why I keep looking at the listings and try to figure out that I need to learn more about.

So if you want me(similar kind of users) as a user, you need to make a "For dummies..." and have even the most stupid stuff explained. This is how it is with RXB (for me) and other great programming langos, for the TI. There is stuff that I do not have the level of understanding to even understand some of the easiest hard stuff. Or I could say it in another way, you are to smart to make the manual! Ironic, but you need someone who is good at structuring the info, so others can learn it. 

So If you want to have as many people as possible to use it... Make a manual that "idiots" like me kinda get it or at lest I can read and reread to get it and start to use your new program. Since I open my mouth I will let you use my simple mind to test if it is understandable for "idiots" like me. If you make the entry step low, you will get more people to use it.

This is also a challenge to makes of other stuff for the TI, use the old TI manuals as a ref to make a good manual. You get more people to at least try out your stuff.

BUT... If you don't... no problem! I am perfectly happy just using Basic and Ex Basic and have fun with that. And sometimes the manuals for Basic and Ex Basic don't help me, then I can ask here. And I am perfectly fine with just that.

But if you want to make it possible for more people to use it, make great documentation. Lol, I think that if someone makes a half decent product but great documentation, it is a bigger chance of people using a half decent program with great documentation, than a great product with half decent documentation. Maybe that is also some of the TI's power, its documentation to the TI is so good that still some 40 years later, I use it. The TI is not the best home computer, but the documentation makes it so that I rather use something I can read up on, and then play with.

I am saying this because I like your thinking, and the program your trying to make!

Edited by oddemann
  • Like 3

Share this post


Link to post
Share on other sites
18 hours ago, SteveB said:

requires 34 bytes.

requires 155 bytes. It is the usual time vs. space optimization. Each and every parameter is an unquoted string with a length byte. As a screen init usually isn't executed very often I've chosen the smaller variant.

Rich is clear winner, RXB only uses 19 bytes and is presumably the fastest, if you do not want to compile using ISABELLA/JEWEL.

RXB also as a feature the really snaps a screen onto the monitor and how it works is you predefine the image screen then use

CALL PLOAD(A,"DSK#.FILENAME") :: CALL MOVES("RV",2079,8192,0) 

This loads that predefined Screen, character definitions, Sprite table, and color table from disk to VDP location of screen.

 

This video at 20:00 shows the SAMS DEMO but even if you do not have a SAMS it still works with just a 32K just not using SAMS:

2020 10 20 10 48 04 - YouTube

  • Like 1

Share this post


Link to post
Share on other sites
19 hours ago, SteveB said:

requires 34 bytes.

requires 155 bytes. It is the usual time vs. space optimization. Each and every parameter is an unquoted string with a length byte. As a screen init usually isn't executed very often I've chosen the smaller variant.

Rich is clear winner, RXB only uses 19 bytes and is presumably the fastest, if you do not want to compile using ISABELLA/JEWEL.

Don't overlook XB 2.8 G.E.M. which can also do CALL COLOR(ALL,FG,BG)

 

From the manual:

CALL COLOR can now define the color of all the character sets from 0 to 31. Although you cannot
change the pattern of the characters below 30 and above 159, by setting the foreground and background
to the same color you can have an 8x8 block of one solid color. There are 15 unused character sets, so
you can have blocks of all 15 colors without sacrificing any of the characters from 30 to 159. These
8x8 blocks can be used for borders and other graphics.
CALL COLOR(ALL,foreground,background) will set all the characters to the selected colors.
These changes to the limit checks makes it possible for XB 2.7 G.E.M. to run TI BASIC programs
using character sets 15 and 16, and usually with a considerable increase in speed.

 

 

  • Like 1

Share this post


Link to post
Share on other sites
On 5/5/2021 at 6:04 PM, oddemann said:

I am saying this because I like your thinking, and the program your trying to make!

Thank you for your open and honest feedback!

 

I must admit, you are right in many ways. Documentation and selling are not my strongest capabilities. I created TiCodEd for my own needs and gladly share it. Currently I do my first "large" Game-Project and found more things that needs improvement. 

 

Yesterday it occured to me that I never even mentioned that you may use TiCodEd just as an Editor for XB without using any of the features TIdBit or SXB added. Just write with line-numbers as before and save to FIAD. For quite some time I was thinking of doing a tutorial video on Youtube. And I have my yellow german "TI Basic/Extended Basic für Anfänger und Fortgeschrittene" also lying beside my keyboard as I need to look up parameters etc. regularely. Because except for the line-numbers and loop-statements, nothing changes. The Version 1.1 has some more demo code included. Perhaps I add a tutorial with the next release.

 

What I can not change is that few persons really do anything in XB anymore. Many do hardware, assembly, Forth, C or Pascal. So we splitt up into even smaller groups. And yet I love to work on TiCodEd and with TiCodEd.

 

Steve

 

  • Like 4

Share this post


Link to post
Share on other sites

I always wanted syntax like CALL COLOR(1..8,foreground,background) since I almost always defined printable text as one color and used sets 9 through 14 (or 16) for graphics.

Share this post


Link to post
Share on other sites
3 hours ago, OLD CS1 said:

I always wanted syntax like CALL COLOR(1..8,foreground,background) since I almost always defined printable text as one color and used sets 9 through 14 (or 16) for graphics.

I have noted a change in RXB as CALL COLOR(&,1,8,foreground,background)

this would be & is the token like ALL or # and 1 is first set and 8 is last set to set to foreground and background.

 

(the period would cause problems with the DSR in that it is reserved for those uses)

  • Like 1

Share this post


Link to post
Share on other sites
On 5/5/2021 at 9:04 AM, oddemann said:

So if you want me(similar kind of users) as a user, you need to make a "For dummies..." and have even the most stupid stuff explained. This is how it is with RXB (for me) and other great programming languages, for the TI. There is stuff that I do not have the level of understanding to even understand some of the easiest hard stuff. Or I could say it in another way, you are to smart to make the manual! Ironic, but you need someone who is good at structuring the info, so others can learn it. 

So If you want to have as many people as possible to use it... Make a manual that "idiots" like me kinda get it or at lest I can read and reread to get it and start to use your new program. Since I open my mouth I will let you use my simple mind to test if it is understandable for "idiots" like me. If you make the entry step low, you will get more people to use it.

I absolutely love this post. Ignore these words at your own peril TI developers. lol. Seriously, this is an important post for the Wizards to read. @oddemann speaks for me!

 

Let me add the following:

 

    Guys, there is a sizable "Shit-Ton" of great stuff I've learned while revisiting my TI since 2016: XB256, some RXB, BASIC Compiler, Magellan, Tipi, 9900 Assembly Language, TidBit, Module Creator, Classic99, SAMS, FinalGROM, Ti99Dir, 9918A VDP, modern editors and various cross assemblers, Telnet on tipi, etc. With the exception of maybe 80% of the Classic99 documentation ( @Tursi earns a B+ here ;) ); at each and every step of the way, I've felt like first asking the expert developers to please play dumb during at least part of our conversations.  

 

   "...you are too smart to make the manual..." - @oddemann    <===== Brilliant!!!

 

Your assumptions and knowledge disqualify you. Just a very important point we shouldn't gloss over.

 

@SteveB I love your project! Once you're finished with Structured Extended BASIC/TiCodEd ... you're not finished! 

 

Grab an average idiot like me and let's talk making a manual for normal people.

 

Cheers!

 

    @oddemann

  • Like 4

Share this post


Link to post
Share on other sites
30 minutes ago, Airshack said:

I absolutely love this post. Ignore these words at your own peril TI developers. lol. Seriously, this is an important post for the Wizards to read. @oddemann speaks for me!

And now you know why we went to extreme lengths to get the information needed to really grok the UberGROM into the manual. Developing that was easily half of the work. Same went for the HRD 4000B. We thought the old manuals were just missing too much necessary information, so we tried to suss out every detail we could and put it into the manuals in a form we hope that people will be able to use, including Doug's new programming guide.

  • Like 4

Share this post


Link to post
Share on other sites

I was trying to put together an "Office Space" reference, with Smykoswki, engineers, people, and the need for technical writers.  But I cannot get off the launch pad, so you guys will have to do the work yourselves.

  • Like 1

Share this post


Link to post
Share on other sites
On 5/21/2021 at 3:04 AM, Airshack said:

@SteveB I love your project! Once you're finished with Structured Extended BASIC/TiCodEd ... you're not finished! 

 

Grab an average idiot like me and let's talk making a manual for normal people.

Hi @Airshack, hi @oddemann and all the XB developers,

 

after attending some TI events I thought I was the only one who has not modified his TI. I only had a tape recorder, XB and the speech synthesizer. Without a peri-box the system wasn't attractive compared to my Atari 800XL with disk drive, which became my primary system in 1985 until I got my first PC in 1989. 

 

But you never forget your first love. 

 

I never found the time to really appreciate the "sizable "Shit-Ton" of great stuff" until Corona hit. A dream came true, it was now possible to program XB games that could compete with at least some of the modules of 1983. 

 

My stuff is really for all the people never went beyond XB on the TI-99, never bothered with GPL and TMS9900 Assembler, or use XB when possible.

 

So if anyone wants to work with me on a step-by-step tutorial, please drop me a line. I would share my document (Google) online. It is true that I spent too much time with it to really know where to pick you up, the other XB programmers in the world. I am willing to do this, but as you pointed out, I can't do it alone. So, @Airshack, can I grab you for this?

 

Steve

Share this post


Link to post
Share on other sites

I will help as much as I can ;) Skills... Good with Paint Shop Pro, good with LibreOffice and I think I have a good esthetic sense (making stuff look good for reading). My front cover is my application :p hehehehe

A starting point, I think in making a manual could be to use the old TI manual as a template. I think that the manuals have a good start and most everything is in there so that you get started. At lest for me.

I made you a "starting point" ;) Also my first use of the TI font I found. For inspiration to the great manual ;) you're making!

TiCodEd.jpg

  • Like 3

Share this post


Link to post
Share on other sites

Hi Steve,

  I'm very enthusiastic about your development environment and have a request.

  I use the char editor a lot and love it.

  I wish the definition would automatically change (16 vs 64 char) - when you change the size of the sprites.

Thanks

Share this post


Link to post
Share on other sites
2 hours ago, dhe said:

Hi Steve,

  I'm very enthusiastic about your development environment and have a request.

  I use the char editor a lot and love it.

  I wish the definition would automatically change (16 vs 64 char) - when you change the size of the sprites.

Thanks

Hi, will be included in the next release. The first 16 char remain unchanged, but the 48 following will be set to 0 or deleted. This means accidently pressing the radio button deletes 3/4 of your work. Is this acceptable?

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.
Note: Your post will require moderator approval before it will be visible.

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

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...