RickyDean Posted December 19, 2018 Share Posted December 19, 2018 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. Quote Link to comment Share on other sites More sharing options...
RXB Posted December 19, 2018 Share Posted December 19, 2018 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. Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted December 19, 2018 Share Posted December 19, 2018 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. Quote Link to comment Share on other sites More sharing options...
RXB Posted December 19, 2018 Share Posted December 19, 2018 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. Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted December 20, 2018 Share Posted December 20, 2018 If you let me have a peek... maybe something useful will come to me. 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted December 20, 2018 Share Posted December 20, 2018 If you let me have a peek... maybe something useful will come to me. Here is entire RXB GPL and ROM Source RXB GRAM SOURCE.zip 1 Quote Link to comment Share on other sites More sharing options...
+9640News Posted December 20, 2018 Share Posted December 20, 2018 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 3 Quote Link to comment Share on other sites More sharing options...
RXB Posted December 21, 2018 Share Posted December 21, 2018 (edited) 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 December 21, 2018 by RXB Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted December 21, 2018 Share Posted December 21, 2018 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! 2 Quote Link to comment Share on other sites More sharing options...
RXB Posted December 22, 2018 Share Posted December 22, 2018 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. 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted December 23, 2018 Share Posted December 23, 2018 (edited) 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 December 23, 2018 by RXB Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted December 24, 2018 Share Posted December 24, 2018 I haven't had enough time to look at the code again yet...this may sound strange comin' from me... but maybe you could sacrifice REM... or integrate HEX into an existing CALL. 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted December 24, 2018 Share Posted December 24, 2018 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. Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted December 27, 2018 Share Posted December 27, 2018 I'm sorry, I haven't had more time to look into the improvements your making to RXB. I'm rolling with the punches myself these days... Happy Holidays Quote Link to comment Share on other sites More sharing options...
RXB Posted March 21, 2019 Share Posted March 21, 2019 (edited) 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 March 21, 2019 by RXB 2 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted March 21, 2019 Share Posted March 21, 2019 Very cool Rich. Nice work. 1 Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted March 25, 2019 Share Posted March 25, 2019 I like this idea, Rich. 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted April 2, 2019 Share Posted April 2, 2019 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? Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted April 2, 2019 Share Posted April 2, 2019 From the MiniMemory manualThe 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. Quote Link to comment Share on other sites More sharing options...
RXB Posted April 2, 2019 Share Posted April 2, 2019 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. Quote Link to comment Share on other sites More sharing options...
RXB Posted April 12, 2019 Share Posted April 12, 2019 (edited) 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 April 12, 2019 by RXB Quote Link to comment Share on other sites More sharing options...
Asmusr Posted April 12, 2019 Share Posted April 12, 2019 At one point you talked about adding additional ROM banks to RXB. Wouldn't that solve the space issue? Quote Link to comment Share on other sites More sharing options...
RXB Posted April 12, 2019 Share Posted April 12, 2019 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. Quote Link to comment Share on other sites More sharing options...
RXB Posted June 1, 2019 Share Posted June 1, 2019 Well new RXB SIZE routine take a look at this.... 2 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted June 1, 2019 Share Posted June 1, 2019 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.) 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.