Jump to content
Sign in to follow this  
Vorticon

SAMS card reference documentation

Recommended Posts

Hi. Aside from Thierry's documentation of the SAMS card, is there another reference available, particularly aimed at the software side of things and for the 1meg card? 

Share this post


Link to post
Share on other sites

Does anyone know if the SAMS card can coexist in the presence of the Geneve?  Thinking about GPL mode usage in Rompage mode.

Share this post


Link to post
Share on other sites
25 minutes ago, TheBF said:

I used made this one for myself base on work by Bruce Harrison.

Happy to answer any questions. I have pretty good working code now in Forth and Forth Assembler.

 

 

SAMS CARD ACCESS and MAPPING.pdf 949.6 kB · 3 downloads

Thank you! I plan on experimenting with the SAMS card over the next few weeks as time allows and I'm sure I'll have many questions 😬

Share this post


Link to post
Share on other sites
2 hours ago, Vorticon said:

Hi. Aside from Thierry's documentation of the SAMS card, is there another reference available, particularly aimed at the software side of things and for the 1meg card? 

I should also mention this difference between Classic99 and real iron.

 

The AMSINI code below works on real IRON.

To use it on Classic99 you must change the >0101 to >0100.

 

* 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

 

Share this post


Link to post
Share on other sites
Just now, Vorticon said:

Why is this the case?

Something to do with supporting bigger cards.

The old cards wanted duplicate values in each byte. Bigger cards need the extra byte to go beyond 256 total pages. 

 

I can't remember if I sent this to @Tursi in a clear enough manner. (oops my bad)

He has said he hasn't done much with SAMS somewhere in the forum so probably not a top priority.

 

  • Thanks 1

Share this post


Link to post
Share on other sites
2 hours ago, Vorticon said:

Hi. Aside from Thierry's documentation of the SAMS card, is there another reference available, particularly aimed at the software side of things and for the 1meg card? 

 

Here is a @FALCOR4 post from SAMS usage in Assembly.

 

...lee

  • Like 2
  • Thanks 1

Share this post


Link to post
Share on other sites
7 minutes ago, Lee Stewart said:

 

Here is a @FALCOR4 post from SAMS usage in Assembly.

 

...lee

I think this is a slightly different situation that that doc addresses in that the AMSINI code from Bruce, is writing a word to the SAMS register but it still doesn't work on Classic99.

I think Classic99 actually gives you more than 1M of memory although I have never tested how much.

The first byte is counting pages 0..255 for a 1M card and the second byte lets you access more pages.

Or am I missing something completely. Been known to happen. :)

 

 

 

Share this post


Link to post
Share on other sites

I should add that I just don't run AMSINI on Classic99 anymore since Classic99 boots up in pass-thru mode. 

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, 9640News said:

Does anyone know if the SAMS card can coexist in the presence of the Geneve?  Thinking about GPL mode usage in Rompage mode.

Try it in MAME. 🙂

However, I'm not sure whether the real card decodes AMA/B/C. My emulation does not.

 

  • Like 1

Share this post


Link to post
Share on other sites
38 minutes ago, TheBF said:

I think this is a slightly different situation that that doc addresses in that the AMSINI code from Bruce, is writing a word to the SAMS register but it still doesn't work on Classic99.

I think Classic99 actually gives you more than 1M of memory although I have never tested how much.

 

Classic99 has 32 MiB SAMS.

 

39 minutes ago, TheBF said:

The first byte is counting pages 0..255 for a 1M card and the second byte lets you access more pages.

 

True, but, it is easier for me to think about it as a word that accesses as many pages as a particular SAMS card can. The card simply ignores the leftmost bits that are not implemented—a fact that can easily be exploited to determine the amount of SAMS memory available (as I do for fbForth 2.0).

 

...lee

  • Like 2

Share this post


Link to post
Share on other sites
3 hours ago, TheBF said:

To use it on Classic99 you must change the >0101 to >0100.

 

Interesting and good to know.  This is probably why I had trouble with my first attempts to use SAMS earlier this week.  Some of the documentation I collected was written for the early AMS hardware, and that tripped me up.

  • Like 4

Share this post


Link to post
Share on other sites

It's not clear to me why the different write is needed though. I mean, yes, it will select a different page, but as long as the selected page is consistent, why does it matter?

 

Understanding this will let the next revision work better.

 

  • Like 2

Share this post


Link to post
Share on other sites
19 hours ago, TheBF said:

I think this is a slightly different situation that that doc addresses in that the AMSINI code from Bruce, is writing a word to the SAMS register but it still doesn't work on Classic99.

I think Classic99 actually gives you more than 1M of memory although I have never tested how much.

