SAMS usage in Assembly

[GDMike]

Let's try something..

I'll try to explain again... lol..oh, and I understand you all completely... typing this up on a phone isn't ideal...

Anyway, here goes..

Forget that previous handwritten code.

I'll tell ya what is and isn't working.

I'm able to turn the card(meaning, AMS card) on and off.

And that is completely understood

I've set up a page as page 1 in SAMS

To use address >3000.

So no code needed to show.

Because it's understood.

My program is just a test

It writes a 1 to address >3000

It also echos that to the display at the top left corner,(0).

Next I turned on the mapper

That's already understood.

I write a "2" to address >3000

this is mapped>3000 and not the unmapped.

I echo that to the screen at position 40

This is a 40 column mode screen.

This next part is my problem.

I thought that turning off the card would revert and I should be able to show that

Address>3000 to be my original"1" 

But it doesn't. It still shows a "2".

My battery is dying..I'll try to throw up code, but hopefully this clears some of the mess.. and trust me it's just as hard typing it as explaining it.

But I'm trying to alleviate too many screen shots, by explaining what is already understood.

 

 

 

 

 

Edited March 5, 2020 by GDMike

[GDMike]

Turning SAMs on/off

Setup page 1

BL routines

[GDMike]

Here I have the EQU..

And a BL routine to initialize my pages

The complete init list isn't showing because, it's exactly like the first init page, just different address..

And it's not important to this since I'm not using it at this point.. but I included a shot of it.

 

 

[GDMike]

The top line is my original data in address >3000 BEFORE mapping anything.

The second line,ignore the words, that is just left over garb. Were just concerned about the number. This is data I placed at >3000 After turning on the mapper.

The third line is after I turned off the mapper and I read >3000 and put those 2 bytes on the screen but it contains a number 2. So it either didn't revert, OR when I mapped it copied what I already had in >3000 ?? I didn't think that would happen..

Edited March 5, 2020 by GDMike

[Asmusr]

Did you set up SAMS register 3 (at >4006, controlling the >3000 region) to map another page than page 3 into that region? Otherwise, when you turn on the SAMS mapper, you are accessing the same RAM as without the mapper turned on.

 

Edit: it looks like you are correctly setting the register to >0100, mapping page 1 into the >3000 region. 

 

Edit2: Do you use SBO 0 before setting up the register and SBZ 0 after setting it up?

Edited March 5, 2020 by Asmusr

[GDMike]

Yes to everything

EXCEPT I set SAMs R3, to >4003

Can you provide me a list of how these addresses map?

I was assuming >4000 was addrr 0

>4001 for >1000

>4002 for >2000

>4003 for >3000

>4004 for>4000

I couldn't find a map

Maybe, and probably this is my issue

I'm recompiling with the change of my SAMs R3 address from what I had>4003 to your suggestion of >4006

 

Edited March 5, 2020 by GDMike

[GDMike]

I am so happy to report, that yes! I had the wrong Sam's R3 loaded..

Looky here..

Well, I don't see anywhere of how to address R3 in this thread. Unless I missed it somehow.

I'm sorry to those who couldn't understand what I was asking, or my explanation of my problem.

But Thanks to Mr. ASMUSR, he read between the lines and kinda saw my R3 problem.

I usually don't screen shoot items that are generally known already, and that confused everyone I guess. Because I don't think it's worth going over something that can be written by others 5 different ways, which in the long run just confuses things more.

I can change spark plugs in a VW, but you may do it differently.

An example, I put up a screen shot of my BL routine, and someone said, you don't need the mov R11 etc...

Whereas I do because it's a BL routine,or else the mov R11@savrtn wouldn't be there.

So I didn't Know what everyone wanted or how they wanted it, as that led me to be confused..

I put up my main code originally that showed All my BLs..then I posted those BL routines..so I don't know what else yall wanted.

I'll try harder next time, I've been trying to do a better job at explaining on each of my episodes of "why does this do that" and I seem to be getting worse at it...ml

 

 

 

Edited March 5, 2020 by GDMike

[+Lee Stewart]

2 hours ago, GDMike said:

Yes to everything

EXCEPT I set SAMs R3, to >4003

Can you provide me a list of how these addresses map?

