Jump to content
Bones-69

RXB - Rich Extended Basic

Recommended Posts

OK, I checked out the development thread and it leads back to this topic area of 35+ pages of posts. Thus far, I have found comments regarding RXB 2018, but have not seen an embedded file or link to where the file can be downloaded.

Still searching......

 

Beery

No, Rich has not let out into the wild, the 2018 or may be 2019 version as of yet.

Share this post


Link to post
Share on other sites

No, Rich has not let out into the wild, the 2018 or may be 2019 version as of yet.

Yea all the latest updates like CALL PRAM, HEX and SAMS are all not yet released....sorry have to finish a few things then new documents.

 

So yea 2019 at earliest.

Share this post


Link to post
Share on other sites

Abstract reasoning skills are high over here at HA. While reviewing commented source code, sometimes solutions just reach in... Comments in GPL are essential... otherwise my interpretations of GPL mnemonics yield less applicable speculations...

got commented code??? the more the merrier.

Share this post


Link to post
Share on other sites

Abstract reasoning skills are high over here at HA. While reviewing commented source code, sometimes solutions just reach in... Comments in GPL are essential... otherwise my interpretations of GPL mnemonics yield less applicable speculations...

 

got commented code??? the more the merrier.

 

Over the years I have taken the XB GPL Source and XB ROM source and keep adding in comments to explain what is going on.

Share this post


Link to post
Share on other sites

Does RXB support any V9938 capabilities such as Text2 mode for 80 columns, or any of the graphics modes? I did not see it in the 2015 docs. Would this be supported in the 2019 version?

 

If not, is there any other XB version with Text 2 mode and AMS capability?

 

Just trying to see what I can do with the 99/5C with the AMS and 9938 potential.

 

Beery

  • Like 3

Share this post


Link to post
Share on other sites

Does RXB support any V9938 capabilities such as Text2 mode for 80 columns, or any of the graphics modes? I did not see it in the 2015 docs. Would this be supported in the 2019 version?

 

If not, is there any other XB version with Text 2 mode and AMS capability?

 

Just trying to see what I can do with the 99/5C with the AMS and 9938 potential.

 

Beery

As far as I know the only Extended Basic that supported the 9938 was on the GENEVE only.

 

As for AMS or SAMS the only Extended Basic ever made that supports AMS or SAMS is RXB alone. (I mean built in support not something you have to load.)

 

I am going to support F18 or MK2 if it comes out, and if you do make a 99/5C I will take what I got from F18/MK2 support and make a 9938 verizon support.

 

The problem with TEXT MODE is that you can not test programs as in EDITOR MODE is 40 or 80 Columns and GRAPHICS MODE is 32 Columns?

 

A simple thing like PRINT A would crash as locations of Strings and Variables and buffers have to all be relocated to do this.

 

This will require a very extensive memory map in long run. Also you lose 100% of backwards compatibility entirely.

 

A more logical move would be to just use GRAPHICS MODE 3 where you have 4 times the pixels per screen and use it for Editor/Graphics modes.

 

:People keep being fixated on TEXT MODE that has crappy Graphics capabilities and forget the memory map for Text and Graphics are very different maps.

Edited by RXB

Share this post


Link to post
Share on other sites

Here is entire RXB GPL and ROM Source

I looked over some of your code yesterday... Not exactly light reading.

I'm still overwhelmed for now.

I imagine you must have put an awful lot of effort in on this.

Nice looking work! I hope others are doing better at this than I...

 

Thanks for the opportunity to contribute! :)

  • Like 2

Share this post


Link to post
Share on other sites

Thanks RXB has been a project I work on since 1992 and as you can see I have spent years pouring over the code and adding or patching it.

Everything of the original TI Extended Basic code is still there.

 

Anytime you see:

* RXB PATCH CODE

 

You will see the original code comment out with Asterisk and the new RXB code that replaced it, or GKXB code that was used.

  • Like 1

Share this post


Link to post
Share on other sites

Crap! Can not add HEX to list of new commands in TI XB ROMs as there is virtually just no space left for 4 bytes!!!!

 

Crazy that

 

HEXZ TEXT "HEX"

BYTE >E2

 

Will not fit!!!!

 

Last ditch is to use >B9 the spare token that TI never used and see if that works.....if not so much for adding any more new tokens presently unused.

 

There are 14 token that TI never used by the way. >80, >AB, >AC, >AD, >AE, >AF, >B9, >E2, >E3, >E4, >E5, >E6, >E7, >F2

 

Would be nice to add more tokens that work more like SEG$, INT, RND, POS, PI, and others.

 

 

(Would be great if someone with really good skill in Assembly could find some space in XB ROM >6000 to >6FFF for adding Tokens???? )

