Jump to content
Sid1968

A worse programmers questions

Recommended Posts

RXB comments in black, my responses in blue:

 

Let's start by reminding you yet again that the XB Game Developer's Package  consists of a number of components. The two major ones are:

XB256  - This is a library of extensions for XB that open up graphics possibilities that cannot be achieved with the crippled graphics capabilities in XB or RXB. (256 characters plus 28 16x16 sprites) Programs written using XB256 run in Extended BASIC or RXB and writing them is no different than writing programs in standard XB or RXB

Compiler - This can be used to compile programs written in XB or XB256 for a 30x speed increase.

And the XB Games Developer Package is not XB in any sense easy to use, people need Assembly understanding to use it. 

I assume that here you are referring to the compiler.  It is obvious to me that you have not tried using this recently. It is literally a matter of pressing Enter at the prompts. 

You can BS all you want on how easy it is to use but it does require understanding of Assembly or frustration just increases.

(I have seen many give up using it due to this simple fact.) 

This would be true of the earlier versions which were much less user friendly. I would guess that the earlier implementation of IF THEN ELSE and the lack of subprograms led to most of the frustration. Also, of course, there is the fact that you are limited to integer arithmetic. Special thanks here to Vorticon who was very patient in helping me work out the bugs in the compiler's implementation of subprograms.

XB and Basic are true beginners languages and there are many more programs written in them then you will ever see in XB Games Developer Package.

Since XB256 is an extension of XB, it too is a true beginner's language. Sadly, I believe the second part of your statement is true, though why people prefer to use the crippled graphics potential of XB or RXB is not obvious to me.

Yes it is a good idea and I applaud your developments. 

 

But quit ragging on something that you need to get programs for in order for your product to exist.

It is both kinda crazy and self defeating ragging on the one thing your product is based on in the first place. Baffling!

What is baffling to me is what it is that you are trying to convey in these two sentences. Both seem to be gibberish to me.

 

Continue to push XB256 it is a great product but not in any sense a beginners product as it requires an assembly learning process.

Here you change the discussion away from the compiler to XB256. Let's compare similar program lines in RXB and XB256:

10 CALL HPUT(ROW,COL,"HELLO WORLD") !rxb version

10 CALL LINK("DISPLY",ROW,COL,"HELLO WORLD") !xb256 version

Both are perfectly understandable with almost identical syntax. Only someone who is willfully obtuse would find much of a mystery in how to use the assembly routine DISPLY.

To steep of gradiante to call it a beginners package. 

  • Like 2
  • Thanks 2

Share this post


Link to post
Share on other sites

Iam very happy that this thread lead to a discussion of two famous Basicdevelopers. 🙂

You both should exchange more often. The TI-Community would profit sooo much of it.

 

Every TI-Language is a win. To be a newbie in the TI-Community has one advantage, to

see it a liitle bit more from outside. One thing i can say is, that here are great people.

Like in other Communities too, often a community lives more or less of the acitvity of

only a few people while the others are, lets say more passiv. Thats normal. Everyone of

the activ Members has its own projects and for that not always time for other things to do.

Thats normal too.

 

This time a developer appealed help, because of the lack of assemblerknowlege. Even

if iam "only" a newbie in your impessive Community, i want to ask you people again to

support Rich in his project. Its clear that you people cant let your other projects go and

only work in the "Extended Basic REMASTERED" Project.

 

But take it easy... every little help is welcome.

 

Like the new AmigaOS 3.1.4, the new "Extended Basic REMASTERED" could be sold for a

reasonable price... maybe at the arcadeshoppers shop, so that all who helped could get

in addition to the fame a pecuniary profit for it.

 

Ahhh... i take one Cardridge... ;-)

 

Lets move the thing in a positiv direction. 🙂

 

Your forummate

Sid

Edited by Sid1968
  • Like 2

Share this post


Link to post
Share on other sites

I don't see the point at all in working with the math routines in Extended BASIC. Or any BASIC, for that matter. They are perfect for high accuracy computations, when you need them.

