Jump to content
IGNORED

A worse programmers questions


Sid1968

Recommended Posts

46 minutes ago, RXB said:

I think that feature was in SuperXB that had the plot routines, but as you could only do this from Assembly limited it to very restrictive SuperXB only programs.

RXB has the same issue from many routines.

The Plot routines used Bit Map Mode so extremely limited VDP RAM size and XB program size.

Thank you Rich. If i understand you right... Using the plot routines in RXB leads to RXB only programs, right?

Its the same as on C64. Using plot routines of Simons Basic, leads to Simons Basic only programs.

 

If i understand you further right, RXB plot routines are veeeerrry slow, right? Do we want to call this a "special feature"?

 

Edited by Sid1968
Link to comment
Share on other sites

19 minutes ago, Sid1968 said:

Thank you Rich. If i understand you right... Using the plot routines in RXB leads to RXB only programs, right?

Its the same as on C64. Using plot routines of Simons Basic, leads to Simons Basic only programs.

 

If i understand you further right, RXB plot routines are veeeerrry slow, right? Do we want to call this a "special feature"?

 

Sorry Super XB had Plot Routines you could call but resided in Lower 8K thus you could not use Assembly support as that space was taken.

They were fast but used up most of the VDP memory which you need for Strings and Variables, thus further created more problems then solved.

 

I opted out of this way to go as the number of Super XB programs you can find using the Plot features are exactly 2 in total in 20 years.

They were cool to look at but The Missing Link (Assembly Links youload) did a better job with more features.

Again same problem it limits VDP memory and uses Lower 8K so you can not get more Assembly support or get back that missing VDP RAM.

  • Thanks 1
Link to comment
Share on other sites

You mean its better to

8 minutes ago, RXB said:

They were cool to look at but The Missing Link (Assembly Links youload) did a better job with more features.

 

Do an example basic listing exists or is it possible to get a short example for that "Assembly Links youload"?

Edited by Sid1968
Link to comment
Share on other sites

1 hour ago, Sid1968 said:

You mean its better to

Do an example basic listing exists or is it possible to get a short example for that "Assembly Links youload"?

 

I did not use CALL LINK("name")  from XB but a RXB subprogram CALL EXECUTE(address)

 

  • Thanks 1
Link to comment
Share on other sites

I finally had a chance to read through this thread. There are a LOT of TI-specific limitations that the original poster does not seem to grasp. First, you have to deal with the memory map of the 99/4A. Any BASIC other than the console BASIC is dependent upon two to three hardware factors. First, the cartridge port only occupies 8K of the system map. It is possible to add additional 8K bank-switched blocks, but for setting up a ROM-only BASIC, all of your tokens and their trampolines would have to be in that first 8K. The code for your routines could be in other 8K blocks though. This assumes you are using Assembly for everything--and that your Assembly code has been optimized to work in a bank-switched memory space. Note that you also need to deal with the way memory is otherwise allocated in the system. Low memory (mentioned several times in this thread) is an 8K space where existing Extended BASIC extension code resides. High memory is a 24K space where your BASIC code lives. You also have about 12K of space in the video memory space that can be used to hold strings and other variables. These spaces are not generally mutable. Use of a SAMS memory card allows you to bank switch in both the low memory area and the high memory area, but you have to make sure your program keeps track of where everything is in those spaces. TI got around many of these limitations by using GPL and GROM chips to store code and programs. The cartridge port generally supports five GROM chips in a group that each store up to 8K of GPL code. Now combining the five GROMs and the cartridge 8K ROM space allows us to create things like TI Extended BASIC V100 (withdrawn in 1981 due to some significant errors in the math routines), Extended BASIC V110 (Last version from TI--and it still contains a few errors in the trigonometric functions). Note that both of these use a combination of ROM and GROM, Assembly code in the ROM (12K, as it bank-switches half of the space), and GPL in the GROMs. RXB, Triton Super Extended BASIC, Tony Knerr's XB 2.7, and Mechatronic Extended BASIC and Extended BASIC II+ all use the same ROM code TI used, as all of their code changes were in the GPL code contained in the GROMs. Winfried Winkler's Expanded BASIC 3 made changes to both the ROM and the GROM code (and uses four ROM banks instead of two). Some of those changes were to add functions, some were to change memory usage (the cartridge has some limited support for SAMS memory and expects a 32K memory space by default, but will run on a bare console), and some were to correct issues with the trigonometric functions from TI. The Assembly versions of basic (Myarc BASIC 2.12 and Cortex BASIC) don't use GPL. Myarc BASIC runs in a specialized memory space in the 128K/256K/512K card, leaving the normally available 32K memory space open for programs (24K for programs and 8K for Assembly subprogram suport, IIRC). Cortex BASIC runs from cartridge space and part of the 32K space--leaving a much smaller space available for programs. Programs written for either of these will run a LOT faster than programs written for the other TI BASIC/Extended BASIC variants.

 

