RXB - Rich Extended Basic

[senior_falcon]

I'm sure it's a simple fix that Rich will work out in the next day or two. It's frustrating to find that something that has always worked suddenly stops. These things happen...

[electricfling]

On 5/14/2022 at 9:01 PM, RXB said:

RELEASE RXB 2022C updated bugs found by Archadeshopper and optimized Assembly so works better.

 

 

RXB 2022C.zip 31.23 MB · 16 downloads

Unfortunately, access to the three floppy drives of the NANOPEB in Rich Editor & Assembler V=2022 does not work in this version either.
 

The RXB package 2022 is called up on the FINALGROM99.
If the D Directory option is selected, the TI-99 hangs. In the RXB this always works perfectly.

This problem started with RXB version 2020.

It is certainly difficult to find where the problem lies with this behaviour. 

Nice greeting Gernot

[RXB]

On 5/14/2022 at 5:11 PM, HOME AUTOMATION said:

Looks like CALL CLEAR has been ...cleared!

This could perhaps effect compatibility.

I think I swapped ROMs by accident with one a test version and other the one intended.

 

[RXB]

On 5/15/2022 at 3:28 PM, Tursi said:

To be a little more direct, it does appear that 2022C does not recognize CALL CLEAR... unless I ported it incorrectly into Classic99?

 

No you are correct the RXBC.bin I use in on desktop and I copied the temp one I was working on instead.

 

 

RXBC.bin RXBG.bin

[RXB]

23 minutes ago, electricfling said:

Unfortunately, access to the three floppy drives of the NANOPEB in Rich Editor & Assembler V=2022 does not work in this version either.
 

The RXB package 2022 is called up on the FINALGROM99.
If the D Directory option is selected, the TI-99 hangs. In the RXB this always works perfectly.

This problem started with RXB version 2020.

It is certainly difficult to find where the problem lies with this behaviour. 

Nice greeting Gernot

So RXB 2022 does not with NANOPEB? 

RXB 2022 to RXB 2022C all have INIT files in ROM now, also XB uses the Character table loaded from ROM3.

Sounds like a DSR conflict as REA 2022 is just the old REA 2015 with a small number of upgrades like INIT in ROM3.

[RXB]

Dang well easy fix here is RXB 2022D

 

Like I said I accidently swapped files.

 

 

[RXB]

RXB 2022D.zip

[RXB]

After we spend days on Atari Age and a long ZOOM discussing LINE TO LONG hack and Myarc XB 3 it occured to me how to get single line XB programs expanded.

I will release a BETA of a RXB titled Mega RXB 

Here is a map of the idea:

Every location in memory of VDP is the same except for Crunch Buffer size, location of Edit/REDO buffer and VDP Stack location.

>0820 Crunch buffer 254 BYTES (1 byte for Length) to >091F

>0920 Editor/REDO Buffer 762 BYTES to >0C1A (1 byte for flag) >0C1B

>0C1C VDP Stack location 16 bytes

>0C2C First Free VDP address so 763 bytes less VDP then normal XB.

 

So what could MEGA RXB do, well how about program lines 254 bytes of Tokens instead of current 160 Tokens.

Thus current single line is 160 Tokens, and this would increase 95 tokens for a single program line.

This would help cut down program lines in XB programs and one heck of a contest for single program line contests.

 

P.S. Would add a new feature of MERGE format DF255 Merge files instead of 163 Merge size now.

[senior_falcon]

4 hours ago, RXB said:

Every location in memory of VDP is the same except for Crunch Buffer size, location of Edit/REDO buffer and VDP Stack location.

>0820 Crunch buffer 254 BYTES (1 byte for Length) to >091F

>0920 Editor/REDO Buffer 762 BYTES to >0C1A (1 byte for flag) >0C1B

>0C1C VDP Stack location 16 bytes

>0C2C First Free VDP address so 763 bytes less VDP then normal XB.

 

So what could MEGA RXB do, well how about program lines 254 bytes of Tokens instead of current 160 Tokens.

Thus current single line is 160 Tokens, and this would increase 95 tokens for a single program line.

This would help cut down program lines in XB programs and one heck of a contest for single program line contests.

 

P.S. Would add a new feature of MERGE format DF255 Merge files instead of 163 Merge size now.

Through the years you have been insistent on maintaining backward compatibility when using RXB on an unexpanded console. Have you thought about the effects this would have using RXB on a a console without 32K? There are long programs that just barely fit when using normal XB on a bare console. If you take away 763 bytes it seems like there are a number of programs that could no longer be loaded or run.

 

