Jump to content
IGNORED

RXB - Rich Extended Basic


Bones-69

Recommended Posts

These are really nice features Rich.

 

I am wondering about the wording in the memory display.

 

Your words. My understanding

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

37CB VDP Free Address VDP End Address

 

FFE7 Program Free Address Program End Address

A040 Program End Address Program 1st Address

 

Is this because RX BASIC builds programs downwards in memory? (ie from highest address to lowest)

 

(You have inspired me to improve the memory report in Camel Forth tools.)

XB in general uses highest memory address (FREE) to lowest memory address (END).

In VDP it goes from >37CB top to bottom of VDP STACK which is >0958 + 64 bytes.

Same goes for RAM in upper 24K it goes from >FFE7 highest address (FREE) to lowest memory address (END) >A040

 

I just show the SAMS memory pages being used also.

  • Like 1
Link to comment
Share on other sites

Hey Rxb :)

What about expanding HCHAR and VCHAR by allowing a negative repetition number?

If the number is negative, it reverses the direction.

HCHAR by default repeats to the right. If negative it would repeat to the left instead.

VCHAR by default repeats downwards. If negative it would repeat upwards.

Just an idea from reading your RXB documentation.

  • Like 1
Link to comment
Share on other sites

Hey Rxb :)

What about expanding HCHAR and VCHAR by allowing a negative repetition number?

If the number is negative, it reverses the direction.

HCHAR by default repeats to the right. If negative it would repeat to the left instead.

VCHAR by default repeats downwards. If negative it would repeat upwards.

Just an idea from reading your RXB documentation.

Now that is a great idea that is quite possible to do.

And not that much work, this would not take me much to do....working on that today!

 

Thanks

  • Like 5
Link to comment
Share on other sites

Hey Rxb :)

What about expanding HCHAR and VCHAR by allowing a negative repetition number?

If the number is negative, it reverses the direction.

HCHAR by default repeats to the right. If negative it would repeat to the left instead.

VCHAR by default repeats downwards. If negative it would repeat upwards.

Just an idea from reading your RXB documentation.

Done!

In RXB you can now do:

 

CALL HCHAR(24,32,65,-768)

 

And it starts at bottom last character and goes right to left bottom to top filling screen with letter A

Or

 

CALL VCHAR(24,32,65,-768)

 

But RXB is super cool you can do:

 

CALL VCHAR(24,32,42,-384,1,1,42,384)

 

This one starts at bottom going up each line going right to left till middle of screen then does a normal VCHAR from top to bottom left to right to middle of screen in a single command.

 

Will make a Youtube of it....

Edited by RXB
  • Like 3
Link to comment
Share on other sites

  • 2 weeks later...

Well next step is to add same feature from HCHAR and VCHAR to HGET and VGET in RXB.

 

Normal RXB is CALL HGET(row,col,length,string-variable) in version 2015 RXB

 

CALL HGET(row,col,-length,string-variable) in next version of RXB will get a negative string length, 

so if row=10 and col=12 and length is -4 it turns col into 12-4=8 and gets the string off screen into string-variable.

 

Just something extra that did not take much effort to add to RXB.

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

With the search feature not working yet due to the forum update and this link from the resources thread:

 

not containing anything to download, can someone point me to where I can download the manual for RXB?

 

Also, am I right in presuming that the largest program size that can be written is 24488 bytes (not including assembly add-ons), even with SAMS memory? In other words, the largest program that can be stored is that size and there is no way to utilize additional SAMS memory as program space. I've seen Rich's IN THE DARK but that appears to be a rather small program that loads data to the SAMS card, not program code.

 

Thanks!

 

Link to comment
Share on other sites

5 hours ago, majestyx said:

With the search feature not working yet due to the forum update and this link from the resources thread:

 

not containing anything to download, can someone point me to where I can download the manual for RXB?

 

Also, am I right in presuming that the largest program size that can be written is 24488 bytes (not including assembly add-ons), even with SAMS memory? In other words, the largest program that can be stored is that size and there is no way to utilize additional SAMS memory as program space. I've seen Rich's IN THE DARK but that appears to be a rather small program that loads data to the SAMS card, not program code.

 

Thanks!

 

HEY BUDDY!

 

 

 

