Jump to content

Photo

RXB - Rich Extended Basic


767 replies to this topic

#751 RXB OFFLINE  

RXB

    River Patroller

  • 2,838 posts
  • Location:Vancouver, Washington, USA

Posted Tue Nov 21, 2017 2:29 AM

I keep finding goofy stuff written by TI mostly due to no communication between Assembly and GPL programs working on same XB module.

Here is the full code I just modifed to fix a totally un-needed routine in XB GROM 6:

********************** CHKIN ******************************
* Check for INIT-FLAG = >AA55
* MOVE ERAM(INITF) to CPU *FAC
PAGE   EQU  $
* CHKIN  DST  FAC,@VAR0         Destination
*        DST  INITF,@VARB       Source
*        DST  2,@ARG            2 bytes
*        XML  MVUP              Move it
* RXB PATCH REPLACE XML MVUP WITH GPL MOVE ****************
*        DCEQ >AA55,@FAC        Syntax error
       DCEQ >AA55,@INITF   *** RXB REPLACEMENT ROUTINE ****
       BR   ERRSYN
* No files have been opened so if there is a syntax error
*  goto ERRSYN!
       RTN
***********************************************************

Edited by RXB, Tue Nov 21, 2017 2:30 AM.


#752 RXB OFFLINE  

RXB

    River Patroller

  • 2,838 posts
  • Location:Vancouver, Washington, USA

Posted Wed Nov 22, 2017 6:24 AM

RXB 2017 change CALL EXECUTE(address) removed and folded into CALL LINK(address)

 

CALL LINK works exactly as before but the change is when it fetches a string it checks to see if a string or number, than branches to the routine needed.

 

CALL LINK("name")  does a BLWP to use >2038 as the Workspace in Lower 8K.

 

RXB CALL LINK(address) also does a BLWP but you specify the location of the first two bytes of Workspace and program start.

 

New code  for CALL LINK in RXB:

***********************************************************
* CALL LINK program
***********************************************************
LINKIT CALL CHKIN             Check if INIT has been called
       DST  @VSPTR,@OLDS      Save VSPTR for later use
