SAMS usage in Assembly

[GDMike]

21 minutes ago, Lee Stewart said:

Here is the same code, but easier to read, i.e., all commented-out lines are removed:

  Hide contents

VSBW   EQU  >210C

***** turn off SAMS Mapping
SAMOFF LI   R12,>1E00
       SBZ  1
       RT

***** turn on SAMS Mapping (and set for >3000->3FFF???}

SAMON  LI   R12,>1E00
       SBO  1
       RT


**** set to BANK 16
*++ Trashes R1, R3.

FIRSTB LI   R12,>1E00
       SBO  0
       LI   R3,>4006
       LI   R1,>1000     bank 16
       MOVB R1,*R3
       SBZ  0
       RT

***** MAP A BANK
*++ Bank# must be in R1 before calling this routine.
*++ Trashes R3.
       
MAPPG  LI   R12,>1E00
       SBO  0
       LI   R3,>4006
       MOV  R1,*R3
       SBZ  0
       RT

***************************
PROGRAM

TEST   BL   @SAMON
       BL   @FIRSTB     * Map first bank (bank 16)
       CLR  R5
       CLR  R4

       LI   R2,>4041    * initial value to copy into 10 banks (16-25)
       LI   R5,>1000    * set opening SAMS page
INC1   MOV  R5,R1       *<--+ set SAMS page for MAPPG
       LI   R4,>3000    *   | starting RAM for copy to this bank
       BL   @MAPPG      *   | map next bank
*+++ Do this for each bank so we can actually see a change on screen
       AI   R2,>0101    *   | increment copy value to next pair of letters
*+++                        |
*+++ The following code fills each successive bank with a new pair of letters
INC2   MOV  R2,*R4+     *<-+| "AB"(bank1),"BC"(bank2),... to next RAM address
       CI   R4,>33C0    *  || are we out of screen range?
       JLT  INC2        *>-+|
*+++                    *   |
       AI   R5,>0100    *   | increment to next bank
       CI   R5,>1A00    *   | only want to fill banks >10->19 (16-25)
       JLT  INC1        *>--+ next bank if less than bank 26
       
       LI   R5,>1000    * opening SAMS page
INC3   MOV  R5,R1       *<--+ set SAMS page for MAPPG
       LI   R4,>3000    *   | starting RAM for reading from this bank
       BL   @MAPPG          |
       LI   R0,0        *   | set initial screen position
       LI   R4,>3000    *   | starting RAM for reading from this bank
*+++                        |
INC4   MOVB *R4+,R1     *<-+| MOVB now..we are working with bytes, not words
       BLWP @VSBW          ||
       INC  R0          *  || increment screen position
       CI   R0,960      *  || done?
       JLT  INC4        *>-+|
*+++                        |
       AI   R5,>0100    *   | increment to next bank
       CI   R5,>1A00    *   | only want to read banks >10->19 (16-25)
       JLT  INC3        *>--+ next bank if less than bank 26

       BL   @SAMOFF      * not necessary unless want powerup conditions
       B    @STOP

**********************
STOP   LIMI 2
       LIMI 0
       JMP  STOP

       END  PROGRAM

 

 

...lee

Thank you so much lee, yes, I thought,as I had some luck with adding

1 at that MSB @>4004. I think I've got a handle on it now. Thanks!!

[GDMike]

*++ Bank# must be in R1 before calling this routine.
*++ Trashes R3.
       
MAPPG  LI   R12,>1E00
       SBO  0
       LI   R3,>4006
       MOV  R1,*R3
       SBZ  0
       RT

I didn't know that about  Sam's register. Well that throws a wrench into everything!! No wonder I had so much trouble and why it wouldn't work. Can't read a SAMs register, manipulate it and put it back.

That's my missing link...of knowledge

 

Thank you!!!

Edited September 10, 2020 by GDMike

[HOME AUTOMATION]

1 hour ago, Lee Stewart said:

1 hour ago, GDMike said:

Is this valid?

ADPG   MOV  R11,@SAVRTN  *this does nothin' useful
       LI   R12,>1E00
       SBO  0
       LI   R3,>4006
       MOV  *R3,R1
       AI   R1,>0100
       MOV  R1,*R3
       SBO  1
       RT

 

No. 

Sorry but, this DOES take >3000-3FFF address range to the next higher numbered SAMS page!

 

1 hour ago, Lee Stewart said:

       MOV  *R3,R1