I was assuming >4000 was addrr 0

>4001 for >1000

>4002 for >2000

>4003 for >3000

>4004 for>4000

I couldn't find a map

Maybe, and probably this is my issue

I'm recompiling with the change of my SAMs R3 address from what I had>4003 to your suggestion of >4006

 

The SAMS registers (SRxx) are addressed on even byte boundaries, i.e., incrementing by 2 for the next higher register: >4000 (SR00), >4002 (SR01), >4004 (SR02) , >4006 (SR03), etc.

 

...lee

[GDMike]

Of course when it's explained it makes sense, I was trying to figure out what that address could calculate to and I was all over the place..

I apologise for my stupidity, but it's my first time working this through...

[GDMike]

I added another verification step, this Time I did not write to the screen. I wanted to actually turn on the mapper, and just put whatever was in >3000 on the screen, and it's this. Wow..I'm relieved!

 

[+9640News]

1 hour ago, GDMike said:

 

So I didn't Know what everyone wanted or how they wanted it, as that led me to be confused..

I put up my main code originally that showed All my BLs..then I posted those BL routines..so I don't know what else yall wanted.

I'll try harder next time, I've been trying to do a better job at explaining on each of my episodes of "why does this do that" and I seem to be getting worse at it...ml

 

 

Don't feel bad.  I've been beating my head on an issue for weeks, chasing an issue for what I thought was a self-imposed coding issue when tweaking someone else's assembly code.   It wasn't until much head scratching later, I embedded some additional code elsewhere and discovered some routines I was calling upon were more restrictive than I thought.  I would not call the issue a bug in the routines I was calling, rather their scope of use was more limited than I anticipated.

 

Beery

[GDMike]

But you now have experience.. I've still gotta cross that threshold..

I can't even accidentally get things right.. oh, it's not supposed to work that way is it ..

I know people get frustrated, either with the messenger or the message, and im just thrilled that in the end things come together, someone somewhere sees my mistake, or mentions a probable miss..

And that happens to me a lot

 

Edited March 5, 2020 by GDMike

[+Lee Stewart]

37 minutes ago, GDMike said:

An example, I put up a screen shot of my BL routine, and someone said, you don't need the mov R11 etc...

Whereas I do because it's a BL routine,or else the mov R11@savrtn wouldn't be there.

 

This says to me that you misunderstand why you might need to save/restore R11. If you save/restore R11 when it is unnecessary, you waste a lot of time and memory.

 

To recap, execution of BL puts the return address in R11 and the RT directive, which is replaced by the Assembler with “B *R11”, causes a branch back to the address in R11, thus returning to the calling routine. If you change R11 before returning, your program will go off into the weeds. As long as you avoid R11 yourself, the only reason that R11 would get changed is if you called another routine with BL. Here is an example of two subroutines. the first calls the second, but the second does not call another subroutine:

* We must save/restore R11 in this subroutine because we trash it with  BL @SUBR2
SUBR1  MOV  R11,@SAVRTN    save return address to avoid trashing it with another call
*       ...
       BL   @SUBR2         this will trash R11 and is the reason to save it above
*       ...
       MOV  @SAVRTN,R11    restore return address trashed by above call
       RT                  Assembler replaces with  B *R11

* There is no change to R11 in this subroutine, so no need to save/restore it
SUBR2  LI   R0,>0100
*       ...
       B    *R11           alternative to RT (see above)

 

If we had, indeed, called a third subroutine (SUBR3, say) from SUBR2, we would have needed a second address (SAVRT2, say) for saving SUBR2’s return address to avoid trashing SUBR1’s return address. If you get to this point, it would be better to implement @TheBF’s suggestion of a small return stack.

 

By the way, here is an alternative to SUBR1 that saves a MOV instruction:

* We must save the return address, R11, in this subroutine because we trash it with  BL @SUBR2
SUBR1  MOV  R11,R7         save return address to unused register to avoid trashing it with another call
*       ...
       BL   @SUBR2         this will trash R11 and is the reason to save it above
*       ...
       B    *R7            return to saved address

 

...lee

[GDMike]

True. Understood. I'm good on BL..I may have just been confused about something else and mixed the two into the same conversation.. bad thing to do..

