Ultimate Extended Basic

[+retroclouds]

So I've been thinking about extended basic lately and that it is the go-to language on the TI-99/4A.

 

We've seen multiple extensions to Extended Basic, like for example Gram Kracker Utility 1 which probably generated one of the first enhanced Extended Basic versions.

We also have Rich Extended Basic and now Extended Basic G.E.M. 

Also don't forget the work on SDD99 that is enhancing Basic in multiple ways.

 

Just for fun, and who knows what happens next in the future, I'd like to collect ideas on how an Ultimate Extended Basic should look like. What the benefits are, etc.

 

I'll kick it off with following proposals:

• Compatible with existing Extended Basic
• Fully runs from cartridge space so that we get as much program space use out of 32KB memory expansion as possible
• Built-in support for SAMS
• Full-screen editor or advanced line editor as  seen in MSX Basic
• Built-in assembler integrated in Extended Basic, so that you can mix assembly source code right with your extended basic program code.
  Something along the lines of: http://www.peter-cockerell.net/aalp/html/ch-4.html
• Full 80 columns support, both for basic program code and line editor.

[+retroclouds]

This thread could/should possible be moved the the TI-99/4a development subforum, but I'd like to get as many ideas as possible and as there's no current development I'd prefer if it can stay here. 

[+OLD CS1]

I need to ask @Albert for move permissions to be restored since the upgrade.

 

With the assembly options, I was thinking about some extension to compiling but then struck that down as not being very innovative for a language but more for a utility.

 

Not trying to poke the bear, but how much functionality already exists in RXB?  Also, would we consider dropping XB's GPL legacy?

[1980gamer]

I have looked at RXB and really like some of the features that have been added.

However, for me, It must generate code I can compile.  It has change the game completely for me.

I do not know assembly, at my age, I try to learn enough new stuff to keep my tech job!

XB is a comfort zone for me.  With the compiler and extensions that can be linked and complied.  It makes TI XB a viable language.

 

Adding and improving is always a great thing.  It just may not be MY thing? If I can compile.  I am ALL for it!

I mostly edit in notepad these days.  But a full editor would be nice.

80 Columns, I take it we are enhancing the TI to do this.  I mostly use Classic99 these days.  If it is supported, great!

 

I read with interest about things like converting WAV to Speech tools.  I am waiting to see what happens!  Again, If I cannot compile it, I may play with it a little, but never really use it.

 

I am SO impressed with what the community has done.  Some incredible ( for lake of a better wording ) Home Brew Games.  These are better than the commercial stuff from BITD.

Graphic Tools, Emulators, Compilers, hardware etc.

 

I learned Basic on my TI99/4A and will always love this little computer!  I will always keep track of what goes on with it!

 

 

[+retroclouds]

3 minutes ago, OLD CS1 said:

I need to ask @Albert for move permissions to be restored since the upgrade.

 

With the assembly options, I was thinking about some extension to compiling but then struck that down as not being very innovative for a language but more for a utility.

 

Not trying to poke the bear, but how much functionality already exists in RXB?  Also, would we consider dropping XB's GPL legacy?

 

Good question regarding RXB and am totally open to what's already available there.

 

Dropping XB's GPL legacy is something that should be seriously considered IMHO. 
Would give execution speed a higher weight compared to GPL code density, at least with todays options such as final GROM.
I've been giving MSX basic a try lately and was very impressed with it's execution speed.

[1980gamer]

3 minutes ago, retroclouds said:

I've been giving MSX basic a try lately and was very impressed with it's execution speed.

Are you doing this via emulation or hardware?  I remember wanting to get one of these about 10-15 years ago, after reading about them.

5 minutes ago, retroclouds said:

Dropping XB's GPL legacy is something that should be seriously considered IMHO. 

I don't know anything about GPL, beyond that it is the language many TI apps are written.

Are you leaving the syntax of XB the same, but changing how it is interpreted?

If the speed increase nears complied XB, I am certainly interested.

OR is this something that would need it own compiler?

 

I will follow the development, if I ever use it or not.  It is TI related and thus I am interested.

[+retroclouds]

12 minutes ago, 1980gamer said:

Are you doing this via emulation or hardware?  I remember wanting to get one of these about 10-15 years ago, after reading about them.

I don't know anything about GPL, beyond that it is the language many TI apps are written.

Are you leaving the syntax of XB the same, but changing how it is interpreted?

If the speed increase nears complied XB, I am certainly interested.

OR is this something that would need it own compiler?

 

I will follow the development, if I ever use it or not.  It is TI related and thus I am interested.

 

1. Tried MSX Basic on the real thing. I recently bought a Sony Hit-Bit MSX1 computer. Really pleased with it.

2. I think for Ultimate Extended Basic ever to be useful it should be compatible with Extended Basic so that you can run existing programs. 

3. Very much like the idea on the compiler 

 

I'm not saying I'm starting development on a new Extended Basic. This is a thread to collect as many ideas as possible and perhaps work out a design specification document.

With the ideas collected and a specification document in place, thins could be implemented in such a way that it's a lot more easy to include features such as built-in compilation.

