Jump to content
IGNORED

RXB SAMS ONLY


RXB

Recommended Posts

I was working on RXBI (RXB INTEGER ONLY) when it occurred to me a much easier way to speed up XB.

Much of XB and TI Basic use VDP to store address and flags.

Here is a VDP list:

       GROM 3
***********************************************************
*    VDP addresses
NLNADD EQU  >02E2             New LiNe ADDress
ENDSCR EQU  >02FE             END of SCReen address
LODFLG EQU  >0371             Auto-boot needed flag
START  EQU  >0372             Line to start execution at
SYMBOL EQU  >0376             Saved symbol table pointer
SPGMPT EQU  >0382             Saved PGMPTR for continue
SBUFLV EQU  >0384             Saved BUFLEV for contiue
SEXTRM EQU  >0386             Saved EXTRAM for continue
SAVEVP EQU  >0388             Saved VSPRT for continue
ERRLN  EQU  >038A             On-error line pointer
BUFSRT EQU  >038C             Edit recall start addr (VARW)
BUFEND EQU  >038E             Edit recall end addr (VARA)
TABSAV EQU  >0392             Saved main symbol table ponte
SLSUBP EQU  >0396             Saved LSUBP for continue
SFLAG  EQU  >0398             Saved on-warning/break bits
SSTEMP EQU  >039A             To save subprogram program ta
SSTMP2 EQU  >039C             Same as above. Used in SUBPRO
MRGPAB EQU  >039E             MERGEd temporary for pab ptr
PMEM   EQU  >03A0             UPPER 24K MEMORY
*----------------------------------------------------------
* Added 6/8/81 for NOPSCAN feature
PSCFG  EQU  >03B7
*----------------------------------------------------------
* RXB PATCH CODE SWAP CONFLG FOR CONSOLE MENU FLAG
*    Flag 0:  99/4  console, 5/29/81
*         1:  99/4A console
CONFLG EQU  >03BB
*----------------------------------------------------------
* Temporary
NOTONE EQU  >0374             NO-TONE for SIZE in ACCEPT us
*                              in FLMGRS (4 bytes used)
ACCVRW EQU  >03AC             Temoporary used in ERRZZ, als
*                              used in FLMGRS
VALIDP EQU  >03B0             Use as two values passing fro
VALIDL EQU  >03B2             VALIDATE code to READL1
OLDTOP EQU  >03BC             Temporary used in ERRZZ, also
CRNBUF EQU  >0820             CRuNch BUFfer address
CRNEND EQU  >08BE             CRuNch buffer END
RECBUF EQU  >08C0             Edit RECall BUFfer
VRAMVS EQU  >0958             Default base of value stack
CNSTMP EQU  >0390             Use as temporary stored place
VROAZ  EQU  >03C0             Temporary VDP Roll Out Are
CHRCUR EQU  >03F0             Definition of CURSOR

       GROM 4
