Jump to content

Photo

RXB - Rich Extended Basic


749 replies to this topic

#726 RXB OFFLINE  

RXB

    River Patroller

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

Posted Thu Oct 26, 2017 6:54 AM

 

I see this could be pretty handy, but also handy to be able to perform the action on a range of characters or a character set.

RXB does have CALL INVERSE already but I suppose  better way would be to include I for inverse of CALL CHAR(I,char#) 

This would just INVERSE the character values like CALL INVERSE does now in RXB.

 

Or CALL CHAR(R,char#) for reverse string.

This would reverse the character definition "AE" _*_*_*** would become "75" ***_*_*_


Edited by RXB, Thu Oct 26, 2017 9:05 AM.


#727 OLD CS1 OFFLINE  

OLD CS1

    River Patroller

  • 3,933 posts
  • Technology Samurai
  • Location:Tallahassee, FL

Posted Thu Oct 26, 2017 7:49 AM

I am surprised the GPL search for sub-programs in TI Extended BASIC does not use a hash table.  How difficult would it be to implement that in RXB?  Would it be worth the trouble?



#728 RXB OFFLINE  

RXB

    River Patroller

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

Posted Thu Oct 26, 2017 8:56 AM

I am surprised the GPL search for sub-programs in TI Extended BASIC does not use a hash table.  How difficult would it be to implement that in RXB?  Would it be worth the trouble?

The TI Basic and XB search are built into the TI OS. And it would not be worth the trouble to implement this.

 

But a updated TI GROM OS like the old SOB board would be a great idea.

 

SOB had a many useful and better features and fixes.



#729 RXB OFFLINE  

RXB

    River Patroller

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

Posted Sat Oct 28, 2017 11:12 AM

Well now that I have the XB ROM Source Code I am looking at fixing some stuff it, but also seems logical to add more banks of Assembly also:

 

1) The main goal is to speed up XB but be backwards compatible with TI Basic and XB yet have more features.

2) So some of the additional features to add are replace some slower routines with assembly versions such as COINC, DISTANCE, KEY, JOYST, POSITION, RTP$

3) Make Value Stack and Buffers like Redo/Edit Bufferr and VDP Roll out and Crunch Buffers movable possibly. (This would allow compatibility with TML or other programs that need to move things.)

4) Add in more SAMS support in XB and increase XB programs space and Variable space into SAMS (Possibly a SAMS only version also exciting with 4 Meg SAMS on way.)



#730 Asmusr OFFLINE  

Asmusr

    River Patroller

  • 2,465 posts
  • Location:Denmark

Posted Sat Oct 28, 2017 11:38 AM

How about a subroutine to globally disable and enable sprite motion? This would allow you to set up layered multicolor sprites and move all layers together.



#731 kl99 OFFLINE  

kl99

    Dragonstomper

  • 676 posts
  • Location:Vienna, Austria

Posted Sat Oct 28, 2017 11:52 AM

Well now that I have the XB ROM Source Code I am looking at fixing some stuff it, but also seems logical to add more banks of Assembly also:

 

1) The main goal is to speed up XB but be backwards compatible with TI Basic and XB yet have more features.

2) So some of the additional features to add are replace some slower routines with assembly versions such as COINC, DISTANCE, KEY, JOYST, POSITION, RTP$

3) Make Value Stack and Buffers like Redo/Edit Bufferr and VDP Roll out and Crunch Buffers movable possibly. (This would allow compatibility with TML or other programs that need to move things.)

4) Add in more SAMS support in XB and increase XB programs space and Variable space into SAMS (Possibly a SAMS only version also exciting with 4 Meg SAMS on way.)

 

Nice ideas. You might also take a look into the Source Code of Extended Basic 2 for the 99/8 where some speedup improvements were done.


  • RXB likes this

#732 RXB OFFLINE  

RXB

    River Patroller

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

Posted Sat Oct 28, 2017 11:16 PM

How about a subroutine to globally disable and enable sprite motion? This would allow you to set up layered multicolor sprites and move all layers together.

Hmm XB already had CALL DELSPRITE(ALL)

And RXB has CALL MOTION(STOP) or CALL MOTION(GO) for stopping all spite movements or go for giving all sprites movement.

 

I even have a demo that shows what you requested and how to do it on Video and part of the RXB CALL USER demo that comes with RXB.