I do not think you can read a SAMS register, which is what this is trying to do. You must tell SAMS what to load. You can only run

Au contraire mon frère. Yes, you can read SAMS' addressing registers, when CRU >1E00 is set to 1(SBO 0). Even when in TRANSPARENT MODE, they show either their default values, or whatever you have changed them to.

 

What you can't read(ever) are the CRU bits(always return a 1, even when set to 0).

[+Lee Stewart]

47 minutes ago, GDMike said:

And the code below.

LI      R3,>3000

Mov *R3 R1

LI       R2,>0C00

A        R2,R1

MOV  R1,*R3

And will this give me bank 13 of (>3000->3FFF)?

 

Almost certainly not. You cannot predict what is sitting at >3000. Also, you are not banking >3000 – >3FFF, You are banking SAMS memory pages to appear at CPU RAM space >3000 – >3FFF. You cannot do anything to those addresses. You can only read/write from/to them. If you want SAMS bank 13 to appear at >3000, assuming SAMS mapping is on (SBO 1) (and, while you are using mapping in your program, there is no good reason to turn it off except at initial setup time), you

• Enable writing the mapper registers ( SBO  0 )
• Write >0D00  to one of your workspace (WS) registers. R1 is fine ( LI  R1,>0D00 )
• Put the relevant mapper register in another WS register. R3 is fine ( LI  R3,>4006 )
• Write the SAMS page # to the mapper register ( MOV  R1,*R3 )
• Disable writing to the mapper registers ( SBZ  0 )

You now can read/write from/to any address in CPU RAM >3000 – >3FFF to access SAMS memory >D000 – >DFFF (page 13). As long as you leave SAMS page 13 in that RAM window, that is all the CPU will see in that RAM space.

 

...lee

[+Lee Stewart]

8 minutes ago, HOME AUTOMATION said:

Sorry but, this DOES take >3000-3FFF address range to the next higher numbered SAMS page!

15 minutes ago, HOME AUTOMATION said:

Au contraire mon frère. Yes, you can read SAMS' addressing registers, when CRU >1E00 is set to 1(SBO 0). Even when in TRANSPARENT MODE, they show either their default values, or whatever you have changed them to.

 

Good to know. I was not aware of that. I will correct that post. The code still will not work the way @GDMike thinks it will,

with mapping turned off at the end. Writing the registers should be turned off ( SBZ  0 ), with mapping left on ( SBO  1 )

 

...lee

[GDMike]

Gotcha! Thanks Lee and automation, I'll be adjusting things tommorow.

Whohoo

[+FALCOR4]

On 9/10/2020 at 6:10 PM, Lee Stewart said:

 

On 9/10/2020 at 5:53 PM, HOME AUTOMATION said:

Au contraire mon frère. Yes, you can read SAMS' addressing registers, when CRU >1E00 is set to 1(SBO 0). Even when in TRANSPARENT MODE, they show either their default values, or whatever you have changed them to.

 

Please do not depend on being able to read the SAMS registers in your software!  Yes, you can read back the registers but only in 1M segments, the SAMS greater than 1M boards will not read back anything beyond 1M segments; i.e. if you have a 4M or 8M or 16M SAMS it will not give you any granularity beyond 1M.  Just a caution to those who are writing software.  And, currently there is only a 4M SAMS available but, the possibility for a 16M does exist  and, in my opinion, should be accounted for in software development.  Again, IMHO.

[GDMike]

5 minutes ago, FALCOR4 said:

Please do not depend on being able to read the SAMS registers in your software!  Yes, you can read back the registers but only in 1M segments, the SAMS greater than 1M boards will not not read back anything beyond 1M segments; i.e. if you have a 4M or 8M or 16M SAMS it will not give your any granularity beyond 1M.  Just a caution to those who are writing software.  And, currently there is only a 4M SAMS available but, the possibility for a 16M does exist  and, in my opinion, should be accounted for in software development.  Again, IMHO.

Very good, I've made note of that and adjusted. Testing now

[GDMike]

Yes, thanks to everyone for learning my head something new!! My test works!

I had filled a 4K area at >3000 with "AB"

For banks 16-17. Then

Turned off mapper mode with the subroutine, "SAMOFF", I then called my subroutine, "SAMON", and subroutine, "SBH" to put bank# to a 1. And ran the test.

Then I got a screen full of "AB" when I read >3000 through 960 bytes.

I reran the test, Except I added an extra "1" in R8, a counter that gets added to >10 in ADPG and bumps the loop on how many banks I need skip before reading 960 bytes again. And here's my 2 test results.