Also see this as a team effort, tackling such a project means years and years of work for a single person. I'm sure @RXB or @senior_falcon can chime in on how much work it is to tackle such project. 

 

But with multiple people working together I think things can get accomplished (e.g. my TiVi full-screen editor could be a little piece in the puzzle. I'm designing it in such a way that it will be possible to edit TI Basic / Extended Basic source code with it).

 

 

[1980gamer]

I am going to check out the Sony Hit-Bit MSX1 computer.

TiVi made me LOL.  Then I said to myself...  TiViM

 

[Airshack]

1 hour ago, retroclouds said:

 

Good question regarding RXB and am totally open to what's already available there.

 

Dropping XB's GPL legacy is something that should be seriously considered IMHO. 
Would give execution speed a higher weight compared to GPL code density, at least with todays options such as final GROM.
I've been giving MSX basic a try lately and was very impressed with it's execution speed.

Speed, Speed, and speed. These are my top three XB wishes.

[+chue]

Someone around here has the source for Myarc XB, I believe.  I thought it was somewhat backwards compatible, and also written in assembly. 

 

I don't know if it would be a good starting point, but maybe worth a look.

[+Vorticon]

For me you already hit on my top priorities for XB:

- Full screen editor in 80 col. 

- SAMS support with the user shielded from the 4K blocks limitation

- Integrated assembler for in-line assembly. This is huge as it will help mitigate some of XB's slow execution.

 

I would add a feature like CALL IO in RXB which is incredibly powerful for low-level hardware access. 

 

The amount of work this would entail is phenomenal, so I will not be holding my breath any time soon  But there is nothing wrong with dreaming!

[Omega-TI]

4 hours ago, Vorticon said:

For me you already hit on my top priorities for XB:

- Full screen editor in 80 col. 

- SAMS support with the user shielded from the 4K blocks limitation

Well, since we are dreaming... ?

I'm with Vorticon, 80 columns when typing in a program!  For compatibility with existing software I understand it would have to go into normal mode upon execution of a program... unless some new commands were added, which would probably take a freaking ton of effort.  Sadly those with standard machines would not get to experience the joy of 80 columns, but man that would be the bomb!  Also with the new F18Mk2 'sometime' in our future, there could be even more potential users.

 

Yes!  Transparent SAM support for sure.  The community has not really exploited that gadget well enough yet, and there are a fair number of them in circulation too.  I don't know how it could be accomplished, but it would be so awesome to type SIZE and get at least 195,904 in program space with the rest for stack or whatever.

 

And yes, or course, anything that could speed up program execution..

[+InsaneMultitasker]

The Geneve's BASIC allows editing in any of the supported video modes, i.e., 32, 40, 80 columns.  Viewing and editing XB programs with multiple statements and separators can be tiring when panning across the full 80 columns, and I  often find myself reverting to 40 or 32 column mode so that I can 'see' the program more clearly. 

 

What about integrating something like Matthew's TidBit into the basic environment?

[+retroclouds]

Thank you for the replies so far. So it seems that 80 columns, execution speed (and compilation), as well as SAMS support would be crucial.

Do concur that looking at extended basic source code in 80 columns can be tiring. Perhaps something along the lines of TidBit could be a solution there.

 

What about graphic commands and utility functions? I think it would make sense to look at the work senior_falcon and RXB have done so far?

 

As far as execution speed is concerned, could imagine having a mode where you can opt for running with integer variables instead of FP?

How would you control these modes? Perhaps the first line in the program could be a "HINT" line to tell the interpreter/compiler how to deal with the program.

 

[+Vorticon]

I am assuming by 80 columns we will be using the F18A correct? Otherwise I agree that it would be very cumbersome to use horizontal scrolling.

As for graphics commands, it would be nice to have access to the bitmap screen since setting it up from XB can be tricky, along with basic hires plotting commands (pixel, box, circle, line).

The thing is, RXB and XB GEM already have most of the requested features except for 80 column and full screen editing. What we lack is a single completely integrated XB product with most of their important features incorporated. A tall order.

[Omega-TI]

I dunno, I prefer 80 columns, because it would also match the printout.  Finding bugs can be a pain, so I use printouts, and also make annotations on them.  Going back and forth between an 80 column print out and 40 column wrapped around text is a bit tedious.  Even if it does nothing else, 80 columns using current TI programming conventions would make this my one and only BASIC environment.

 

Now the ability to compile anything into an E/A 5 or better yet.... a cartridge BIN image would be the ULTIMATE!  I can imagine pressing a function key, and everything in active memory automatically being compiled and saved.  With a FinalGROM, F18A/F18A Mk2, and the SAMS I believe this could all be possible, but man, this would be a gargantuan task possibly taking 2, 3, 4 or even 5 years to complete.

 

In the end, some sort of 'lock in' of features and expectations will be necessary to avoid feature creep that historically leads to vaporware.

[+InsaneMultitasker]

Don't get me wrong; 80 columns is great. And thanks to Michael's efforts you have the option of experimenting with it using Geneve emulation.  Source code for the Geneve BASIC is available if anyone wishes to inspect the code for use in future endeavors. 

[RXB]

17 hours ago, Vorticon said:

For me you already hit on my top priorities for XB:

- Full screen editor in 80 col. 

- SAMS support with the user shielded from the 4K blocks limitation

- Integrated assembler for in-line assembly. This is huge as it will help mitigate some of XB's slow execution.

 

I would add a feature like CALL IO in RXB which is incredibly powerful for low-level hardware access. 

 

The amount of work this would entail is phenomenal, so I will not be holding my breath any time soon  But there is nothing wrong with dreaming!

CALL IO is a GPL command built into GPL, I just added access to it from RXB. 

[majestyx]

For 80 columns, I am guessing that would indeed mean an F18A chip. Since it's not fully implemented in Classic99 and the implications with numerous commands such as DISPLAY AT, ACCEPT AT, CALL V/H/GCHAR, TAB() with PRINT - I'm not sure how viable that addition would be unless enhancements were made to all of those command or new ones were introduced. I'm just wondering how compatible that would keep it with original XB. My guess is Rich and Harry would be the ones who could explain further what all would be involved.

 

Definitely agree that the speed factor needs to be addressed.

 

Would LOVE easily implemented SAMS support (especially if there's a way to break the barrier of what's available for program space, or a way to store variable data in it), since I'm at a stand-still with my Baseball simulation without being able to utilize it in any useful way. Plus I don't want to program for diskette-based record keeping, which even in emulation is slow, when it may be possible to do it all in expanded memory. It's cool that the TI is able to HAVE up to 4 MB of memory (with 1 MB currently being a reality). But if you're still limited to the ~24K program size, or can't use it to easily store program data/arrays/variables, who cares? Plus, as far as I've seen, there's not one "killer app" or game that is a must-have/must play that uses the SAMS.

 

A REAL way to chain programs that retain variable values between them would be excellent if the amount of memory dedicated to program storage is still limited. The claim on the XB manual cover is very misleading when it claims you can make a program of nearly unlimited size by chaining pieces together. Again, useless when you can't retain values of variables between the pieces.

 

Easy access to 40-column text mode without the issues of crashing the system would be higher on my list than 80-column support, but again, it would likely need changes to the commands I've listed re: 80-column mode.

 

Full screen editor would be cool too, but I'm kinda used to the TI's FCTN keys and do most of my coding in notepad, then paste into Classic99.

 

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.

 

Those are the things I can think of for now.

[+adamantyr]

29 minutes ago, majestyx said:

Would LOVE easily implemented SAMS support (especially if there's a way to break the barrier of what's available for program space, or a way to store variable data in it), since I'm at a stand-still with my Baseball simulation without being able to utilize it in any useful way. Plus I don't want to program for diskette-based record keeping, which even in emulation is slow, when it may be possible to do it all in expanded memory. It's cool that the TI is able to HAVE up to 4 MB of memory (with 1 MB currently being a reality). But if you're still limited to the ~24K program size, or can't use it to easily store program data/arrays/variables, who cares? Plus, as far as I've seen, there's not one "killer app" or game that is a must-have/must play that uses the SAMS.

Ahem... See my upcoming CRPG.

 

As for SAMS in an Extended BASIC environment, the real challenge is to create the memory architecture. Paged memory requires you to think in a more modular way at the assembly level, so masking that from view or consideration in XB is a major chunk of work.

[+Vorticon]

2 hours ago, majestyx said:

A REAL way to chain programs that retain variable values between them would be excellent if the amount of memory dedicated to program storage is still limited. The claim on the XB manual cover is very misleading when it claims you can make a program of nearly unlimited size by chaining pieces together. Again, useless when you can't retain values of variables between the pieces.

 

Chaining is easily done in XB by simply saving the needed shared variables to disk then reading them back. The screen and character definitions are all preserved automatically. Both Stratego and Close Action used chaining (Close Action has 4 chained programs!). Granted this process does slow things down a little when switching from one program to the other, but it's tolerable. So yes, in a sense you can have programs of unlimited size in XB, just as the manual states! ?

[jrhodes]

The c64 spoiled me. Having the c64 fullscreen BASIC editor on a XB version is all i want to see in new xb.

[LASooner]

Since we're just in full "Pie in the Sky" mode, I'd like some functions for flipping and rotating sprites. Better sprite to sprite and sprite to background collision. 

[Omega-TI]

7 minutes ago, LASooner said:

Since we're just in full "Pie in the Sky" mode... 

 

If there is anything I've learned during my time here at AtariAge in the TI section, it's this:

Never underestimate the programming gurus here, because as history has shown, what's pie in the sky today, has a habit of becoming reality.

[RXB]

For over a year I have asked for help on XB ROM's.

Honestly I asked for help on re-writing XB ROMs since 2000 with not one offer.

 

So this is pretty pie in the sky if I can not get help for 12K of Assembly ROM asking for 1 meg help is hilariously sad.

 

Yea you can use Myarc XB but it has almost no backward compatibility for good reasons.

 

This could be done, but it is going to take a group effort and never got any help yet myself so good luck.