Jump to content

Photo

RXB - Rich Extended Basic


633 replies to this topic

#626 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,053 posts
  • Location:Silver Run, Maryland

Posted Sun Mar 5, 2017 7:36 AM

...

PRINT LEN(ASC("")) ! BAD ARGUMENT, actually it should factually report BAD VALUE, not BAD ARGUMENT

(my change would report o for length and be correct)

 

No.  Your change would result in a different error, “STRING-NUMBER MISMATCH”, which would be correct.  You have complicated your position with a bad example.  Somehow, with this example, you are focused on ASC()’s parameter, not its result.  If you insist on ASC("") reporting 0, so be it.  Then, the result for LEN(ASC("")) will be the same as for LEN(ASC("ABC")):  “STRING-NUMBER MISMATCH”.  Whatever you do with ASC("") matters not one whit in how LEN() should handle parameters that are numbers.  As InsaneMultitasker pointed out, taking the LEN() of a number is a misuse of LEN() and should always report an error.  Numbers are not strings.  Like I said:  Bad example.

 

...lee



#627 RXB OFFLINE  

RXB

    River Patroller

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

Posted Sun Mar 5, 2017 10:22 AM

Hmm LEN(ASC("")) = is a empty string with 0 length and LEN(ASC("ABC")) = 65 so I have no idea what you are talking about.

Look a empty string has zero length, why is so complicated to understand. ASC("") is a BAD VALUE as it is incorrect.

 

Where the hell are you getting this CHARACTER 0? A empty string does not have any characters in it?

 

Look I am not putting a CHR$(0) in that string as it is still empty, and still has a 0 length.

 

I think you guys are hung up on something that does not exist, or you love a certain error for LEN(ASC("")) of Bad Argument which is incorrect for that error.

1. ASC returns a NUMBER not a string.

2. ASC only uses the first character in the string.

3. NOTHING HAS CHANGED,

4. ASC("") should be BAD VALUE, not BAD ARGUMENT as if X$ is a empty string it should say BAD VALUE as for mixing terms like CHR$("") or ASC(65) will  be String number mismatch

 

Note: Even XB manual is kind of nuts and says......

         BAD ARGUMENT:  Bad value given in ASC, ATN, COS, EXP, INT, LOG, SIN, SOUND, SQR, TAN or VAL

         So is it a BAD VALUE or BAD ARGUMENT? Apparently according to this they are the same??????

 

        Ok so XB manual says.....

        BAD VALUE: Incorrect value given in .....

 

This is clearly totally contradictory! Want proof.....ASC("") is incorrect value thus a BAD VALUE! But by all means lets confuse it completely and say both are the same.


Edited by RXB, Sun Mar 5, 2017 10:39 AM.


#628 Asmusr OFFLINE  

Asmusr

    River Patroller

  • 2,146 posts
  • Location:Denmark

Posted Sun Mar 5, 2017 11:22 AM

Hmm LEN(ASC("")) = is a empty string with 0 length and LEN(ASC("ABC")) = 65 so I have no idea what you are talking about.

 

Attached File  screenshot.png   2.91KB   1 downloads



#629 RXB OFFLINE  

RXB

    River Patroller

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

Posted Sun Mar 5, 2017 12:52 PM

Ok enough about this I will just not do anything to ASC or LEN

 

 

1. is deleted.

 

Any issues with the others?


Edited by RXB, Sun Mar 5, 2017 12:55 PM.


#630 InsaneMultitasker OFFLINE  

InsaneMultitasker

    Stargunner

  • 1,484 posts

Posted Sun Mar 5, 2017 3:20 PM

I like the VAL hex value idea. Could have used that one long ago ;)

 

Would removing/replacing EAPGM and EALR cause any problems?  What if EAPGM and EALR both just figure out what to do with either file type (that is, make them work the same way, like your proposed EA?).  I don't know how often the two names are called, so maybe the new EA is the better approach..



#631 RXB OFFLINE  

RXB

    River Patroller

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

Posted Mon Mar 6, 2017 3:34 AM

I like the VAL hex value idea. Could have used that one long ago ;)

 

Would removing/replacing EAPGM and EALR cause any problems?  What if EAPGM and EALR both just figure out what to do with either file type (that is, make them work the same way, like your proposed EA?).  I don't know how often the two names are called, so maybe the new EA is the better approach..