***********************************************************
*    VDP addresses
SCRNBS EQU  >02E0             Screen base addr for last lin
NLNADD EQU  >02E2             New LiNe ADDress
ENDSCR EQU  >02FE             END of SCReen address
LODFLG EQU  >0371             Auto-boot needed flag
START  EQU  >0372             Line to start execution at
* Temporary
NOTONE EQU  >0374             NO-TONE for SIZE in ACCEPT us
*                              in FLMGRS (4 bytes used)
SYMBOL EQU  >0376             Saved symbol table pointer
SPGMPT EQU  >0382             Saved PGMPTR for continue
SBUFLV EQU  >0384             Saved BUFLEV for contiue
SEXTRM EQU  >0386             Saved EXTRAM for continue
SAVEVP EQU  >0388             Saved VSPRT for continue
ERRLN  EQU  >038A             On-error line pointer
BUFSRT EQU  >038C             Edit recall start addr (VARW)
BUFEND EQU  >038E             Edit recall end addr (VARA)
CSNTMP EQU  >0390             Use as temporary stored place
*                          or CSN TEMPORARY FOR FAC12
TABSAV EQU  >0392             Saved main symbol table ponte
AUTTMP EQU  >0394             AUTOLD TEMPORARY IN SIDE ERRZ
SLSUBP EQU  >0396             Saved LSUBP for continue
SFLAG  EQU  >0398             Saved on-warning/break bits
SSTEMP EQU  >039A             To save subprogram program ta
SSTMP2 EQU  >039C             Same as above. Used in SUBPRO
MRGPAB EQU  >039E             MERGEd temporary for pab ptr
PMEM   EQU  >03A0             UPPER 24K MEMORY
INPUTP EQU  >03AA             INPUT TEMPORARY FOR PTR TO PR
ACCVRW EQU  >03AC             Temoporary used in ERRZZ, als
*                              used in FLMGRS
*                             or temporary for @VARW, @VARA
ACCVRA EQU  >03AE             TRY AGAIN
VALIDP EQU  >03B0             Use as two values passing fro
*                          or PTR TO STANDARD STRING IN VAL
VALIDL EQU  >03B2             VALIDATE code to READL1
*                          or Length of string in validate
SIZCCP EQU  >03B4             SIZE TEMPORARY FOR CCPADR
SIZREC EQU  >03B6             SIZE TEMPORARY FOR RECLEN
*                            Also used as temporary in RELO
*----------------------------------------------------------
* Added 6/8/81 for NOPSCAN feature
PSCFG  EQU  >03B7
*----------------------------------------------------------
ACCTRY EQU  >03B7             ACCEPT "TRY AGAIN" FLAG
SIZXPT EQU  >03B8             Save XPT in SIZE when "try ag
SAPROT EQU  >03B9             PROTECTION flag in SAVE
CSNTP1 EQU  >03BA             CSN TEMPORARY FOR FAC10
*----------------------------------------------------------
*    Flag 0:  99/4  console, 5/29/81
*         1:  99/4A console
CONFLG EQU  >03BB
*----------------------------------------------------------
OLDTOP EQU  >03BC             Temporary used in ERRZZ, also
*                          or Old top of memory for RELOCA
CPTEMP EQU  >03BC             CCPPTR, RECLEN temp in INPUT
NEWTOP EQU  >03BE             New top of memory for RELOCA
VROAZ  EQU  >03C0             Temporary VDP Roll Out Area
CRNBUF EQU  >0820             CRuNch BUFfer address
CRNEND EQU  >08BE             CRuNch buffer END
RECBUF EQU  >08C0             Edit RECall BUFfer
VRAMVS EQU  >0958             Default base of value stack

       GROM 5
***********************************************************
*    VDP addresses
NLNADD EQU  >02E2             New LiNe ADDress
SPRSAL EQU  >0300             Sprite attribute list
LODFLG EQU  >0371             Auto-boot flag
START  EQU  >0372             Line to start execution at
* Temporary
SYMBOL EQU  >0376             Saved symbol table pointer
ONECHR EQU  >0378             Used for CHRZ
VRMSND EQU  >0379             Sound blocks
SPGMPT EQU  >0382             Saved PGMPTR for continue
SBUFLV EQU  >0384             Saved BUFLEV for contiue
SEXTRM EQU  >0386             Saved EXTRAM for continue
SAVEVP EQU  >0388             Saved VSPRT for continue
ERRLN  EQU  >038A             On-error line pointer
CSNTMP EQU  >0390             Use as temporary stored place
*                          or CSN TEMPORARY FOR FAC12
SLSUBP EQU  >0396             Saved LSUBP for continue
SFLAG  EQU  >0398             Saved on-warning/break bits
SPNUM  EQU  >03AA             Sprite number temporary
CSNTP1 EQU  >03BA             CSN TEMPORARY FOR FAC10
VROAZ  EQU  >03C0             Temporary roll-out area
SPRVB  EQU  >07FF             Sprite velocity block.
CRNBUF EQU  >0820             CRuNch BUFfer address

       GROM 6
