Jump to content
Bones-69

RXB - Rich Extended Basic

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

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
Share on other sites
Posted (edited)

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
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!

 

Share this post


Link to post
Share on other sites
Posted (edited)
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

Share this post


Link to post
Share on other sites

Thanks, Rich, but I'm still not finding a download link on either of those posts. Am I blind, crazy, or is the link just not there?

Share this post


Link to post
Share on other sites
7 minutes ago, majestyx said:

Thanks, Rich, but I'm still not finding a download link on either of those posts. Am I blind, crazy, or is the link just not there?

Found the post:

 

You have to find the post that says june 2016

 

Rich_Gilbertson.zip

  • Thanks 2

Share this post


Link to post
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

Share this post


Link to post
Share on other sites
Posted (edited)

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
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

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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 3

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites

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

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