Ultimate Extended Basic

[GDMike]

13 hours ago, Vorticon said:

Well XB is as simple to learn as you can get. It's already familiar to most TI users and it is quite a capable XB even without extensions, with it's major shortcoming being very slow execution speed, something Senior Falcon remedied with his XB compiler. We have over the recent years seen a renaissance of sorts with new XB programs coming out of the woodwork on almost a monthly basis, most compiled for speed and I highly doubt you are going to have a run of users trying to learn a new programming language on the TI no matter how good the specs are (think FbForth and TurboForth for example) because familiarity is comforting for many. It takes a concerted effort to learn a new language, and even longer to become proficient at it, and since the vast majority here already have years, if not decades, of experience with XB, it would be hard to put it down and go with something else. Take me for example: I know assembly, Forth and Pascal on the TI and have produced programs in all 3 languages, but nonetheless the majority of my projects remain in XB (or RXB) because it is comforting and so easy to work with, and I bet that feeling is shared by many users as well.

Therefore, what retroclouds is trying to do actually makes a lot more sense than coming up with an entirely new language. Don't get me wrong, your wish list is very appealing, but as you said, pie in the sky...

See, this is my situation. I want a program that has good documentation, at least supported by more than two people, and can do some work with little learning curve. I found that in Turboforth. Then I came across a bump in the road, it occupies the cart port. Then Lee reminded me that TI forth freed up that port. And in like, yeah, but the reason for choosing TF in the first place was it already had new and powerful words, like FB does and camel does, but I had already spent a good 6 months learning TF practically on my own, (utube videos, asking questions on the forum),  AND I still have more to learn  its a total dedication to learn one of these, especially when youre mind,(and maybe this is the real reason), isn't as snappy as it used to be. And no offense, it's always easier to say, hey learn this it'll solve your problem, then it doesn't. A lot of why the languages are scarce is because the memory of the machine is low and, even though great things can be written in forth, without the SAMs 1mb card, I would not even attempt writing at all, but RXB, TF, FB forth are becoming stronger as we dip into that SAMs card. I was shocked at what I was able to write in TF with the SAMs card being available. But now that SAMs is out, we need libraries that take advantage of that space. Then any of those languages get easier to use.

[globeron]

I am reading up on MSX-1 (and MSX-2) I have a Philips VG8020 (MSX-1) and in the emulators all the versions of MSX.

in the past I converted some simple graphics programs (like lines, etc.) to the TI in the "Gee" program.

 

but my question is which Extended Basic version comes closest to MSX Basic

(e.g. to go to a graphics mode  to draw lines) and to re-write MSX Basic programs on a TI?

(trying my kid to learn some BASIC)

 

* Mechatronic Extended Basic II Plus (with ApeSoft) ?

 

*   I found this link to load routines in XB  (and with CALL FILES(9))

   * https://atariage.com/forums/topic/213848-apesoft-expanded-basic-routines/?do=findComment&comment=3078637   * https://atariage.com/forums/topic/213848-apesoft-expanded-basic-routines/?do=findComment&comment=3079190

 

 

 

 

 

* or The Missing Link ?  (I think I have the disks)

   Is this XB TML ?  

 

 