***********************************************************
*    VDP addresses
NLNADD EQU  >02E2             New LiNe ADDress
LODFLG EQU  >0371             Auto-boot needed flag
* Temporary
*                              in FLMGRS (4 bytes used)
SYMBOL EQU  >0376             Saved symbol table pointer
BUFSRT EQU  >038C             Edit recall start addr (VARW)
BUFEND EQU  >038E             Edit recall end addr (VARA)
MRGPAB EQU  >039E             MERGEd temporary for pab ptr
PMEM   EQU  >03A0             UPPER 24K MEMORY
*----------------------------------------------------------
*    Flag 0:  99/4  console, 5/29/81
*         1:  99/4A console
CONFLG EQU  >03BB
*----------------------------------------------------------
VROAZ  EQU  >03C0             Temporary roll-out area
CRNBUF EQU  >0820             CRuNch BUFfer address
RECBUF EQU  >08C0             Edit RECall BUFfer
VRAMVS EQU  >0958             Default base of value stack

These are address used by GPL in GROM to but if were in SAMS memory instead should be way faster to access then VDP

especially address like VDP STACK or CRNBUF >0820 in SAMS RAM instead of VDP which I would assume is way slower.

Here is ROM list:

       ROM  1
* VDP variables
SYMBOL EQU  >0376 * Saved symbol table pointer
ERRLN  EQU  >038A * On-error line pointer
TABSAV EQU  >0392 * Saved main symbol table ponter
VROAZ  EQU  >03C0 * Temporary VDP Roll Out Area
FPSIGN EQU  >03DC
CRNBUF EQU  >0820 * CRuNch BUFfer address
CRNEND EQU  >08BE * CRuNch buffer END

       ROM  2
* VDP variables
SYMBOL EQU  >0376 * Saved symbol table pointer
ERRLN  EQU  >038A * On-error line pointer
TABSAV EQU  >0392 * Saved main symbol table ponter
VROAZ  EQU  >03C0 * Temporary VDP Roll Out Area
FPSIGN EQU  >03DC
CRNBUF EQU  >0820 * CRuNch BUFfer address
CRNEND EQU  >08BE * CRuNch buffer END

Later to move the Symbol table from VDP to SAMS RAM would also be done.

And also the VDP STACK moved to SAMS RAM.

 

The 32K area would >B000 as >A000 has the Subroutine stack at >A000 to >A040 already and >FFF0 to >FFFF is taken by TI Debug hooks.

The SAMS pages I would use is SAMS PAGEs 0, 1, 4, 5, 6, 7, 8, 9 of course I have to check with others who might be using these pages.

 

What do you guys think as I would promote an excuse to buy the SAMS and would speed up XB considerably?

 

Edited by RXB
Spelling
  • Like 6
Link to comment
Share on other sites

Just now, WhataKowinkydink said:

And those of us who don't have a real SAMS can check it out in emulation :)

True RXB 2020 on up to RXB 2024B  supports up to a 16Meg SAMS.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

1 hour ago, RXB said:

What do you guys think as I would promote an excuse to buy the SAMS and would speed up XB considerably?

An Extended BASIC which uses the SAMS natively without any confabulation by the user?  I am not certain how perceptible the increase in performance would be, but I say do it!  At the very least, freeing up VDP RAM for other purposes could introduce new levels of functionality from within XB.  Do it!

  • Like 2
Link to comment
Share on other sites

38 minutes ago, OLD CS1 said:

An Extended BASIC which uses the SAMS natively without any confabulation by the user?  I am not certain how perceptible the increase in performance would be, but I say do it!  At the very least, freeing up VDP RAM for other purposes could introduce new levels of functionality from within XB.  Do it!

