Jump to content

Photo

RXB - Rich Extended Basic


716 replies to this topic

#626 Lee Stewart ONLINE  

Lee Stewart

    River Patroller

  • 3,233 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 ONLINE  

RXB

    River Patroller

  • 2,646 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,351 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   3 downloads



#629 RXB ONLINE  

RXB

    River Patroller

  • 2,646 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,656 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 ONLINE  

RXB

    River Patroller

  • 2,646 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,996 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 ONLINE  

RXB

    River Patroller

  • 2,646 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 ONLINE  

RXB

    River Patroller

  • 2,646 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.



#635 RXB ONLINE  

RXB

    River Patroller

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

Posted Thu Apr 6, 2017 8:19 AM

Would like some help on this project as I have requested some help before with no takers:

 

PROJECT: Get the XB ROM SOURCE CODE fully commented and explained so we can convert XB ROM to not use VDP for STRINGS and STACK but instead use SAMS memory thus making XB run at least 3 times faster.

 

Really would like some of you Experts in Assembly to give  it a look and make some comments in the source code please.

 

Rich

Attached Files



#636 RXB ONLINE  

RXB

    River Patroller

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

Posted Mon Apr 10, 2017 10:08 AM

And no one know assembly but me? 

 

Can not think of another answer why no one wants to speed up XB but me I guess?



#637 Lee Stewart ONLINE  

Lee Stewart

    River Patroller

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

Posted Mon Apr 10, 2017 10:21 AM

And no one know assembly but me? 

 

Can not think of another answer why no one wants to speed up XB but me I guess?

 

Trying to get cooperation by insulting us, I see.  :P

 

I am actually interested, but simply do not yet have the time.

 

...lee


  • RXB likes this

#638 mizapf OFFLINE  

mizapf

    River Patroller

  • 2,435 posts
  • Location:Germany

Posted Mon Apr 10, 2017 10:39 AM

Currently busy with the Hexbus floppy disassembly; I think I figured it out now. About to start Hexbus implementation in MAME.



#639 --- Ω --- OFFLINE  

--- Ω ---

    --- Ω ---

  • 10,180 posts
  • TI-99/4A Fanatic
  • Location:In the den playing with my FinalGROM 99!

Posted Mon Apr 10, 2017 10:43 AM

And no one know assembly but me? 

 

Can not think of another answer why no one wants to speed up XB but me I guess?

 

Hi Rich, 

    I one of 'those guys' that does not know a lick of assembly language, and I don't have the time or inclination to try learning it either.  It's simply, "not my bag".   Now while I have done a few things in Extended BASIC, I like you wish it was faster, but it's not an environment I want to actually RUN my programs in.  For me (personally) compiling the completed program is, "where it's at".  To that end I'm REALLY, REALLY looking forward to Fest West this year... but I don't want to give anything away.


  • RXB likes this

#640 Asmusr OFFLINE  

Asmusr

    River Patroller

  • 2,351 posts
  • Location:Denmark

Posted Mon Apr 10, 2017 1:05 PM

I feel kind of responsible for planting this idea of adding seamless SAMS support to RXB. But I didn't know that the ROM code was not part of the RXB code. I thought, perhaps naively, that when you developed a dialect of BASIC you developed both a new GROM and ROM. It an interesting project, but I know very little about BASIC interpreters, and I currently have 3 different games projects I'm working on.  :)



#641 Asmusr OFFLINE  

Asmusr

    River Patroller

  • 2,351 posts
  • Location:Denmark

Posted Mon Apr 10, 2017 3:15 PM

To that end I'm REALLY, REALLY looking forward to Fest West this year... but I don't want to give anything away.

 

That sounds very interesting. A new XB compiler?



#642 --- Ω --- OFFLINE  

--- Ω ---

    --- Ω ---

  • 10,180 posts
  • TI-99/4A Fanatic
  • Location:In the den playing with my FinalGROM 99!

Posted Mon Apr 10, 2017 6:33 PM

 

That sounds very interesting. A new XB compiler?

 

I'm NOT gonna say!  :P

But I will tell you that the Fest West CD has a sub-directory dedicating 129 megabytes to one of the scheduled presentations. :-D 

With any luck the planned video will inform everyone about a week after Fest West, for those unable to attend.



#643 RXB ONLINE  

RXB

    River Patroller

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

Posted Tue Apr 11, 2017 3:04 AM

 

Hi Rich, 

    I one of 'those guys' that does not know a lick of assembly language, and I don't have the time or inclination to try learning it either.  It's simply, "not my bag".   Now while I have done a few things in Extended BASIC, I like you wish it was faster, but it's not an environment I want to actually RUN my programs in.  For me (personally) compiling the completed program is, "where it's at".  To that end I'm REALLY, REALLY looking forward to Fest West this year... but I don't want to give anything away.

The speed increase would make Compiled XB look like a insane amount of time is needed to speed up a program originally written in XB.

 

The advantage of using RAM over VDP for Strings and RAM STACK vs VDP STACK would be like comparing Basic to XB, the difference would be very very noticeable.

 

In some cases the difference would a 16 time increase in speed especially for RAM STACK memory compared to VDP STACK memory.
Example VPUSH and VPOP would be changed to RPUSH and RPOP, these alone would really speed up XB CALL  LINK and XB routines in general.



#644 RXB ONLINE  

RXB

    River Patroller

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

Posted Tue Apr 11, 2017 3:07 AM

 