You can find it here just click on the new link for RXB in there too.

Rich

 

P.S. I am working on a new version of RXB 2019 or 2020 and will come out with IN THE DARK TOO 

different game and will have assembly in it also. Also I have a way to run multiple assembly program

from XB command mode at same time. All new stuff no one has done yet.

Edited by RXB
Link to comment
Share on other sites

Thanks for the download link, Rich! I swear, I still see no link on any of the messages. This is what I see:

 

image.thumb.png.7295cd5d84611e8d1da7bad811f293a5.png

 

Just your message with no attachment. Anyway, thanks for attaching it to your previous message.

 

As I get the time, my next project is going to use RXB. It's more-so a project I've been wanting to do for myself and likely won't have much appeal to very many other people, but it's another one of those "can it be done?" deals that I'd love to see work. Thus my question of if there is a hard limit to the amount of program space available, which, scanning back through the discussion here, appears to be answered with a definite YES. Guess I need to brush up on how to link program pieces should it come to that.

 

Thanks for your continued work on making Extended BASIC even more extended~!

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

Quick question and I think I know the answer already...

 

Is there a way to chain RXB programs and still retain variable values? Based on a few discussions I've seen in the Development forum, this doesn't appear to be possible except in XB256 without either saving them to disk and then reloading them back into the newly loaded program, or moving values to a part of memory that doesn't get wiped out when the new program runs.

 

I find the XB manual to be a bit deceiving with this statement about the RUN command being used as a statement:

 

Quote

RUN as a Statement — RUN can be used as a statement as well as a command. RUN has also been modified to allow you to specify which program to run. As a result, one program can load and run another program from a diskette. You can, therefore, write programs of almost unlimited size by breaking them into pieces and letting each segment run the next.

 

Umm, no. If you can't retain variable values, you cannot write programs of almost unlimited size. Of course, this is never mentioned nor given any explanation of how it works in the manual.

 

If there is a simple way to do this, please point me in the right direction.

 

EDIT: After doing some more digging, it looks like the CALL LINK("RUNL1",A$) from XB256 can be used in conjunction with RXB. I'm making plans in case I end up running out of memory on my new project.

Edited by majestyx
Link to comment
Share on other sites

  • 2 months later...

I'm hoping you can explain this one to me, carrying on our conversation from the SAMS/RXB one I started. For the following command:

 

CALL MOVES("VR",2079,0,8192)

 

...why is the value 2079 used? I understand that the ZERO is where the screen data is in VDP memory and the 8192 is where the data is being moved to in the TI's lower 8K of RAM. 2079 just seems like such an odd figure so I'm wondering where this comes from. Again, this is due to my incomplete of knowledge of memory mapping and the various types of memory that the TI uses. I thought that an entire screen took up 768 bytes (32x24) and 2079 isn't a multiple of that.

 

Thanks!

Edited by majestyx
Link to comment
Share on other sites

7 hours ago, majestyx said:

I'm hoping you can explain this one to me, carrying on our conversation from the SAMS/RXB one I started. For the following command:

 


CALL MOVES("VR",2079,0,8192)

 

...why is the value 2079 used? I understand that the ZERO is where the screen data is in VDP memory and the 8192 is where the data is being moved to in the TI's lower 8K of RAM. 2079 just seems like such an odd figure so I'm wondering where this comes from. Again, this is due to my incomplete of knowledge of memory mapping and the various types of memory that the TI uses. I thought that an entire screen took up 768 bytes (32x24) and 2079 isn't a multiple of that.

 

Thanks!

That saves everything-the screen image table 0-767,sprite attribute table from 768-879, pattern table from 1008-1919,sprite motion table 1920-2031,color table 2032-2079.

If you're not changing colors, character definitions, sprites, etc. then you just need to save the screen image table from 0-767

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

18 hours ago, majestyx said:

I'm hoping you can explain this one to me, carrying on our conversation from the SAMS/RXB one I started. For the following command:

 


CALL MOVES("VR",2079,0,8192)

 

...why is the value 2079 used? I understand that the ZERO is where the screen data is in VDP memory and the 8192 is where the data is being moved to in the TI's lower 8K of RAM. 2079 just seems like such an odd figure so I'm wondering where this comes from. Again, this is due to my incomplete of knowledge of memory mapping and the various types of memory that the TI uses. I thought that an entire screen took up 768 bytes (32x24) and 2079 isn't a multiple of that.

 