As a side note, my personal feeling is that XB lines tend to be too long already. I much prefer to have shorter lines and more of them which makes programming and debugging much easier. For the 10 line contest, trying to squeeze as much code as possible into each line was a real pain, and I will never put myself through that again. But obviously, not everyone will feel this way.

[GDMike]

36 minutes ago, senior_falcon said:

Through the years you have been insistent on maintaining backward compatibility when using RXB on an unexpanded console. Have you thought about the effects this would have using RXB on a a console without 32K? There are long programs that just barely fit when using normal XB on a bare console. If you take away 763 bytes it seems like there are a number of programs that could no longer be loaded or run.

 

As a side note, my personal feeling is that XB lines tend to be too long already. I much prefer to have shorter lines and more of them which makes programming and debugging much easier. For the 10 line contest, trying to squeeze as much code as possible into each line was a real pain, and I will never put myself through that again. But obviously, not everyone will feel this way.

If I were an xb programming person, I'd rather it be 4-5 lines myself. Definitely not keen on troubleshooting super long lines.

[+OLD CS1]

1 hour ago, senior_falcon said:

But obviously, not everyone will feel this way.

Not I.  I like being able to bum as much into a single line as possible.  While this can be abused, it really does have its benefits sometimes.  Another one of those "allows bad behavior, but does not encourage it" things.

[GDMike]

Ok, is it time for 1 liner xb code again? Lol

[RXB]

9 hours ago, senior_falcon said:

Through the years you have been insistent on maintaining backward compatibility when using RXB on an unexpanded console. Have you thought about the effects this would have using RXB on a a console without 32K? There are long programs that just barely fit when using normal XB on a bare console. If you take away 763 bytes it seems like there are a number of programs that could no longer be loaded or run.

 

As a side note, my personal feeling is that XB lines tend to be too long already. I much prefer to have shorter lines and more of them which makes programming and debugging much easier. For the 10 line contest, trying to squeeze as much code as possible into each line was a real pain, and I will never put myself through that again. But obviously, not everyone will feel this way.

Yea very much why it is MEGA RXB and is a stand alone product, unlike RXB (year here)

[RXB]

8 hours ago, GDMike said:

If I were an xb programming person, I'd rather it be 4-5 lines myself. Definitely not keen on troubleshooting super long lines.

No one says you have to ever use :: ever.

[RXB]

8 hours ago, OLD CS1 said:

Not I.  I like being able to bum as much into a single line as possible.  While this can be abused, it really does have its benefits sometimes.  Another one of those "allows bad behavior, but does not encourage it" things.

I never have liked lots of line numbers vs not having as many.

With modern computers I can have lines with smaller fonts so text files can show in excess of 128 characters per line.

[+mizapf]

RPK for RXB 2022D

rxb2022d.rpk

[senior_falcon]

(Moved from "Strategy for efficiently storing and checking sets of boolean values in TI BASIC" to avoid further contamination of that thread)

4 hours ago, senior_falcon said:

WRONG! It is based on testing, and YOU did the testing.

In post #43 you quote Rasmus:

 

(Rasmus)

These are my results using Classic99 QI399.057:

TI BASIC: 10:24

XB: 3:43

RXB 2022A: 8:39

 

(RXB response)

I ran this test multiple times with same results: (this was looping 10000 times)

TI Basic 13 Minute 44 seconds

XB  13 Minute 9 seconds

XB 2.9 13 Minute 9 seconds

RXB 2022A 13 Minute 8 seconds

 

I trust that even you would have to agree that the results are not even close to being the same.

 

