A worse programmers questions

[Sid1968]

Thank you buddies the discussion begins to get exciting. ?

For the sake of completeness i ran Richs suggested test on my real TI-99/4A this afternoon.

10 A=RND
20 C=C+1
30 GOTO 10

Value of "C" after exactly 60 Minutes:

------------------------------------------

TI-Basic: 203628
TI-Extended Basic: 28824
RXB 2015: 180399

Rich was right as he said, that he improved RXB against XB a lot.

Another truth is, that RXB is still slower than TI-Basic.

A good reason for improvement. ?

As proof i made these fotos of the results:

 

 

TI-Basic

 

TI-Extended Basic

 

RXB 2015

 

Kind Regards

Sid

 

Edited September 25, 2019 by Sid1968

[RXB]

2 hours ago, senior_falcon said:

 

I would like to know how to remain backwards compatible with all the XB programs if it was all Assembly?

Secondly where would you store the programs as upper 24K has to be for XB programs and lower 8K for Assembly?

 

Thus you are stuck with like XB3 total incompatibility with every old XB program ever written.

 

And doing away with GPL means you need to remove a bunch of chips from the TI99/4A so might as well just go Geneve DOS.

FACT: vast majority of all programs in TI99/4A use GPL, carts, games, XB, and others.

[apersson850]

1 hour ago, Lee Stewart said:

 

Actually, fbForth 2.0 does not use the console math routines. A few years ago (with permission), I ported the MDOS L10 Floating Point Library (FPL) to fbForth 2.0 to replace them.

That was interesting. Does the MDOS library use the same radix 100 format as TI does?

[RXB]

2 minutes ago, apersson850 said:

That was interesting. Does the MDOS library use the same radix 100 format as TI does?

I do not know much about the Geneve at all. Only wrote some ROMs for the Geneve to use as it could not use normal ROM routines from RXB.

[+Lee Stewart]

29 minutes ago, apersson850 said:

That was interesting. Does the MDOS library use the same radix 100 format as TI does?

Indeed it does. It is pretty much identical to the console ALC and GPL routines, except that the transcendental routines do not use any VRAM and, I think, at least one of the transcendental routines may have been tweaked [the approximating polynomial’s coefficient(s)] to yield a more accurate result, but I am not sure I ever tracked down which one(s). There may be documentation in the code—I will take a look.

 

...lee

[Sid1968]

54 minutes ago, RXB said:

I would like to know how to remain backwards compatible with all the XB programs if it was all Assembly?

Secondly where would you store the programs as upper 24K has to be for XB programs and lower 8K for Assembly?

 

Thus you are stuck with like XB3 total incompatibility with every old XB program ever written.

 

And doing away with GPL means you need to remove a bunch of chips from the TI99/4A so might as well just go Geneve DOS.

FACT: vast majority of all programs in TI99/4A use GPL, carts, games, XB, and others.

How did Myarc Extended BASIC II solved that issue? Senior_falcon said its programmed in assembler. Dont know if it uses GPL.

Edited September 25, 2019 by Sid1968

[senior_falcon]

Look folks, let's get realistic here. Rich won't do it. He writes pretty much exclusively in GPL. None of the assembly gurus will do it, and I can't blame them. Why spend a whole bunch of time writing something that will be way slower than what they can do easily right now. The only ones who want this are the ones who do not have the programming skills to do it. 

Bottom line: It ain't gonna happen.

[Sid1968]

37 minutes ago, senior_falcon said:

Look folks, let's get realistic here. Rich won't do it. He writes pretty much exclusively in GPL. None of the assembly gurus will do it, and I can't blame them. Why spend a whole bunch of time writing something that will be way slower than what they can do easily right now. The only ones who want this are the ones who do not have the programming skills to do it. 

Bottom line: It ain't gonna happen.

I got another feedback.

Are you out of arguments about what Rich said to compatibilityproblems with assembler and GPL?

Edited September 25, 2019 by Sid1968

[apersson850]