Thanks!

OMG 4 times I have posted an answer on AtariAge and it did not take any of them????

 

2079 is number of bytes.

From 0 to 2079 (>081F in Hex) bytes in VDP are moved to RAM.

Link to comment
Share on other sites

10 hours ago, senior_falcon said:

That saves everything-the screen image table 0-767,sprite attribute table from 768-879, pattern table from 1008-1919,sprite motion table 1920-2031,color table 2032-2079.

If you're not changing colors, character definitions, sprites, etc. then you just need to save the screen image table from 0-767

Correct, I just defaulted to ENTIRE VDP RAM only to make it less complicated to use.

Nothing is preventing anyone from using just 768 bytes of Screen only.

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

Thanks to both of you for the responses.

 

I believe someone, maybe one of you, had pointed me to this very useful blog entry which goes into more detail of how the TI's memory is mapped:

 

 

Man, I wish I had known about text mode before actually programming my baseball sim! Of course, that mode isn't mentioned in the XB manual since it looks like there is no way to enter it from XB, but I do see that there is a POKER command that can be used to enter it. 40 columns makes a huge difference for screen real estate. I may end up attempting to use that. Since there is no rush in getting this thing done, I'm thinking it might be worth it to go back to attempt using that mode.

 

It's also pretty cool all of the new stuff I'm learning about this computer which makes it much more interesting to program! The additional tools both of you have provided makes it a lot easier too.

 

EDIT: Looks like I spoke too soon. It looks like it's not as easy as I thought it would be to use text mode. Well, it was worth trying!

Edited by majestyx
Link to comment
Share on other sites

Man, I wish I had known about text mode before actually programming my baseball sim! Of course, that mode isn't mentioned in the XB manual since it looks like there is no way to enter it from XB, but I do see that there is a POKER command that can be used to enter it. 40 columns makes a huge difference for screen real estate. I may end up attempting to use that. Since there is no rush in getting this thing done, I'm thinking it might be worth it to go back to attempt using that mode.

 

EDIT: Looks like I spoke too soon. It looks like it's not as easy as I thought it would be to use text mode. Well, it was worth trying!

 

Take a look in the thread "40 column routine or early version of XB24 for XB" Page 2, post #30. That may do what you want.

  • Like 4
Link to comment
Share on other sites

On 9/12/2019 at 8:21 AM, majestyx said:

Thanks to both of you for the responses.

 

I believe someone, maybe one of you, had pointed me to this very useful blog entry which goes into more detail of how the TI's memory is mapped:

 

 

Man, I wish I had known about text mode before actually programming my baseball sim! Of course, that mode isn't mentioned in the XB manual since it looks like there is no way to enter it from XB, but I do see that there is a POKER command that can be used to enter it. 40 columns makes a huge difference for screen real estate. I may end up attempting to use that. Since there is no rush in getting this thing done, I'm thinking it might be worth it to go back to attempt using that mode.

 

It's also pretty cool all of the new stuff I'm learning about this computer which makes it much more interesting to program! The additional tools both of you have provided makes it a lot easier too.

 

EDIT: Looks like I spoke too soon. It looks like it's not as easy as I thought it would be to use text mode. Well, it was worth trying!

Before you use Text mode you have to change locations of some tables including the Screen image table in XB.

The main reason is the VDP Buffer Rollout at >03C0 and many other uses in that area that Text Mode would crash.