Yea, the idea was to remove as many commands from RXB as possible. 

 

See RXB has more Subprograms then XB so I need to re-arrange them to speed up search in GPL for those names of Subprograms like CALL CLEAR is used the most often than CALL SCSI is used the least.

Also reducing the number of RXB Subprograms also speeds up the search as less is better.

 

Thus removing as many commands and combining them into one is more efficient and speeds up the search.

 

CALL EA("DSK#.FILE") is much more efficient if it looks at the file before it picks a loader, it has to do this anyway as how much time does it take in GPL to tell Program Image from DF80? (Not much time.)

Note: I can also make this go load a DV80 file for the Editor in Editor Assembler as what else would you need to do with a DV80 file other then view or edit it?


Edited by RXB, Mon Mar 6, 2017 3:37 AM.


#632 Willsy OFFLINE  

Willsy

    River Patroller

  • 2,899 posts
  • Location:Uzbekistan (no, really!)

Posted Mon Mar 6, 2017 5:04 AM

I like the VAL hex value idea. Could have used that one long ago ;)

 

Would removing/replacing EAPGM and EALR cause any problems?  What if EAPGM and EALR both just figure out what to do with either file type (that is, make them work the same way, like your proposed EA?).  I don't know how often the two names are called, so maybe the new EA is the better approach..

Yes, this is cool.

 

Yea, the idea was to remove as many commands from RXB as possible. 

 

See RXB has more Subprograms then XB so I need to re-arrange them to speed up search in GPL for those names of Subprograms like CALL CLEAR is used the most often than CALL SCSI is used the least.

Also reducing the number of RXB Subprograms also speeds up the search as less is better.

 

Thus removing as many commands and combining them into one is more efficient and speeds up the search.

 

CALL EA("DSK#.FILE") is much more efficient if it looks at the file before it picks a loader, it has to do this anyway as how much time does it take in GPL to tell Program Image from DF80? (Not much time.)

Note: I can also make this go load a DV80 file for the Editor in Editor Assembler as what else would you need to do with a DV80 file other then view or edit it?

This sounds like a much better focus for your efforts than LEN/ASC, and will improve the system. Nice.


  • RXB likes this

#633 RXB OFFLINE  

RXB

    River Patroller

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

Posted Mon Mar 6, 2017 1:33 PM

Yes, this is cool.

 

This sounds like a much better focus for your efforts than LEN/ASC, and will improve the system. Nice.

Thanks the routine oddly is pretty much already in the ROMs and GPL , but oddly TI never used them for that?



#634 RXB OFFLINE  

RXB

    River Patroller

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

Posted Fri Mar 10, 2017 4:47 AM

After looking into TI Intern for how the XB ROM operate as many of the routines use the ROM 0 to access and work with XB ROMs I have seen oddly how to really speed up BASIC.

 

Example: 

Fetch space for string:
515C : DADD @>830C,>0004 Length+4 (address and twice length byte)
5160 : DST @>8356,@>831A Start string space
5163 : DSUB @>8356,@>830C Minus length
5166 : DST @>8358,@>836E Value stack pointer
5169 : DADD @>8358,>0040 + 8*8
516D : DCH @>8356,@>8358 Enough space?
5170 : BS GROM@>5187 Yes, jump
5172 : CALL GROM@>51A9 Garbage collection
5175 : DST @>8358,@>836E Compute space once more
5178 : DADD @>8358,>0040
517C : DST @>8356,@>831A
517F : DSUB @>8356,@>830C
5182 : DCH @>8356,@>8358
5185 : BR GROM@>567D No space, memory full
5187 : DSUB @>830C,>0004 Length -4
518B : ST VDP*>831A,@>830D Write length byte in VDP
518F : DSUB @>831A,@>830C Start string space minus length
5192 : DST @>831C,@>831A Temporary pointer on string space
5195 : DSUB @>831A,>0004 -4
5199 : DCLR VDP@>0001(@>831A) Free
519D : ST VDP@>0003(@>831A),@>830D 2nd length byte in VDP
51A2 : RTN

Now XB uses the ROMs instead:

********************************** GETSTR XML ***********************
*
* SYSTEM GET STRING *
* @BYTES = LENGTH
* @SREF = ADDRESS OF STRING
*
GETSTR EQU  $
LN61A2 LI   R6,>736C                    Load address >736c
LN61A6 JMP  LN61BE  
*********************************************************************    
       

  * GETSTR                     