What BASIC could benefit from is instead integer variables, perhaps with the famous VAR1% notation. Thus you could use them for all indexing and other such stuff, where no floating point math is required. They consume less memory and the math routines would be as simple as they are in Forth. Or in Pascal, for that matter, where you already have the two data types integer and real.

 

Talking about Pascal, the p-system is a better development environment than BASIC ever was, so the idea of making a side cart which emulates the p-code card is perhaps better to spend your time on. It's quite a bit faster than BASIC, in spite of the interpreter for the p-code. And easy to augment with assembly routines, for the most time critical parts.

  • Like 3

Share this post


Link to post
Share on other sites

If i read it right GDMike and aperson850 shows interest in improving XB.  A good start. 🙂

Maybe Mizapf could help too. Mizapf what is your opinion in that? 🙄

 

And certainly it would be great if Tursi would be onboard even if that would be limited because of other projects. 🙃

 

 

Edited by Sid1968
  • Like 2

Share this post


Link to post
Share on other sites

No, when I use the TI 99/4A for programming (not too frequently nowadays), I prefer to use Pascal. It already addresses the limitations of BASIC, and then some. So I have no personal interest in improving any BASIC dialect.

I just used my experience in various development to point out that I found the focus in this thread, so far, to be on the wrong thing.

  • Sad 1

Share this post


Link to post
Share on other sites
57 minutes ago, apersson850 said:

No, when I use the TI 99/4A for programming (not too frequently nowadays), I prefer to use Pascal. It already addresses the limitations of BASIC, and then some. So I have no personal interest in improving any BASIC dialect.

I just used my experience in various development to point out that I found the focus in this thread, so far, to be on the wrong thing.

That is a .... ahhhh a good news, yes... 😭

 

Where do i find the p-system? Do it run on the FinalGROM 99?

If the p-system is so good, it would be interesting if you run Basictestprogram 2 translated to Pascal on it. 🙂

 

10 FOR I=1 TO 15000
20 A=I*(2+I)
30 NEXT I
40 PRINT A

Edited by Sid1968

Share this post


Link to post
Share on other sites

My opinion is that if we are going for BASIC enhancements, efforts should be put into current BASIC dialects like RXB. In fact, RXB is quite obviously a powerful BASIC variant. The reason why I am not working with it is simply because my focus is not on BASIC but other languages like assembly language or C. I am just not interested in BASIC programming; same with Forth for me, although there are really cool projects around here.

 

As you mentioned the development of AmigaOS: I see a difference between OS development with the Amiga and working on the console ROM for the TI. We could say that the 8K ROM (+18K GROM) are something like an operating system, but it has a quite different role. Drivers, for example, are contained in the ROMs of the peripheral cards (like the floppy controller, the serial interface etc.); if we were to update them, efforts go into developing new "DSRs" (Device Service Routines). This indeed makes sense and is pretty feasible, since most EPROMs on cards are socketed. Also, there are ongoing developments for new peripheral devices based on the cards or via the cartridge slot. One recent achievement is, for instance, the SDD:

 

 

Back to the console ROMs, they do contain central features like keyboard scanning, cassette operations (uhm... yes, not so interesting), arithmetic routines, the interrupt handler etc., but they do not play a central role during execution. So for most developments, apart from these features, the console ROMs are less important.

 

Dlease don't be disappointed if you don't see immediate support for your ideas; we really have lots of places to work on.

 

  • Like 2
  • Thanks 2

Share this post


Link to post
Share on other sites

Thank you for presenting your ideas to improve XB, Mizapf. Do i read you right, that you are onboard to develope an impoved xb (rxb) version and help Rich?

I think the time exposure will be managed in that manner, that everyone will have time for other projects too. But let us more talk about what improvements we need

in XB and how it could be managed. In my opinion the RXB REMASTERED Version can be delivered in a new Cartridge with new roms on it.

 

 

SDD 99: I worte a few days ago with the developer Ralph Benzinger. SDD 99 is maybe available next spring. It will bring 32 KB for the TI-99/4A onboard, but