Thank you Lee. I'm having as much fun with my car restoration, it's now become a fix it rather than restore..

I'm running between these two projects lately.

This one is the easiest vs the car.

[+9640News]

As mentioned above, there are lots of ways to accomplish the same task.  Sometimes, one is working within memory constraints and needs to memory every byte possible.  Other times, it is speed issues and someone may use successive MOV(b) instructions rather than a loop counter.  And then other times, neither is critical as you have lots of memory and things aren't speed critical.

 

Beery

 

[GDMike]

Yup..been to each of those...

I prefer lots of ram.. but with good coding techniques it is possible.

I'm doing good here in my code. But as stated, I gotta go check my memory too, hoping I still have some left..lol

 

 

[HOME AUTOMATION]

I see where you can save 24 Bytes!

 

8 hours ago, GDMike said:

and someone said,

 

"Someone" at your service...

 

Didn't mean to turn you away from the progress you're making!

 

However, the issue of how/why and when to save/restore whilst switching to different parts of your program, seemed germane, perhaps even prerequisite to your issue of switching pages as well.

...Perhaps not.

 

When considering a problem with unfamiliar code, one tries to recognize the "purposes" intended. Things that look particularly out of place tend to fixate attention during this process.

We've often all found ourselves falling into the same holes, again and again, since there are so many idiosyncrasies to coding.

 

You're SAMON(mmm, Salmon)/SAMOFF subs, remind me very much of my own ON/OFF subs, used to send 1s 'n 0s, to my shift registers. When developing this process, I wanted to control the speed, in order to check accuracy, so I BL'd out of ON/OFF to my DLY1... but doing this overwrote the address ON/OFF needed in order to return to the subroutine from which, itself was called, replacing R11 instead with the address DLY1 needed in order to return to ON/OFF. Thus, when ON/OFF tries to return to the subroutine from which, itself was called, by using RT, execution instead goes again to the line following the BL to DLY1.

 

This is when I relearned... to save R11 before I BL from one sub to another. Also that different save locations are needed for each deeper  level of sub called.

 

So here is an example of a more proper usage of "RT address saves".

...DISCLAIMER: Almost all else herein; is wrong!

 

* CALL DIAL R0=DIALING STRING
*
       AORG >7200
       DEF  DIAL
SAVE   DATA 0
DTAB   BYTE 0,1,2,3,4,5,6,7,8,9
       BYTE >A,>B,>C,>D,>E,>F,>FF
DS     BSS  768
DIAL   MOV  R11,@SAVE
       CLR  R12
       LI   R10,2
PRESS  LI   R1,DTAB
       LI   R2,JTAB
       CLR  R3
COMP   INCT R3
       CB   *R0,*R1+
       JNE  COMP
       DECT R3
       A    R3,R2
       MOV  *R2,R2
       BL   *R2
       INC  R0
       JMP  PRESS
JTAB   DATA D0,D1,D2,D3,D4,D5,D6
       DATA D7,D8,D9,DA,DB,DC,DD
       DATA DE,DF,FF
D0     LI   R6,4
       LI   R5,2
       JMP  SS
D1     LI   R6,1
       LI   R5,1
       JMP  SS
D2     LI   R6,1
       LI   R5,2
       JMP  SS
D3     LI   R6,1
       LI   R5,3
       JMP  SS
D4     LI   R6,2
       LI   R5,1
       JMP  SS
D5     LI   R6,2
       LI   R5,2
       JMP  SS
D6     LI   R6,2
       LI   R5,3
       JMP  SS
D7     LI   R6,3
       LI   R5,1
       JMP  SS
D8     LI   R6,3
       LI   R5,2
       JMP  SS
D9     LI   R6,3
       LI   R5,3
       JMP  SS
DA     LI   R6,1
       LI   R5,4
       JMP  SS
DB     LI   R6,2
       LI   R5,4
       JMP  SS
DC     LI   R6,3
       LI   R5,4
       JMP  SS
DD     LI   R6,4
       LI   R5,4
       JMP  SS
DE     LI   R6,4
       LI   R5,1
       JMP  SS
DF     LI   R6,4
       LI   R5,3
       JMP  SS