Well RAM has to be faster than VDP as you have to use NOP often to use VDP or you outrun the VDP memory, not a problem with RAM.

Running STACK from RAM instead of VDP STACK would also speed up XB as VPUSH and VPOP are using 64 bytes at >0958 so that alone would free up 64 VDP bytes.

VPUSH and VPOP normally push 8 bytes onto or off the the VDP STACK, so that stack should be much faster.

Crunch Buffer >0820 could could also be increased so a line could be more then 163 bytes so we could have full 255 byte XB lines of XB program code.

Thus MERGE format files would be 255 format instead of 163 format.

Mostly backward compatible as shorter lines would still run fine, thus would still run TI Basic programs just fine but way faster.

As Crunch Buffer >0820 is running from RAM instead of VDP would also benefit as program lines are copied to VDP at >0820 in normal XB.

All pointers and flags except for a few would be in RAM.

For example >03C0 is the VDP ROLL OUT area and used constantly in XB, but RXB SAMS would use RAM instead thus big speed increase.

 

I will run some tests to see the speed difference between VDP vs SAMS RAM when using GPL and ROM Assembly.

  • Like 2
Link to comment
Share on other sites

And if we ever have a 16 bit Sam's this would be the fastest ever. One of the things that Myarc basic did was less vdp usage. Plus without using video ram for storage frees up vdp to support better graphics modes in basic without any issues. I see no reason at all to still limit ourselves to the 32k space now that you can even emulate a Sams via a pico pi.

  • Like 2
Link to comment
Share on other sites

5 hours ago, Gary from OPA said:

And if we ever have a 16 bit Sam's this would be the fastest ever. One of the things that Myarc basic did was less vdp usage. Plus without using video ram for storage frees up vdp to support better graphics modes in basic without any issues. I see no reason at all to still limit ourselves to the 32k space now that you can even emulate a Sams via a pico pi.

Well problem is you need someplace in the 32K to put the stuff that was in VDP.

Originally I was going to use >B000 but that opens a can of worms when the problem is using >B000 to >BFFF so deep six that idea.

So after some thought I have changed it to >2000 to >4FFF with possibly 32K of 8 4K pages.

This would allow for 28K of Strings or Numbers memory instead of the current 12K in XB now.

Leaving a full 4K for stack memory, yea less then currently set up but when have you used 5K of stack?

 

Now support for Assembly would still be there along with normal RXB CALL SAMS, so things that access these needs a kind of memory manager.

Thus CALL LINK, CALL INIT, CALL LOAD, CALL PEEK, and CALL POKE will return lower 8K to normal functions when called.

 

  • Like 3
Link to comment
Share on other sites

13 hours ago, RXB said:

Well RAM has to be faster than VDP as you have to use NOP often to use VDP or you outrun the VDP memory, not a problem with RAM.

Running STACK from RAM instead of VDP STACK would also speed up XB as VPUSH and VPOP are using 64 bytes at >0958 so that alone would free up 64 VDP bytes.

VPUSH and VPOP normally push 8 bytes onto or off the the VDP STACK, so that stack should be much faster.

Crunch Buffer >0820 could could also be increased so a line could be more then 163 bytes so we could have full 255 byte XB lines of XB program code.

Thus MERGE format files would be 255 format instead of 163 format.

Mostly backward compatible as shorter lines would still run fine, thus would still run TI Basic programs just fine but way faster.

As Crunch Buffer >0820 is running from RAM instead of VDP would also benefit as program lines are copied to VDP at >0820 in normal XB.

All pointers and flags except for a few would be in RAM.

For example >03C0 is the VDP ROLL OUT area and used constantly in XB, but RXB SAMS would use RAM instead thus big speed increase.

 

I will run some tests to see the speed difference between VDP vs SAMS RAM when using GPL and ROM Assembly.

This is cool idea. I did some cheap and dirty experiments putting integers and strings in VDP RAM instead in normal RAM and running some simple benchmarks. 