* RXB PATCH CODE CHANGE
*       CEQ  LPARZ,@CHAT       Check for "("
*       BR   ERRSYN
*       XML  PGMCHR            Advance program pointer
*       XML  PARSE             Get the routine name.
*       BYTE RPARZ           * Read up to ")"
*       CEQ  >65,@FAC2         Should be a string
*       BR   ERRBA
* RXB REPLACEMENT CODE
       CALL GLPARZ            Check for (
       CALL STRFCH            Fetch string or number
       CEQ  >65,@FAC2         STRING?
       BS   NORMAL
       BR   LNKADD            LINK ADDRESS RUN
* Normal LINK code
NORMAL DCZ  @FAC6             Don't accept null string
       BS   ERRBA
       CH   6,@FAC7           Should be less then 6 char
       BS   ERRBA
       XML  VPUSH             Push to make it semi-permanen
       CLR  @COUNT            Initialize parameter counter
***********************************************************
* PARAMETERS get evaluated here
***********************************************************
PAR01  CEQ  RPARZ,@CHAT       No arg. So execute it
       BS   EXE01
       CEQ  COMMAZ,@CHAT      Should have a comma
       BR   ERRSYN
       DST  @PGMPTR,@ERRCOD   Save text pointer
       XML  PGMCHR            Get the character
       CHE  >80,@CHAT         Must be an expression
       BS   VAL01
* If CHAT = LPARZ then pass by expression
       CALL CLRFAC            Clear FAC entry for SYM
       XML  SYM               Read in the symbol table info
* After XML SYM @FAC area contains a pointer to symbo table
* Below statement checks if it is a UDF.
       CLOG >40,V*FAC         Pass by value
       BR   VAL01
       CEQ  COMMAZ,@CHAT      Pass by reference
       BS   REF01
       CEQ  RPARZ,@CHAT       Pass by reference
       BS   REF01
       CEQ  LPARZ,@CHAT       An array
       BS   ARRAY
       CHE  >80,@CHAT         Pass by value
       BS   VAL01
       BR   ERRSYN
***********************************************************
* ARRAY case gets checked here
***********************************************************
* Should look like A(,,) etc.
* Stack entry for an array will look like
* +--------------+-------+---+-------------+---------------
* | Pointer to   |  >00  |   | Pointer to  |
* | symbol table |   or  |   | dim info in |
* | entry        |  >65  |   | real v.s.   |
* +- FAC --------+ FAC2 -+---+- FAC4 ------+- FAC6 --------
*
ARRAY  XML  PGMCHR            Get the next character
       CEQ  RPARZ,@CHAT       Pass by reference
       BS   ARRAY2
       CEQ  COMMAZ,@CHAT      More array information
       BS   ARRAY
       DDEC @PGMPTR           Adjust the pointer
       ST   LPARZ,@CHAT
       BR   REF01             Pass by reference
* In array cases the symbol table address gets stored at FA
* area, and the pointer to the value space (dimension info)
* goes into FAC4
ARRAY2 XML  PGMCHR            Advance the program pointer
       CLOG >80,V*FAC         Test string bit
       BR   GC39D
       ST   4,*COUNT          Numeric array
       BR   GC3A1
GC39D  ST   5,*COUNT          String array case
* Check if array is being shared. If it is then go back
* through the linkage to get the actuals symbol table
* pointer. Put the pointer to the value space (dimension in
* into FAC4.
GC3A1  CLOG >20,V*FAC         Shared array?
       BS   GC3BE
       MOVE 2,V@6(@FAC),@FAC4 If so, get pointer
       CLOG >20,V@-6(@FAC4)   Shared also?
       BS   GC3BC
       MOVE 2,V*FAC4,@FAC4    Array is not shared
GC3BC  BR   GC3C5
GC3BE  DST  @FAC,@FAC4        Array is not shared
       DADD 6,@FAC4           Point to value space
GC3C5  BR   PUSH
***********************************************************
* VALUE
*  Passing the parameter by value
***********************************************************
VAL01  DST  @ERRCOD,@PGMPTR   Restore program pointer
       XML  PGMCHR            Skip the first character
       DST  @BYTES,@TEMP      In case of passing a string
       XML  PARSE             Parsing up to comma
       BYTE RPARZ
       DST  @TEMP,@BYTES      Restore the value in >0C area
* After parsing @FAC area contains its actual numeric value
*  in a numeric case, and the following information in a
*  string case.
* +----------------+-----+--+------------+-----------------
* | >001C  or      | >65 |  | Pointer to | Length of string
* | value pointer  |     |  | string     | string
* | address        |     |  |            |
* +- FAC ----------+-FAC2+--+-FAC4 ------+- FAC6 ----------
*
       CGT  >63,@FAC2         If more then 99 then
       BR   GC3E0
       ST   1,*COUNT          Store flag for string express
       BR   GC3E3
GC3E0  CLR  *COUNT            Otherwise it is a numeric exp
GC3E3  BR   PUSH              Push into stack
***********************************************************
* REFERENCE
*   Passing the parameter by reference
***********************************************************
* Variables, array element and whole array passing.
*
* After SMB @FAC entry shold look like;
* +--------------+------+-----+-------------+--------------
* | Pointer to   | >00  |     | Pointer to  |
* | symbol table |      |     | value space |
* | entry        |      |     |             |
* +-- FAC -------+ FAC2 +-----+- FAC4 ------+- FAC6 -------
*  for numeric case, and
* +--------------+------+-----+-------------+--------------
* | Pointer to   | >65  |     | Pointer to  | String
* | value space  |      |     | string      | length
* | entry        |      |     |             |
* +- FAC --------+ FAC2 +-----+- FAC4 ------+- FAC6 -------
* for a string case.
REF01  XML  SMB               Get the location
       CHE  >B8,@CHAT         Pass array expression
       BS   VAL01
       CZ   @FAC2
       BR   GC3F6
       ST   2,*COUNT          Must be a numeric variable
       BR   PUSH
GC3F6  ST   3,*COUNT          Must be a string variable
***********************************************************
* PUSH routine
*  Pushes @FAC entry into a value stack.
***********************************************************
PUSH   INC  @COUNT
       CGT  16,@COUNT         Too many parameters
       BS   ERRBA
       XML  VPUSH
       BR   PAR01             Get the next argument.
***********************************************************
* EXECUTE routine
*  Restore file name info transfer control over to ALC
***********************************************************
EXE01  ST   >20,@FAC          Store blank in the FAC area.
       MOVE 5,@FAC,@FAC1
       MOVE 4,V@12(@OLDS),@STORE   Get the file name info
       MOVE @STORE+2,V*STORE,@FAC  Move to FAC
       DCLR @ERRCOD           Clear program pointer for
*                              error code
       XML  ALSUP             Go to CPU at >2000 to execute
       BS   ERROR             Error found
*                             If no error, start checking s
***********************************************************
* RETURN to the XB main program.
***********************************************************
NOERR  DCH  @OLDS,@VSPTR      Pop the stack
       BR   GC429
       XML  VPOP              Pop the stack
       B    NOERR
GC429  B    LNKRTN            Check ")" and end of statemen
***********************************************************
* SUBROUTINES used in this file.
***********************************************************
CLRFAC CLR  @FAC
       MOVE 7,@FAC,@FAC1
       RTN
***********************************************************
* CPU PROGRAM FOR >8300 SCATCH PAD SUBROUTINE EXECUTE     *
***********************************************************
*                          AORG >8300
CPUPGM DATA >8302 * CPUPGM DATA >8302  First address. *
       DATA >0420 *        BLWP >834A  Switch contex  *
       DATA >834A *                    FAC not used   *
       DATA >04E0 *        CLR  @>837C Clear for GPL  *
       DATA >837C *                                   *
       DATA >045B *        RT          Return to GPL. *
                  *        END                        *
*******************************************************
* RXB EXCEUTE ADDRESS FROM CALL LINK(ADDRESS)         *
LNKADD CALL CFIFCH             Convert from FP to INT
       MOVE 12,@VAR0,V@VROAZ   Save CPU values
       MOVE 12,G@CPUPGM,@VAR0  Load PGM
       DST  @FAC,@VARY         Load address    
       XML  >F0                Execute address 
       MOVE 12,V@VROAZ,@VAR0   Restore CPU values
       BR   NOERR
***********************************************************


#753 RXB OFFLINE  

RXB

    River Patroller

  • 2,838 posts
  • Location:Vancouver, Washington, USA

Posted Thu Nov 23, 2017 5:27 PM

Jeez just keep finding errors in source code of XB all the time, this time in CALL CHARPAT this time:

***********************************************************
* CHARPAT ROUTINE             99/4A - JDH 10/01/80
***********************************************************
*
* FORMAT:
*  CALL CHARPAT(numeric-expression,string-variable,...)
*
*  FUNCTION:
*   RETURNS THE CHARACTER DEFINITION PATTERN FOR CHARACTER
*   NUMBER <numeric expression> INTO <string variable>
*
******************* GETCHR - GETCHR2***********************
* RXB PATCH CODE REPLACEMENT (6 bytes replace 10 bytes)****
* GETCHR CEQ  LPARZ,@CHAT
*        BR   ERRSYN
* GCHR2  XML  PGMCHR
*        XML  PARSE
*        BYTE RPARZ
*        CEQ  STRING,@FAC2      Can't be a string
*        BS   ERRSNM
*        XML  CFI               Convert FAC to integer
*        CEQ  3,@FAC10          Range 32 to 143
*        BS   ERRBA             ERROR BAD ARGUMENT
*        DCGE 32,@FAC           32
*        BR   ERRBA             ERROR BAD ARGUMENT
*        DCGT 143,@FAC          143
*        BS   ERRBA             ERROR BAD ARGUMENT
* RXB REPLACEMENT CODE ************************************
GETCHR CALL GLPARZ            Check for (?
GCHR2  CALL SUBLP3  * Skip and parse value convert to INT
       DCGE 30,@FAC           30
       BR   ERRBV             ERROR BAD VALUE
       DCGT 159,@FAC          159
       BS   ERRBV             ERROR BAD VALUE
       DSLL 3,@FAC            8 bytes / entry so times 8
       DST  >0300,@TBLPTR     Base of char table less 32*8
       DADD @FAC,@TBLPTR      Add in arg offset
       DST  16,@BYTES         16 byte string in string spac
       XML  GETSTR
       DST  @SREF,@STRPTR     Save pointer to string
       ST   8,@INDEXC         Loop counter
GC46D  ST   V*TBLPTR,V*STRPTR
       SRL  4,V*STRPTR        Get rid of low nibble
       ADD  >30,V*STRPTR      Add ASCII "0"
       CGT  >39,V*STRPTR      >39 = ASCII "9"
       BR   GCHR3
       ADD  7,V*STRPTR        Value "A" to "F"
GCHR3  DINC @STRPTR
       ST   V*TBLPTR,V*STRPTR
       AND  >0F,V*STRPTR
       ADD  >30,V*STRPTR      Add ASCII "0"
       CGT  >39,V*STRPTR
       BR   GCHR4
       ADD  7,V*STRPTR        Value "A" to "F"
GCHR4  DINC @TBLPTR
       DINC @STRPTR
       DEC  @INDEXC
       CZ   @INDEXC
       BR   GC46D
* NOW assign the string just created to the string
*  variable following
       XML  PGMCHR            Skip comma
* The following check has been put in SYM, 5/26/81
* If CHAT >= >80 then ERRSYN (Do not allow token).
* RXB PATCH CODE REPLACEMENT 
*       XML  SYM  * Get symbol table info for next argument
*       XML  SMB
*       XML  VPUSH         Save on stack for ASSGNV
* RXB REPLACE XB WITH RXB CALL SNDER
       CALL SNDER * Get symbol table info for next arguement
       CEQ  STRING,@FAC2      Must be a stirng variable
       BR   ERRSNM            ERROR STRING NUMBER MISMATCH
       DST  >001C,@FAC        Temp string so use SREF as ad
       DST  @SREF,@FAC4       Pointer to string
       DST  16,@FAC6          String length
       XML  ASSGNV            Assign to string variable
       CEQ  COMMAZ,@CHAT      Comma?
       BS   GCHR2             Restart again
       B    PEEK5
***********************************************************

Turns out it TI put ERRBA which is ERROR BAD ARGUMENT instead of every other routine in XB that has ERRBV which is ERROR BAD VALUE.

 

Also looking over the excessive amount of code I replace with subroutines from RXB or XB for some reason they never used as they should.


Edited by RXB, Thu Nov 23, 2017 5:35 PM.


#754 RXB OFFLINE  

RXB

    River Patroller

  • 2,838 posts
  • Location:Vancouver, Washington, USA

Posted Fri Nov 24, 2017 7:13 PM

Just finished changes to SAMS access in RXB 2017:

 

Old RXB 2015:

CALL AMSBANK(lowpage,highpage)

 

New RXB change to:

CALL SAMS(lowpage,highpage)

 

Old RXB 2015 commands AMSON, AMSOFF, AMSMAP, AMSPASS replaced with:

CALL SAMS("ON") 

CALL SAMS("OFF")

CALL SAMS("MAP")

CALL SAMS("PASS")

 

Old RXB 2015 line of commands: 

100 CALL AMSON :: CALL LOAD(24548,9) :: CALL LOAD(24550,10) :: CALL AMSOFF

 

New RXB line of same commands:

100 CALL SAMS("ON")  :: CALL LOAD(24548,9) :: CALL LOAD(24550,10) :: CALL SAMS("OFF")

or 

100 CALL SAMS(9,10) ! SAMS turns on and changes and turns off SAMS controls.

 

Now you can play with upper memory of 24K while running a RXB program. (of course do not change SAMS page where that control program is running)

100 CALL SAMS("ON") :: CALL LOAD(16404,245) :: CALL SAMS("OFF") ! Change page at >A000 of upper 24K to another 4K page in SAMS

(Original page of upper 24K of SAMS was 10 and this above line changed it to page 245 to be used instead.)


Edited by RXB, Fri Nov 24, 2017 7:18 PM.


#755 RXB OFFLINE  

RXB

    River Patroller

  • 2,838 posts
  • Location:Vancouver, Washington, USA

Posted Sat Nov 25, 2017 5:13 AM

Another update on RXB 2017 is CALL XBPGM("DSK.volumename.filename") has been removed and folded into CALL XB and CALL RUN

 

So now to go back to RXB main menu screen:

CALL XB

or

100 CALL XB

 

To load a XB program:

100 CALL XB("DSK.volumename.filename") 

or

100 CALL RUN("DSK.volumename.filename") 

 

Additional feature is number of files opened before the XB program is run:

CALL XB("DSK2.XBPGM",1) ! The 1 indicates do a NEW, CALL FILES(1) then RUN "DSK2.XBPGM"

 

What do you think of a feature that you can run a line number out of a program?

EXAMPLE: CALL RUN(1173,"DSK2.XBPGM",2) ! The 1173 is the line number to run from "DSK2.XBPGM" after NEW,CALL FILES(2) so it will start XB program at that line 1173


Edited by RXB, Sat Nov 25, 2017 5:17 AM.


#756 Ksarul OFFLINE  

Ksarul

    River Patroller

  • 4,234 posts

Posted Sat Nov 25, 2017 11:57 AM

What would be a good use case for that feature, Rich? I think the other changes you've been making all make sense--but I don't quite see a reason to do what you're proposing here by starting at a specific line number.



#757 RXB OFFLINE  

RXB

    River Patroller

  • 2,838 posts
  • Location:Vancouver, Washington, USA

Posted Sun Nov 26, 2017 1:42 AM

Well myself I often run a line number to test a section of code, just figured others do the same thing. 

 

Especially when testing multiple versions of the same XB code.



#758 OLD CS1 OFFLINE  

OLD CS1

    River Patroller

  • 4,038 posts
  • Technology Samurai
  • Location:Tallahassee, FL

Posted Sun Nov 26, 2017 2:54 AM

 

I keep finding goofy stuff written by TI mostly due to no communication between Assembly and GPL programs working on same XB module.

Here is the full code I just modifed to fix a totally un-needed routine in XB GROM 6:

********************** CHKIN ******************************
* Check for INIT-FLAG = >AA55
* MOVE ERAM(INITF) to CPU *FAC
PAGE   EQU  $
* CHKIN  DST  FAC,@VAR0         Destination
*        DST  INITF,@VARB       Source
*        DST  2,@ARG            2 bytes
*        XML  MVUP              Move it
* RXB PATCH REPLACE XML MVUP WITH GPL MOVE ****************
*        DCEQ >AA55,@FAC        Syntax error
       DCEQ >AA55,@INITF   *** RXB REPLACEMENT ROUTINE ****
       BR   ERRSYN
* No files have been opened so if there is a syntax error
*  goto ERRSYN!
       RTN
***********************************************************

 

Was XB developed in-house?  ISTR TI BASIC was developed by MicroSoft under contract but required to be ANSI.  CHKIN is one of the ubiquitous MS routines found in all of its 6502 BASIC for which I have seen sources or documentation, so that would stand to reason for me.  If in-house, maybe TI built XB on top or incorporating some of MS's original BASIC sources?



#759 OLD CS1 OFFLINE  

OLD CS1

    River Patroller

  • 4,038 posts
  • Technology Samurai
  • Location:Tallahassee, FL

Posted Sun Nov 26, 2017 3:07 AM

What would be a good use case for that feature, Rich? I think the other changes you've been making all make sense--but I don't quite see a reason to do what you're proposing here by starting at a specific line number.

 

I dunno, if you can give a variable as the line number that could be useful in a similar way to how you call library functions or DLLs.  It would wind up being a style choice, I suppose, whereas you could have multiple programs load and run for specific conditions, or a single monolithic program to branch out to, calling specific line numbers (like a GOTO/GOSUB "jump" table) for related functions.

 

A={1,2,3,4} :: rem the result of some condition, optionally range-checked

A=A*10 :: rem  translate to a line number in a GOTO table

CALL RUN(A,"DSK1.LIBRARY",2) :: rem not really certain why 2 files would be useful or significant, but for the sake of demonstration

 

Then DSK1.LIBRARY would have something like:

 

10 GOTO 500 :: REM clear screen and load/fetch variables

20 GOTO 740 :: REM retain screen and use variables as-is

30 GOTO 1020 :: REM draw request dialog on screen, request input

40 GOTO 3200 :: REM retain screen, request input

etc.

 

Now, I'm assuming variables are not retained when branching to a new program.  This could save the time of loading variables from disk or fetching from memory as we can just assume certain things based upon the entrance line number.

 

As well, if there is no in-built catch for a bad line number, maybe in ON ERROR in say line 5 could trap a bad line number for something like this:

 

5 ON ERROR GOTO 50  :: REM Correct syntax??

 

50 REM Bad line number handling starts here.

...

 

 

Just some thoughts.



#760 RXB OFFLINE  

RXB

    River Patroller

  • 2,838 posts
  • Location:Vancouver, Washington, USA

Posted Sun Nov 26, 2017 4:07 AM

 

Was XB developed in-house?  ISTR TI BASIC was developed by MicroSoft under contract but required to be ANSI.  CHKIN is one of the ubiquitous MS routines found in all of its 6502 BASIC for which I have seen sources or documentation, so that would stand to reason for me.  If in-house, maybe TI built XB on top or incorporating some of MS's original BASIC sources?

Factually most of the TI programmers came from Microsoft so likely this is very true. Now in TI GPL XB source they have 3 versions of CHKIN and CHKOUT and a one in XB ROMs source.

 

The ones in GPL have one that is for Loading or Saving XB programs in GROM4 and the two others are one in GROM3 and GROM5 almost the same except for one extra selection for RTN vs RTNC

 

I posted the GROM4 one for use in fixing the bug in XB posted by Senior Falcon that I fixed recently.

 

Summery is yea I think TI programmers came from Microsoft but was not a Microsoft product.

 

(Could be why TI was so tight lipped about source code on the TI99/4A)


Edited by RXB, Sun Nov 26, 2017 4:08 AM.


#761 RXB OFFLINE  

RXB

    River Patroller

  • 2,838 posts
  • Location:Vancouver, Washington, USA

Posted Sun Nov 26, 2017 4:22 AM

 

I dunno, if you can give a variable as the line number that could be useful in a similar way to how you call library functions or DLLs.  It would wind up being a style choice, I suppose, whereas you could have multiple programs load and run for specific conditions, or a single monolithic program to branch out to, calling specific line numbers (like a GOTO/GOSUB "jump" table) for related functions.

 

A={1,2,3,4} :: rem the result of some condition, optionally range-checked

A=A*10 :: rem  translate to a line number in a GOTO table

CALL RUN(A,"DSK1.LIBRARY",2) :: rem not really certain why 2 files would be useful or significant, but for the sake of demonstration

 

Then DSK1.LIBRARY would have something like:

 

10 GOTO 500 :: REM clear screen and load/fetch variables

20 GOTO 740 :: REM retain screen and use variables as-is

30 GOTO 1020 :: REM draw request dialog on screen, request input

40 GOTO 3200 :: REM retain screen, request input

etc.

 

Now, I'm assuming variables are not retained when branching to a new program.  This could save the time of loading variables from disk or fetching from memory as we can just assume certain things based upon the entrance line number.

 

As well, if there is no in-built catch for a bad line number, maybe in ON ERROR in say line 5 could trap a bad line number for something like this:

 

5 ON ERROR GOTO 50  :: REM Correct syntax??

 

50 REM Bad line number handling starts here.

...

 

 

Just some thoughts.

Sorry I guess I have no idea what you are talking about here???

 

Say I am writing a program and have 3 different XB program versions and a section that sets up sprites is being tested instead of running the entire program I just run the line that has changed.

 

Using this idea I thought ok say I test that line in one program and want to test the other versions:

 

CALL XB(LINENUMBER,"DSK2.TEST2") ! XB program TEST2 on DISK 2

 

I see the difference then do

 

CALL XB(LINENUMBER,"DSK3.TEST3") ! XB program TEST3 on DISK 3

And if I wish can go back to orginal version

 

CALL XB(LINENUMBER,"DSK1.TEST1") ! XB program TEST1 on DISK 1

 

I am loading and running 3 different programs not the same one is this what you were saying?

 

Also you can use NUMERIC VARIABLES but it would be better to use hard coded line numbers like CALL XB(40,"DSK2.TESTPGM")

 

P.S. RXB 2015 already had the number of files open in XBPGM so CALL XB has the same feature of CALL XB("DSK3.PGM",1) would do a NEW, CALL FILES(1), RUN "DSK3.PGM" in one command.


Edited by RXB, Sun Nov 26, 2017 4:26 AM.


#762 Casey ONLINE  

Casey

    Chopper Commander

  • 136 posts

Posted Sun Nov 26, 2017 8:46 AM

I think such a feature would be useful to give you multiple entry points into a program also, based on what the previous program did.  

 

Perhaps RXB has this feature already and I haven't seen it yet.  I've often thought a conditional MERGE from inside a program would be useful also, but not sure if that is even something that could be implemented.   If I have a library of small modules that I want to use on occasion in a program, based on actions taken in the program I might want to merge in a display routine or a math routine, but I don't want to eat up all my memory with those if I don't need them.  Something like:

100 INPUT "CHOICE? ":A
110 ON A GOTO 200,300,400,...
200 MERGE "DSK1.DISPLAYRT"
210 CALL DISP()
300 MERGE "DSK1.ACCEPTRT"
310 CALL...


Edited by Casey, Sun Nov 26, 2017 8:47 AM.

  • RXB likes this

#763 RXB OFFLINE  

RXB

    River Patroller

  • 2,838 posts
  • Location:Vancouver, Washington, USA

Posted Sun Nov 26, 2017 10:48 AM

 

I think such a feature would be useful to give you multiple entry points into a program also, based on what the previous program did.  

 

Perhaps RXB has this feature already and I haven't seen it yet.  I've often thought a conditional MERGE from inside a program would be useful also, but not sure if that is even something that could be implemented.   If I have a library of small modules that I want to use on occasion in a program, based on actions taken in the program I might want to merge in a display routine or a math routine, but I don't want to eat up all my memory with those if I don't need them.  Something like:

100 INPUT "CHOICE? ":A
110 ON A GOTO 200,300,400,...
200 MERGE "DSK1.DISPLAYRT"
210 CALL DISP()
300 MERGE "DSK1.ACCEPTRT"
310 CALL...

You know that is logical and doable if you enter a program out of order it just has LINE NUMBER:POINTER to that address in memory.

But problem is VARIABLES need  to be declared and none can be added by MERGE and all the Line numbers would have to be same for that section.

 

This is similar to my 32K swap that had two 32K banks. But if >A000 to >BFFF was always used as that portion of program always line numbers 26000 to 32766 it would work.



#764 OLD CS1 OFFLINE  

OLD CS1

    River Patroller

  • 4,038 posts
  • Technology Samurai
  • Location:Tallahassee, FL

Posted Sun Nov 26, 2017 11:50 AM

Sorry I guess I have no idea what you are talking about here???

 

Say I am writing a program and have 3 different XB program versions and a section that sets up sprites is being tested instead of running the entire program I just run the line that has changed.

 

Using this idea I thought ok say I test that line in one program and want to test the other versions:

 

CALL XB(LINENUMBER,"DSK2.TEST2") ! XB program TEST2 on DISK 2

 

I see the difference then do

 

CALL XB(LINENUMBER,"DSK3.TEST3") ! XB program TEST3 on DISK 3

And if I wish can go back to orginal version

 

CALL XB(LINENUMBER,"DSK1.TEST1") ! XB program TEST1 on DISK 1

 

I am loading and running 3 different programs not the same one is this what you were saying?

 

Also you can use NUMERIC VARIABLES but it would be better to use hard coded line numbers like CALL XB(40,"DSK2.TESTPGM")

 

P.S. RXB 2015 already had the number of files open in XBPGM so CALL XB has the same feature of CALL XB("DSK3.PGM",1) would do a NEW, CALL FILES(1), RUN "DSK3.PGM" in one command.

 

My scenario is having only one program with the differing functions as your multiple programs, the different functions dependent upon the entrance line number.  Not saying my scenario is better, just a different approach using the same tool.



#765 RXB OFFLINE  

RXB

    River Patroller

  • 2,838 posts
  • Location:Vancouver, Washington, USA

Posted Sun Nov 26, 2017 12:29 PM

 

My scenario is having only one program with the differing functions as your multiple programs, the different functions dependent upon the entrance line number.  Not saying my scenario is better, just a different approach using the same tool.

Here is a major issue....VDP BUFFER! 

 

If a merge you need to load a buffer somewhere and stop the program from running but where do you move all the program if VDP only, and if only RAM version how do you deal with that?

 

Now if the code is loaded and you switch memory pages that is more doable and less complicated without having to move everything around to adjust for buffers making a mess to manage DSR's and VDP.

 

My code so far could load the XB code in secondary memory pages and switch them out and I even demoed this on video but preloaded before starting.

 

 


Edited by RXB, Sun Nov 26, 2017 12:31 PM.


#766 RXB OFFLINE  

RXB

    River Patroller

  • 2,838 posts
  • Location:Vancouver, Washington, USA

Posted Mon Nov 27, 2017 7:15 PM

Well I got the CALL XB(linenumber,"DSK.VNAME.FNAME") to work but it take us so much space 380 bytes of space makes it so expensive as to be not worth using.

 

It required to many special requirements to save the line number and modifies sections of normal XB and RXB code to be worth the trouble.

 

So as suggested by Ksarul this is not a worthwhile addition to RXB.

 

Just a update.


Edited by RXB, Mon Nov 27, 2017 7:17 PM.


#767 RXB OFFLINE  

RXB

    River Patroller

  • 2,838 posts
  • Location:Vancouver, Washington, USA

Posted Wed Nov 29, 2017 2:09 AM

Well after giving up on loading a XB program to run a line number as a option I was looking over REA (Rich Editor Assembler) and noticed I could take the Cataloger in REA 

and stuff it into XB but why not put everything from EA into XB and thus

 

MAKE XB AND EA INTO ONE SINGLE CART (NOT TWO SEPARATE CARTS) AND EVERYTHING IS IN XB!

 

Of course preserve the EA environment for things like Editor or Assembler or running EA program or Dis/Fixed files. 

 

Currently working on putting the Directory section of EA into XB, then Editor and Assembler, so after that would be cake to include the rest.

 

If you watch this it shows the Directory:

 



#768 RXB OFFLINE  

RXB

    River Patroller

  • 2,838 posts
  • Location:Vancouver, Washington, USA

Posted Sat Dec 9, 2017 9:53 PM

For years people have complained there is no DOS for the TI99/4A and it is very very hard to create one.

 

RXB has CALL USER that is a TI99/4 version of a DOS, anything you type into a USER Batch file the TI will do just like DOS batch files.

Load multiple programs and return to USER environment just like DOS.

Copy, Rename, Create/Rename Directories, Protect files, Delete files are all done from RXB edit mode or program mode or a USER batch file including running multiple programs.

(I have even demoed RXB from a USER Batch File creating other Batch files and running these from a original batch file that edited itself, never saw a DOS file do that before.)

 

Which brings me back to RXB 2018 and DOS environment of XB & EA as one single program cartridge, not two.

 

Example: CALL ASSEMBLER puts up the menu similar to ASSEMBLER in EA Cartridge but using a CALL USER batch file could compile,

run object or change into a program image and run that EA program then on return to RXB continue that USER batch file to do what else is desired in that batch.

 

CALL EDITOR puts up the menu similar to the EDITOR in EA Cartridge. Again using a Batch file many options are available.

 

CALL CAT("path.filename") or CALL DIR("path.filename") would be from program or edit mode how you run XB programs, Load & Run DF80, Program Image EA5 or C programs.

 

RXB 2018 will do it all from Edit or Program mode that EA or XB can do but both from one Cartridge. (This also frees up a ton of GROM for me to play with.)






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users