One min. I'll upload

 

This is exactly how it should look for my test.

I'll be using a variable anyway to track "BANK" so in the future I'll just be using BANK in  the "ADPG" routine to look at and that way I'm always landing on the right bank#.

Thanks to @ASMUSR, Lee, theBF and @automation! Job well explained and worked out. 

It's always good to get an explanation sometimes. 

Now, where's my car keys...

 

Edited September 11, 2020 by GDMike

[+Lee Stewart]

20 minutes ago, FALCOR4 said:

Please do not depend on being able to read the SAMS registers in your software!  Yes, you can read back the registers but only in 1M segments, the SAMS greater than 1M boards will not not read back anything beyond 1M segments; i.e. if you have a 4M or 8M or 16M SAMS it will not give your any granularity beyond 1M.  Just a caution to those who are writing software.  And, currently there is only a 4M SAMS available but, the possibility for a 16M does exist  and, in my opinion, should be accounted for in software development.  Again, IMHO.

 

Re accounting for higher SAMS memory, I initially changed fbForth 2.0 to check for 16 MiB SAMS because it seemed unlikely to go higher anytime soon, even though it could, I suppose, go as high as 256 MiB. I did finally settle on 32 MiB, mainly due to Classic99’s implementation, which can be read/written from/to in page >1FFF. The current build (13) under construction is already reporting whether SAMS is found and if so how much (see post #1568 of the main fbForth development thread for a screen shot). The startup code starts at SAMS page >1FFF, shifting right one bit at a time (halving) until writable SAMS is found or page >001F (128 KiB high page) fails, at which point the SAMS flag stores the highest page # or 0.

 

...lee

[HOME AUTOMATION]

13 hours ago, FALCOR4 said:

Yes, you can read back the registers but only in 1M segments, the SAMS greater than 1M boards will not not read back anything beyond 1M segments; i.e. if you have a 4M or 8M or 16M SAMS it will not give you any granularity beyond 1M.  Just a caution to those who are writing software.

So, in other words, each register will continue to show precisely which page it's block is set to.

Are you saying the LSByte will not be displayed at all? If so what would be the delineator between segments?

 

[GDMike]

Nagging judith only has one thing to say!

 

"See, I told you harold, you never listen to me, I told you harold!! Next time you better listen Harold! You been reading that register since the day we met!!!"

 

 

[Asmusr]

22 hours ago, TheBF said:

So that last SBZ 0 turns off the SAMS card. It MUST be done because other cards occupy that same space at >4000.  (DISK, RS232 etc.)

In my project I choose to leave it on because I'm not going to access any DSRs.

 

But what happens if you leave it on and then enable the disk DSR, for instance. Will a read to >4000 read the SAMS register or the disk ROM? 

 

Edited September 11, 2020 by Asmusr
typos

[+TheBF]

31 minutes ago, Asmusr said:

In my project I choose to leave it on because I'm not going to access any DSRs.

 

But what happens if you leave it on and then enable the disk DSR, for instance. Will a read to >4000 read the SAMS register or the disk ROM? 

 

I have never tried. Sounds like an experiment will follow.

 

[+TheBF]

52 minutes ago, TheBF said:

I have never tried. Sounds like an experiment will follow.

 

Doesn't matter in Camel99 Forth.

R12  gets changed, the disk card is enabled and the DSR proceeds.

While the DSR is running of course you can't control the SAMS card until it completes whatever it is doing.

So if you need disk buffers in SAMS memory better page them in first.

 

[+Lee Stewart]

42 minutes ago, TheBF said:

Doesn't matter in Camel99 Forth.

R12  gets changed, the disk card is enabled and the DSR proceeds.

While the DSR is running of course you can't control the SAMS card until it completes whatever it is doing.

So if you need disk buffers in SAMS memory better page them in first.

 

I think I should be safe in fbForth, with >MAP issuing ( SBZ  0 ) before it returns.

 

...lee

[+FALCOR4]

5 hours ago, HOME AUTOMATION said:

So, in other words, each register will continue to show precisely which page it's block is set to.

Are you saying the LSByte will not be displayed at all? If so what would be the delineator between segments?

 

Correct.  The SAMS circuitry is simplistic, and I don't mean to say that is a bad thing.  It's not, it just means that not all possible functionality is implemented which would require more ICs and board space.  It will put the same page number (repeats) for a 1M segment in both the LSByte and the MSByte from the LS612 when you do a register read (>00 to >FF).  The LSByte that is latched (which gives you banks beyond the first 1M) is not connected in such a way that it can be read back.  So, you'll only be able to see page numbers for any one particular 1M bank, you won't be able to read back what bank you're in which would be in the LSByte if it were implemented.  If needed, the software will just have to keep track of banks.

 

I just put together another 4M board and am doing a burn in right now that should run through the night.  When it's done, I'll play with it to verify that what I'm telling you is true or not.  I'll report back with what I find.

[GDMike]

Just monitoring, and taking notes..hehe...

Guess I'll have to order a whole new board soon..

 

[GDMike]

I powered off the peb and console this morning to take another run of the code I showed pictures of running yesterday, while it ran as expected yesterday, it would not repeat the process today since powering everything down.

 

So I've gone through the code over and over today with only the ability to write to bank 16 over and over, no matter what number I placed in MSB of the word at >4006.

I wasn't surprised that it ran yesterday as I plugged in the code while we discussed what was going on. 

But I never did shut down the peb during my tests, until Today and yup .

That's what's going on.

 

Btw, im not trying to read the Sam's registers as we discussed. But I am manually plugging in >10 and writing to that page, and that is fine, then writing completely different data to >11 and then going back and reading >10 and I get the data from my last write, page 17.

As if page 16,17 are now duplicated with page 17s data.

But I'm pretty sure that for some reason I'm not getting a higher bank of >3000.

I've tried so many combinations in my three subs that for source code I'd just refer back to what we had yesterday.

Btw, my code, test from yesterday, is running isolated as my test, so I'm sure I don't have any contaminated code interfereing, but I've been trying what we talked about yesterday, that worked yesterday and I'm not getting higher banks of >3000->3FFF. Darn lol

I'll try again for sure, but I'd just thought I'd let you know in case there's something amiss.

 

 

 

 

 

 

 

 

Edited September 12, 2020 by GDMike

[+Lee Stewart]

2 minutes ago, GDMike said:

But I'm pretty sure that for some reason I'm not getting a higher bank of >3000.

 

????  Not sure what this means. Are you trying to page in SAMS bank >3000? Or, are you just saying you cannot page higher SAMS banks than >11 to the >3000 RAM window?

 

...lee

[GDMike]

Yeah, can't page higher Sam's banks than >11

Edited September 12, 2020 by GDMike

[GDMike]

I've screwed up all my test source for the day, I'd have to rebuild it from scratch, because I tried so, haha, many varied changes, that it's spaghetti code rt now.

When I tried just the "SAMON" code just on it's own, my card went power off. 

So that led me to start trying different facets of code..

 

Edited September 12, 2020 by GDMike

[GDMike]

I'm not even sure if I don't have a card issue? I talked with Gary opa who is having issues with his Tripple tech card, but only after he moved his 1mb Sam's card to another port slot.

So that's another idea, maybe I should try another slot?.

I only have the original ti controller, tipi, and sam's.

I have a couple of consoles, maybe try another also. 

Edited September 12, 2020 by GDMike

[GDMike]

Tommorow I'll move the SAMs card port, I'll change consoles, and I'll rebuild test code.

Then I'll update my findings.

 

[+Lee Stewart]

I just had an epiphany! What @FALCOR4 said earlier about reading SAMS registers and a discussion among [member-'RXB'], [member-'tursi'] and me over in the Classic99 Updates thread led me to the conclusion that my method in fbForth 2.0 of determining the amount of SAMS memory available is flawed! See post #1870 for my thinking.

 

What occurred to me is that checking any, putative “highest” bank of an actual SAMS card will succeed, even for the lowest SAMS (128 KiB, highest page = >001F) expected, leading my code to conclude there is 32 MiB of SAMS available. FYI, my method writes a test value to the mapping window (>E000) and starts paging in “highest” pages of SAMS beginning with 32 MiB’s highest page, >1FFF, to see whether the test value is still there. If it fails, the code checks for SAMS at half that value until it succeeds or fails at 128 KiB, My point is that mapping >1FFF will always map a writable SAMS page for any working SAMS, 128 KiB or higher. If the card only has 128 KiB, mapping page >1FFF will actually map page >001F because the unattached bits are ignored. I will need to get more clever so that I am mapping only pages that I expect or use a clever pattern that will lead me to the correct conclusion in the shortest amount of code—aye, there’s the rub!  ( sorry, Will )

 

...lee