I was surprised that the speed difference was only about 12% if I remember right.

When you think about it, If you write code to set the VDP address and then read or write sequential data on the VDP chip it is just a normal memory read or write from the CPU.

The VDP chip is handling the memory incrementing AND on TI-99 it is a full speed read/write operation because the VDP chip in on the motherboard. 

Read/writes to expansion RAM are throttled down to 8 bit chunks so not ideal.

 

Of course read/writes to random locations in VDP RAM will be slower.  Come to think of that I didn't do that test. I will give it try. 

 

So SAMS is a great alternative to VDP. It will be a hell of a neat BASIC system, but don't be shocked if it you don't see 2x performance. 

 

  • Like 2
Link to comment
Share on other sites

26 minutes ago, TheBF said:

So SAMS is a great alternative to VDP. It will be a hell of a neat BASIC system, but don't be shocked if it you don't see 2x performance. 

It also depends on the overhead of switching SAMS pages. This could easily take up as many instructions as setting up a VDP address. 

  • Like 3
Link to comment
Share on other sites

I re-purposed a benchmark I found online years ago and made two versions.

One uses a RAM variable (just an address in Forth) and the other uses a VDP variable. 

 

The difference showed VDP was 23% slower reading and writing an integer (2 bytes) than in expansion RAM.

This was measured on real hardware, but I am using RS232 and terminal emulator for the Forth console.

 

23% will give you a nice performance boost on RXB. :) 

 

 

COM1_19200bps - TI-99 VT100 VT 2024-03-09 10_18_41 AM.png

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

13 minutes ago, Asmusr said:

It also depends on the overhead of switching SAMS pages. This could easily take up as many instructions as setting up a VDP address. 

For sure.

If you lock down the RAM window for SAMS to one 8K chunk the code to page in SAMS is quite small but not insignificant. 

 

I did a brutal nesting benchmarking, sub-routines calling sub-routines calling sub-routines very deeply.

I put each sub-routine in a different SAMS page. :) (cruel)

The benchmark went from 2:30  to 10:00 . 

 

 

  • Like 2
Link to comment
Share on other sites

3 hours ago, TheBF said:

23% will give you a nice performance boost on RXB. :) 

Consider the speed increases @RXB has provided by changing GPL to assembly, then add, say, 20% speed increase putting the variable stack into SAMS.  Sounds exciting.

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

3 hours ago, Asmusr said:

It also depends on the overhead of switching SAMS pages. This could easily take up as many instructions as setting up a VDP address. 

When you have a 32K normal XB puts the Numeric values in upper 24K starting at >FFE0 and goes downward which is why this reduces your program space. 

XB prescan looks for all variables and definitions and subs to set this up before a XB program is run.

In normal XB in console without 32K Numeric values and Strings and XB programs are all in VDP.

 

As I will make RXB SAMS work like normal XB but instead of VDP use SAMS RAM thus there will be less SAMS page switching the smaller the XB program.

This also means much larger XB will be allowed as that space that was used by Numeric Variables in 24K will not be used making more space for XB programs.

 

The routine in RXB since 2000 has always been a 18 byte program in Scratch Pad Fast RAM so that is why it is faster then a CALL LINK version used by others.

 

  • Like 1
Link to comment
Share on other sites

3 hours ago, TheBF said:

For sure.

If you lock down the RAM window for SAMS to one 8K chunk the code to page in SAMS is quite small but not insignificant. 

 

I did a brutal nesting benchmarking, sub-routines calling sub-routines calling sub-routines very deeply.

I put each sub-routine in a different SAMS page. :) (cruel)

The benchmark went from 2:30  to 10:00 . 

 

 

Pretty sure moving the VDP STACK to RAM should be way faster long term.

Link to comment
Share on other sites

2 hours ago, RXB said:

Pretty sure moving the VDP STACK to RAM should be way faster long term.