I checked the thread, and no, you didn't get any other feedback. You just choose to read something else than what was written.

It's good to be positive, but, as you probably have seen already, I'm also of the opinion that there are better things to spend work hours on than this project.

[senior_falcon]

1 hour ago, Sid1968 said:

I got another feedback.

Are you out of arguments about what Rich said to compatibilityproblems with assembler and GPL?

Contrary to Rich's assertation, a good programmer could write an all assembly XB that was fully compatible with programs written for the original TI XB. But you need a place to put it. You could probably put it in SAMS or one of the new super carts with a lot of RAM. But this is very tedious programming. Writing and testing, rewriting and retesting just to get it to duplicate what XB does. I can't imagine anyone actually doing this for the entire XB cartridge.

[+9640News]

3 hours ago, Sid1968 said:

How did Myarc Extended BASIC II solved that issue? Senior_falcon said its programmed in assembler. Dont know if it uses GPL.

To my knowledge, nobody at this moment outside of perhaps Lou Phillips, that may have the source code for Myarc Extended Basic II.  Myarc Extended Basic was written in assembly.  If it uses any GPL, and I use the word "if", it would have to be in the TI-99/4A groms as the cartridge was 8K ram only at >6000 to >7FFF that was populated with a module header and enough code to load the the Myarc XB program image files from a storage device.

 

That module header and code was "copied" into the 8K cartridge ram space by the power-up routine of the Myarc 128/256/512K card containing an XBII flavored DSR eprom.

 

Beery

Edited September 25, 2019 by BeeryMiller

[+Lee Stewart]

4 hours ago, RXB said:

I would like to know how to remain backwards compatible with all the XB programs if it was all Assembly?

Secondly where would you store the programs as upper 24K has to be for XB programs and lower 8K for Assembly?

 

Thus you are stuck with like XB3 total incompatibility with every old XB program ever written.

 

And doing away with GPL means you need to remove a bunch of chips from the TI99/4A so might as well just go Geneve DOS.

FACT: vast majority of all programs in TI99/4A use GPL, carts, games, XB, and others.

Sigh...You are tilting at windmills, Rich. Nobody is suggesting doing away with GPL. XB can be written in 100% ALC without ripping out the console ROMs and GROMS and rewriting the OS to remove the GPL interpreter. It would simply not use GPL unless GPL were the best way to accomplish a particular task.

As to backward compatibility, there is no GPL in XB. There is only Basic code. GPL is simply the language that is used for the interpreter. ALC would simply replace GPL as the language for said interpreter. Any compatibility issues would hang on how faithful to current XB such an ALC interpreter would be written.

I am not sure what your program storage issue is. XB programs would use the same storage space as before. If you mean storage space for interpreter routines, that would be cartridge ROM space just like all the XBs under discussion use.

...lee

[Sid1968]

14 hours ago, apersson850 said:

I checked the thread, and no, you didn't get any other feedback. You just choose to read something else than what was written.

It's good to be positive, but, as you probably have seen already, I'm also of the opinion that there are better things to spend work hours on than this project.

Aspersson, i really dont count on you anymore, but did you read my PMs too? ?

If you want to help it would be great, if not its accepted!

Edited September 26, 2019 by Sid1968

[Sid1968]

14 hours ago, Lee Stewart said:

Sigh...You are tilting at windmills, Rich. Nobody is suggesting doing away with GPL. XB can be written in 100% ALC without ripping out the console ROMs and GROMS and rewriting the OS to remove the GPL interpreter. It would simply not use GPL unless GPL were the best way to accomplish a particular task.

As to backward compatibility, there is no GPL in XB. There is only Basic code. GPL is simply the language that is used for the interpreter. ALC would simply replace GPL as the language for said interpreter. Any compatibility issues would hang on how faithful to current XB such an ALC interpreter would be written.

I am not sure what your program storage issue is. XB programs would use the same storage space as before. If you mean storage space for interpreter routines, that would be cartridge ROM space just like all the XBs under discussion use.