That sounds very interesting. A new XB compiler?

Compilers are nice, but they have a very very long development time in exchange for a good end product.

 

I much prefer a speed up that gives you the speed of faster development and speed just slightly slower and the added bonus you do not get from a Compiled version....COMPATIBILITY!

 

Every Compiler has the distinct disadvantage of you having to rewrite the XB code to fit the compiler, the worst from my SAMS XB would be adding delay loops to slow it down.



#645 RXB ONLINE  

RXB

    River Patroller

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

Posted Tue Apr 11, 2017 3:10 AM

I do what to thank everyone for at least responding as this was bothering me that after 28 years the TI99/4A would for the first time have XB ROM source code.

 

I mean that is a long time for something to not be tackled that everyone knew needs to be done!



#646 --- Ω --- OFFLINE  

--- Ω ---

    --- Ω ---

  • 10,180 posts
  • TI-99/4A Fanatic
  • Location:In the den playing with my FinalGROM 99!

Posted Tue Apr 11, 2017 5:25 AM

I'll keep an open mind Rich, and see what develops.  There have been things over the years I would have liked to have done, but the dog slow nature of TI's BASIC(s) was one of the reasons I didn't.  Even eliminating pre-scan, the wait time before program execution is a pain.  



#647 senior_falcon OFFLINE  

senior_falcon

    Dragonstomper

  • 855 posts
  • Location:Lansing, NY, USA

Posted Tue Apr 11, 2017 6:01 AM

The speed increase would make Compiled XB look like a insane amount of time is needed to speed up a program originally written in XB.

 

The advantage of using RAM over VDP for Strings and RAM STACK vs VDP STACK would be like comparing Basic to XB, the difference would be very very noticeable.

 

In some cases the difference would a 16 time increase in speed especially for RAM STACK memory compared to VDP STACK memory.
Example VPUSH and VPOP would be changed to RPUSH and RPOP, these alone would really speed up XB CALL  LINK and XB routines in general.

The idea that there would be a 16x increase in speed is just plain silly.  If strings were kept in RAM and all string operations were performed directly on them in ram then of course there would be some speed increase. (nowhere near 16x)  But most programs aren't doing a lot of string manipulation.  Instead, there are numbers to multiply, HCHAR's to perform, sprites to create, etc.  And all those are going to happen at the same slow speed.  If you really want to speed up Extended BASIC then ditch GPL and write the whole thing in assembly.  I think Myarc XB was all in assembly, so that would be a good starting point and as I recall it was good for about a 3x speed increase.

 

 And then you might think about really unlocking the graphics mode by using all 256 characters along with a separate sprite table.  You could even have two separate screens that can be toggled, and add some routines for smooth scrolling.  But of course, that's just a fantasy...  Oh, I forgot - that is available today in XB256, and it runs on original hardware with no need for anything special other than a disk drive, the XB cartridge and 32K..


Edited by senior_falcon, Tue Apr 11, 2017 7:12 PM.


#648 RXB ONLINE  

RXB

    River Patroller

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

Posted Tue Apr 11, 2017 10:03 AM

I'll keep an open mind Rich, and see what develops.  There have been things over the years I would have liked to have done, but the dog slow nature of TI's BASIC(s) was one of the reasons I didn't.  Even eliminating pre-scan, the wait time before program execution is a pain.  

This is not TI BASIC, it is XB that is much faster than TI Basic.



#649 RXB ONLINE  

RXB

    River Patroller

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

Posted Tue Apr 11, 2017 10:12 AM

The idea that there would be a 16x increase in speed is just plain silly.  If strings were kept in RAM and all string operations were performed directly on them in ram then of course there would be some speed increase. (nowhere near 16x)  But most programs aren't doing a lot of string manipulation.  Instead, there are numbers to multiply, HCHAR's to perform, sprites to create, etc.  And all those are going to happen at the same slow speed.  If you really want to speed up Extended BASIC then ditch GPL and write the whole thing in assembly.  I think Myarc XB was all in assembly, so that would be a good starting point and as I recall it was good for about a 3x speed increase.

 

 And then you might think about really unlocking the graphics mode by using all 256 characters along a separate sprite table.  You could even have two separate screens that can be toggled, and add some routines for smooth scrolling.  But of course, that's just a fantasy...  Oh, I forgot - that is available today in XB256, and it runs on original hardware with no need for anything special other than a disk drive, the XB cartridge and 32K..

I have used ALL of the XB compilers and not a single one can you convert and compile with any speed, it is even slower than Assembly to do that as all the extra steps.

 

XB is good for what it is designed for which is quickly type in a program and test as you go with the interpreter.

 

Why are you even writing in XB if your goal is Assembly?

I mean talk about doing something totally unnecessary to end up someplace else.

Why not just write it in Assembly in the first place?

Or for that matter C that is 100% designed around that idea in the first place.

 

Also I am a GPL programmer and like it, so am I telling you to abandon what you like to do?

You can see how this would rub me the wrong way.

Which is why I asked for Assembly Language Programmers to help out. 

I am not attempting to convert anyone to my thinking, but give me a break for my goals.

 

Am I poo pooing on yours?



#650 Lee Stewart ONLINE  

Lee Stewart

    River Patroller

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

Posted Tue Apr 11, 2017 10:20 AM

This is not TI BASIC, it is XB that is much faster than TI Basic.

 

Pay attention, Rich.  He referred to all TI Basic languages with “TI's BASIC(s)”.

 

...lee






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users