On pixel graphics, there are several options: Mechatronic Extended BASIC II+ includes the APESoft expanded graphics routines that give access to Bitmap Graphics modes. These routines were also available in Austria/Switzerland/Germany as APESoft Expanded Grafics BASIC and in the US as Amerisoft Expanded Graphics BASIC. The Mechatronic and separate versions were loaded into the 8K low memory space. Cortex BASIC has the necessary routines as well. There are also several external packages that add help here, many of which have already been identified in the thread.

 

Cortex BASIC source code is based on BASIC for the Powertran Cortex, which is a derivative of TI-990 Power BASIC. This would probably be a good starting point if someone really had the time to try and create a full Assembler version of TI BASIC. Don't even think of trying to tie me to that task, as my programming skills are limited to BASIC and a little bit of Pascal.

 

Logo/Logo II are TI cartridges that add another programming language to the TI. Very little was written for this environment, but it is interesting in that there are versions of the cartridge in English, French, German, Dutch, Italian, and Spanish, making it a very suitable language for teaching children to program.

 

The Arcadeshopper store has new-manufactured Cortex BASIC, XB 2.7, Winkler Expanded BASIC 3, Triton Super Expanded BASIC, and RXB 2015 cartridges available. I can also supply any of the above cartridges.

 

The really important thing to understand with any attempt to completely rewrite Extended BASIC is that almost all versions are dependent upon GPL to leave enough memory space open to be able to actually write programs. This means BASIC will be slow, really slow. Cortex BASIC is the only current dialect completely written in Assembler--and it leaves much less open space for programmers to actually write their programs. More importantly, it is not compatible with any of the other BASIC dialects for the TI. It also has very few programs written specifically for it at this point in time.

 

Rewriting ANY of these BASIC dialects is not a project for the casual programmer. It also requires a programmer committed to the project, something the available programmers on this forum have pretty much avoided saying. If YOU want this to come to life, you'll have to dedicate yourself to completing it. Others may help you with specific elements when you get stuck, but that's about all of the help you can hope for. Rich has been asking for help rewriting the XB ROMs for years--and getting nowhere. That is a much smaller undertaking than you are asking for here. . .

 

Auf Deutsch: niemand Hier moechte sowas machen, da der Aufwand ist viel zu Gross und am Ende, kaum Jemand wird es benuetzen. Leider.

 

 

 

  • Like 5
  • Thanks 2
Link to comment
Share on other sites

Genau!

 

Besides, since I now understand that the purpose of this BASIC improvement isn't to use it, but to impress owners of various Commodore computers, the problem is already solved. Just use the ported Cortex BASIC. The fact that it's quite a bit less useful, due to limited space for application programs, doesn't matter, if the purpose is to demonstrate performance. That's invariably done with a program less than a page long, if you print it.

 

For useful things, it would be better to make some p-code card clone, and focus on getting a native code generator running on the 99/4A.

Edited by apersson850
  • Like 1
Link to comment
Share on other sites

11 hours ago, Ksarul said:

I finally had a chance to read through this thread. There are a LOT of TI-specific limitations that the original poster does not seem to grasp. First, you have to deal with the memory map of the 99/4A. Any BASIC other than the console BASIC is dependent upon two to three hardware factors. First, the cartridge port only occupies 8K of the system map. It is possible to add additional 8K bank-switched blocks, but for setting up a ROM-only BASIC, all of your tokens and their trampolines would have to be in that first 8K. The code for your routines could be in other 8K blocks though. This assumes you are using Assembly for everything--and that your Assembly code has been optimized to work in a bank-switched memory space. Note that you also need to deal with the way memory is otherwise allocated in the system. Low memory (mentioned several times in this thread) is an 8K space where existing Extended BASIC extension code resides. High memory is a 24K space where your BASIC code lives. You also have about 12K of space in the video memory space that can be used to hold strings and other variables. These spaces are not generally mutable. Use of a SAMS memory card allows you to bank switch in both the low memory area and the high memory area, but you have to make sure your program keeps track of where everything is in those spaces. TI got around many of these limitations by using GPL and GROM chips to store code and programs. The cartridge port generally supports five GROM chips in a group that each store up to 8K of GPL code. Now combining the five GROMs and the cartridge 8K ROM space allows us to create things like TI Extended BASIC V100 (withdrawn in 1981 due to some significant errors in the math routines), Extended BASIC V110 (Last version from TI--and it still contains a few errors in the trigonometric functions). Note that both of these use a combination of ROM and GROM, Assembly code in the ROM (12K, as it bank-switches half of the space), and GPL in the GROMs. RXB, Triton Super Extended BASIC, Tony Knerr's XB 2.7, and Mechatronic Extended BASIC and Extended BASIC II+ all use the same ROM code TI used, as all of their code changes were in the GPL code contained in the GROMs. Winfried Winkler's Expanded BASIC 3 made changes to both the ROM and the GROM code (and uses four ROM banks instead of two). Some of those changes were to add functions, some were to change memory usage (the cartridge has some limited support for SAMS memory and expects a 32K memory space by default, but will run on a bare console), and some were to correct issues with the trigonometric functions from TI. The Assembly versions of basic (Myarc BASIC 2.12 and Cortex BASIC) don't use GPL. Myarc BASIC runs in a specialized memory space in the 128K/256K/512K card, leaving the normally available 32K memory space open for programs (24K for programs and 8K for Assembly subprogram suport, IIRC). Cortex BASIC runs from cartridge space and part of the 32K space--leaving a much smaller space available for programs. Programs written for either of these will run a LOT faster than programs written for the other TI BASIC/Extended BASIC variants.

 

On pixel graphics, there are several options: Mechatronic Extended BASIC II+ includes the APESoft expanded graphics routines that give access to Bitmap Graphics modes. These routines were also available in Austria/Switzerland/Germany as APESoft Expanded Grafics BASIC and in the US as Amerisoft Expanded Graphics BASIC. The Mechatronic and separate versions were loaded into the 8K low memory space. Cortex BASIC has the necessary routines as well. There are also several external packages that add help here, many of which have already been identified in the thread.

 

Cortex BASIC source code is based on BASIC for the Powertran Cortex, which is a derivative of TI-990 Power BASIC. This would probably be a good starting point if someone really had the time to try and create a full Assembler version of TI BASIC. Don't even think of trying to tie me to that task, as my programming skills are limited to BASIC and a little bit of Pascal.

 

Logo/Logo II are TI cartridges that add another programming language to the TI. Very little was written for this environment, but it is interesting in that there are versions of the cartridge in English, French, German, Dutch, Italian, and Spanish, making it a very suitable language for teaching children to program.

 

The Arcadeshopper store has new-manufactured Cortex BASIC, XB 2.7, Winkler Expanded BASIC 3, Triton Super Expanded BASIC, and RXB 2015 cartridges available. I can also supply any of the above cartridges.

 

The really important thing to understand with any attempt to completely rewrite Extended BASIC is that almost all versions are dependent upon GPL to leave enough memory space open to be able to actually write programs. This means BASIC will be slow, really slow. Cortex BASIC is the only current dialect completely written in Assembler--and it leaves much less open space for programmers to actually write their programs. More importantly, it is not compatible with any of the other BASIC dialects for the TI. It also has very few programs written specifically for it at this point in time.

 

Rewriting ANY of these BASIC dialects is not a project for the casual programmer. It also requires a programmer committed to the project, something the available programmers on this forum have pretty much avoided saying. If YOU want this to come to life, you'll have to dedicate yourself to completing it. Others may help you with specific elements when you get stuck, but that's about all of the help you can hope for. Rich has been asking for help rewriting the XB ROMs for years--and getting nowhere. That is a much smaller undertaking than you are asking for here. . .

 

Auf Deutsch: niemand Hier moechte sowas machen, da der Aufwand ist viel zu Gross und am Ende, kaum Jemand wird es benuetzen. Leider.

 

 

 

Thank you for giving a full account!

 

1. The space problem is the Archille`s Heel of Cortex Basic. How could this problem get solved?

    I guess another problem of Cortex Basic is that its no longer in developement. This makes it overall unattractive.

    But maybe Stuart could help improving RXB.

 

2. Do the APESoft expanded graphics routines in Mechatronic Extended BASIC II+ work in an acceptable manner (e.g.: speed)?

 

3. Could the implementation of the APESoft expanded graphics routines be a solution for RXB, too?

 

 

Like MacGuyver, we should "cook" with what we have. I try to get the best of what we have HERE for the improvement for Rich`s Project RXB. ;-)