...lee

That sounds very profound and first of all factual. Thank you Lee. ?

Thanks to senior_falcon who had the idea to programm RXB in 100% Assembler first and who helped his buddy Rich. ?

Thanks to Rich for the factual discussion. ?

 

Look folks, this thread has gone a "long" way. At first we realized some issues in RXB, then we spotted that not the system architecture of the TI-99/4 is the problem, but the software. After that we dicussed (and still discuss) in what manner improvement should happen. And dont forget that Rich had the great to appeal for help because of the lack of assemblerknowlage. That is a what i call progress!!!

 

Dont forget: We will make it together :-)

 

To understand Richs stance: Would someone of you change something in his projects without good reasons???  I guess we found a good reason.

 

If i resume this thread about improving RXB, the best solution would be to rewrite RXB 100% in Assembler. The compatibility to old programs would not get lost. Is that right?

Why is it not necessary to rewrite the roms in assembler?

 

Kind Regards

Sid

 

 

 

 

 

 

Edited September 26, 2019 by Sid1968

[apersson850]

19 hours ago, Lee Stewart said:

 

Actually, fbForth 2.0 does not use the console math routines.

<...snip...>

• The GPL-based transcendental functions are slow

<...snip...>

The only drawback is that the non-transcendental functions in the console run in ALC on the 16-bit bus, making them clearly faster than fbForth 2.0’s 8-bit-bus versions.

Which means that if you really win anything on the port to the new library, speedwise, depends entirely on what kind of floating point math you are doing.

Do they provide the same results? I mean, are the algorithms the same? Perhaps the standard add/subtract/multiply/divide routines, which are in assembly in the console ROM, are identical in the MDOS libarary?

[apersson850]

52 minutes ago, Sid1968 said:

If i resume this thread about improving RXB, the best solution would be to rewrite RXB 100% in Assembler.

If we instead look at what would return something for a reasonable amount of work, there are better targets.

Leave BASIC as it is. It's easy to access and can do a lot, in the extended edtions, as long as you aren't in a hurry.

If you are, you can stay with BASIC and learn how to include assembly support, perhaps to the extent that you build libraries with useful, and fast, functions.

 

Or you can go Forth, which is already there and is much faster than BASIC will ever be.

 

If you want to stay with a more conventional language, which is still very well developed on the 99/4A, you can go to Pascal. It's faster than BASIC and comparatively easy to support with assembly. Where Forth represents a slowdown, compared to assembly, of three times, Pascal is about five-six times slower. Both are stack based. In Forth, which is much closer to the hardware, that's obvious. In Pascal, it's more an under-the-hood thing.

 

For the p-system, there are actually two possible projects, which are reasonably doable, and beneficiary.

The first is to make a modern version of the p-code card, if not as an expansion box card, but at least as a side expansion "device". Today, 60 kbytes of memory and some logic for simulating GROM access to 48 of these isn't too difficult, if you are used to making hardware projects. Making a clone implies that you don't have to rewrite it, just re-package it. There may be copyright issues, although I doubt anyone would find it worth fighting. The reason for this is of course to make the p-system available to more people, since the original p-code card is pretty rare today.

The second is to implement a native code generator, NCG. Many p-systems had that from the beginning, but not the one for the TI 99/4A. However, the PME does support the opcodes NAT and NAT-INFO. As far as I've been able to determine, it should be possible to run code that's been exposed to a NCG on a 99/4A too.

The purpose of the NCG is to let it process an ordinary code file, produced by the compiler, and automatically replace p-code instructions by assembly equivalents. There are quite a few p-codes, that can be replaced by one, or a few, TMS 9900 instructions. You thus get rid of the PME overhead in interpreting these p-codes, and hence speed up that particular piece of code by a factor of five or so. The more complex p-code instructions, like Call global procedure or Call external intermediate, probably also Divide real, you simply let stay put as they are. They execute so many assembly instructions when they run, that the interpreter overhead is minimal. But simple things, like load constants, integer arithmetic, fetch/store local/global variables, they are translated to the NAT p-code instruction followed by the assembly code in line.

 