(RXB post #44)

OK RAN A 100000 LOOP TEST SO RESULTS ARE:

XB       = 37 Minutes 5 Seconds

XB 2.9 = 37 Minutes 6 Seconds

RXB     = 26 Minutes 2 Seconds

 

Please explain how looping 10 times as much only takes 3x longer for XB and 2x longer for RXB?

 

The text you wrote in #216 was:

"I wanted to dispute that RXB was slowest in CALL CLEAR so showed a test proving it was not.

This is to show FOR NEXT is very very consistant per any XB variant on the TI99/4A"

 

Naturally I assumed that this test was comparing the speeds of CALL CLEAR. Turns out it only tests the speed of a FOR/NEXT loop. The results here are fairly close to an actual TI running XB and TI BASIC. I apologize for misunderstanding what was being shown, but you have to admit that your text is confusing.

 

You still have to explain the strange results from your post #43 and #44.

 

 

Yea maybe I made a mistake and I do admit when wrong.

It is true the ALL >80 in GPL was about the same as an Assembly version of it so switched back to GPL version original.

CALL CLEARPRINT on the other hand has to be Assembly instead. (Clears columns 2 to 23 from row 1 to 24

 

You still have not explained the strange results from your post #43 and #44.

 

[MikeV]

On 5/17/2022 at 1:49 PM, RXB said:

RXB 2022D.zip 31.23 MB · 15 downloads

Hi Rich,

I like the font in RXB 2022 - very evenly spaced!

 

I am having some trouble with CALL HGET:

 

100 CALL CLEAR
110 A$="HELLO WORLD!"
120 CALL HPUT(1,1,A$)
140 CALL HGET(1,1,12,B$)
150 IF B$=A$ THEN CALL HPUT(5,1,"All is right with the World.")
160 CALL HPUT(10,1,A$) :: CALL HPUT(11,1,B$)
170 GOTO 170

 

Does not appear to work correctly in 2022 (or 2021), but does in 2020. I also tried it on the 2022D version. Thank you.

 

[RXB]

4 hours ago, MikeV said:

Hi Rich,

I like the font in RXB 2022 - very evenly spaced!

 

I am having some trouble with CALL HGET:

 

100 CALL CLEAR
110 A$="HELLO WORLD!"
120 CALL HPUT(1,1,A$)
140 CALL HGET(1,1,12,B$)
150 IF B$=A$ THEN CALL HPUT(5,1,"All is right with the World.")
160 CALL HPUT(10,1,A$) :: CALL HPUT(11,1,B$)
170 GOTO 170

 

Does not appear to work correctly in 2022 (or 2021), but does in 2020. I also tried it on the 2022D version. Thank you.

 

Thanks will have to find out what is going on here!

[senior_falcon]

5 hours ago, MikeV said:

I like the font in RXB 2022 - very evenly spaced!

 

Yes, the font is much better now.

[senior_falcon]

(Moved from "Something A Little Different" to this thread trying to avoid any further contamination of that thread)

8 hours ago, Reciprocating Bill said:

I observed that expansion RAM makes about a 1- 2% difference in Extended BASIC performance.  You said "That's just nuts."

 

Then Lee explained why there is "only a minor (1%-2%) increase in speed when the program is in RAM vs. VRAM."  

 

Since we're all happy, let's move on. 

 

(RXB response) Ok avoid the fact that you can not prove this in anyway.

 

If you have any curiosity, you can test this out yourself.

OLD DSK1.PROG2TEST then RUN and time it

 

CALL INIT then CALL LOAD(-31868,0,0,0,0) - This turns off the memory expansion

OLD DSK1.PROG2TEST

SIZE and you will see that no CPU memory is used, therefore it is running from VDP ram.

RUN and time it.

 

Report the results.

Edited May 31, 2022 by senior_falcon

[+OLD CS1]

12 hours ago, senior_falcon said:

(Moved from "Something A Little Different" to this thread trying to avoid any further contamination of that thread)

Also here:

 

 

 

[RXB]

13 hours ago, senior_falcon said:

(Moved from "Something A Little Different" to this thread trying to avoid any further contamination of that thread)

(RXB response) Ok avoid the fact that you can not prove this in anyway.

 

If you have any curiosity, you can test this out yourself.

OLD DSK1.PROG2TEST then RUN and time it

 

CALL INIT then CALL LOAD(-31868,0,0,0,0) - This turns off the memory expansion

OLD DSK1.PROG2TEST

SIZE and you will see that no CPU memory is used, therefore it is running from VDP ram.

RUN and time it.

 

Report the results.

CALL LOAD(-31868,0,0,0,0) 

XB in Classic99 crashes with error in 11176 every time.

RXB 2022 in Classic99 crashes with * INCORRECT STATEMENT

 

Will have to try on my Hardware TI99/4A behind me.

[senior_falcon]

Works fine in Classic99 and I just checked in JS99er and it works fine there as well.

Do the CALL LOAD first, then load the program from disk or type it in.

Edited May 31, 2022 by senior_falcon

[+TheBF]

So to be clear Rich, we are only talking about how fast the BASIC program is read by the interpreter.

Nothing else is under consideration.

 

I took Willy's three line program and ran it in XB with the PEB turned off and also with the PEB turned on.

I changed the count to 2000 to shorten the video times but we can see the time difference from the video runtime.

 

The only difference here is where the BASIC code is coming from. VDP RAM or CPU RAM.

 

VDP RAM:  23 seconds 

CPU RAM:  22 seconds

 

Difference= 4.5% faster from CPU RAM

 

Two videos attached