That will lead to a hugde win of prestige for the TI-Community. (Post #283)

 

 

Cheers

Sid

 

Edited by Sid1968
  • Like 1
Link to comment
Share on other sites

You seem laser-focused on speed as the way to improving BASIC. So long as BASIC (any flavor) requires the use of GPL, you will never get an overall gain in execution speed. It is a hardware constraint that you cannot ignore. Rich does all of his programming in GPL, and has kept his focus there for well over 20 years. His work has benefitted the community, and the somewhat recent availability of phsical RXB cartridges has moved interest outside the limited membership of those with access to GRAM devices that emulate the GROMs his code needs to reside in. More people use RXB now--and that is a good thing, but it requires GPL to work, and anything using GPL will not give you the speed increases you are loking for.

 

As to the APESoft routines, they have the same limitations as the Draw and Plot routines, The Missing Link, XB256, or any other language extension. All of them would reside in the 8K of Low Memory--and if you are using one of them, you aren't using any other BASIC support routines, as they would need to occupy the same space. Rich has already identified the scope of the problems here, and why RXB stays away from integration attempts. This is not a simple plug-and-play activity to blend the functions of the language to get the "fast" features you want. It is a complex task. Rich has dedicated much of his adult life towards making RXB as efficient and as useful as possible (and I appreciate that). Harry has taken the BASIC support routines about as far as it is possible to take them in his XB256 program--and integrated them into his Compiler to allow just what you are asking for: FAST program execution at near-Assembler speed. I say near-Assembler speed because code written from the ground up in Assembler will be better optimized and slightly faster, but what the user gets here with his existing software is phenomenal. I am glad that we have his tools to work with--and I'm glad we have Rich's RXB (and Tony Knerr's XB 2.7, which only stopped being developed because of his untimely passing a couple of years ago). Cortex BASIC is also interesting, it just doesn't have a lot of programs written in it--and the code space is a lot smaller due to the memory map of the 99/4A. That shows just how fatal the compatibility issue is: if you can't use the existing Extended BASIC program library with the software you are developing, the only person you will be developing for is yourself.

 

You might want to try and USE the existing products to see what they can give you. Each has advantages, and each has disadvantages too, but all of them meet the first rule of programming: they are useful tools.  :) :) :)

  • Like 1
  • Thanks 2
Link to comment
Share on other sites

6 hours ago, apersson850 said:

For useful things, it would be better to make some p-code card clone, and focus on getting a native code generator running on the 99/4A.

Actually, TI already made a p-Code sidecar. It is really hard to find (I know of only three to four surviving examples, as most of them were sold into the education market and didn't make it into the collector/user community), but it could be cloned if using an apropriate GROM emulation in the box. I'll have to open mine up to get some pictures of the board, as that will be a major determinant on difficulty.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

4 hours ago, Ksarul said:

As to the APESoft routines, they have the same limitations as the Draw and Plot routines, The Missing Link, XB256, or any other language extension. All of them would reside in the 8K of Low Memory--and if you are using one of them, you aren't using any other BASIC support routines, as they would need to occupy the same space.

 

That is a common misconception. Actually, XB doesn't care where the assembly routines are located. It can run them just fine when they are in the 24K high memory. There is a utility in TML called HMLOADER that will embed assembly routines in high memory and you can then add an XB program to the embedded routines. So you can fill up the 8K from >2000 to >3FFF with assembly routines (or use TML or XB256) and add more routines to the high memory.

The compiler runs completely from high memory.

 

By the way, the apesoft routines stink compared to the missing link. Don't take my word for it-compare them yourself.

Edited by senior_falcon
  • Like 3
  • Thanks 1
Link to comment
Share on other sites

That was understood, @senior_falcon--my comment was more about maintaining integrity of the 24K of High Memory as space for the BASIC program and not expanding the support routines into that space. Thanks for making sure that knowledge is known to everyone.  :) :) :)  I have to be more careful not to jump too far from the lines of common knowledge when I write (or at least explain myself better when I do):) :) :)  

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

11 hours ago, apersson850 said:

Genau!

 

Besides, since I now understand that the purpose of this BASIC improvement isn't to use it, but to impress owners of various Commodore computers, the problem is already solved. Just use the ported Cortex BASIC. The fact that it's quite a bit less useful, due to limited space for application programs, doesn't matter, if the purpose is to demonstrate performance. That's invariably done with a program less than a page long, if you print it.

 

For useful things, it would be better to make some p-code card clone, and focus on getting a native code generator running on the 99/4A.

LOL if you have a Cortex base of like 20 people and no programs for it....what advantage is there at all to using it?

Yea it is faster but if no one is using it what is the freaking point?

Besides not being remotely backwards compatible and restricted to very very small programs why us it? (Bragging Rights?) 