I've never used any NCG myself, but I've read about that they typically don't convert an entire program, but you tell it which procedure(s) to convert, and there you do of course select those that run many times, and thus does the brunt of the work. There's no point in converting code that handles user input, or other things that aren't time critical. The beauty of the solution is of course that you write and debug your projects in Pascal, then just make a speed improvement on the selected parts, and that improvement is fully automatic.

[Sid1968]

Thank you for that discours in programlanguages. In my college of electrical engineering in the late 80s i

learnded Pascal and C. On TI-99/4A i would have interests in programming Pascal (didnt found a Compiler)

and fbForth.

 

My extremly high interest in the improvement of Extended Basic is founded in the history of the TI-99/4A.

The TI-99/4A`s history woked my interests in that computer. I knew that TI-Basic would not be that fast,

but i really got a punch to the midriff as I realized that the Expansion Basic was (sometimes) slower then

TI-Basic. For me is "Expansion Basic" that, what "Simon`s Basic" is for the C64. I love it.

 

That made me question for the reasons. As an former outsider i strongly believe that this Computer, the

TI-99/4A, deserves a more improved Extended Basic Version. And why Extension Basic? Because its a part

of the TI-99/4A`s Computerhistory too! Since we found out, that an improvement is possible iam sure we

all, the people of this community, will make this happen. ?

 

Edited September 26, 2019 by Sid1968

[+Lee Stewart]

3 hours ago, apersson850 said:

Which means that if you really win anything on the port to the new library, speedwise, depends entirely on what kind of floating point math you are doing.

Do they provide the same results? I mean, are the algorithms the same? Perhaps the standard add/subtract/multiply/divide routines, which are in assembly in the console ROM, are identical in the MDOS libarary?

 

As near as I can tell, the functions are the same and do provide the same results, with one (or more) possible exceptions that involve the coefficients of the polynomial used to approximate a given (usually transcendental) function. I remember reading, in the code for at least one of the transcendental functions, a comment by Paul Charlton or his collaborator that they needed to correct one of the equations to get more accurate results. I will do a bit of research tonight or tomorrow to see whether I can find it.

 

You may find interesting my discussion in posts #966 and #972 of the main fbForth thread about the arctan function.

 

Regarding the console ROM routines, the code is essentially identical as I remember checking it lo these many years ago.

 

...lee

[senior_falcon]

On 9/25/2019 at 10:08 AM, Sid1968 said:

For the sake of completeness i ran Richs suggested test on my real TI-99/4A this afternoon.

10 A=RND
20 C=C+1
30 GOTO 10

Value of "C" after exactly 60 Minutes:

------------------------------------------

TI-Basic: 203628
TI-Extended Basic: 28824
RXB 2015: 180399

 

This agrees with my tests. After 1 minute I got:

TI-Basic:   3329

RXB 2015: 2990

Multiply by 60 and we get:

TI-Basic:   199740 vs. 203628      these agree closely as does the video.

RXB 2015: 179400 vs. 180399                     "

After 5 hours Rich got:

TI-Basic:   391427

RXB:         492783

The divergence is so great it is clear there is either something wrong with his computer or the results are fabricated.

 

 

[Sid1968]

39 minutes ago, senior_falcon said:

 

This agrees with my tests. After 1 minute I got:

TI-Basic:   3329

RXB 2015: 2990

Multiply by 60 and we get:

TI-Basic:   199740 vs. 203628      these agree closely as does the video.

RXB 2015: 179400 vs. 180399                     "

After 5 hours Rich got:

TI-Basic:   391427

RXB:         492783

The divergence is so great it is clear there is either something wrong with his computer or the results are fabricated.

 

 

I guess its more the weakness of the simulator he tested with. Therefore i took a real TI-99/4A.

Or he simply made an error in the flurry. Rich wont fake us! I like him very much.

 

But lets more talk about the improvements we should make, mate.

Edited September 26, 2019 by Sid1968

[+adamantyr]

I'm not sure how this thread got here... Just to cover a few points:

 

1) TI BASIC and Extended BASIC v.110 are by far the most common languages used.

2) RXB is an elegant and opulent version of Extended BASIC that is supported by its creator, and was the platform upon which the latest 10-line contest was won.

3) The TI architecture, especially around video, makes getting any significant speed or performance difficult unless you go to a low level language.

4) Nobody wants to make a new BASIC language.

5) If there is one flaw among the general 99'er community here, it's that there's too much focus on producing platforms and not enough focus on producing software ON platforms.

6) Anyone who isn't already familiar with TMS9900 assembly programming is far too intimidated by it. It's not that bad, really. Leave BASIC behind and learn how the machine really works!

 

[Sid1968]

Thank you for your statement, adamtyr.

 

Rich, you improved the RND functiom of RXB compared to Extended Basic a lot. How did you do that?

 

Kind Regards

Sid

Edited September 26, 2019 by Sid1968

[RXB]

On 9/25/2019 at 9:29 AM, senior_falcon said:

Look folks, let's get realistic here. Rich won't do it. He writes pretty much exclusively in GPL. None of the assembly gurus will do it, and I can't blame them. Why spend a whole bunch of time writing something that will be way slower than what they can do easily right now. The only ones who want this are the ones who do not have the programming skills to do it. 

Bottom line: It ain't gonna happen.

Why are you always so hostile to me.

I say you have a great product and you do not even have the manners to do the same?

And how am I not "REALISTIC" does everyone on Earth have to just agree with you with no choice?

I do GPL and RXB that is my thing, do I rag on you about your thing....no I make "REALISTIC" observations about facts.

Assembly is not easy to learn, XB256 is much harder to learn then TI Basic or XB, fact.

I do not try convert you, but I am not saying anything bad about XB256 is it a great product, but not same as XB or Basic.

I can write a 20 line program in XB or Basic in few seconds with no compiler needed or anything to load.

I can debug that program easy within seconds, as that is the drawback and advantage of Basic or XB, it is slower but more friendly.

Lastly it is 100% backwards compatible every time with no conversions needed.

[RXB]

On 9/25/2019 at 11:50 AM, BeeryMiller said:

To my knowledge, nobody at this moment outside of perhaps Lou Phillips, that may have the source code for Myarc Extended Basic II.  Myarc Extended Basic was written in assembly.  If it uses any GPL, and I use the word "if", it would have to be in the TI-99/4A groms as the cartridge was 8K ram only at >6000 to >7FFF that was populated with a module header and enough code to load the the Myarc XB program image files from a storage device.

 

That module header and code was "copied" into the 8K cartridge ram space by the power-up routine of the Myarc 128/256/512K card containing an XBII flavored DSR eprom.

 

Beery

Yea do not know anyone with the source of XB 2, but I did get a copy of some of the disassembled code. 

Lost it when my SCSI drive failed.

[Sid1968]

10 minutes ago, RXB said:

Why are you always so hostile to me.

I say you have a great product and you do not even have the manners to do the same?

And how am I not "REALISTIC" does everyone on Earth have to just agree with you with no choice?

I do GPL and RXB that is my thing, do I rag on you about your thing....no I make "REALISTIC" observations about facts.

Assembly is not easy to learn, XB256 is much harder to learn then TI Basic or XB, fact.

I do not try convert you, but I am not saying anything bad about XB256 is it a great product, but not same as XB or Basic.

I can write a 20 line program in XB or Basic in few seconds with no compiler needed or anything to load.

I can debug that program easy within seconds, as that is the drawback and advantage of Basic or XB, it is slower but more friendly.

Lastly it is 100% backwards compatible every time with no conversions needed.

 

I do agree Rich. In Germany we say "Der Ton macht die Musik" (The Tone makes the Music).

Edited September 26, 2019 by Sid1968