you can make of the 32KB with software 32 MB too!!! It will be a HDD and will have WiFi... an amazing piece of Hardware. RXB REMASTERED would profit from it

if it would support the SDD 99.

Edited by Sid1968
  • Like 1

Share this post


Link to post
Share on other sites
57 minutes ago, Sid1968 said:

Thank you for presenting your ideas to improve XB, Mizapf. Do i read you right, that you are onboard to develope an impoved xb (rxb) version and help Rich?

I meant what I wrote, no more or less. 🙂

  • Like 1
  • Confused 1

Share this post


Link to post
Share on other sites
10 hours ago, senior_falcon said:

Incorrect. I ran each for 1 minute (you may have 3 hours to spare - I don't) The results:

TI XB         774

RXB         2990

TI BASIC  3329

 

TI BASIC is faster here, so RXB is only dining on a 1 course meal.

Odd using Classic99 I got after 5 hours TI Basic:

image.thumb.png.b7a715e20c2af242420d730c2d36cbb1.png

RXB:

image.thumb.png.35c2c4c3025e3f5ee5c81bb545baee0e.png

I started them at same time within 1 second of each and started TI Basic first!

 

I did this test twice so I do not see how you could possibly get those numbers?

 

I should explain that the longer this runs the worse TI Basic gets as it puts all values into VDP memory and has to flush and restart.

That is that lag you get in TI Basic at times and what is going on in VDP that is much slower then RAM.

Edited by RXB
  • Thanks 1

Share this post


Link to post
Share on other sites
6 hours ago, apersson850 said:

I don't see the point at all in working with the math routines in Extended BASIC. Or any BASIC, for that matter. They are perfect for high accuracy computations, when you need them.

What BASIC could benefit from is instead integer variables, perhaps with the famous VAR1% notation. Thus you could use them for all indexing and other such stuff, where no floating point math is required. They consume less memory and the math routines would be as simple as they are in Forth. Or in Pascal, for that matter, where you already have the two data types integer and real.

 

Talking about Pascal, the p-system is a better development environment than BASIC ever was, so the idea of making a side cart which emulates the p-code card is perhaps better to spend your time on. It's quite a bit faster than BASIC, in spite of the interpreter for the p-code. And easy to augment with assembly routines, for the most time critical parts.

I would need to add another XB ROM in order to fix this issue, you see the way the GPL GROM and XB ROM code is written is based on Floating Point only.

Floating Point takes way more time to even input let alone the time to calculate takes even longer then any integer calculation.

I could keep the inputs at Floating Point but would need a ton of GPL and Assembly code to make this work.

So I have already looked into this, and it would no longer be backwards compatible with XB as most of XB is designed to work with Floating Point.

Same for TI Basic, I could spend a year making a Integer only based XB that would be much faster, but all programs would need major rewrites.

  • Thanks 1

Share this post


Link to post
Share on other sites

Thank you, Rich. Another step forward. So what is your suggestion, how RXB should get improved best?

Edited by Sid1968
  • Thanks 1

Share this post


Link to post
Share on other sites

This reminds me of the basic compiler, which *ALSO* substitutes integer math for floating point math (for the same reason.)

 

Perhaps a revisiting of Carmac's "magic number" based approach would be a good compromise?

https://blog.dave.io/0x5f3759df-a-true-magic-number/

 

Still integer math, but returns values approximating floating point in complexity.

 

A better question to ask oneself--  How many times does FP math end up getting a rounded result anyway, and what is the largest significant decimal depth used?

Armed with that, a "not fully accurate, but good enough because the program rounds it off anyway" integer math approach should be possible, that would not break most software.

Edited by wierd_w
  • Thanks 1

Share this post


Link to post
Share on other sites
7 hours ago, apersson850 said:

I don't see the point at all in working with the math routines in Extended BASIC. Or any BASIC, for that matter. They are perfect for high accuracy computations, when you need them.

What BASIC could benefit from is instead integer variables, perhaps with the famous VAR1% notation. Thus you could use them for all indexing and other such stuff, where no floating point math is required. They consume less memory and the math routines would be as simple as they are in Forth. Or in Pascal, for that matter, where you already have the two data types integer and real.

 

Talking about Pascal, the p-system is a better development environment than BASIC ever was, so the idea of making a side cart which emulates the p-code card is perhaps better to spend your time on. It's quite a bit faster than BASIC, in spite of the interpreter for the p-code. And easy to augment with assembly routines, for the most time critical parts.

 +1 for VAR1% like AppleSoft Basic.

 

Another idea is a declaration that pre-scan would find:

for instance:

!INTEGER I

 

Here is a Texas Instruments approved syntax:

 

 

TI BASIC on the 990 had this format:

 

REAL A,B,C

INTEGER I,J,K

DECIMAL [precision] D,E,F

where precision is a number of digits.

 

You can change the default type of all variables like so:

INTEGER ALL

the default is

REAL ALL

 

References:

 

http://bitsavers.trailing-edge.com/pdf/ti/990/basic/

 

TI BASIC Reference Manual, revised December 1983

  • Thanks 1

Share this post


Link to post
Share on other sites
33 minutes ago, wierd_w said:

This reminds me of the basic compiler, which *ALSO* substitutes integer math for floating point math (for the same reason.)

 

Perhaps a revisiting of Carmac's "magic number" based approach would be a good compromise?

https://blog.dave.io/0x5f3759df-a-true-magic-number/

 

Still integer math, but returns values approximating floating point in complexity.

 

A better question to ask oneself--  How many times does FP math end up getting a rounded result anyway, and what is the largest significant decimal depth used?

Armed with that, a "not fully accurate, but good enough because the program rounds it off anyway" integer math approach should be possible, that would not break most software.

When it comes to graphics ALWAYS! 

Floating Point 17.876032 is just 18, but that calculation took more time then needed just to round up or down.

 

 

  • Thanks 1

Share this post


Link to post
Share on other sites
6 minutes ago, FarmerPotato said:

 +1 for VAR1% like AppleSoft Basic.

 

Another idea is a declaration that pre-scan would find:

for instance:

!INTEGER I

 

Here is a Texas Instruments approved syntax:

 

 

TI BASIC on the 990 had this format:

 

REAL A,B,C

INTEGER I,J,K

DECIMAL [precision] D,E,F

where precision is a number of digits.

 

You can change the default type of all variables like so:

INTEGER ALL

the default is

REAL ALL

 

References:

 

http://bitsavers.trailing-edge.com/pdf/ti/990/basic/

 

TI BASIC Reference Manual, revised December 1983

What I envisioned is just Integer numbers for Graphics after all there is no row and column 17.8 or pixel at that location.

Thus all math dealing with screen graphics are integer only, and Texas Instruments should have thought of that instead of making everything Floating Point only.

Edited by RXB
misspelling
  • Thanks 1

Share this post


Link to post
Share on other sites

but not all divisions will be for graphics that align to real discretized elements (like pixels, cols, rows, etc..) though.  Some will be for things you really do want decimals for, like say-- the handful of "Home finance" programs, which would need several significant decimals to handle things like compound interest correctly.

 

The question was, given the full set of all existing basic programs that use FP division/multiplication, what is the maximally needed precision-- and, once you know that, what is the magic number to achieve that level of precision with integer math using a Carmac like approach.

 

This would allow those programs to still run correctly, without invoking the complex set of crazy that is floating point math on a processor without a dedicated set of ALUs for that process (Eg, No FPU). 

  • Thanks 1

Share this post


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

I started them at same time within 1 second of each and started TI Basic first!

 

I did this test twice so I do not see how you could possibly get those numbers?

 

I should explain that the longer this runs the worse TI Basic gets as it puts all values into VDP memory and has to flush and restart.

That is that lag you get in TI Basic at times and what is going on in VDP that is much slower then RAM.

You posted this video in 2014:

https://youtu.be/QsTtF3Fe3Po

In this video you are demonstrating the new random number generator in RXB. After running for 2:27:37 you get 532913 iterations for TI BASIC

473222 iterations for RXB

That jibes well with my one minute test showing BASIC running about 12% faster. (3329 vs 2990)

 

Now you say that after running for five hours (more than twice as long) you get:

391427 iterations for TI BASIC

492782 iterations for RXB

There is something very wrong here. Your most recent test show both programs to be running at half speed and with RXB having a considerable speed advantage.

 

Your comment  about "flush and restart" is total BS.  I believe you are referring to the "garbage collection" and this only happens when you are using strings.

Edited by senior_falcon
  • Like 1
  • Sad 2

Share this post


Link to post
Share on other sites

Gentlemen, that discussion dont help in this thread. I think we saw enough of the problems of RXB in the testprograms. Now please lets talk about improving RXB. I want a positiv discussion only with the target to help and improve. 🙂

Edited by Sid1968
  • Like 1

Share this post


Link to post
Share on other sites
8 hours ago, Sid1968 said:

Where do i find the p-system? Do it run on the FinalGROM 99?

If the p-system is so good, it would be interesting if you run Basictestprogram 2 translated to Pascal on it. 🙂

 

10 FOR I=1 TO 15000
20 A=I*(2+I)
30 NEXT I
40 PRINT A

The p-system, as it's implemented on the 99/4A, is an operating system stored on an expansion card, designed to sit in the peripheral expansion box. Or to be attached to the side of the console, if you look at the early version.

To my knowledge, it has never been cloned as a piece of hardware.

 

Running that same program in Pascal isn't too useful, since a program like this one

program looptest;

var i: integer;
  a: real;

begin
  for i := 1 to 15000 do
    a := i*(2+i);
  next i;
  writeln(a);
end.

would run the same floating point math routines as BASIC does.

Using integers give the same problem as with integers in Forth. You can't multiply 15000 by 15002 and get a result within 16 bits.

UCSD Pascal has a special data type, called long integers, that could be used. I don't know how efficient that implementation is, though. But they can be 36 digits long, so they are big enough.

 

  • Like 1
  • Thanks 1

Share this post


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

You posted this video in 2014:

https://youtu.be/QsTtF3Fe3Po

In this video you are demonstrating the new random number generator in RXB. After running for 2:27:37 you get 532913 iterations for TI BASIC

473222 iterations for RXB

That jibes well with my one minute test showing BASIC running about 12% faster. (3329 vs 2990)

 

Now you say that after running for five hours (more than twice as long) you get:

391427 iterations for TI BASIC

492782 iterations for RXB

There is something very wrong here. Your most recent test show both programs to be running at half speed and with RXB having a considerable speed advantage.

 

Your comment  about "flush and restart" is total BS.  I believe you are referring to the "garbage collection" and this only happens when you are using strings.

Dude everything including NUMBERS are running in TI Basic, this is a fact you seem to not understand that I know full well as I know GPL and you do not.

Hell this is even mentioned in EA manual, and I do not get why you are so hostile at me.

If TI Basic is so much faster how come no one is using it over XB or any other XB versions? (Considering for 20 years everyone call TI Basic slow?)

By the way XB and RXB are the same except for some GPL modifications I have done. But that just indicates another attack on my character huh?

 

Comparing Language speeds had this nugget from Tursi:

"The goal of the "optimized" column is "how fast can the same environment be made to run by a skilled developer", and it's no longer the same environment. Likewise I would reject stepping outside the language with assembly subroutines and the like. ;)"

Edited by RXB
  • Like 1
  • Sad 1

Share this post


Link to post
Share on other sites
9 minutes ago, chue said:

Slightly related - Here's another discussion on benchmarking languages on the TI

 

 

Thank you. In this case our basictestprogram 2 is of most interest, because it showed some speedissues in RXB. ;-)

Edited by Sid1968

Share this post


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

Thank you. In this case basictestprogram 2 is of most interest, because it show some speedissues in RXB. ;-)

Look 80% of RXB is exactly the same as XB, I just added some routines and some work slightly faster and most are exactly the same speed.

 

I do not get this confusion of why XB and RXB are somehow magically different when over 80% is exactly the same?

  • Thanks 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

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