The first byte is counting pages 0..255 for a 1M card and the second byte lets you access more pages.

Or am I missing something completely. Been known to happen. :)

 

Actually, the point, I think, of Doug’s (@FALCOR4’s) note was to stay out of trouble by always writing a word via MOV (and never bytes via MOVB)to a SAMS register as though it could select any page that might be possible (above and below 1 MiB), regardless of the actual hardware situation. This means that, for SAMS of 1 MiB and below, the byte that selects pages higher than 1 MiB should be 0. It helps to think of the word written to a SAMS register as selecting the desired SAMS page number and, then, swapping the bytes before actually writing to the register:

SAMS   Number    SAMS
Page   to write  Address
-----  --------  --------
>0000   >0000    >0000000
>000A   >0A00    >000A000
>00FF   >FF00    >00FF000  <--highest page for 1 MiB card
>0123   >2301    >0123000
>03FF   >FF03    >03FF000  <--highest page for 4 MiB card
>0FFF   >FF0F    >0FFF000  <--highest page for 16 MiB card
>1FFF   >FF1F    >1FFF000  <--highest page for 32 MiB card (Classic99)

...lee

  • Like 5

Share this post


Link to post
Share on other sites
On 1/14/2022 at 7:46 PM, Lee Stewart said:

 

Actually, the point, I think, of Doug’s (@FALCOR4’s) note was to stay out of trouble by always writing a word via MOV (and never bytes via MOVB)to a SAMS register as though it could select any page that might be possible (above and below 1 MiB), regardless of the actual hardware situation. This means that, for SAMS of 1 MiB and below, the byte that selects pages higher than 1 MiB should be 0. It helps to think of the word written to a SAMS register as selecting the desired SAMS page number and, then, swapping the bytes before actually writing to the register:

SAMS   Number    SAMS
Page   to write  Address
-----  --------  --------
>0000   >0000    >0000000
>000A   >0A00    >000A000
>00FF   >FF00    >00FF000  <--highest page for 1 MiB card
>0123   >2301    >0123000
>03FF   >FF03    >03FF000  <--highest page for 4 MiB card
>0FFF   >FF0F    >0FFF000  <--highest page for 16 MiB card
>1FFF   >FF1F    >1FFF000  <--highest page for 32 MiB card (Classic99)

...lee

Thank you Lee, spot on.  With the 1M and smaller cards, when you execute a register write, the LSbyte is written to the LS612 but when the TI next writes the MSByte it overwrites the LSbyte that it just wrote which makes the LSbyte of the WORD irrelevant.  That's why it really doesn't matter what you have in the LSbyte of a WORD that you write to the SAMS card if it is 1M or smaller.  However, it does matter with the 4M card (and any other larger increments that may come along), which has a separate latch that captures the LSbyte of a WORD that is written to the registers.  That's why it's recommended that software assumes a larger card and to be fully compatible with any SAMS.

  • Like 4
  • Thanks 1

Share this post


Link to post
Share on other sites
On 1/14/2022 at 9:31 AM, TheBF said:

I think this is a slightly different situation that that doc addresses in that the AMSINI code from Bruce, is writing a word to the SAMS register but it still doesn't work on Classic99.

I think Classic99 actually gives you more than 1M of memory although I have never tested how much.

The first byte is counting pages 0..255 for a 1M card and the second byte lets you access more pages.

Or am I missing something completely. Been known to happen. :)

 

 

 

Actually RXB 2020 or 2021 supports 32Meg of SAMS RAM in Classic99 and would work fine on the old ASM Memory card too.

As RXB unlike Assembly uses byte access to change pages not full words.

 

Share this post


Link to post
Share on other sites

Byte access works? That would in theory only work if read-back is implemented. I don't know if it was on the real physical 32MB card...

 

Share this post


Link to post
Share on other sites
1 hour ago, Tursi said:

Byte access works? That would in theory only work if read-back is implemented. I don't know if it was on the real physical 32MB card...

 

Yea might have to fix that if it ever turns up and I get one. I do want the real iron to test it.

SIZE in RXB  reports the SAMS pages being used and memory address too.

Z14.pdf

Edited by RXB
picture

Share this post


Link to post
Share on other sites
1 hour ago, Tursi said:

Byte access works? That would in theory only work if read-back is implemented. I don't know if it was on the real physical 32MB card...

 

