SAMS usage in Assembly

[gregallenwarner]

I was wondering if anybody could help me with some Assembly techniques for using the SAMS extended memory. Assembly is really the only language I'm interested in writing in at the moment.

 

I'm specifically wondering about broader techniques here, not the basic how to control the card stuff. That much I'm familiar with. I know how to page in and out the various banks of memory.

 

What I'm more interested in is any programming techniques that people have come up with for making efficient use of it. For example:

 

1. How do you use the TI's address space? Do you select an area of the TI's memory space to designate a code region, and another area a data region?

 

2. Where do you place the code for switching banks? What's the strategy behind switching banks in the middle of a running program?

 

3. Do you have executable code that resides in multiple banks? How do you switch between them? How do you make a call to a subroutine that exists in another bank?

 

4. How does this all impact the linking loader? How do you load a program into multiple banks? Do you have to write your own loader? Also, is there any difference in loading code based on whether it's an EA3 or EA5 program?

 

Sorry for the wall of questions. I've never used the SAMS before, so it's proper usage is a bit of a mystery to me.

[TI-Sissy]

wall of questions. i like it! ur lucky, i don't understand much of this stuff here. i don't know enough to even ask questions!

[+adamantyr]

I've had a lot of the same questions! There's definitely a case here of having to write your program in a particular fashion to take full advantage.

 

I had considered for my CRPG how I may use it... For example, I'd probably have separate "modules" of executable code for the two primary modes, travel and combat, that occupy the same pages of memory, while common utilities, switching mechanisms, and so forth are kept in a "page zero" area, which remains constant. Data storage would definitely be in pages... the 4k of "travel map" would be swapped out for buffer space for combat, for example.

 

However, given I don't HAVE a SAMS card and a general disinclination to hooking up my potential-fire-hazard PEB which isn't compatible with my CF card reader system, I haven't really explored this... I really want to make sure the finished game works on the hardware, and I'm hoping I can make everything fit in the standard 32k with an 8k RAM Supercart. (I do own now a "SuperSpace II" cartridge with four 8k pages, which I'll resort to if need be, but that's definitely going to make accessibility hard! I may have to write a SAMS version in emulation only at that point.)

 

Adamantyr

[RobertLM78]

The memory, as I understand, is accessed through 8k pages. The SAMS is cool, but kind of a PITA. That's why I dig the Geneve so much - no faffing with paged memory.

[Willsy]

It's 4k pages but yeah - a PITA.

[+Lee Stewart]

And—those 4K pages map to the 32K card's space—and only that space. So, no 32K card; but, you probably already knew that.

 

There are several Micropendium articles on it (see WHTech site).

 

...lee

[RXB]

The memory, as I understand, is accessed through 8k pages. The SAMS is cool, but kind of a PITA. That's why I dig the Geneve so much - no faffing with paged memory.

Hmm sorry no!

 

SAMS is organized as 4K pages.

[RobertLM78]

Hmm sorry no!

 

SAMS is organized as 4K pages.

Yes, that was clarified by Willsy 3 posts back

[RXB]

If you want to play around with it is in Clasic99 RXB supports SAMS

 

As RXB does all the management of SAMS pages for you all you have to do is load a program SAMS lower 8K and use it then switch banks.

 

 

I wrote a game that loads over 400K of screens from VDP to the SAMS. It transfers then back and forth and saves your progress to the SAMS.

 

 

SAMS Assembly loader and show how to use it.

 

Edited August 28, 2014 by RXB

[gregallenwarner]

Thanks, Rich.

 

To be honest, rather than knowing how the RXB user makes use of the SAMS, I'm much more interested in how RXB itself makes use of it. Is there a memory manager present that keeps track of pages under the hood? What kind of memory structure do you use to store this data?

[Asmusr]

I actually have a SAMS card but I'm not aware of any software except RXB (which I don't have) that uses it. I have thought about using it for a game with a big map that is updated dynamically, in which case I would simply swap in the active page/screen into low memory. But for something like Sabre Wulf with highly repetitive graphics it's not really necessary, and for static data you could just as well use a ROM cart.

[+InsaneMultitasker]

I know there is/was documentation out there, perhaps part of the RAG assembler package and the AMS package.

 

The process is not overly difficult to map pages in and out. I believe the following information comes from an article in Micropendium written by Bruce Harrison.