* or other XB versions?

   (XB256, RichXB, SuperXB, (others ?)

 

* would it be possible to port MSX-1 Basic or MSX-2 Basic to a TI-99/4a environment

   (without or with added hardware like F18A ?)

 

 

 

 

 

 

 

 

Edited October 15, 2020 by globeron

[senior_falcon]

XB 2.8 G.E.M. has The Missing Link for bit mapped graphics, T40XB for 40 column test mode, T80XB for 80 column text mode, and XB256 all built in.

 

Apesoft can do bit mapped graphics and the Apesoft demo is spectacular. But it turns out the XB version is much more limited.

Edited October 15, 2020 by senior_falcon

[Omega-TI]

I apologize if I overlooked it, but is there a manual for XB 2.8 GEM?

 

Never mind, I found the manual in the new copy that was updated << HERE >>

Edited October 16, 2020 by Omega-TI
Updated

[RXB]

 Now that RXB 2020 has CALL VDPSTACK(VDP address) and  CALL PRAM(start XB RAM address, end XB RAM address)

along with CALL SAMS(4K RAM address boundary,4K RAM page)

it will be possible to load Classic99 SAMS 32meg with insane number of XB programs and assembly support also.

Look instead of a chain of RUN "DSK#.programfile" instead set up VDP, RAM location with PRAM then run that XB program and SAMS assembly support in one shot multiple times.

 

Not to take away from XB256 speed up of XB programs, but really you can only load one at each time and this would be much less complicated to use.

(It would be great news if XB256 had a RXB version.)

One RXB USER file can run 800 XB programs one after the other and even load more into 32meg of SAMS (yea I know Classic99 required for this one.)

 

But I digress the point is now instead of daisy chain of XB programs running each one just load ALL OF THEM AT ONCE and pick one from RAM.

32 Meg is huge considering that was the standard size of the largest SCSI drive the TI could use at that time and format. (I could be mistaken.)

[oddemann]

For me... #1 over ALL... Call Char(32...some insane number) This limitation is HUGE on the normal TI! If I could make all kinds of graphic stuff, I think games could be drawn so so much better!

              #2 Sprites, would love more then 29... maybe 4 times more. Then you can use 4 Sprites on top of one and other to make cool animation. Animations with in animation it self.

              #3 80 col., IF it makes the resolution go from 256 to 512.

              #4 Compiler!

 

              #5 More colors, if there is a limitation.... what about a option for 15 gray tones!

Edited October 15, 2020 by oddemann

[RXB]

11 minutes ago, oddemann said:

For me... #1 over ALL... Call Char(32...some insane number) This limitation is HUGE on the normal TI! If I could make all kinds of graphic stuff, I think games could be drawn so so much better!

              #2 Sprites, would love more then 29... maybe 4 times more. Then you can use 4 Sprites on top of one and other to make cool animation. Animations with in animation it self.

              #3 80 col., IF it makes the resolution go from 256 to 512.

              #4 Compiler!

 

              #5 More colors, if there is a limitation.... what about a option for 15 gray tones!

All of these are HARDWARE problems.

[oddemann]

Just now, RXB said:

All of these are HARDWARE problems.

[senior_falcon]

4 hours ago, Omega-TI said:

I apologize if I overlooked it, but is there a manual for XB 2.8 GEM?

Of course! It is included with the docs.

[senior_falcon]

3 hours ago, RXB said:

Not to take away from XB256 speed up of XB programs, but really you can only load one at each time and this would be much less complicated to use.

(It would be great news if XB256 had a RXB version.)

One RXB USER file can run 800 XB programs one after the other and even load more into 32meg of SAMS (yea I know Classic99 required for this one.)

 

But I digress the point is now instead of daisy chain of XB programs running each one just load ALL OF THEM AT ONCE and pick one from RAM.

32 Meg is huge considering that was the standard size of the largest SCSI drive the TI could use at that time and format. (I could be mistaken.)

First of all, and as mentioned many times, XB256 does not speed up XB programs. It makes some major additions to graphics: 256 characters (maybe that's why it is called XB256?) plus 28 sprites vs 112 characters; less if you use sprites. XB256 provides many other enhancements such as pixel scrolling, etc. etc. You can compile a program written using XB256 for a 20-30x speed increase but that is optional.

 

One of my design considerations has always been to write programs that will run on the "standard" system available in 1983 - console, XB, 32K and disk system. XB 2.8 G.E.M. violates that rule, but I thought the enhancements were worth it. There are versions of all the graphics utilities that can be run from a standard system.

 

What is more important? XB 2.8 G.E.M. offers bit mapped graphics, 40 column text mode, 80 column text mode, XB256 with all 256 characters, etc. RXB offers easy access to SAMS but is saddled with the limitations of XB graphics. This question can only be answered by the individual user. (For what it's worth, XB 2.8 G.E.M. has about 10K of grom free which could be used for SAMS access or other enhancements.)

[Omega-TI]

2 hours ago, senior_falcon said:

Of course! It is included with the docs.

Thanks.  I located it in the version you just uploaded.  I also added it to the GROM section of the Repository.

[globeron]

17 hours ago, senior_falcon said:

XB 2.8 G.E.M. has The Missing Link for bit mapped graphics, T40XB for 40 column test mode, T80XB for 80 column text mode, and XB256 all built in.

 

Apesoft can do bit mapped graphics and the Apesoft demo is spectacular. But it turns out the XB version is much more limited.

 

@senior_falcon @Omega-TI thank you, I never heard of it before!  Will try it out!

[oddemann]

Why not open Ex B so that it has the power of a modern PC. Would one be able to make great games with much less memory?

If one cant open Ex B to be used on a modern PC, why?

In my mind it is easy hehehehehe But I can not do it! Some 30 years ago I was doing Pascal and the "grownups" got pissed at me. I would say... "Ohh that's easy!" They would counter with. "NOOO it is not!" Had been programming for 3-4 years on the TI. So converting into Pascal was not that hard. Then I got tools to draw on the computer! And I left programming. With the Amiga I had so much fun in Digital Paint. Then Paint Shop Pro. Also I make my own web page. HTML was easy when I had learned Basic.

I am starting up my programming on the TI, and hoping to be able to use some of my art on it. But... getting back into it... Ohhh he.. it is so limited :p But how I love that computer!

Been testing Scratch... and maybe that is the way to go to have some fun and easily add my art.
 

Edited October 16, 2020 by oddemann

[Ed in SoDak]

On 12/31/2019 at 11:25 AM, majestyx said:

More DOS-like functions, as I'm constantly having to refer to the Reference Guide and Disk Memory manuals to figure out how to do stuff that was a breeze in Apple's DOS 3.3/ProDOS & MS-DOS. Unless I'm mistaken, there isn't even a TYPE command that allows you to view the data in a text file on the screen, such as with other DOSes.

If your XB program has the space, you can add some DOS-like functions with CALL SUB.

 

My thoughts when I was programming a lot was why exit my program just to do some simple file-related task. I took my favorite XB LOAD program and tuned it into a SUB. The one I chose has a disk directory with options to delete a file, load a program or view/print a text-type file.

 

I added CALL CLEAR :: CALL DIR(KOR): as a menu option which then ran the SUBprogram XB LOAD. My SXB cart has a CALL CAT as a command, but that doesn't support file viewing. I used DIR for my subprogram name to avoid conflicts with CAT. KOR is the variable name I used for the character number of the last key pressed to avoid conflict with the variable K that's typically used in many XB programs. I have another small program called FILEREAD that could be added in the same way and I used that in another program I wrote along with XB LOAD.

 

For the example I show below, the only listing I happen to have handy is just a disk catalog, but the same process would work to add any small XB utility program you like to any other XB program. As long as there's enough memory for it to fit.

 

To use it as a CALL SUB, I just renumbered the original XB utility to put it at the end of the main program and changed anything like variables, screen colors, etc. that might interfere with the main program.

 

Spoiler

9450 SUB DIR(KOR)! catalog
9500 ON ERROR 11050 :: CALL CLEAR
9550 DIM TYPE$(5)
9600 TYPE$(1)="DIS/FIX"
9650 TYPE$(2)="DIS/VAR"
9700 TYPE$(3)="INT/FIX"
9750 TYPE$(4)="INT/VAR"
9800 TYPE$(5)="PROGRAM"
9850 DISPLAY AT(22,1):"Disk (1-3)? 4-Return ":"Any Key-Pause / Space-Resume" ::
CALL KEY(3,A,WOW):: IF WOW=0 THEN 9850 :: A=A-48
9900 IF A=0 OR A=-35 THEN SUBEXIT
9950 IF A=4 THEN SUBEXIT
10000 IF A<1 OR A>3 THEN 9850
10050 OPEN #1:"DSK"&STR$(A)&".",INPUT ,RELATIVE,INTERNAL
10100 INPUT #1:A$,J,J,K
10150 DISPLAY "DSK";STR$(A);"-DISKNAME= ";A$:"AVAILABLE= ";K;"USED= ";J-K
10200 DISPLAY :" FILENAME  SIZE  TYPE      P":"---------- ---- ---------- -";
10250 FOR LOOP=1 TO 127
10300 INPUT #1:A$,A,J,K
10350 IF LEN(A$)=0 THEN 10750
10400 DISPLAY :A$;TAB(12);J;TAB(17);TYPE$(ABS(A));
10410 CALL KEY(3,KOR,WOW):: IF WOW=0 THEN 10450 ELSE 10420
10420 CALL KEY(3,KOR,WOW):: IF KOR=32 THEN 10450 ELSE 10420
10450 IF ABS(A)=5 THEN 10600
10500 B$=" "&STR$(K)
10550 DISPLAY SEG$(B$,LEN(B$)-2,3);
10600 IF A>0 THEN 10700
10650 DISPLAY TAB(28);"Y";
10700 NEXT LOOP
10750 CLOSE #1
10800 PRINT : :" Dir / Enter"
10850 CALL KEY(3,KOR,WOW):: IF WOW=0 THEN 10850
10900 IF KOR=68 THEN DISPLAY AT(23,0):"" :: GOTO 9850
10950 IF KOR=13 THEN SUBEXIT
10960 GOTO 10850
11000 SUBEXIT
11050 CALL ERR(AW,BW,CW,DW):: CALL CLEAR :: A=1 :: PRINT "Disk Error, re-running
" :: RUN
11100 SUBEND

 

Save your add-on as a MERGE file and insert it into whatever program you like, space permitting. The just add the menu choice and the CALL DIR(KOR)

 

This all might be getting away from designing the Ultimate XB, but it describes a way to add a little extra power to our old and comfortable version of it. The downside is it's only useful in a running program and it robs some memory space. Usually there's not that many programs out there which use ALL of XB's memory space. That's why I figured why not add a little icing to my own programs and use some of that idle RAM.

Edited October 17, 2020 by Ed in SoDak

[Omega-TI]

One command I'd like to see in all updated Extended 

BASICs would be "DOS" which would exit BASIC and go straight to Force Command.

[senior_falcon]

 

 

For me... #1 over ALL... Call Char(32...some insane number) This limitation is HUGE on the normal TI! If I could make all kinds of graphic stuff, I think games could be drawn so so much better!

               256 characters can be defined in XB256. That's not an insane number, but it is more than twice as many as the 112 available in XB

              #2 Sprites, would love more then 29... maybe 4 times more. Then you can use 4 Sprites on top of one and other to make cool animation. Animations with in animation it self.

              Only 28 sprites are available in XB256 but they use different patterns than the 256 regular characters. You can define up to 28 double size sprites or 112 small size sprites,                      and still have all 256 regular characters defined. The 4 sprites on a line limit is inherent to the 9918A VDP.  

              #3 80 col., IF it makes the resolution go from 256 to 512.

              T80XB provides 80 column text utilities. If you have a real TI then you need a hardware upgrade such as the F18A. Classic99 runs T80XB just fine.

              #4 Compiler!

              Part of the XB Game Developer's Package.

 

              XB256, T40XB, T80XB, The Missing Link (bit mapped graphics), TML Graphic Adventure are all part of the XB 2.8 G.E.M. cartridge.

 

 

 

[RXB]

On 10/15/2020 at 6:48 PM, senior_falcon said:

First of all, and as mentioned many times, XB256 does not speed up XB programs. It makes some major additions to graphics: 256 characters (maybe that's why it is called XB256?) plus 28 sprites vs 112 characters; less if you use sprites. XB256 provides many other enhancements such as pixel scrolling, etc. etc. You can compile a program written using XB256 for a 20-30x speed increase but that is optional.

 

One of my design considerations has always been to write programs that will run on the "standard" system available in 1983 - console, XB, 32K and disk system. XB 2.8 G.E.M. violates that rule, but I thought the enhancements were worth it. There are versions of all the graphics utilities that can be run from a standard system.

 

What is more important? XB 2.8 G.E.M. offers bit mapped graphics, 40 column text mode, 80 column text mode, XB256 with all 256 characters, etc. RXB offers easy access to SAMS but is saddled with the limitations of XB graphics. This question can only be answered by the individual user. (For what it's worth, XB 2.8 G.E.M. has about 10K of grom free which could be used for SAMS access or other enhancements.)

The idea of RXB was using SAMS and Assembly as a combo.

XB alone sucks at access to SAMS and RXB fixed that.

Thus why I keep saying make XB256 for RXB and you get best of both.

By the way RXB SAMS access total size is 242 BYTES of GROM, loads in any 32K location and has a built in Program Image loader/saver.

[senior_falcon]

4 hours ago, RXB said:

Thus why I keep saying make XB256 for RXB and you get best of both.

 

You realize that XB256 works fine with RXB?

[RXB]

3 hours ago, senior_falcon said:

You realize that XB256 works fine with RXB?

Not what I said.

XB256 is like you said optimized for ONLY XB. 

RXB commands like CALL HPUT(row,col,variable or string or number) is better then DISPLY AT or PRINT restricted to 28 per line.

RXB commands like CALL GMOTION(#sprite,dot-row variable,dot-col variable) great for fetching movement of where JOYSTICK's moves a Sprite.

These could be updated for XB256 specifically for RXB, not likely but they would be great features to use.

[senior_falcon]

You have me stumped. "Thus why I keep saying make XB256 for RXB and you get best of both." XB256 already works fine with RXB.

You say you want "RXB commands like CALL HPUT(row,col,variable or string or number) is better then DISPLY AT or PRINT restricted to 28 per line." Nothing stops you from using those commands.

[1980gamer]

I do find some of the RXB command interesting.

However, I am so hooked on compilation, it is hard for me to embrace it.

 

I have been using the compiler for years.  I knew XB from the 80's so it was an easy thing to embrace.

And TRULY brought me back to the TI.  My first computer .  So many of the things that just didn't work because of execution speed were solved.

 

So, are you saying to add some of the RXB command to the compiler compatibility? ( I'd love this, but seems unlikely )

 

I know XB256 and the compiled XB are also different things.  I am trying to figure out the last few posts.

 

My RXB knowledge is limited.  I think many of the commands are optimized as well as many cool additional commands added.  

Do you want the commands added to XB256? 

 

That would also be cool.  But then I think they would need to be rewritten?  RXB is all in GPL correct?  Or is some of it assembly?

OR could they be linked/called even if they are GPL? and if so... can I still compile if I include these commands?

 

I have a few vacation days to use up in the next 2 months... and it is GEM time!

[1980gamer]

Ah, I also love being able to test without having to compile.

So,  even if some RXB commands were added to the compiler compatibility list, I think it would still be problematic.  It would be a NEW compiler for RXB.

 

But what do I know?  You guys are SO beyond my knowledge.  I can handle the 40 or so commands in XB.  ( well most of them... to some degree )

 

[RXB]

2 hours ago, 1980gamer said:

I do find some of the RXB command interesting.

However, I am so hooked on compilation, it is hard for me to embrace it.

 

I have been using the compiler for years.  I knew XB from the 80's so it was an easy thing to embrace.

And TRULY brought me back to the TI.  My first computer .  So many of the things that just didn't work because of execution speed were solved.

 

So, are you saying to add some of the RXB command to the compiler compatibility? ( I'd love this, but seems unlikely )

 

I know XB256 and the compiled XB are also different things.  I am trying to figure out the last few posts.

 

My RXB knowledge is limited.  I think many of the commands are optimized as well as many cool additional commands added.  

Do you want the commands added to XB256? 

 

That would also be cool.  But then I think they would need to be rewritten?  RXB is all in GPL correct?  Or is some of it assembly?

OR could they be linked/called even if they are GPL? and if so... can I still compile if I include these commands?

 

I have a few vacation days to use up in the next 2 months... and it is GEM time!

RXB came out with version 1001 in 1988. It is the oldest XB still supported today hands down.

RXB works from just a console alone or with 32K or SAMS up to 32Meg.

Almost all the new XB Carts out today will not do much of anything without 32K, RXB like XB can function without a 32K or SAMS.

Lastly almost all TI Basic programs will run in RXB unlike any other XB carts made with 32K or not. No other XB made can do that.

XB GEM is a great product but Ultimate Extended Basic is a matter of taste more then just Speed, run it from a Console to see differences.

30 years into a RXB can show quality of work I think.

[senior_falcon]

6 hours ago, RXB said:

Lastly almost all TI Basic programs will run in RXB unlike any other XB carts made with 32K or not. No other XB made can do that.

Thank you for the kind words about GEM. Although a few of the enhancements will work without 32K, what you say about GEM needing 32K is generally correct.

However, the above statement is incorrect. Both GEMs can run BASIC programs same as RXB.

[1980gamer]

No doubt RXB is excellent. I am impressed with the dedication.

 

If I was using a TI in 1988, I would have loved it.  I didn't start using a TI ( actually via emulation ) until I 2006 or 7.  And I quickly put it down.

I want to play parsec and moon patrol.  Paresec didn't really work well and the speech was awful.  Moon Patrol was pretty good but slow.

I think I was using V9T9 back then.    I got a much faster PC and Moon Patrol was near perfect... based on memory of 1983-4.

 

I didn't think about doing anything else with the TI at that time.   Several years later and new laptops later... I thought about trying Parsec again.

I couldn't get V9T9 to run.  Then I started digging through the forums here.  Up to this point, I was 99% intellivision while on this site.

I tried WIN99 I think? and that worked pretty well.  Still Parsec didn't really play the same and I couldn't get Moon Patrol to work at all.

But It was easy to expand the TI!  I had only The Console, XB and Cassette as a kid.  Always wanted PE BOX

I started toying in XB again and ran into the same old issues.. Sprite collision issues and general speed problems.

Then I read about Puck Man?  I think?  I tried it was was impressed with the speed.  This is TI Basic? WOW!

 

I tried to play around with the compiler and had some issues.  I just could not get things to work.

 

So many people helped me.  It was great!  But along the way, they were all talking about Classic99.

Another game changer.  I can test in overdrive. I can edit in notepad and paste it in.  Compile in Overdrive!!

 

I was now back into doing what I always wanted to do as a kid.  Make a playable game for my first computer.

 

Around this same time I looked at RXB, you had some cool demos that ran pretty fast.

But I was already setup... I had my process in place.  I hoped RXB would be compatible with the compilation process, but it just wasn't.

 

Then XB256 came along and things just keep getting better.

 

Like I said, RXB would have been awesome if I wasn't using the C64 and PC's by that time.