The 8 bit address captured by the LS612 can be read back and you will get the MSbyte of the last write to that register.  But, on cards larger than 1M, the latch for the 4 bits of the LSbyte cannot be read back because the latch is not wired to read back on the data bus.  So, what happens is that you will get a "copy" of the MSbyte that was loaded into the register which may not be (and probably isn't) what was loaded into the latch.

 

It's confusing.  Say you wrote a >0100 to a register.  If you read it back you will get >0101 on any SAMS card.  The LSbyte read back is simply a copy of the MSbyte from the LS612 and not the latch.  This means that software must be aware of register write addresses if it is necessary to keep track of the addresses.

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites
22 minutes ago, FALCOR4 said:

The 8 bit address captured by the LS612 can be read back and you will get the MSbyte of the last write to that register.  But, on cards larger than 1M, the latch for the 4 bits of the LSbyte cannot be read back because the latch is not wired to read back on the data bus.  So, what happens is that you will get a "copy" of the MSbyte that was loaded into the register which may not be (and probably isn't) what was loaded into the latch.

 

It's confusing.  Say you wrote a >0100 to a register.  If you read it back you will get >0101 on any SAMS card.  The LSbyte read back is simply a copy of the MSbyte from the LS612 and not the latch.  This means that software must be aware of register write addresses if it is necessary to keep track of the addresses.

So that would indicate I need to use the last pages of SAMS as a memory map of what pages I used and where?

Should fit as >0000 to >FFFF minus memory that is not changed list >0000 to >1FFF or >4000 to >5FFF or >6000 to >7FFF 

Would this take 32K just to store the page used?

And another 32K of what memory address? 

Share this post


Link to post
Share on other sites
1 hour ago, RXB said:

So that would indicate I need to use the last pages of SAMS as a memory map of what pages I used and where?

Should fit as >0000 to >FFFF minus memory that is not changed list >0000 to >1FFF or >4000 to >5FFF or >6000 to >7FFF 

Would this take 32K just to store the page used?

And another 32K of what memory address? 

Rich, I don't know if I am answering your question correctly but I'm willing to take a stab at it.  For a 32M SAMs, it would take 8K of WORDs to define each 4K memory page along with another 8K WORDs to define where in the TI memory map each 4K memory page would be found.  Check my math!  😁 Of course, to complicate things, that's only if you assign one 4K block to one TI memory segment!  You could have the same 4K memory page show up in multiple TI memory segments, there are uses for that I suppose.

 

BTW, I don't personally believe that we will see a SAMS card any larger than 16M because that is the limit for the LS612 chip.  It would take some rework to go any higher than that. In emulators and in RXB, I totally got it.  I have a few 4M cards and I don't know how many others are out there in use right now.  1M may remain the gold standard card for a while if not for quite a while, IMHO.

  • Thanks 1

Share this post


Link to post
Share on other sites
4 hours ago, FALCOR4 said:

It's confusing.  Say you wrote a >0100 to a register.  If you read it back you will get >0101 on any SAMS card.  The LSbyte read back is simply a copy of the MSbyte from the LS612 and not the latch. 

I tried this interactively in this short video on my 1M SAMS card running Forth on real iron.

You can see that when I write >0B00 it comes back as 0B0B. 

 

 

  • Like 2
  • Thanks 1

Share this post


Link to post
Share on other sites
4 hours ago, FALCOR4 said:

BTW, I don't personally believe that we will see a SAMS card any larger than 16M because that is the limit for the LS612 chip.  It would take some rework to go any higher than that. In emulators and in RXB, I totally got it.  I have a few 4M cards and I don't know how many others are out there in use right now.  1M may remain the gold standard card for a while if not for quite a while, IMHO.

The 32MB exists in Classic99 because a hardware prototype was developed. But I was not informed what the latch was. ;)

 

  • Like 2

Share this post


Link to post
Share on other sites
6 hours ago, FALCOR4 said:

Rich, I don't know if I am answering your question correctly but I'm willing to take a stab at it.  For a 32M SAMs, it would take 8K of WORDs to define each 4K memory page along with another 8K WORDs to define where in the TI memory map each 4K memory page would be found.  Check my math!  😁 Of course, to complicate things, that's only if you assign one 4K block to one TI memory segment!  You could have the same 4K memory page show up in multiple TI memory segments, there are uses for that I suppose.

 

BTW, I don't personally believe that we will see a SAMS card any larger than 16M because that is the limit for the LS612 chip.  It would take some rework to go any higher than that. In emulators and in RXB, I totally got it.  I have a few 4M cards and I don't know how many others are out there in use right now.  1M may remain the gold standard card for a while if not for quite a while, IMHO.

 

Would be cool if SAMS > 1MB exist that can be split up in 1MB partitions. That way you’d have multiple virtual 1MB cards.

Think that could be a good way for running multiple SAMS programs at the same time without them stepping on eachothers toes.

Sure you’d need some way to control the partitions, but sounds doable.

 

  • Like 2

Share this post


Link to post
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...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...