FF     MOV  @SAVE,R11
       RT
*                      SET
 
SS     MOV R11,R13
SE     LI  R15,4
ROW    C   R15,R6
       JNE LENR
       BL  @OFF
       DEC R15
       JMP ROW
LENR   CI  R15,0
       JEQ SHIFTC
       BL  @ON
       DEC R15
       JMP ROW
SHIFTC LI  R15,4
COL    C   R15,R5
       JNE LENC
       BL  @OFF
       DEC R15
       JMP COL
LENC   CI  R15,0
       JEQ STEP2
       BL  @ON
       DEC R15
       JMP COL
STEP2  NOP
 
*                  RESET CONTROLER
 
       LI   R4,2
REPEAT LI   R7,8
BON    BL   @OFF
       DEC  R7
       JNE  BON
       LI   R7,8
BOFF   BL   @ON
       DEC  R7
       JNE  BOFF
       DEC  R4
       JNE  REPEAT
       BL   @LATCH
       LI   R5,9
       LI   R6,9
       BL   @DLY1
       DEC  R10
       JNE  SE
       LI   R10,2
       MOV  R13,R11
       RT
*                   DIGIT DONE
OFF    SBZ  16
       MOV  R11,R14
       BL   @DLY1
       SBO  24
       BL   @DLY1
       SBZ  24
       BL   @DLY1
       MOV  R14,R11
       RT
ON     SBO  16
       MOV  R11,R14
       BL   @DLY1
       SBO  24
       BL   @DLY1
       SBZ  24
       BL   @DLY1
       MOV  R14,R11
       RT
LATCH  SBO  25
       MOV  R11,R14
       BL   @DLY1
       SBZ  25
       BL   @DLY1
       MOV  R14,R11
       RT
DLY1   LI   R8,1
DLYR   LI   R9,>44
DLY    DEC  R9
       JNE  DLY
       DEC  R8
       JNE  DLYR
       RT
RUN    CLR  R12
       LI   R10,2
       LI   R0,DS
       BL   @DIAL
       RT
       END

(The RUN entry point was only used for testing)

 

Notice that there is no save of R11 before the first level BL, or restore before the final RT.

 

DLY1 being at the deepest level, requires no save/restore.

 

If I were to remove the BLs to DLY1, from the ON/OFF subs, I could also remove the...
MOV  R11,R14
MOV  R14,R11
...from both of those subs as well!

 

BTW...
This test program sends 2 of 8 codes to a 74595 shift reg. driving a 5089 DTMF encoder.

 

   P.S. The next version is where I started using page switching, for the first time!

Edited March 5, 2020 by HOME AUTOMATION
couldn't get <code> 'n [spoiler] to cooperate(???)... I for Invisible(Italics)

[RXB]

I think assembly for the SAMS is fast but sucks to change pages. 

My entire code of Assembly for SAMS in RXB:

[1802]               ***********************************************************
[1803]               * CPU PROGRAM FOR >8300 SCATCH PAD SUBROUTINE AMSCRU      *
[1804]               ***********************************************************
[1805]               *                 *        AORG >8300
[1806] C96B 83,02    AMSCRU DATA >8302 * AMSCRU DATA >8302     * First address.
[1807] C96D C0,4C           DATA >C04C *        MOV  R12,R1    * Save R12 
[1808] C96F 02,0C           DATA >020C *        LI   R12,>1E00 * Load CRU bits
[1809] C971 1E,00           DATA >1E00 *
[1810] C973 1D,00           DATA >1D00 *        SBO  0         * Set bits ones
[1811] C975 C3,01           DATA >C301 *        MOV  R1,R12    * Restore R12
[1812] C977 04,E0           DATA >04E0 *        CLR  @>837C    * Clear for GPL
[1813] C979 83,7C           DATA >837C *
[1814] C97B 04,5B           DATA >045B *        RT             * Return to GPL.
[1815]                                 *        END
[1816]               ***********************************************************
[1817]               * CPU PROGRAM FOR >8300 SCRATCH PAD CPU ISR HOOK ON       *
[1818]               ***********************************************************
[1819]               *                  *        AORG >8300
[1820] C97D 83,02    GISRON DATA >8302  *        DATA >8302
[1821] C97F C8,20           DATA >C820  *        MOV  @>834A,@>83C4
[1822] C981 83,4A           DATA >834A  *
[1823] C983 83,C4           DATA >83C4  *
[1824] C985 04,E0           DATA >04E0  * EXIT   CLR  @>837C
[1825] C987 83,7C           DATA >837C  *
[1826] C989 04,5B           DATA >045B  *        RT
[1827]               *                  *        END
[1828]               ***********************************************************
[1829]               * CPU PROGRAM FOR >8300 SCRATCH PAD CPU ISR HOOK OFF      *
[1830]               ***********************************************************
[1831] C98B 83,02    GISROF DATA >8302 *        DATA >8302
[1832] C98D C8,20           DATA >C820 * ISROFF MOV  @>83C4,@>83C4
[1833] C98F 83,C4           DATA >83C4 *
[1834] C991 83,C4           DATA >83C4 *
[1835] C993 13,05           DATA >1305 *        JEQ  NHOOK
[1836] C995 C8,20           DATA >C820 *        MOV  @>83C4,@>834A
[1837] C997 83,C4           DATA >83C4 *
[1838] C999 83,4A           DATA >834A *
[1839] C99B 04,E0           DATA >04E0 * NHOOK  CLR  @>83C4
[1840] C99D 83,C4           DATA >83C4 *
[1841] C99F 04,E0           DATA >04E0 *        CLR  @>837C
[1842] C9A1 83,7C           DATA >837C *
[1843] C9A3 04,5B           DATA >045B *        RT
[1844]               *                 *        END
[1845]               ***********************************************************

99/4 GPL-ASSEMBLER (Pass 3) correct                                   PAGE 0033 
EQUATES ALCS-359
[1846]               * CPU PROGRAM FOR >8300 SCATCH PAD SUBROUTINE EXECUTE     *
[1847]               ***********************************************************
[1848]               *                          AORG >8300                 *
[1849] C9A5 83,02    CPUPGM DATA >8302 * CPUPGM DATA >8302  First address. *
[1850] C9A7 04,20           DATA >0420 *        BLWP @>834A Switch contex  *
[1851] C9A9 83,4A           DATA >834A *                    FAC not used   *
[1852] C9AB 04,E0           DATA >04E0 *        CLR  @>837C Clear for GPL  *
[1853] C9AD 83,7C           DATA >837C *                                   *
[1854] C9AF 04,5B           DATA >045B *        RT          Return to GPL. *
[1855]                                 *        END                        *
[1856]               *******************************************************

 

This code handles CPU programs/CRU/ISRhook/DSR SAMS and is total of 68 bytes.

Also only runs from Scratch pad RAM only.

It swaps out the same area in scratch pad RAM thus never has any affect on RAM in 32K, this means swapping pages instantly faster.

[GDMike]

I've gotten my pages working and since I never need to return, and I might have to think about this but I'm going to put it out here, I don't have to turn off my SAMs card, so far, because all my pages are running in and out of >C000 as I only need 4K until the user changes the 4Th screen page, then I have to load Sam's page2 for another 4K to be divided up amongst 4 more screen pages. And on and on.

So as long as the user is moving pages, there's no need for me to turn off SAMs.

But once that changes I will have to.. I think.. probably.. Haven't gotten that far yet ...but yeah..

But even though it's a bit of a pain, what a couple 3 steps, it's powerful.

 

Edited March 5, 2020 by GDMike

[GDMike]

4 hours ago, HOME AUTOMATION said:

I see where you can save 24 Bytes!

 

 

"Someone" at your service...

 

Didn't mean to turn you away from the progress you're making!

 

However, the issue of how/why and when to save/restore whilst switching to different parts of your program, seemed germane, perhaps even prerequisite to your issue of switching pages as well.

...Perhaps not.

 

When considering a problem with unfamiliar code, one tries to recognize the "purposes" intended. Things that look particularly out of place tend to fixate attention during this process.

We've often all found ourselves falling into the same holes, again and again, since there are so many idiosyncrasies to coding.

 