It is like comparing a Ferrari  to a VW Bug in the 1950's, yea it was fast but who the hell was driving them?

  • Like 1
Link to comment
Share on other sites

You are right Rich. BTW in Germany we called it the "Käfer" what you can translate as "Bug" or "Beetle". The french 2CV was called "Ente (=Duck)". How do you called it?

 

Coming back to the graphics routines, i guess Mechatronic Extended BASIC II+ with the APESoft expanded graphics routines would be the simplest way for me.

Just read that it has even an "axis" command, which draws a Cartesian coordinate system.... Thats great!!!

 

How do other languages and dialects (XB, RXB, fbForth,...) solves it to draw a Cartesian coordinate system?

Edited by Sid1968
  • Like 1
Link to comment
Share on other sites

2 hours ago, RXB said:

LOL if you have a Cortex base of like 20 people and no programs for it....what advantage is there at all to using it?

Yea it is faster but if no one is using it what is the freaking point?

Besides not being remotely backwards compatible and restricted to very very small programs why us it? (Bragging Rights?)

I wouldn't say that 14K of RAM free for program and variables restricts it to "very very small programs"!

  • Like 1
Link to comment
Share on other sites

17 minutes ago, Stuart said:

I wouldn't say that 14K of RAM free for program and variables restricts it to "very very small programs"!

True--I just noted it was less than the 24K available to the XB programmer, not that it was too small to use. I like Cortex BASIC :) I was really glad to see you do this port too. :)  14K allows the programmer to make substantial programs, larger than what would be possible in console basic or with the various flavors of Extended BASIC without memory expansion. There are a lot of interesting and useful TI programs that size or smaller.  :)

  • Like 2
Link to comment
Share on other sites

9 hours ago, Stuart said:

I wouldn't say that 14K of RAM free for program and variables restricts it to "very very small programs"!

Can you explain that more detailed?

I guess you speak of 14K free RAM by using a 32KB RAM Expension, while the others speak of the raw TI-99/4A.

 

Do you still develope Cortex Basic?

 

Are the other XBs able to use the 32KB RAM Expension, too?

 

 

Edited by Sid1968
Link to comment
Share on other sites

The 32K Ram Expansion is the 24K of High Memory and the 8K of Low Memory. All versions of Extended BASIC use the High Memory for their programs when it is available (this means a 32K card is installed), or they use about 13K of the VDP memory as the program space when it isn't present (no 32K card installed).

  • Thanks 1
Link to comment
Share on other sites

12 minutes ago, Ksarul said:

The 32K Ram Expansion is the 24K of High Memory and the 8K of Low Memory. All versions of Extended BASIC use the High Memory for their programs when it is available (this means a 32K card is installed), or they use about 13K of the VDP memory as the program space when it isn't present (no 32K card installed).

But why do people than think, that only tiny programs can run on CortexBasic?

Link to comment
Share on other sites

Because there's a difference between 24 K in high memory expansion plus some 12 K in VDP RAM, which Extended BASIC also uses, for strings and some other stuff, compared to 14 K available for applications in Cortex BASIC.

So for Extended BASIC it's a total of some 36 K available, for Cortex 14 K. Thus Extended BASIC has about 2.5 times the memory at its disposal, compared to Cortex.

Then, if that implies that Extended BASIC can run large, and Cortex small, programs, or if Cortex can run large and Extended BASIC gigantic programs, that's a question about semantics. Compared to today's memory requirements, Extended BASIC can run minimal and Cortex virtually non-existing programs, but the memory requirements in the 99/4A environment isn't like what we see today...

 

As far as I know, Cortex BASIC is dead. There's obviously a port to the 99/4A, but the Cortex, to which it was originally ported, is dead since way back.

Edited by apersson850
  • Like 1
  • Thanks 1
Link to comment
Share on other sites

16 hours ago, Sid1968 said:

How do other languages and dialects (XB, RXB, fbForth,...) solves it to draw a Cartesian coordinate system?

I can't speak to the BASIC systems directly, but Forth is a low level language. It is really a clever macro assembler for a two stack machine. But the language is extendable. If you want cartesian coordinates then you just add words to the language that do that for you.  

 

FbForth has all the support needed to accomplish that.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

On 10/5/2019 at 11:07 AM, Sid1968 said:

Yes the good old times... From my first Computer you probably never heard in your life before... with the age of 18 i got a "Commodore C64" in 1986. ;-)

I used it with Oxford Pascal. And now, only a "few weeks" later... i look in the mirror and see a 51 year old man...

Yeah the loading time with the 1541 were a pain... but 33 years to load Pascal? ?

 

  • Thanks 1
Link to comment
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...