Edited by RXB

Share this post


Link to post
Share on other sites

Would be nice but the problem is REM is first in list and when you remove or sub it XB ROM crash with SYNTAX ERROR as PRESCAN before program starts will crash it.

 

The best solution is to get more space in XB ROMS and that would allow a fix.

Share this post


Link to post
Share on other sites

Some modifications I have made to RXB include PRAM (Program RAM) that allows change of

upper 24K memory selection address.

Or VDPSTACK where you can change location of the VDP STACK address.

 

So testing is taking longer then I thought as some address that have to be checked is in VDP

like >039E was MRGPAB for merging files so I moved it to >03B8 used for ACCEPT AT reset

with a bad value or error.

Made sense as if you are merging files you could not at same time be using ACCEPT AT routine.

So putting Program RAM END address at that location allowed changing Program space in

the upper 24K of RAM for XB Programs.

[0250]               * RXB PATCH CODE * MOVED TO >03B8 SIZXPT (Size ACCEPT AT)
[0251]               * MRGPAB EQU  >039E           MERGEd temporary for pab ptr
[0252] 039E          PMEM   EQU  >039E             UPPER 24K MEMORY

This is exiting for the TI99/4A as for the first time you can put assembly or data files in upper 24K without

without affecting XB program speed using my new routine CALL PLOAD that will load 4K Assembly or data

into any area of RAM in the TI99/4A.

If you have SAMS you can swap out RAM from a XB program having up to 960K of Assembly or data.

This does not even affect whatever support in lower 8K used also.

Edited by RXB
  • Like 2

Share this post


Link to post
Share on other sites

Well been testing new release of RXB and ran into snag.

Changed XB CALL LINK to use not only a LINK name but also ADDRESS.

Problem is if it has variables it crashes and attempting to figure out why?

 

CALL LINK("LOW") or CALL LINK(12574) both work exactly as designed, but....

 

CALL LINK("LINE",107,101) will crash???

or

CALL LINK("GCHAR",Q) will crash?

 

Now the variables are fetched by Assembly and used so program pointer should be pointing at the ")" and should work the same as no variable list? (But does not?)

Anyone have any idea why?

Share this post


Link to post
Share on other sites

From the MiniMemory manual
The LINK subprogram performs the following actions. (the second point is where your problem might lie)

*It builds the argument list, consisting of identifiers for each argument in the parameter list, and builds a stack entry for each argument.

If you are bypassing that step then LINK doesn't know where to find the parameters.

Share this post


Link to post
Share on other sites

From the MiniMemory manual

The LINK subprogram performs the following actions. (the second point is where your problem might lie)

*It builds the argument list, consisting of identifiers for each argument in the parameter list, and builds a stack entry for each argument.

If you are bypassing that step then LINK doesn't know where to find the parameters.

Yea kind of silly as the name of the routine only works for LINK NAME and all parameters follow it, so needing that name is like stupid? (only 1 name can be used at a time!)

You can only use one LINK NAME at a time no matter 1 parameter or 8 parameters so retention of the LINK NAME seems pretty pointless.

Also a huge waste of space not to mention the looking at that name each time to verify that one on stack, which it is the only name on stack each check.

This is one of those cases of not really taking a look at buggy code.

Now a address does not need these checks as it does not need to be placed on stack or checked for spelling.

 

Guess I will have to see what is on stack and figure out how to bypass the name check.

Share this post


Link to post
Share on other sites

Given up on CALL LINK(address) as only way to fix issues is to have a second CALL INIT2 that would load a separate routine to enter and exit Assembly support.

 

In a nutshell the NAME search routine pushes name on stack and pops off the name later when finished, now pushing a address instead of name worked.

 

But this just ruins the entire concept as there still is a search and there is still the delay of clearing the VDP STACK even when this was the point to not do that for speed.

 

I would have to create a CALL INIT2 routine to bypass the NAME SEARCH and EXIT back to GPL routines to fix the issue, there is just no space for this to be done.

 

So again size of Assembly support suffer thus destroys the entire original concept for speed and space to use.

 

Too bad I had hoped I could have fixed this problem.

Edited by RXB

Share this post


Link to post
Share on other sites

At one point you talked about adding additional ROM banks to RXB. Wouldn't that solve the space issue?

Share this post


Link to post
Share on other sites

At one point you talked about adding additional ROM banks to RXB. Wouldn't that solve the space issue?

Yea that would but that was not in this version, I do have most of the documentation done and have been testing for errors for this release.

Share this post


Link to post
Share on other sites

Well new RXB SIZE routine take a look at this....

 

  • Like 2

Share this post


Link to post
Share on other sites

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

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