You're SAMON(mmm, Salmon)/SAMOFF subs, remind me very much of my own ON/OFF subs, used to send 1s 'n 0s, to my shift registers. When developing this process, I wanted to control the speed, in order to check accuracy, so I BL'd out of ON/OFF to my DLY1... but doing this overwrote the address ON/OFF needed in order to return to the subroutine from which, itself was called, replacing R11 instead with the address DLY1 needed in order to return to ON/OFF. Thus, when ON/OFF tries to return to the subroutine from which, itself was called, by using RT, execution instead goes again to the line following the BL to DLY1.

 

This is when I relearned... to save R11 before I BL from one sub to another. Also that different save locations are needed for each deeper  level of sub called.

 

So here is an example of a more proper usage of "RT address saves".

...DISCLAIMER: Almost all else herein; is wrong!

 

* CALL DIAL R0=DIALING STRING
*
       AORG >7200
       DEF  DIAL
SAVE   DATA 0
DTAB   BYTE 0,1,2,3,4,5,6,7,8,9
       BYTE >A,>B,>C,>D,>E,>F,>FF
DS     BSS  768
DIAL   MOV  R11,@SAVE
       CLR  R12
       LI   R10,2
PRESS  LI   R1,DTAB
       LI   R2,JTAB
       CLR  R3
COMP   INCT R3
       CB   *R0,*R1+
       JNE  COMP
       DECT R3
       A    R3,R2
       MOV  *R2,R2
       BL   *R2
       INC  R0
       JMP  PRESS
JTAB   DATA D0,D1,D2,D3,D4,D5,D6
       DATA D7,D8,D9,DA,DB,DC,DD
       DATA DE,DF,FF
D0     LI   R6,4
       LI   R5,2
       JMP  SS
D1     LI   R6,1
       LI   R5,1
       JMP  SS
D2     LI   R6,1
       LI   R5,2
       JMP  SS
D3     LI   R6,1
       LI   R5,3
       JMP  SS
D4     LI   R6,2
       LI   R5,1
       JMP  SS
D5     LI   R6,2
       LI   R5,2
       JMP  SS
D6     LI   R6,2
       LI   R5,3
       JMP  SS
D7     LI   R6,3
       LI   R5,1
       JMP  SS
D8     LI   R6,3
       LI   R5,2
       JMP  SS
D9     LI   R6,3
       LI   R5,3
       JMP  SS
DA     LI   R6,1
       LI   R5,4
       JMP  SS
DB     LI   R6,2
       LI   R5,4
       JMP  SS
DC     LI   R6,3
       LI   R5,4
       JMP  SS
DD     LI   R6,4
       LI   R5,4
       JMP  SS
DE     LI   R6,4
       LI   R5,1
       JMP  SS
DF     LI   R6,4
       LI   R5,3
       JMP  SS
FF     MOV  @SAVE,R11
       RT
*                      SET
 
SS     MOV R11,R13
SE     LI  R15,4
ROW    C   R15,R6
       JNE LENR
       BL  @OFF
       DEC R15
       JMP ROW
LENR   CI  R15,0
       JEQ SHIFTC
       BL  @ON
       DEC R15
       JMP ROW
SHIFTC LI  R15,4
COL    C   R15,R5
       JNE LENC
       BL  @OFF
       DEC R15
       JMP COL
LENC   CI  R15,0
       JEQ STEP2
       BL  @ON
       DEC R15
       JMP COL
STEP2  NOP
 
*                  RESET CONTROLER
 
       LI   R4,2
REPEAT LI   R7,8
BON    BL   @OFF
       DEC  R7
       JNE  BON
       LI   R7,8
BOFF   BL   @ON
       DEC  R7
       JNE  BOFF
       DEC  R4
       JNE  REPEAT
       BL   @LATCH
       LI   R5,9
       LI   R6,9
       BL   @DLY1
       DEC  R10
       JNE  SE
       LI   R10,2
       MOV  R13,R11
       RT
*                   DIGIT DONE
OFF    SBZ  16
       MOV  R11,R14
       BL   @DLY1
       SBO  24
       BL   @DLY1
       SBZ  24
       BL   @DLY1
       MOV  R14,R11
       RT