#733 RXB OFFLINE  

RXB

    River Patroller

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

Posted Sat Oct 28, 2017 11:16 PM

 

Nice ideas. You might also take a look into the Source Code of Extended Basic 2 for the 99/8 where some speedup improvements were done.

Thanks will take a look at that.



#734 Asmusr OFFLINE  

Asmusr

    River Patroller

  • 2,465 posts
  • Location:Denmark

Posted Sun Oct 29, 2017 10:25 AM

Hmm XB already had CALL DELSPRITE(ALL)

And RXB has CALL MOTION(STOP) or CALL MOTION(GO) for stopping all spite movements or go for giving all sprites movement.

 

I even have a demo that shows what you requested and how to do it on Video and part of the RXB CALL USER demo that comes with RXB.

 

Somehow I knew you would say that.  :)



#735 RXB OFFLINE  

RXB

    River Patroller

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

Posted Sat Nov 11, 2017 6:16 AM

Update did some Testing for new versions of next version of RXB using a test look of 10,000 passes with Classic99 showing times of start to finish.

EXAMPLE of RXB 2015 vs RXB 2017

100 CALL CLEAR
110 OPEN #1:"CLOCK",INPUT
120 INPUT #1:A$,B$,C$
130 PRINT A$;B$;C$
140 ! RXB EXAMPLE            CALL COLOR(D,#value,#value) CALL CHAR(D,char,char)
150 A(0)=-1 :: A(1)=1 :: CALL MOTION(GO)
160 CALL MAGNIFY(2) :: CALL SCREEN(15)
170 FOR S=1 TO 28
180 CALL SPRITE(#S,64+S,INT(RND*16)+1,20+S,50+S,INT(A(RND*1))*INT(RND*20),INT(A(RND*1))*INT(RND*20))
190 NEXT S
200 CALL COLOR(D,#INT(RND*28)+1,#INT(RND*28)+1)
210 CALL CHAR(D,INT(RND*28)+64,INT(RND*28)+64)
220 Z=Z+1 :: IF Z<10000 THEN 200
230 INPUT #1:A$,B$,C$
240 PRINT A$;B$;C$

       RXB 2015                                                     RXB 2017                                       TIME       WINNER

___________________________________________________________________________________

CALL SWAPCHAR(charset#,#charset#) vs CALL CHAR(S,charset#,#charset#)      1.14         RXB 2015

CALL SWAPCOLOR(#sprite,#spirte)      vs CALL COLOR(S,#sprite,#spirte)            2.81         RXB 2015

CALL DUPCOLOR(#sprite,#sprite)         vs CALL COLOR(D,#sprite,#spirte)           1.05         RXB 2017

CALL DUPCHAR(char#,char#)               vs CALL CHAR(D,#char,#char)                    .95         RXB 2015

DUP & SWAP both used                         vs D and S both used                                1.14          RXB 2015

 

          XB                                                            RXB 2017                        

CALL CHAR & CALL COLOR                vs CALL CHAR & CALL COLOR                 .84           XB

 

So this new version seems to be a dead end. Adding more commands slows GPL down but this new approach also does not help at all.

 

I did get a speed up in CALL DUPCOLOR(#sprite,#sprite) vs CALL COLOR(D,#sprite,#spirte) but all the rest were slower sometimes by to much to be tolerated.

 

Thus I may have to use a new approach that is a combination of the two or stick with original RXB 2015 way of command and see if I can remove some of them for speed.

 

Also make more use of the XB ROM assembly routines that can avoid GPL as Assembly is always faster but just always takes up more program space to do same thing.


Edited by RXB, Sat Nov 11, 2017 6:19 AM.


#736 Ksarul OFFLINE  

Ksarul

    River Patroller

  • 4,215 posts

Posted Sat Nov 11, 2017 9:42 AM

Depending on what you  want to do, you could also expand the number of Assembly routines too, Rich. You'd have to use more than the original two banks of ROM, but that is easily done using current cartridge formats (and can be tested on several emulators too). That may help eliminate some of the speed issues.


Edited by Ksarul, Sat Nov 11, 2017 9:42 AM.


#737 RXB OFFLINE  

RXB

    River Patroller

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

Posted Sat Nov 11, 2017 10:02 AM

Depending on what you  want to do, you could also expand the number of Assembly routines too, Rich. You'd have to use more than the original two banks of ROM, but that is easily done using current cartridge formats (and can be tested on several emulators too). That may help eliminate some of the speed issues.

Yea that is what needs to be done.

 

4 banks or more as with more a 80 column version of XB is possible with SAMS support even a memory manager.

 

What kind of banking method?



#738 Ksarul OFFLINE  

Ksarul

    River Patroller

  • 4,215 posts

Posted Sat Nov 11, 2017 12:20 PM

Banking in the modern cartridges is actually just an extension of the banking already used in Extended BASIC, with one slight difference. XB switches half of each 8K bank (simulated in new cartridges by replicating the 4K that stays the same into both 8K banks), whereas the new cartridges switch the whole 8K. Banking is done by writing a byte to >6000, >6002, >6004, >6006, etc., and this method works on both Inverted and non-Inverted cartridge boards (the banking addresses are always the same, just the order of the stack in the EPROM changes to always place the correct bank into the desired bank address).



#739 RXB OFFLINE  

RXB

    River Patroller

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

Posted Sun Nov 12, 2017 1:30 AM

Banking in the modern cartridges is actually just an extension of the banking already used in Extended BASIC, with one slight difference. XB switches half of each 8K bank (simulated in new cartridges by replicating the 4K that stays the same into both 8K banks), whereas the new cartridges switch the whole 8K. Banking is done by writing a byte to >6000, >6002, >6004, >6006, etc., and this method works on both Inverted and non-Inverted cartridge boards (the banking addresses are always the same, just the order of the stack in the EPROM changes to always place the correct bank into the desired bank address).

Can I use GPL to write to >6000 or >6002 or >6004 or >6006 and switch banks to use or do I have to use an Assembly routine loaded into Scratch to do this?

 

Example GPL: ST >FF,@>6006 

 

Assembly I would have to load a routine into scratch pad and then use XML >FO to run from >8300 ?



#740 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

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

Posted Sun Nov 12, 2017 8:06 AM

Can I use GPL to write to >6000 or >6002 or >6004 or >6006 and switch banks to use or do I have to use an Assembly routine loaded into Scratch to do this?

 

Example GPL: ST >FF,@>6006 

 

Assembly I would have to load a routine into scratch pad and then use XML >FO to run from >8300 ?

 

Since you are ultimately using the Assembly Language of the GPL Interpreter to perform the actual “write” to ROM, I should think GPL could effect the bank switching just fine.

 

...lee


  • RXB likes this

#741 Ksarul OFFLINE  

Ksarul

    River Patroller

  • 4,215 posts

Posted Sun Nov 12, 2017 9:55 AM

Lee is correct, Rich. I suspect the existing code is already doing that to some extent by just bouncing to the 4K of static ROM for the pointers to each routine and then the existing assembly is doing the bank switching to execute, but there is absolutely no reason to keep the trampolines locked into that space. You could just as easily identify the routine in GPL space and bounce to it directly with a return routine to bring things back to the GPL space and continue program execution from there once you were done. You might have to do some register protection/restoration as part of each routine to make sure nothing else is accidentally impacted, but again, that's what the existing Assembly subprograms are doing, so you have a usable template for subprogram behavior.



#742 RXB OFFLINE  

RXB

    River Patroller

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

Posted Sun Nov 12, 2017 10:28 AM

Yea in the XB ROMS Source you see R11 is the PGM Counter and R8 & R7 is mostly used for saving a Return address for a BL routine it branches to it it does two deep BL routines.

Registers R0 to R7 are used for all the XB ROM routines.

While R15 to R10 are uses for various things like GROM ADDRESS or VDP ADDRESS or CRU selection or DSR counters for searches.

 

So cool I can still use slightly modified XB ROMs but will have to fix the FILE XML359 that is the page selector:

********************************************************************************
       AORG >6000
       TITL 'XML359'
 
* PAGE SELECTOR FOR PAGE 1
PAGE1  EQU  $                 >6000
C2     DATA 2                 0
* PAGE SELECTOR FOR PAGE 2
PAGE2  EQU  $                 >6002
C7     BYTE >00
CBH7   BYTE >07               2
CBHA   BYTE >0A
CBH94  BYTE >94               4
C40    DATA 40                6
C100   DATA 100               8
C1000  DATA >1000             A
       DATA 0                 C
FLTONE DATA >4001             E
*************************************************************
* XML table number 7 for Extended Basic - must have         *
*     it's origin at >6010                                  *
*************************************************************
*           0      1      2      3      4      5     6
       DATA COMPCG,GETSTG,MEMCHG,CNSSEL,PARSEG,CONTG,EXECG
*           7      8    9     A    B    C      D
       DATA VPUSHG,VPOP,PGMCH,SYMB,SMBB,ASSGNV,FBSYMB
*             E     F
       DATA SPEED,CRNSEL
*************************************************************
* XML table number 8 for Extended Basic - must have         *
*     it's origin at >6030                                  *
*************************************************************
*           0   1      2    3      4  5     6      7
       DATA CIF,CONTIN,RTNG,SCROLL,IO,GREAD,GWRITE,DELREP
*           8    9    A      B      C      D      E
       DATA MVDN,MVUP,VGWITE,GVWITE,GREAD1,GWITE1,GDTECT
*           F
       DATA PSCAN
 
* Determine if and how much ERAM is present
GDTECT MOVB R11,@PAGE1        First enable page 1 ROM
*-----------------------------------------------------------*
* Replace following line      6/16/81                       *
* (Extended Basic must be made to leave enough space at     *
* top of RAM expansion for the "hooks" left by the 99/4A    *
* for TIBUG.)                                               *
*      SETO R0                Start at >FFFF                *
* with
       LI   R0,>FFE7          Start at >FFE7
*-----------------------------------------------------------*
       MOVB R11,*R0           Write a byte of data
       CB   R11,*R0           Read and compare the data
       JEQ  DTECT2            If matches-found ERAM top
*-----------------------------------------------------------*
* Change the following line   6/16/81                       *
*      AI   R0,->2000         Else drop down 8K             *
       LI   R0,>DFFF          Else drop down 8K
*-----------------------------------------------------------*
       MOVB R11,*R0           Write a byte of data
       CB   R11,*R0           Read and compare the data
       JEQ  DTECT2            If matches-found ERAM top
       CLR  R0                No match so no ERAM
DTECT2 MOV  R0,@RAMTOP        Set the ERAM top
       RT                     And return to GPL
CNSSEL LI   R2,CNS
       JMP  PAGSEL
CRNSEL LI   R2,CRUNCH
* Select page 2 for CRUNCH and CNS
PAGSEL INCT @STKADD           Get space on subroutine stack
       MOVB @STKADD,R7        Get stack pointer
       SRL  R7,8              Shift to use as offset
       MOVB R11,@PAD0(R7)     Save return addr to GPL interpeter
       MOVB @R11LB,@PAD1(R7)
       MOVB R11,@PAGE2        Select page 2
       BL   *R2               Do the conversion
       MOVB R11,@PAGE1        Reselect page 1
       MOVB @STKADD,R7        Get subroutine stack pointer
       DECT @STKADD           Decrement pointer
       SRL  R7,8              Shift to use as offset
       MOVB @PAD0(R7),R11     Restore return address
       MOVB @PAD1(R7),@R11LB
       RT                     Return to GPL interpeter
GETCH  MOVB @R6LB,*R15
       NOP
       MOVB R6,*R15
       INC  R6
       MOVB @XVDPRD,R8
GETCH1 SRL  R8,8
       RT
GETCHG MOVB R6,@GRMWAX(R13)
       MOVB @R6LB,@GRMWAX(R13)
       INC  R6
       MOVB *R13,R8
       JMP  GETCH1
GETCGR MOVB *R6+,R8
       JMP  GETCH1
*
CBHFF  EQU  $+2
POPSTK LI   R5,-8
       MOVB @VSPTR1,*R15
       LI   R6,ARG
       MOVB @VSPTR,*R15
       A    R5,@VSPTR
STKMOV MOVB @XVDPRD,*R6+
       INC  R5
       JNE  STKMOV
       RT
*
PUTSTK INCT @STKADD
       MOVB @STKADD,R4
       SRL  R4,8
       MOVB @GRMRAX(13),@PAD0(R4)
       MOVB @GRMRAX(13),@PAD1(R4)
       DEC  @PAD0(R4)
       RT
*
GETSTK MOVB @STKADD,R4
       SRL  R4,8
       DECT @STKADD
       MOVB @PAD0(R4),@GRMWAX(R13)
       MOVB @PAD1(R4),@GRMWAX(R13)
       RT
********************************************************************************
 



#743 RXB OFFLINE  

RXB

    River Patroller

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

Posted Mon Nov 13, 2017 1:19 AM

Freaking amazing fact in XB I was looking to test XB ROM routines from GPL and this routine called GVWITES

********************************************************************************
       AORG >7FDA
       TITL 'GVWITES'
 
* Move data from ERAM to VDP (RAM to VDP)
* @GSRC  : Source address where the data stored on ERAM
* @DEST  : Destination address on VDP
* @BCNT3 : byte count
 
GVWITE MOV  @DEST,R2          VDP address
       MOVB @R2LB,*R15        LSB of VDP address
       ORI  R2,WRVDP          Enable VDP write
       MOVB R2,*R15           MSB of VDP address
       MOV  @GSRC,R3          ERAM address
GV$1   MOVB *R3+,@XVDPWD      Move a byte
       DEC  @BCNT3            One less to move
       JNE  GV$1              If not done, loop for more
       RT                     Return
 
       AORG >7FFE
       DATA >9226
 
********************************************************************************

Not a single call used from XB GPL at all yet it has a GPL XML value of >8A that is never used...why even put it as a XML at all if it is never ever used in XB ROMs?

 

Also not a single routine in XB ROMs calls it ever?

 

So TI put in a section of XB Assembly in XB ROM that is never used or called and has a XML assigned to it? 

 

Now in EA manual is does have VGWITE >34 which obviously is not in XB ROMs as that would be >6? or >7? or >8A in the ROMs?



#744 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

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

Posted Mon Nov 13, 2017 7:41 AM

Freaking amazing fact in XB I was looking to test XB ROM routines from GPL and this routine called GVWITES

********************************************************************************
       AORG >7FDA
       TITL 'GVWITES'
 
* Move data from ERAM to VDP (RAM to VDP)
* @GSRC  : Source address where the data stored on ERAM
* @DEST  : Destination address on VDP
* @BCNT3 : byte count
 
GVWITE MOV  @DEST,R2          VDP address
       MOVB @R2LB,*R15        LSB of VDP address
       ORI  R2,WRVDP          Enable VDP write
       MOVB R2,*R15           MSB of VDP address
       MOV  @GSRC,R3          ERAM address
GV$1   MOVB *R3+,@XVDPWD      Move a byte
       DEC  @BCNT3            One less to move
       JNE  GV$1              If not done, loop for more
       RT                     Return
 
       AORG >7FFE
       DATA >9226
 
********************************************************************************

Not a single call used from XB GPL at all yet it has a GPL XML value of >8A that is never used...why even put it as a XML at all if it is never ever used in XB ROMs?

 

Also not a single routine in XB ROMs calls it ever?

 

So TI put in a section of XB Assembly in XB ROM that is never used or called and has a XML assigned to it? 

 

Now in EA manual is does have VGWITE >34 which obviously is not in XB ROMs as that would be >6? or >7? or >8A in the ROMs?

 

As you know, the XML signature’s first hex digit (nybble), after doubling, is an offset into XMLTAB at >0CFA in the console ROM.  This is a pointer to a second table of subroutine pointers.  The second nybble, after doubling, is an offset into this second table.  For XML signatures beginning with >8, this second table is located at >6030 in XB ROM space.  >8A references >6030 + >14 = >6044, which contains >7FC0—not the >7FDA of your GVWITES routine.  That routine’s address is in the next word, which has an XML signature of >8B.  I am guessing that >8A actually points to VGWITE.  [EDIT:  The code in your previous post actually shows this to be the case.]
 
For the E/A cartridge, the XML signatures for VGWITE and GVWITE are >34 and >36, respectively.  The first nybble, after doubling, points to XMLTAB + 6 = >0D00, which contains >3FC0 in low ex[ansion RAM. For VGWITE, the address of its code is pointed to by >3FC0 + 8 = >3FC8.  The pointer for GVWITE is at >3FC0 + C = >3FCC.  These routines are for TI Basic support and are in the file BSCSUP (on one of the E/A disks), which must be loaded in TI Basic to be used.
 
...lee


#745 RXB OFFLINE  

RXB

    River Patroller

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

Posted Mon Nov 13, 2017 10:13 AM

Lee 

Yea I know this as this is the XB ROM source code I am posting. And I went into XB and RXB looking for anything that ever used GVWITE and not a single time was it ever used, 

even as a subroutine of some XB ROM routine as in GVWITE or GV$1 and even looked for it in Debug in Classic99.

 

The TI Basic version of EA support created by me and placed in TI Basic from >3800 to >3FFF and >4800 to >5FFF and many people use it so no EA cart is needed for TI Basic Assembly support.

I think the video and ZIP are still on AtariAge.

 

My point was that TI created some routines in XB ROMs that are never used as I think there were either for future versions or just bad management.

 

See routine like MVDN does exactly the same thing but can move from RAM to Scratch Pad or VDP and is used quite a bit from GPL XML to MVDN. (They just never removed what was never used?)

********************************************************************************
       AORG >7F7E
       TITL 'MVDNS'

* (VDP to VDP) or (ERAM to ERAM) 
* WITHOUT ERAM : Move the contents in VDP RAM from a lower
*                 address to a higher address avoiding a
*                 possible over-write of data
*                ARG    : byte count
*                VAR0   : source address
*                VARY2  : destination address
* WITH ERAM    : Same as above except moves ERAM to ERAM
 
MVDN   MOV  @ARG,R1           Get byte count
       MOV  @VARY2,R5         Get destination
       MOV  @VAR0,R3          Get source
MVDN2  MOV  @RAMTOP,R7        ERAM or VDP?
       JNE  MV01              ERAM, so handle it
       JMP  MV05              VDP, so jump into loop
MVDN1  DEC  R5
       DEC  R3
MV05   EQU  $
       MOVB @R3LB,*R15        Write out read address
       MOVB R3,*R15
       MOVB @XVDPRD,R7        Read a byte
       MOVB @R5LB,*R15        Write out write address
       ORI  R5,WRVDP          Enable VDP write
       MOVB R5,*R15
       MOVB R7,@XVDPWD        Write the byte
       DEC  R1                One less byte to move
       JNE  MVDN1             Loop if more to move
       RT
MV01   EQU  $
MVDN$1 MOVB *R3,*R5           Move a byte
       DEC  R3                Decrement destination
       DEC  R5                Decrement source
       DEC  R1                One less byte to move
       JNE  MVDN$1            Loop if more to move
       RT
********************************************************************************

One of the issues I have is GPL spends a stupid amount of time loading the source, byte count and destination just to move 2 stupid bytes?

When a GPL DST source,destination could do the same thing. It wastes 24 bytes of GPL to call a Assembly routine that moves 2 bytes??? Freaking insane!

GPL get slowed to a crawl by idiotic things like this.



#746 RXB OFFLINE  

RXB

    River Patroller

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

Posted Thu Nov 16, 2017 12:25 AM

In case no one saw this is the XB ROM source code this is from GROM6 >C000 to >DFFF from CALL LOAD 

*  MVUP WAS USED TO TRANSFER DATA FROM CPU RAM TO ERAM
*  SINCE IT WAS NOT KNOWN AT FIRST THAT THE MOVE
*  INSTRUCTION COULD TRANSFER FROM CPU RAM TO ERAM
*   (PROVIDED THAT >8300 IS SUBTRACTED FROM THE ADDRESSES)
***********************************************************

MVUP was tested vs GPL MOVE command and MVUP is faster but requires more memory to set up then GPL MOVE

 

Example:

 

MVUP and MVDN both XML Assembly routines in XB ROM have set Variables:

*******************************
       DST  2,@ARG            * BYTE COUNT
       DST  >1000,@VAR0       * SOURCE ADDRESS
       DST  >3000,@VARY2      * DESTINATION ADDRESS
       XML  MVDN              * ASSMBLY MOVE IT
       BR   LNKRT2            * Return to GPL

Set variable address ARG (>835C), VAR0 (>8300) and VARY2 (>8306)

Thus if these variables are in other locations have to copied to these set variables thus takes  more memory to use and access as then they need to be transferred.

 

On the other hand GPL MOVE does not care what variables:

     MOVE @VAR3,@TEMP1,@>830E

Assembly is faster but requires more work to make work. So incase you did not know many routines in XB ROMs only exist from

lack of communication between GPL programmers and Assembly programmers teams.


Edited by RXB, Thu Nov 16, 2017 12:26 AM.


#747 RXB OFFLINE  

RXB

    River Patroller

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

Posted Thu Nov 16, 2017 4:39 AM

CONFIRMED sometime GPL is faster than XML Assembly routines in XB ROMs:

100 CALL CLEAR
110 OPEN #1:"CLOCK",INPUT
120 INPUT #1:A$,B$,C$
130 PRINT A$;B$;C$
140 CALL ATEST ! Assembly XML or  CALL MTEST used for GPL
150 X=X+1
160 IF X<>100000 THEN 140
170 INPUT #1:A$,B$,C$
180 PRINT A$;B$;C$

Results are Assembly XML in XB ROMs 29.29 and for GPL MOVE 23.45 for a difference of 6 minutes & 24 seconds.

Example code of XB ROM routines:

0790]               *************** LOAD DATA INTO ERAM ***********************
[0791]               * LOAD FRESTA, FREEND from ERAM
[0792] C097 BF,16,20        DST  FSLOC,@VARB           Source
       C09A 02
[0793] C09B BF,00,83        DST  FRESTA,@VAR0          Destination
       C09E 08
[0794] C09F BF,5C,00        DST  4,@ARG                # of bytes to move
       C0A2 04
[0795] C0A3 0F,89           XML  MVUP 


(TOTAL BYTES USED TO SET UP XML MVUP 11 BYTES AND 3 DST GPL COMMANDS BEFORE XML USED)

RXB REPLACEMENT:

[4213] CCC4 35,00,04        MOVE 4,@FSLOC,@FRESTA     GPL MOVE IT
       CCC7 20,9D,00
       CCCA 8F,08,00

(TOTAL BYTES USED TO SET UP GPL MOVE 0 BYTES AND 1 GPL MOVE COMMAND WITH 9 BYTES USED)
                    

Now this is only in cases where numerous GPL commands have to be used to call a XML Assembly routine like MVUP or MVDN are used.

 

I will use as many XML Assembly XB ROM routines as possible in RXB 2017 but some are just slower and memory hogs so more code needs to be looked into and timed.


Edited by RXB, Thu Nov 16, 2017 4:46 AM.


#748 senior_falcon OFFLINE  

senior_falcon

    Dragonstomper

  • 946 posts
  • Location:Lansing, NY, USA

Posted Thu Nov 16, 2017 7:35 AM

When you tested this were you replacing MTEST with ATEST so they would be in exactly the same place in the table when CALL looks up the name?  If the subroutines ATEST and MTEST were both available at the same time then whichever one CALL comes to first would have a speed advantage.

 

GPL runs on the 16 bit bus and the XB ROMS are on the 8 bit bus so it may well be that there are times when GPL could be faster.


  • RXB likes this

#749 RXB OFFLINE  

RXB

    River Patroller

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

Posted Thu Nov 16, 2017 9:44 AM

When you tested this were you replacing MTEST with ATEST so they would be in exactly the same place in the table when CALL looks up the name?  If the subroutines ATEST and MTEST were both available at the same time then whichever one CALL comes to first would have a speed advantage.

 

GPL runs on the 16 bit bus and the XB ROMS are on the 8 bit bus so it may well be that there are times when GPL could be faster.

Right and I timed this too. Know what it came out to for 100,000 times? 

 

(12 seconds and that was with 36 names between them, not one behind to the other like this test .) 

 

When I tested them one after the difference even at 100,000 loops was not even 1 second, that second just never showed up in the results on the clock.

 

So add 1 second to the Assembly one and I guess  it would be 6 minutes 23 seconds instead of 6 minutes 24 seconds for a true result.

 

I can give you the GROM5 is you want to test it on Classic99. I even ran these tests on XB instead and a slight improvement but XB has many less commands than RXB.

 

As for the ROMs being on the 8 bit bus that is why it uses the Scratch Pad for everything as much as possible, or as it is called in the XB ROM and GPL Source code ERAM.


Edited by RXB, Thu Nov 16, 2017 9:46 AM.


#750 RXB OFFLINE  

RXB

    River Patroller

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

Posted Thu Nov 16, 2017 11:24 AM

Just finished the XB ROMs Assembly:

SOURCE is source code in one huge text file

LIST is listing of the assembled file.

 

 

Attached Files


Edited by RXB, Fri Nov 17, 2017 5:13 AM.





0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users