ACCESS and MAPPING



             To use other than the default setup, you have to do two

        things.  First, you have to "turn on" the card's memory in the

        >4000 block and write to the mapping registers there.  Second,

        you have to "turn on" the mapper function to make what you've

        written into the >4000 block take effect.  The first step in all

        this is to set Register 12 to the value >1E00, which is the CRU

        address of the AMS card.  Now doing a SBO 0 instruction will

        enable the >4000 memory block for reading and writing.  In that

        block, each word starting with >4000 and ending with >401E acts

        to control what page maps into what memory location.  The

        subroutine AMSINI (see sidebar) initializes all the mapping

        registers to power-up condition.  Thus, for example, >4004 is

        set for page 2, >4006 to page 3, etc.  In our own program, we're

        mapping things into the >A000 through >F000 blocks.  Thus the

        registers we write to in >4000 are at >4014 thru >401E.  To make

        a mapping selection, we write the desired page number to the

        high order byte of the control register.  Let's take a concrete

        example.  Suppose we want pages 4, 5 and 6 of the AMS to behave

        as if they were at >A000, >B000, and >C000.  It's this easy:



                  LI  R12,>1E00 CRU ADDRESS

                  SBO 0         TURN ON CARD'S >4000 BLOCK

                  LI  R1,>0400  PAGE NUMBER IN LEFT BYTE

                  LI  R3,>4014  MAPPING REGISTER FOR >A000 BLOCK

                  MOV R1,*R3+   WRITE TO >4014 AND ADD 2 TO R3

                  AI  R1,>100   LEFT BYTE OF R1=5

                  MOV R1,*R3+   WRITE 5 TO >4016 AND ADD 2 TO R3

                  AI  R1,>100   LEFT BYTE OF R1=6

                  MOV R1,*R3    WRITE 6 TO LEFT BYTE AT >4018



             This sets the registers, but does not actually start the

        mapper working.  To put the mapping in effect, we have to

        perform one more operation:



                  SBO 1          TURN ON THE MAPPER



             Now that the mapper is turned on, anything written to >A000

        thru >CFFF will actually be written into pages 4 thru 6 of the

        AMS memory instead of into pages >A thru >C.  Similarly, any

        memory reading from >A000 thru >CFFF will actually read the

        contents of pages 4 thru 6 of the AMS memory.  Thus your program

        can write and read as if to >A000 thru >CFFF, but the mapper

        will make things actually access the pages 4 thru 6 in the AMS

        card.  You can turn off access to the card's >4000 block and

        still leave the mapper in effect by the instruction SBZ 0.

        (Provided R12 still contains >1E00.)  You can turn off the

        mapper by SBZ 1, and then the areas >A000 thru >CFFF will revert

        to "normal", reading and writing to pages >A thru >C of the AMS

        card.



             In the finished AMS version of Video Titler, the program

        works by frames, where each frame accounts for three pages of

        the AMS memory.  We use an odd-even scheme, so that odd numbered

        frames (1,3,5,...19) go into pages mapped to >A000 thru >CFFF,

        and even numbered ones go into pages mapped to >D000 thru >FFFF.

        This way the program always has immediate access to two frames

        at any given time.  Let's say for example that the user asks to

        load a TI-Artist picture (with color) into Frame 1.  We take the

        desired frame number, multiply that by three, add one, then put

        that in the left byte of a workspace register.  Since this is an

        odd frame, we use the mapping registers at >4014 thru >4018, and

        put 4, 5, and 6 into the left bytes of those mapping registers,

        respectively.  (For an even page, we'd use >401A thru >401E.)

        Now when the program reads the file, it dumps the contents of

        the pattern and color parts into >A000 thru >CFFF, which really

        goes into pages 4 thru 6 of the AMS memory.  In similar fashion,

        frame 2 goes into pages 7 thru 9, frame 3 into pages 10 thru 12,

        frame 4 goes to pages 13 thru 15, and so on until frame 20,

        which goes into pages 61 thru 63.  Clear as mud?  Look at Part

        Two of the Sidebar, which may help.  Meanwhile, how about a

        little different perspective?



                           The AMS Owner's Viewpoint



             The Super AMS card is a most welcome and needed addition to

        the TI 99/4A.  The physical aspects are a well-made, high-quality

        card which inserts in place of the 32K card.  In normal use, it

        duplicates the 32K card exactly, except for the absence of an

        indicator light.  In expanded mode, the card provides from 128K

        to 1 meg of paged memory, depending on the chips installed.



             There are three disks of software provided with the card,

        of which two are archived.  Included is an excellent memory

        tester that writes and reads to every bit.  This assures the

        user that everything is functioning properly.  Also included is

        an excellent disk copy program, AMS Copy.  The program reads an

        entire 720 sector disk into memory, then writes to the copy disk

        in one pass.  Contents of the master disk remain in memory,

        allowing as many copies to be made as needed without re-reading.

        Also there were two games, which I could not get to run.  The

        remainder of the software is mainly for programmers and of

        little consequence for the end user.  So, aside from testing the

        memory and copying disks, what can be done with the Super AMS

        card? Well, prior to the middle of July, the answer was "not too

        much."

             Enter Bruce Harrison.  When I first purchased the Super AMS

        card back in May at Cleveland, Bruce rather poo-pooed it,

        saying that he could write any program for the TI and keep it

        well within the 32K space.  No argument here.  Then I posed the

        hypothetical question....how many titles could the Video Titler

        program hold in 256K of memory?  To which Bruce answered, "I'll

        think about it."



             Well, Bruce did a lot of thinking and a lot of programming.

        The result.... the Video Titler can now hold up to twenty color

        graphic files in memory on a 256K card.  Super.  They are

        instantly available using any of the many different wipes in the

        program.  If you make a mistake, or change your mind, any frame

        can be reloaded without changing the others.  The sequence can

        also be started at any frame.  Anyone who has previously used

        the Video Titler will most certainly appreciate the new

        features, added versatility, speed, and power of the new AMS

        Video Titler.  The entire operation of paging twenty titles into

        memory, then using them is totally seamless and transparent to

        the user.  It is as though the TMS9900 had twenty address lines.

        Substantial documentation is included with the program, but I

        dare say that most folks won't read them.  Aside from possibly

        looking up which keys to use for what wipes, the Titler is that

        easy to use.  When you are ready to quit, the Titler returns

        nicely to the E/A menu screen.



             It's rather ironic....  To the best of my knowledge, Bruce

        Harrison is the first programmer outside of the SAMS development

        team to make any real productive software for the Super AMS

        card.  Yet, he is the one programmer that never received a card

        to use.  The AMS Video Titler beta copy worked flawlessly the

        very first time.  This is a real tribute to outstanding

        programming ability.



                            Programmer's Update



             Since the above was written, I have received a set of the

        AMS documentation and an offer of a card from David Ormand of

        the SW99ers.  David has been sent a copy of the AMS Video Titler

        and a letter accepting the offer of a card to use for

        programming and testing my new products designed for use with

        AMS.



* SIDEBAR PART ONE - A TEST PROGRAM

* COMPLETE AS SHOWN

*

* TEST PROGRAM FOR AMS CARD

* SPECIAL BY B. HARRISON

* FOR TITLER AMS VERSION

* AMST/S

       REF  KSCAN,VMBW

       DEF  START

KEYADR EQU  >8374        Key-unit address

KEYVAL EQU  >8375        Reported keystroke

STATUS EQU  >837C        GPL STATUS BYTE

GPLWS  EQU  >83E0        GPL workspace

GR4    EQU  GPLWS+8      GPL Reg 4

GR6    EQU  GPLWS+12     GPL Reg 6

STKPNT EQU  >8373        stack pointer

LDGADD EQU  >60          load grom address address

XTAB27 EQU  >200E        a storage location

GETSTK EQU  >166C        get stack



START  LWPI WS           LOAD OUR WORKSPACE

       BL   @AMSINI      USE AMS INITIALIZE SUBROUTINE (BELOW)

       C    R1,@>401E    AMS CARD PRESENT? 0=NO 401E=0F0F=YES

       JNE  NOAMS        IF NO AMS CARD, JUMP AHEAD

       SBO  1            TURN ON MAPPER

       CLR  R1           R1=0

       CLR  R4           R4=0

       MOV  R1,@>401E    SET >F000 TO PAGE >00

       MOV  R1,@>F000    SET FIRST WORD PAGE 0 TO 0

       LI   R3,>8000     R3 TO PAGE >80

       MOV  R3,@>401A    SET >D000 TO PAGE >80

       LI   R1,>0F00     START AT PAGE 15

AMSLP1 AI   R1,>100      ADD ONE PAGE

       INC  R4           INC NUMBER FOUND

       MOV  R1,@>401C    SET >E000 TO PAGE 16, 17, 18, ETC.

       MOV  R1,@>E000    LOAD >E000 WITH PAGE #

       C    R1,@>E000    DID IT LOAD?

       JNE  AMSDO        IF NOT, WE'RE BEYOND LAST PAGE

       C    @>F000,@>E000     CHECK PAGE 0 FOR CHANGE

       JEQ  AMSDO        IF EQUAL, JUMP

       CI   R1,>9000     LIMIT NUMBER?

       JL   AMSLP1       IF LESS, REPEAT

       C    @>D000,@>E000     CHECK PAGE 80 FOR CHANGE

       JNE  AMSLP1       IF NOT EQUAL, REPEAT

AMSDO  DEC  R4           ONE LESS (R4 EQUALLED PAGE NOT FOUND)

       MOV  R4,@AMS      SAVE NUMBER OF PAGES ABOVE 15

       BL   @AMSINI      AMS INITIALIZE (BACK TO "NORMAL")

       SBZ  0            TURN OFF CARD - MAPPER STILL ON

       SBZ  1            TURN OFF MAPPER

       JMP  REPORT       JUMP TO REPORT SECTION

NOAMS  LI   R0,11*32+3   ROW 12, COL 4

       LI   R1,NOSTR     NO AMS MESSAGE

       BL   @DISSTR      DISPLAY THAT

       JMP  KEYEX        JUMP TO EXIT ROUTINE

REPORT LI   R0,10*32+3   ROW 11, COL 4

       LI   R1,PGSTR     PAGES STRING

       BL   @DISSTR      DISPLAY THAT

       A    R2,R0        ADD LENGTH TO POINTER

       MOV  @AMS,R3      GET NUMBER OF PAGES PAST 15

       MOV  R3,@>835E    PUT AT >835E

       BL   @SHWINT      SHOW NUMBER ON SCREEN

       LI   R0,12*32+3   ROW 13, COL 4

       LI   R1,FRMSTR    FRAMES STRING

       BL   @DISSTR      SHOW THAT

       A    R2,R0        ADD LENGTH

       CLR  R2           CLEAR R2

       LI   R1,3         SET R1 TO 3

       DIV  R1,R2        DIVIDE R2-R3 BY 3

       AI   R2,4         ADD 4 FOR PAGES 4 THRU 15

       MOV  R2,@>835E    QUOTIENT PLUS 4 (FRAMES) TO >835E

       BL   @SHWINT      SHOW THAT NUMBER (1/3 OF PAGES NUM + 4= FRAMES)

KEYEX  BLWP @KSCAN       SCAN KEYBOARD

       LIMI 2            ALLOW INTS

       LIMI 0            STOP INTS

       CB   @ANYKEY,@STATUS KEY STRUCK?

       JNE  KEYEX        IF NOT, REPEAT

       LWPI GPLWS        LOAD GPL WORKSPACE

       B    @>6A         BACK TO GPL INTERPRETER

*

* SUBROUTINES SECTION

*

* AMSINI SETS AMS CARD TO "POWER-UP" CONDITION

*

AMSINI LI   R12,>1E00    AMS CRU BASE

       SBO  0            TURN ON AMS

       LI   R1,>FEFF     (THIS IS ->0101)

       LI   R0,>4000     START OF MEMORY

AMSLP  AI   R1,>0101     ADD 1 PAGE

       MOV  R1,*R0+      MOVE 2 BYTES TO MEM-MAPPER

       CI   R0,>4020     ALL DONE?

       JLT  AMSLP        NO, INIT MORE

       RT                RETURN

*

* DISSTR DISPLAYS STRING POINTED BY R1 AT SCREEN

* LOCATION POINTED TO BY R0

*

DISSTR MOVB *R1+,R2      LENGTH BYTE TO R2

       JEQ  DISX         IF ZERO, SKIPIT

       SRL  R2,8         RT JUST

       BLWP @VMBW        WRITE STRING TO SCREEN

       A    R2,R1        ADD LENGTH TO POINTER

DISX   RT

*

* FOR SHWINT, FIRST PUT INTEGER AT >835E,

* AND POINT R0 AT DESIRED LOCATION

* THEN BL  @SHWINT

*

SHWINT BLWP @GPLLNK      USE GPLLNK VECTOR

       DATA >2F7C        DATA FOR INT TO STRING

       MOVB @>8361,R2    LENGTH TO R2

       SRL  R2,8         RT JUST.

       MOVB @>8367,R1    ADDR TO R1

       SRL  R1,8         RT JUST

       AI   R1,>8300     ADD OFFSET

       BLWP @VMBW        WRITE STRING

       RT

*  GENERAL PURPOSE GPL LINK

*  by Doug Warren/Craig Miller

*

GPLLNK DATA GLNKWS

       DATA GLINK1

RTNAD  DATA XMLRTN

GXMLAD DATA >176C

       DATA >50

GLNKWS EQU  $->18

       BSS  >08

GLINK1 MOV  *R11,@GR4

       MOV  *R14+,@GR6

       MOV  @XTAB27,R12

       MOV  R9,@XTAB27

       LWPI GPLWS

       BL   *R4

       MOV  @GXMLAD,@>8302(R4)

       INCT @STKPNT

       B    @LDGADD

XMLRTN MOV  @GETSTK,R4

       BL   *R4

       LWPI GLNKWS

       MOV  R12,@XTAB27

       RTWP

*

* DATA SECTION

*

WS     BSS  32           OUR REGISTERS

AMS    DATA 0            PAGES BEYOND 15

NOSTR  BYTE 19

       TEXT 'NO AMS CARD PRESENT'

PGSTR  BYTE 14

       TEXT 'PAGES FOUND = '

FRMSTR BYTE 9

       TEXT 'FRAMES = '

ANYKEY BYTE >20

       END

*

* END OF COMPLETE PROGRAM

*

* PART TWO OF SIDEBAR - A "SNIPPET"

*

* SUBROUTINE SETFRM (FROM AMS VIDEO TITLER)

* ON ENTRY, R3 CONTAINS THE CURRENT FRAME NUMBER (1 THRU XX)

* WHERE XX CAN BE 9 (128K CARD), 20 (256K CARD), OR 41 (512K CARD)

* PAGE NUMBERS START WITH 0, SO FOR EXAMPLE ON A 256K CARD, PAGES

* ARE NUMBERS 0 THRU 63, FOR A TOTAL OF 64 PAGES

*

* THE PROGRAM "KNOWS" HOW MANY FRAMES ARE AVAILABLE, AND

* WON'T USE THIS SUBROUTINE BEYOND THE AVAILABLE FRAMES.

*

SETFRM MOV  R3,R1        COPY CURRENT FRAME # TO R1

       MPY  @THREE,R3    MULTIPLY R3 BY 3

       INC  R4           ADD 1 TO PRODUCT IN R4 (PAGE NUMBER ON AMS = 4 THRU YY)

* YY IS THE HIGHEST PAGE -2

       SWPB R4           SWAP TO LEFT BYTE

       COC  @ONEWD,R1    CHECK CURRENT FRAME FOR ODD/EVEN

       JNE  SETEVN       IF NOT 1 IN LSB, EVEN

SETODD LI   R8,>4014     MAP FOR >A000

       LI   R1,>A000     SET R1=>A000

       JMP  SETPGS       JUMP

SETEVN LI   R8,>401A     MAP FOR >D000

       LI   R1,>D000     SET R1=>D000

SETPGS LI   R12,>1E00    AMS CRU ADDR

       SBO  0            TURN ON CARD

       SBO  1            TURN ON MAPPER

       LI   R5,3         THREE WRITES TO MAKE (3 PAGES PER FRAME)

SETLP  MOV  R4,*R8+      SET CURRENT PAGE AND INCT R8

       AI   R4,>100      NEXT PAGE

       DEC  R5           DEC COUNT

       JNE  SETLP        RPT IF NOT 0

       SBZ  0            TURN OFF CARD MEMORY (>4000)

* THE MAPPER STAYS ON

       RT                RETURN

* UPON RETURN, R1 IS USED TO DETERMINE WHERE THE FRAME IS SENT OR GOTTEN FROM

* DEPENDING WHETHER WE'RE WRITING OR READING A FRAME

*

* END OF PART 2 OF SIDEBAR

[+Lee Stewart]

@Willsy's TurboForth can use it. TF auto-detects SAMS and initializes it if it is found. TF has a >MAP word for managing SAMS memory. It requires on the stack a bank number and an address on a 4K boundary in 32K RAM space to map it to.

 

...lee

 

PS: I may lift @Willsy's code into fbForth. He gave me permission—I just don't have the hardware, so I didn't really think much about it. I know I can test it under emulation...so...maybe.

Edited August 29, 2014 by Lee Stewart

[+InsaneMultitasker]

The memory, as I understand, is accessed through 8k pages. The SAMS is cool, but kind of a PITA. That's why I dig the Geneve so much - no faffing with paged memory.

Both used paged memory.

 

The Geneve pages memory using an 8-byte mapper, where each byte represents 8K of a 64K window. SAMS differs in the window size (4k) and the mapping (CRU based). I'm not sure where the big PITA comes from, it's pretty simple really.

[RobertLM78]

I'm honestly not sure how memory works under the hood on the Geneve. What I do know is I was able to do what I wanted with Myarc BASIC without moving stuff around in memory like I would have had to do with SAMS and RXB.

Edited August 29, 2014 by RobertLM78

[+InsaneMultitasker]

I'm honestly not sure how memory works under the hood on the Geneve. What I do know is I was able to do what I wanted with Myarc BASIC without moving stuff around in memory like I would have had to do with SAMS and RXB.

Ah, yes, gotcha. Myarc BASIC for the Geneve takes away the memory management pain in that regard

[RXB]

Thanks, Rich.

 

To be honest, rather than knowing how the RXB user makes use of the SAMS, I'm much more interested in how RXB itself makes use of it. Is there a memory manager present that keeps track of pages under the hood? What kind of memory structure do you use to store this data?

When RXB sees the command:

CALL AMSINIT

or

100 CALL AMSINIT ! Can be used in a program or command mode.

 

CALL AMSINIT tells RXB to find the SAMS card and sets the memory from top of what ever SAMS size top to bottom with the values of (top page) 255 to (bottom page) 0 for each 4K page of SAMS memory.

RXB turns off interrupts first then sets the memory pages then puts the SAMS card into MAP MODE and returns to XB.

This is a cut and paste from the RXB 2012 documents:

 In MAP mode the mapper register setup is equivalent to: EXAMPLE1
 
     mapper address  mapper  page num            address range
     --------------  ------  --------            -------------
      HEX     Dec            HEX  Dec             memory area
      ---     ---            ---  ---             -----------
     >4004 = 16388 is MR02 = >10 = 16 points to >2000 - >2FFF range
     >4006 = 16390 is MR03 = >11 = 17 points to >3000 - >3FFF range
 
     >4014 = 16404 is MR10 = >12 = 18 points to >A000 - >AFFF range
     >4016 = 16406 is MR11 = >13 = 19 points to >B000 - >BFFF range
     >4018 = 16408 is MR12 = >14 = 20 points to >C000 - >CFFF range
     >401A = 16410 is MR13 = >15 = 21 points to >D000 - >DFFF range
     >401C = 16412 is MR14 = >16 = 22 points to >E000 - >EFFF range
     >401E = 16414 is MR15 = >17 = 23 points to >F000 - >FFFF range
 
     (MR=Mapper Register)

In RXB presently SAMS 4K pages 0,1,2,3,4,5,6,7 are reserved (32K) for future use in RXB (I have some ideas not fully written yet) watch for future expansions of RXB.

But 240 pages of 4K are for use in RXB SAMS to the user. So 960K is available to any user depending on size of the SAMS card you use.

Now RXB includes the same commands originally created by Joe Delekto and Paul Schippnick. (Depending on what year you talk about.)

These commands are

CALL AMSON ! Turns on the SAMS mapper registers write access.

CALL AMSOFF ! Turns off the SAMS mapper registers write access.

CALL AMSPASS ! Turns on the SAMS pass mode so it acts like a normal TI 32K.

CALL AMSMAP ! Turns on the SAMS map mode so pages can be changed, but CALL AMSON must be turned on first.

Lastly the real meat of RXB SAMS support is CALL AMSBANK(low page,high page)

Here is a page from RXB docs on AMSBANK:

The AMSBANK command will only work with a AMS memory card.
AMSBANK turns on the read/write lines of AMS mapper registers
stores the first value into the mapper register that sets low
half of lower 8K, then stores the second value into the mapper
register that sets high half of lower 8K. If the page-number
is less then 0 or larger than 239 a BAD VALUE error results.
If page-number is larger than the AMS card size allows
* AMS BANK NUMBER ERROR * results. Neither error will affect
previously loaded pages. No lock-up will result.
AMSBANK breaks the lower 8K into two halves of 4K. The lower
4K is Hex >2000 to >2FFF and the upper is Hex >3000 to >3FFF
so switching lower 8K requires two 4K pages to be used. This
is the only disadvantage to AMSBANK, but flexibility does
result. Less wasted pages results in more memory available.
The formula is: AMS SIZE/4-16=pages.
EXAMPLE: 256/4-16 is 48 pages.
In other words 0 to 15 pages would be 16 pages for use.
The odd ball numbering scheme of AMSBANK results from pages
0 to 15 not being used in MAP mode. AMSBANK creates it's
own numbers of pages 0 to 239 by starting actually at page
16 of the AMS. That would be page 0 of AMSBANK. This lay out
leaves open 8 4K pages for PASS mode, and 8 4K pages for
future use.

The reason I did not require single 8K pages is you can put the same SAMS bank in both the lower and upper page at same time and when you write to either it writes to both at same time.

EXAMPLE:

100 CALL AMSINIT ! INITIALIZE LOWER 8K SAMS MEMORY
110 CALL AMSBANK(5,5) ! AMS PAGES IS IN LOWER 8K IN BOTTOM >2000 AND UPPER >3000 AT SAME TIME
120 CALL LOAD(8192,128,255) ! PUT HEX >80 AND >FF AT >2000 IN LOWER 8K
130 CALL PEEK(12288,X,Y) ! GET VALUES AT HEX >3000 AND PUT INTO X AND Y VARIABLES
140 CALL PEEK(8192,A,B) ! GET VALUES AT HEX >2000 AND PUT INTO A AND B VARIABLES
150 PRINT A;B,X;Y

run this program and you get:

128 255 128 255

 

This much faster then variables or VDP access as it writes two places at same time. All kinds of ideas for this come to mind for search or compare in XB.

 

Maybe I need to make some more videos.

 

P.S. RXB uses the SAMS for ASSEMBLY or extra memory that the user decides what to use it for unlike Myarc XB you are basically stuck with one way to use it. That makes it easy but limited.

Edited August 29, 2014 by RXB

[jacquesg]

You can find the 3 disks that accompanied the SAMS card when released by the SW99er group on the Yahoo site named SWPB under the Files section. These disks contain a number of archived files containing Art Green's SAM's program including, a SAMS macro assembler, linker and library manager, with explanatory manuals. Joe Delekto's c99 for use with the SAMS card is also included. This was used to create the TI-NOPOLY program. Art also included a menu program to run SAMS and non-SAMS programs. There are other SAMS related items on this Yahoo site.

 

If you have trouble accessing this site write to me privately.

 

Regards,

 

Jacques

[Willsy]

http://turboforth.net/source/Bank1/1-04-Memory.html

 

t's easy to select banks in the SAMS card. See the above page for some source. Look for >MAP (as in "to memory mapper").

[gregallenwarner]

Rich,

 

Forgive me if my question doesn't make a lot of sense, but how does RXB keep the program memory safe when remapping banks with CALL AMSBANK? In other words, if I've got an RXB program loaded into memory, if I want to map new page into a memory bank, how does it avoid the situation where the current page of memory where the current line of code is being executed gets paged out for a different one, making the next line of code for execution unavailable? Or is this an impossible scenario?

 

For example, if I've got program code loaded at >2000, and the instruction at >2000 instructs the SAMS to swap out bank >2 with a new page, all of a sudden, the memory at >2000 changes, so when the program counter increments to the next instruction at >2002, the memory appearing at that location is now different from a new bank being paged in, and my program is corrupted. Does RXB have a way to detect this or prevent it?

 

I'm just trying to develop good strategies for using the SAMS so I avoid any pitfalls like this as I'm experimenting with it.

[RXB]

Rich,

 

Forgive me if my question doesn't make a lot of sense, but how does RXB keep the program memory safe when remapping banks with CALL AMSBANK? In other words, if I've got an RXB program loaded into memory, if I want to map new page into a memory bank, how does it avoid the situation where the current page of memory where the current line of code is being executed gets paged out for a different one, making the next line of code for execution unavailable? Or is this an impossible scenario?

 

For example, if I've got program code loaded at >2000, and the instruction at >2000 instructs the SAMS to swap out bank >2 with a new page, all of a sudden, the memory at >2000 changes, so when the program counter increments to the next instruction at >2002, the memory appearing at that location is now different from a new bank being paged in, and my program is corrupted. Does RXB have a way to detect this or prevent it?

 

I'm just trying to develop good strategies for using the SAMS so I avoid any pitfalls like this as I'm experimenting with it.

Impossible as the SAMS support for RXB only swtiches the lower 8K used for Assembly, but can also be used for many more functions if you watch the demos of loading graphics or games or Assembly.

 

First off why would you load code to swap SAMS banks when RXB has that feature built in and management is handled for you by CALL AMSBANK(low page,high page) ?????

 

Now say you load an Assembly program and want to load another and use both at once from RXB.

 

100 CALL AMSINIT ! Must proceed any use of AMSBANK or the pages will be out of order and unknown result will happen.

....... program....

500 CALL AMSBANK(0,1) ! Page 0 and 1 are used for lower 8K in two 4K pages of page 0 is >2000 to >2FFF and page 1 is >3000 to >3FFF

510 ! Your Assembly program is loaded here....

520 CALL AMSBANK(2,3) ! Page 2 and 3 are used for lower 8K in two 4K pages of page 2 is >2000 to >2FFF and page 3 is >3000 to >3FFF

530 ! Your other Assembly program is loaded here....

.... program....

800 CALL AMSBANK(low page,high page) ! Put either 0,1 or 2,3 depending on which Assembly program you want to use.

 

So do you see you have 240 pages in RXB to use for 4K pages in lower and higher page?

 

Now only pitfall is you must write your program so you do not over write your own code, but that is no different then using the same variable and not saving it.

In other words like doing this:

100 A(X,Y)=10

... program ...

340 A(X,Y)=50

 

But you did not change X,Y so you just over wrote the value in A(X,Y) with 50 instead of the 10 it was before. You see not changing X,Y resulted in a bad value.

Thus the same goes for CALL AMSBANK(0,1) or CALL AMSBANK(2,3) as you just need to keep the correct pages in lower 8K per what you are doing.

 

By the way CALL AMSBANK(X,Y) is equally valid as hard coded numbers like CALL AMSBANK(44,66)

 

Additionally RXB has a way to load faster then any other way for the SAMS memory.

Example loader:

RXB SAMS LOADER EXAMPLE

100 ! RXB AMS LOADER DEMO
110 ! NO ASSEMBLY USED
120 CALL AMSINIT
130 FOR A=1 TO 20
140 CALL AMSBANK(A,A+20)
150 CALL BLOAD("DSK1.SCRN"&STR$(A)) ! This line could just as easily load Assembly programs saved with CALL BSAVE that creates these files.
160 CALL MOVES("RV",2079,8192,0)
170 NEXT A
180 FOR A=1 TO 20
190 CALL AMSBANK(A,A+20) 
200 CALL MOVES("RV",2079,8192,0)
210 NEXT A
220 GOTO 180

Watch the video demos as it shows this working. And works with Assembly or in the above example loads LOWER 8K with a copy of video memory.

Edited August 31, 2014 by RXB

[RXB]

I forgot to mention that RXB command CALL AMSINIT will not delete anything out of the SAMS or will it change any data in the SAMS or will it affect any programs in memory.

CALL AMSINIT just loads the SAMS memory mapper with the values of each page from lowest to highest.

 

So what every page you were on is still the same you loaded.

Edited September 1, 2014 by RXB

[+Vorticon]

 

I know there is/was documentation out there, perhaps part of the RAG assembler package and the AMS package.

 

The process is not overly difficult to map pages in and out. I believe the following information comes from an article in Micropendium written by Bruce Harrison.

 

 

Do you happen to know which issue this was published in by any chance?

[+Lee Stewart]

Do you happen to know which issue this was published in by any chance?

 

Walid, here's an excerpt from the list of articles for Micropendium:

Article                                        Date       Page
-----------------------------------            --------   ----
AMS CARD TAKING ADVANTAGE OF MEMORY            9/1/1996   22
AMS COPY REV                                   9/1/1995   24
AMS CUSTOMIZING YOUR AMS CARD                  7/1/1995   14
AMS REV                                        7/1/1995   20
AMS SCHEMATICS BECOME PUBLIC DOM               3/1/1994   23
AMS SLIDESHOW REV                              1/1/1997   34
AMS UPDATE TO THE AMS AND SCSI                 7/1/1995   20
AMS VIDEO TITLER REV                          11/1/1996   35

...lee

[+Vorticon]

Thanks Lee! I have had a SAMS card for quite some time but I still have to do anything with it. All I use it for is as a glorified 32K RAM expansion which is ignominious when you think of it, and I'm hoping to re-familiarize myself with its use in the hope that the gods of inspiration will perhaps bestow on me a good project idea fit for its technical greatness