ON     SBO  16
       MOV  R11,R14
       BL   @DLY1
       SBO  24
       BL   @DLY1
       SBZ  24
       BL   @DLY1
       MOV  R14,R11
       RT
LATCH  SBO  25
       MOV  R11,R14
       BL   @DLY1
       SBZ  25
       BL   @DLY1
       MOV  R14,R11
       RT
DLY1   LI   R8,1
DLYR   LI   R9,>44
DLY    DEC  R9
       JNE  DLY
       DEC  R8
       JNE  DLYR
       RT
RUN    CLR  R12
       LI   R10,2
       LI   R0,DS
       BL   @DIAL
       RT
       END

(The RUN entry point was only used for testing)

 

Notice that there is no save of R11 before the first level BL, or restore before the final RT.

 

DLY1 being at the deepest level, requires no save/restore.

 

If I were to remove the BLs to DLY1, from the ON/OFF subs, I could also remove the...
MOV  R11,R14
MOV  R14,R11
...from both of those subs as well!

 

BTW...
This test program sends 2 of 8 codes to a 74595 shift reg. driving a 5089 DTMF encoder.

 

   P.S. The next version is where I started using page switching, for the first time!

My code is a little fishy....hmmm

[HOME AUTOMATION]

Mine goes a little overboard at times, so... they should get along well together!

 

I could probably eliminate the overly flexible jump table, and increment R3 by 12 using D0's addr. as a base instead, just for starters. Seems like every time I take a look at my old code, I see that it could be leaner.

[+TheBF]

I have SAMS card usage working well under Camel99 Forth now. It can access selectable 64K segments as contiguous memory for data and I have a simple way to compile code to discrete 4K pages.

 

For my own amusement, I am working on how I could make a multi-user Forth system for the TI. This is in the tradition of an old system from the 70s called PolyForth.

 

It will consist of a TI-99 console Forth running with along with an RS232 terminal running as the second user. 

The plan is for the kernel code to run in Super Cart with some extensions in memory >A000..AFFF.

 

The memory from >B000.. >FFFF will be swapped for each user's local Forth system.

 

My question therefore is what is the fastest code that could swap all RAM pages simultaneously?  ( >B000,>C000,>D000,>E000,>F000)

 

Here is my first attempt in RPN Forth Assembler. (instructions on the right).  I take a SAMS page# from the Forth R4 (tos cache) and increment that value to get pages for each 4K page of RAM.

I have this working swapping memory in a task but I am curious if there is any way to map multiple sequential pages faster?

 

Note:   ** is indirect addressing.   *+ is indirect/auto-increment addressing.

CODE HIMAPPER ( SAMSpage# --) \ Maps B000..FFFF into SAMS
        TOS SWPB,
        R12 1E00  LI,
        0 SBO,          \ card on
        R1  4016  LI,   \ HI ram SAMS register for B000

        R4  R1 *+ MOV,  \ MAP B000, BUMP R1 to next register
        R4  0100  AI,   \ next page
        R4  R1 *+ MOV,  \ MAP C000, BUMP R1 to next register
        R4  0100  AI,   \ next page
        R4  R1 *+ MOV,  \ MAP RD000, BUMP R1 to next register
        R4  0100  AI,   \ next page
        R4  R1 *+ MOV,  \ MAP E000, BUMP R1 to next register
        R4  0100  AI,   \ next page
        R4  R1 ** MOV,  \ MAP F000, BUMP R1 to next register

        0 SBZ,          \ card off
        R4 POP,         \ refill Forth top of stack register
        NEXT,
        ENDCODE

 

 

[GDMike]

Are you saving a Meg or almost near a Meg of data out to a disk? 

If so, what output format are you using.

Df128?

 

[+TheBF]

Not saving out to disk. Everything stays in the SAMS card.

 

But I have multiple copies of UPPER RAM  from B000..FFFF for different Forth tasks running on the machine.

 

 

[+Lee Stewart]

8 hours ago, TheBF said:

I have this working swapping memory in a task but I am curious if there is any way to map multiple sequential pages faster?

 

The only thing faster would be INC, , but that, of course, cannot be done to the left byte of a word without time-consuming manipulation. Presuming the registers are in Scratchpad RAM, it looks like you hit upon the most efficient code right out of the gate!

 

...lee