[0209]               ***********************************************************
[0210]               *    VDP addresses
[0211] 02E2          NLNADD EQU  >02E2             New LiNe ADDress
[0212] 02FE          ENDSCR EQU  >02FE             END of SCReen address
[0213] 0371          LODFLG EQU  >0371             Auto-boot needed flag
[0214] 0372          START  EQU  >0372             Line to start execution at
[0215] 0376          SYMBOL EQU  >0376             Saved symbol table pointer
[0216] 0382          SPGMPT EQU  >0382             Saved PGMPTR for continue
[0217] 0384          SBUFLV EQU  >0384             Saved BUFLEV for contiue
[0218] 0386          SEXTRM EQU  >0386             Saved EXTRAM for continue
[0219]               * SAVEVP EQU  >0388           Saved VSPRT for continue
[0220]               * ERRLN  EQU  >038A           On-error line pointer
[0221] 038C          BUFSRT EQU  >038C             Edit recall start addr (VARW)
[0222] 038E          BUFEND EQU  >038E             Edit recall end addr (VARA)
[0223] 0392          TABSAV EQU  >0392             Saved main symbol table ponte
[0224] 0396          SLSUBP EQU  >0396             Saved LSUBP for continue
[0225] 0398          SFLAG  EQU  >0398             Saved on-warning/break bits
[0226] 039A          SSTEMP EQU  >039A             To save subprogram program ta
[0227] 039C          SSTMP2 EQU  >039C             Same as above. Used in SUBPRO
[0228]               * RXB PATCH CODE * MOVED TO >03B8 SIZXPT (Size ACCEPT AT)
[0229]               * MRGPAB EQU  >039E             MERGEd temporary for pab pt
[0230] 039E          PMEM   EQU  >039E             UPPER 24K MEMORY
[0231] 03B8          MRGPAB EQU  >03B8             MERGEd temporary for pab ptr
[0232]               *----------------------------------------------------------
[0233]               * Added 6/8/81 for NOPSCAN feature
[0234] 03B7          PSCFG  EQU  >03B7
[0235]               *----------------------------------------------------------
[0236]               * RXB PATCH CODE SWAP CONFLG & >35D7 FOR CONSOLE MENU FLAG
[0237]               *    Flag 0:  99/4  console, 5/29/81
[0238]               *         1:  99/4A console
[0239] 03BB          CONFLG EQU  >03BB
[0240]               *----------------------------------------------------------
[0241]               * Temporary
[0242] 0374          NOTONE EQU  >0374             NO-TONE for SIZE in ACCEPT us
[0243]               *                              in FLMGRS (4 bytes used)
[0244] 0388          SAVEVP EQU  >0388
[0245] 038A          ERRLN  EQU  >038A
[0246] 03AC          ACCVRW EQU  >03AC             Temoporary used in ERRZZ, als
[0247]               *                              used in FLMGRS
[0248] 03B0          VALIDP EQU  >03B0             Use as two values passing fro
[0249] 03B2          VALIDL EQU  >03B2             VALIDATE code to READL1
[0250] 03BC          OLDTOP EQU  >03BC             Temporary used in ERRZZ, also
[0251] 0820          CRNBUF EQU  >0820             CRuNch BUFfer address
[0252] 08BE          CRNEND EQU  >08BE             CRuNch buffer END
[0253] 08C0          RECBUF EQU  >08C0             Edit RECall BUFfer
[0254] 0958          VRAMVS EQU  >0958             Default base of value stack
[0255] 0390          CNSTMP EQU  >0390             Use as temporary stored place
[0256] 03C0          VROAZ  EQU  >03C0             Temporary VDP Roll Out Are
[0257]               ***********************************************************

Senior Falcon has a layout he uses in XB.

Link to comment
Share on other sites

  • 2 weeks later...

I've put it off long enough. I have a FinalGrom99 coming, and i intend to load RXB into it dive into it head first, just like i did TI Basic and Extended Basic.

In the meantime though, i fired up RXB in classic 99 and wrote my first program in RXB, a simple hello world:

1 !HELLO WORLD W/VPUT&HPUT
5 CALL CLEAR
10 WHERE(0)=1 :: WHERE(1)=2 :: WHERE(2)=5 :: WHERE(3)=1
15 MSG1$="HELL" :: MSG2$="WORLD!"
20 CALL VPUT(WHERE(0),WHERE(1),MSG1$)
25 CALL HPUT(WHERE(2),WHERE(3),MSG2$)
30 GOTO 30

 

I'm going to hold off exploring RXB any much further until the FinalGrom99 gets here and i can run it on real metal, as i want this learning experience to be just as much of a challenge as my first exposure to the TI. I need immersion, and nothing is more immersive then the real deal.

  • Like 4
Link to comment
Share on other sites

  • 2 months later...

Sorry to be the bearer of bad news, but there is a bug in the fast TI BASIC random number generator you included in RXB. When running TMLDEMO using The Missing Link with RXB, the program exited  with an error message when it came to "Random Circles." Here is the offending piece of code in line 3160:

CALL LINK("CIRCLE",.5+RND*192,.5+RND*240,5+RND*35,0,J,1)

After some experimenting I found that any time you pass a random number to an assembly subroutine there would be a crash, error message, or other misbehavior. This does not happen with the normal XB random number routine. 

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

16 hours ago, senior_falcon said:

Sorry to be the bearer of bad news, but there is a bug in the fast TI BASIC random number generator you included in RXB. When running TMLDEMO using The Missing Link with RXB, the program exited  with an error message when it came to "Random Circles." Here is the offending piece of code in line 3160:

CALL LINK("CIRCLE",.5+RND*192,.5+RND*240,5+RND*35,0,J,1)

After some experimenting I found that any time you pass a random number to an assembly subroutine there would be a crash, error message, or other misbehavior. This does not happen with the normal XB random number routine. 

I would suspect if you tried the same routine in TI Basic with CALL LINK("CIRCLE",.5+RND*192,.5+RND*240,5+RND*35,0,J,1)

 

It would also crash as I used EXACTLY THE SAME CODE AS TI BASIC WITH NO CHANGES.

 

I ran a couple hundred programs to test if I could crash RXB 2015 RND and only found one problem but it required a CALL LOAD to create that error.

As it was a anomaly I rejected it so guess some other problem is the result, i.e. out of range to large or to small or LINK error. 

Link to comment
Share on other sites

15 hours ago, Tursi said:

It's neat that TML runs with RXB though... I didn't expect that. :)

 

I wonder what the crash could be, though... especially since you're doing so much math on it first. Surely only the resulting number is passed to Asm?

As I said looking at the code I can see no cause for this but will keep looking.

 

RXB 2015

[0905]               ***********************************************************
[0906]               * RXB BASIC RND REPLACEMENT FROM TI BASIC
[0907] A2A3 BE,4A,3F NRND   ST   >3F,@FAC       * Exponent    
[0908] A2A6 BE,10,4B        ST   >4B,@VAR5      * Loop counter
[0909] A2A9 02,63    NRND1  RAND >63            * 0?
[0910] A2AB 8E,78           CZ   @RANDOM        * No, go on
[0911] A2AD 42,B9           BR   NRND3     
[0912] A2AF 92,4A           DEC  @FAC           * 0?
[0913] A2B1 8E,4A           CZ   @FAC           * End with 0
[0914] A2B3 62,C6           BS   NRND4          * Go on
[0915] A2B5 42,A9           BR   NRND1

99/4 GPL-ASSEMBLER (Pass 3) correct                                   PAGE 0016 
EQUATES EXEC-359
[0916] A2B7 02,63    NRND2  RAND >63            * Till 100
[0917] A2B9 BC,90,10 NRND3  ST   @RANDOM,*VAR5  * All digits
       A2BC 78
[0918] A2BD D6,10,51        CEQ  >51,@VAR5      * Till >8351
[0919] A2C0 62,C8           BS   NRND5 
[0920] A2C2 90,10           INC  @VAR5          * Increase loop counter
[0921] A2C4 42,B7           BR   NRND2 
[0922] A2C6 86,4B    NRND4  CLR  @FAC1          * Set 0
[0923] A2C8 0F,75    NRND5  XML  CONT
[0924]               ***********************************************************

TI BASIC

Basic RND:
4F00 : ST @>834A,>3F Exponent
4F03 : ST @>8310,>4B Loop counter
4F06 : RAND >63 till 100
4F08 : CZ @>8378 0?
4F0A : BR GROM@>4F16 No, go on
4F0C : DEC @>834A -1
4F0E : CZ @>834A 0?
4F10 : BS GROM@>4F23 End with 0
4F12 : BR GROM@>4F06 Go on
4F14 : RAND >63 till 100
4F16 : ST *>8310,@>8378 All digits
4F1A : CEQ @>8310,>51 Till >8351
4F1D : BS GROM@>4F25
4F1F : INC @>8310 Increase loop counter
4F21 : BR GROM@>4F14
4F23 : CLR @

As you can see the code is the same in TI INTERN as my code in RXB 2015, error? (where?)

Edited by RXB
Added Text.
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...