LN736C MOV  @BYTES,R0                  
LN7370 MOV  R11,R12    * FOR RETURN                
LN7372 C    *R0+,*R0+                  
LN7374 MOV  @STREND,R1                 
LN7378 S    R0,R1                      
LN737A MOV  @VSPTR,R2  * Value Stack Pointer                
LN737E AI   R2,>0040                   
LN7382 C    R1,R2      * STREND = VSPTR?                
LN7384 JH   LN73A2     * Higher jump                 
LN7386 BL   @COMPCT    * GARBAGE ROUTINE                
LN738A MOV  @VSPTR,R2  * Save VSPTR                
LN738E AI   R2,>0040   * VSPTR+>40                
LN7392 MOV  @BYTES,R0  *                 
LN7396 C    *R0+,*R0+  ????                
LN7398 MOV  @STREND,R1 * STREND                
LN739C S    R0,R1      * BYTES-STREND                
LN739E C    R1,R2      * STREND = VSPTR?                
LN73A0 JLE  LN7368     * Less or equal to?                 
LN73A2 AI   R0,>FFFC                 
LN73AA BL   @LN641E    * VDP                  
LN73AE C    *R10,R12                   
LN73B0 S    R0,@STREND                 
LN73B4 MOV  @STREND,@SREF * Save              
LN73BA DEC  @STREND                    
LN73BE BL   @LN641E    * VDP                 
LN73C2 C    *R10,R12                   
LN73C4 DECT @STREND    * STREND-2                
LN73C8 CLR  R6                         
LN73CA MOV  @STREND,R1 * Save STREND
* WRITE ADDRESS, WRITE 2 BYTES to VDP                  
LN73CE BL   @>18AE                     
LN73D2 DEC  @STREND    * STREND-1                
LN73D6 B    *R12       * RETURN
*
* COMPCT  ROUTINE (GARBAGE COLLECTION)
GRBAGE EQU  $                    
LN73D8 MOV  R11,R7                     
LN73DA MOV  @FREPTR,R0 * Pointer free space under symbol table                 
LN73DE MOV  @STRSP,R5  * End string space (high address)                
LN73E2 MOV  R0,@STRSP  * New pointer end string space                
LN73E6 INC  R5         * WTF does this do?               
LN73E8 DEC  R5         * WTF does this do?            
LN73EA C    @STREND,R5 * End of string space?                
LN73EE JL   LN73F6     * No, shift if necessary?                 
LN73F0 MOV  R0,@STREND * New pointer start string space, low address                
LN73F4 B    *R7 
*                       
LN73F6 MOV  R5,R2      * Get string space (high address)                
LN73F8 MOV  R5,R3      * Get string space (high address)
* WRITE ADDRESS, READ BYTE                      
LN73FA BL   @>1880                     
LN73FE MOVB R1,R6                      
LN7400 SRL  R6,8       * Swap bytes                
LN7402 S    R6,R5      *                 
LN7404 AI   R5,>FFFD   * Upper 24K address+R5                
LN7408 MOV  R5,R3                      
LN740A BL   @LN6C9E                     
LN740E MOV  R1,R1                      
LN7410 JEQ  LN73E8                      
LN7412 C    *R6+,*R6+                  
LN7414 MOV  R2,R3                      
LN7416 MOV  R0,R4 
* WRITE ADDRESS, READ BYTE                     
LN7418 BL   @>1880                     
LN741C BL   @LN6422                     
LN7420 DEC  R3                         
LN7422 DEC  R4                         
LN7424 DEC  R6                         
LN7426 JGT  LN7418                      
LN7428 ANDI R4,>3FFF                   
LN742C MOV  R4,R0                      
LN742E INC  R4                         
LN7430 MOV  R4,R3                      
LN7432 BL   @LN6C9E                     
LN7436 MOV  R3,R6                      
LN7438 AI   R6,>0003
* WRITE ADDRESS, WRITE 2 BYTES                  
LN743C BL   @>18AE                     
LN7440 JMP  LN73E8                

So wondering if Basic GPL sections could us the XB ROM routines to speed up BASIC by a considerable speed increase.

Will have to put this on back burner but damn would really make Basic fly.






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users