With your strategy of minimizing paging in and out absolutely. But that paging will get in your face if it's too frequent.

  • Like 1
Link to comment
Share on other sites

Sorry for spamming, but this reminded me of some speculations about the best way to make SAMS available in BASIC that I made a few years ago. My idea was that BASIC would make SAMS available as arrays, and it would internally maintain a list of allocated areas (i.e. a memory manager). To the user it would make these subroutines available:

 

CALL AMSDIM(ARR,N)              // Allocate an array in SAMS of size N. Return reference to array in ARR. Default data type is number. 
CALL AMSGET(ARR,I,VAL)          // Read entry I of array ARR into variable VAL
CALL AMSSET(ARR,I,VAL)          // Set entry I of array ARR to value VAL
CALL AMSFILL(ARR,I,L,VAL)       // Fill L entries of array ARR from index I with value VAL
CALL AMSCOPY(ARR1,I1,ARR2,I2,L) // Copy L entries from ARR1 index I1 to ARR2 index I2
CALL AMSFREE(ARR)               // Deallocate array

// Data types
CALL AMSDIM(ARR,"N",N)   // number (default)
CALL AMSDIM(ARR,"S",N,M) // string (fixed length M)
CALL AMSDIM(ARR,"B",N)   // byte
CALL AMSDIM(ARR,"W",N)   // word

// Same as above for 2-dimensional arrays
CALL AMSDIM(ARR,N,M)                    // Also with data types
CALL AMSGET(ARR,I,J,VAL)                // Read entry I, J of array ARR into variable VAL
CALL AMSSET(ARR,I,J,VAL)                // Set entry I, J of array ARR to value VAL
CALL AMSFILL(ARR,I,J,L,M,VAL)           // Fill a 'rectangle' at (I,J) size (L,M)
CALL AMSCOPY(ARR1,I1,J1,ARR2,I2,J2,L,M) // Copy a 'rectangle' between arrays

 

Just an idea, it could be implemented in any version of BASIC.

 

Edit: and there could also be subroutines for copying byte data directly from SAMS to VDP.

Edited by Asmusr
  • Like 3
Link to comment
Share on other sites

Problem with TI Basic is it is so SLOOOW! 

Also TI Basic ONLY USES VDP, it never once uses RAM. 

 

RXB SAMS is designed to use SAMS RAM instead of VDP.

 

VDP STACK will be in SAMS RAM

String Variables will be in SAMS RAM not VDP

Variable names will be in SAMS RAM not VDP

 

The routines to copy from RAM to VDP or VDP to RAM are already built into XB ROMs.

SAMS RAM is just a bonus to these routines already were in XB ROMs version 110

  • Like 2
Link to comment
Share on other sites

  • 2 weeks later...

By all means go for it! Also it would be great to be able to use variable length strings in SAMS without having to convert. It appears that all the info is there, i.e. "string length byte" to make this happen? Thanks.

Link to comment
Share on other sites

Problems with Ryte Data GPL Assembler and RAG GPL Assembler and even Thierry GPL Assembler all crash for various reasons.

None of these apparently are designed to deal with this project.

Some commands just crash Ryte Data GPL Assembler due to 35 year old bugs.

RAG GPL Assembler only lists to Printer so unusable to list to Disk or Hard drive

Thierry GPL Assembler gives errors that are not defined or why it crashed as there is a error it just stops working with no clue what is wrong!

With no list file to explain what is wrong it makes the Assembler totally useless, same exact problem I had with RAG GPL Assembler.

 

So had Ralph help me install to use XGA99 on my PC to use it instead, but OMG still problems that thankfully Ralph is working on fixing.

 

But some success as replacing many of the VDP Flags and Temp locations from VDP to RAM has shown this is going to work.

I have yet to put the Crunch Buffer from VDP to RAM or the VDP STACK from VDP to RAM but that requires some XB ROM modifications first.

(This is going to free up some XB ROM space for more features.)

  • Like 3
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...