Jump to content

Recommended Posts

1 hour ago, GDMike said:

Wow. I figured it out.

On the real console, it wants a "init" of the SAMS card, then a turn on followed by turn off of the card.

Oh my my, this is part of the issues I've been having.

I'm figuring it out.

At the bottom of my TI-Forth version was this:

 

SAMSINI MAP-ON

CR ." SAMS card activated"

 

SAMSINI turns on the card.  Does the register inits, then turns off the card. (using CRU bit 0)

Then turn the mapper on.  (using CRU bit 1)

 

You're welcome.  :) 

  • Thanks 1

Share this post


Link to post
Share on other sites

Not sure if you care but I didn't give a blow by blow explanation of the code before.

 

These pieces of TI-Forth do that same as Assembler.  The difference  SBO SBZ  for bits 0 and 1 are pre-defined as Forth words.

You load R12 with the card's CRU address with the SAMSCARD routine. (you could do it manually as well if you wanted to)

It's all there for you to enjoy.

\ *set the CRU address in 'R12 before using these words*
  CODE 0SBO ( -- ) 1D00 ,  NEXT,
  CODE 0SBZ ( -- ) 1E00 ,  NEXT,
  CODE 1SBO ( -- ) 1D01 ,  NEXT,
  CODE 1SBZ ( -- ) 1E01 ,  NEXT,

: SAMSCARD  ( -- ) 1E00 'R12 ! ;    \ select sams card
: SAMS-ON   ( -- ) SAMSCARD 0SBO ;  \ enable card
: SAMS-OFF  ( -- ) SAMSCARD 0SBZ ;  \ disable card
: MAP-ON    ( -- ) SAMSCARD 1SBO ;  \ enable mapper
: MAP-OFF   ( -- ) SAMSCARD 1SBZ ;  \ disable mapper

These are a little weirder partly because of TI-FORTH's variable word.

 

TI-FORTH VARIABLE  takes the initial value on the left side.  After the name of the variable,  comma will just put another number in memory right after the initial value.

So it makes an array of numbers (as big as you want)

 

Think of what is there like this:

LOSAMS    DATA 0202,0303 

HISAMS    DATA 0A0A,0B0B,0C0C,0D0D,0E0E, 0F0F 

 

There are 2 arrays.  One for low ram and one for hi ram.

The numbers are the initial values for the SAMS card that make it look like a normal 32K card.

SAMSINI  turns on the card 

Then takes LOSAMS array, the register for SAMS pages at CPU RAM >2000,  which is >4004 and a length of 2 CELLS (4 bytes)

CMOVE does  a string copy of 2 CELLS (ie: 4 bytes) from LOSAMS to >4004 so it also fills the next register at >4006 as well. It's just a memory to memory transfer :) 

 

Next we do the same thing with HISAMS array into address >4014 for 6 more SAMS registers .

TI-99 to thinks it has a 32K card in the normal memory locations. at the bottom of the SAMS card memory.

\ These are arrays of sams registers values for TI-FORTH pass thru
\ 1ST                2nd     3rd   4th    etc.
0202 VARIABLE LOSAMS 0303 ,
0A0A VARIABLE HISAMS 0B0B , 0C0C , 0D0D , 0E0E , 0F0F ,

: SAMSINI
      SAMS-ON
      LOSAMS 4004  2 CELLS CMOVE    \ load low ram registers
      HISAMS 4014  6 CELLS CMOVE    \ load hi ram registers
      SAMS-OFF
;

After this you use    DMAP with a bank# from >10 to >FF and the bank will appear in your memory at whatever address you selected for the DMEM CONSTANT.

The CPU address must be selected from HEX 2000 3000 A000 B000 C000 D000 E000 F000. (2000 3000 A000 F000 are forbidden with TI-FORTH)

 

Hope that makes sense.

 

  • Thanks 1

Share this post


Link to post
Share on other sites
13 hours ago, GDMike said:

So I'm thinking that forth FB1.0 would now possibly work as long as the card was initialized, turned off and turned on again with good mapper info prior.

I'll have to review. That's how it works in my assembly program now.

 

The Catch 22 I mentioned a few posts back will be a problem with running code loaded before initializing SAMS. Once fbForth 1.0 (and, TI Forth, for that matter) is running, you cannot safely initialize SAMS from expansion RAM. I am working on a safe way to do it from Forth:

  1. Back up scratchpad, from >8348 (following Inner Interpreter) to length of SAMSINIT, to VRAM prior to loading and calling SAMSINIT.
  2. Run SAMSINIT (40 bytes).
  3. Return to calling routine, which will be back in place.
  4. Restore scratchpad from VRAM.

...lee

Edited by Lee Stewart
updates
  • Thanks 1

Share this post


Link to post
Share on other sites

Ahh. Ok. I got really confused when I was

Physicaly writing to memory without the thought that I was going to do any SAMs stuff, and I had Problems. I wasn't expecting that at all, I did understand that I could encounter issues if I was planning to do SAMs stuff.

I never had any Trouble writing to the super cart at all, so I took the same code and wrote to >F000 and the machine only liked it once, after that it didn't.

Fool me once...I thought the term "turn on" meant use the card for Special operation.

I thought "init" meant the card was already on, but needed a setup done to it.

Well, I guess I went the long way around.

That's one way 😂

Share this post


Link to post
Share on other sites
On 10/13/2020 at 9:27 AM, TheBF said:

Right.  If you turn on the SAMS card and the mapping tables are not set up for "pass through" addresses

ALL YOUR RAM with TI-Forth in it changes to some other random blocks of RAM.  :)

That will lock it up for sure.

Yes, I just never thought it would apply since my Supercart responded differently. I NOW know differently.

Eye opening. Sorry, I was already so deep in FB 1.0 that after having issues, I then went back to my original assembly code and then it all came together.

 

Share this post


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

 

The Catch 22 I mentioned a few posts back will be a problem with running code loaded before initializing SAMS. Once fbForth 1.0 is running, you cannot safely initialize SAMS from expansion RAM. I am working on a safe way to do it from Forth:

  1. Back up scratchpad, from >8348 (following Inner Interpreter) to length of SAMSINIT, to VRAM prior to loading and calling SAMSINIT.
  2. Run SAMSINIT (52 bytes).
  3. Return to calling routine, which will be back in place.
  4. Restore scratchpad from VRAM.

...lee

Right.  That's to be avoided for now.

So GDMike could experiment with TI-Forth to get a feel for things if he wanted to try some of the Forth code methods.

I find testing at the command line gives me clarity but that could just me my way of thinking.

  • Like 1

Share this post


Link to post
Share on other sites

But TI forth has SO much missing code that Mr. Stewart developed for FB. And I'm definitely not comfortable at redesigning it when FB has already done that. I'm not sure if "SOUNDS" are defined or speech in FB 1. But I think lee has a plan to possibly adding a SAMS addition. I can wait as he probably has other things going on, and I'm good on going forward with SAMs in my SNP assembly version now after you guys gave me some ideas that helped me get it working. Thank you!

BTW, I'm not capable of putting my heels together and clicking them 3 times like you three. It's a process that takes time, but I understand that you want me in there, ears and elbows. 

Hehe

 

Edited by GDMike

Share this post


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

Right.  That's to be avoided for now.

So GDMike could experiment with TI-Forth to get a feel for things if he wanted to try some of the Forth code methods.

I find testing at the command line gives me clarity but that could just me my way of thinking.

Hehe.. BTW ive written a nice "essentials" program in Turboforth last year. Tf also has words for speech.

But it's a cartridge like FB. Both are fantastic to develop in, as is camel I'm sure. But with my bad memory, I need a good manual for whatever language. But the speed of TF is exceptional and I love its Sam's use, such as "4 BANK" to put the user in a totally new bank to start writing new words for with no other words reqd from the user AND all words can be found across all banks without me having to switch to that particular bank.

 

 

Edited by GDMike

Share this post


Link to post
Share on other sites

Continuing with SNP, the assy version today.

Completed the: check for Sam's routine.

This only detects if I can write to and read from a page of Sam's.

It doesn't check for the size of the card.

If the write/read/verify doesn't work, then a msg is displayed that the program needs S.A.M.S. and after a time reboots to title screen.

If card is found, a msg displayed that a initialize process is taking place.. and we continue..

 

Share this post


Link to post
Share on other sites
15 hours ago, Lee Stewart said:

The Catch 22 I mentioned a few posts back will be a problem with running code loaded before initializing SAMS. Once fbForth 1.0 (and, TI Forth, for that matter) is running, you cannot safely initialize SAMS from expansion RAM. I am working on a safe way to do it from Forth:

  1. Back up scratchpad, from >8348 (following Inner Interpreter) to length of SAMSINIT, to VRAM prior to loading and calling SAMSINIT.
  2. Run SAMSINIT (40 bytes).
  3. Return to calling routine, which will be back in place.
  4. Restore scratchpad from VRAM.

 

OK...I have working code for SAMS! . It accomplishes the four points above, handily. The spoiler below has all of the necessary SAMS words, including SBO and SBZ , so no need to load them from block 20. I redefined SAMS-ON and SAMS-OFF to be in line with @TheBF’s code. It does make sense to have setting/resetting of bit 0 be named for turning the card on/off. That does, after all, provide access to the >4000 address space where the SAMS registers are located. I added MAP-ON and MAP-OFF to, again, conform to @TheBF’s usage. They now mean what I had defined SAMS-ON and SAMS-OFF to be, so be forewarned! I will, eventually, put all this code in a separate SAMS blocks file:

 

Spoiler
HEX
( These CRU words needed by SAMS words may be commented out if loaded.)
CODE SBO  ( CRUbit -- )
   C339 , A30C , 1D00 , NEXT,
CODE SBZ  ( CRUbit -- ) 
   C339 , A30C , 1E00 , NEXT,

( Change this constant's value to the highest SAMS page in your system.)
( The setting below is for page 255, the highest page for 1 MiB SAMS.)
0FF CONSTANT SAMS?  ( highest SAMS page)

: SAMS-ON   ( -- )
   0F00 SBO       ( enable SAMS card and access to mapper registers )
;
: SAMS-OFF  ( -- )
   0F00 SBZ       ( disable SAMS card and access to mapper registers)
; 
( SAMS card bit 1 can be set/reset without "turnong on" the card)
: MAP-ON   ( -- )
   0F01 SBO       ( enable SAMS card mapping )
;
: MAP-OFF  ( -- )
   0F01 SBZ       ( disable SAMS card mapping)
; 

( SAMSINIT machine code, which maps SAMS to pass-through)
( settings. It will be loaded to >8348 after backing up)
( 40 bytes to VRAM...)
0200 VARIABLE SAMSINIT  
      4004 , 0201 , 0200 , CC01 , 0201 , 0300 , C401 , 
      0200 , 4014 , 0201 , 0A00 , 0202 , 0006 , CC01 ,
      0221 , 0100 , 0602 , 16FB , 045B ,

( SAMSINEX executes SAMSINIT loaded at 8348)
CODE SAMSINEX                                                  
   06A0 , 8348 , NEXT,         ( BL @SAMSINIT)

( Initialize SAMS...)
: SAMS!  ( -- )
   8348 1400 0028 VMBW     ( back up scratchpad RAM area)
   SAMS-ON                 ( enable access to mapper registers)
   MAP-OFF                 ( disable mapping while we set it up)
   SAMSINIT 8348 014 MOVE  ( copy machine code to scratchpad RAM)
   SAMSINEX                ( execute SAMSINIT)
   ( All code should now be mapped where it was before initializing SAMS.)
   MAP-ON                  ( enable mapping)
   SAMS-OFF                ( lock the mapper registers)
   1400 8348 0028 VMBR     ( restore scratchpad RAM area)
;

( *** S0&TIB! *** Set S0 and TIB [same address] to a new value.)
( This word is primarily for use in a SAMS environment, where it is or may)
( be necessary to move the stack base and TIB buffer, both of which start)
( up at the same address, viz., >FFA0.  S0&TIB! forces addr1 to >DFA0,)
( >EFA0 or >FFA0; copies it to the User Variables, S0 and TIB, in the table)
( of default values so the settings will survive COLD; copies the old TIB)
( to the new TIB; ignores the old stack; clears the new stack;  and leaves)
( the new address on the new stack as addr2.  The lower limit is forced)
( above HERE so as not to destroy the user's dictionary.)

: S0&TIB!  ( addr1 --- addr2 )
   F000 AND                   ( force to 4 KiB boundary n)
   DUP HERE U< IF             ( corrected addr1 >= HERE?)
      ." S0 too low! " ABORT  ( no..abort)
   THEN
   0FA0 OR                    ( force addr1 to nFA0)
   >R                         ( copy new address [addr2] to return stack)
   TIB @ R 052 CMOVE          ( copy 82 bytes from old TIB to new TIB)
   R UCONS$ @ 08 + !          ( store new default S0 )
   R UCONS$ @ 0E + !          ( store new default TIB)
   R TIB !                    ( store new TIB)
   R S0 !                     ( store new S0)
   SP!                        ( reset top of stack)
   R>                         ( new address to new stack)
;
( >MAP presumes the SAMS card mapping is enabled.)
: >MAP   ( bank addr -- )
   ( set up SAMS register address)
   F000 AND                ( set to 4KiB boundary)
   0B SRL                  ( divide by 2048)
   4000 OR                 ( convert to SAMS register address)
   ( set up bank information)
   SWAP SAMS? AND          ( mask off pages too high)
   SWPB                    ( reverse byte order to write to SAMS register)
   ( map bank)
   SAMS-ON                 ( enable SAMS registers)
   SWAP !                  ( poke SAMS register)
   SAMS-OFF                ( disable SAMS registers)
;
DECIMAL

 

 

I will be reposting this over in the main fbForth thread in the near future. Right now, though, I think I will work on porting @Willsy’s “SAMS Programming Library” to fbForth:waving:

 

...lee

  • Like 3
  • Thanks 1

Share this post


Link to post
Share on other sites
9 hours ago, Lee Stewart said:

Right now, though, I think I will work on porting @Willsy’s “SAMS Programming Library” to fbForth:waving:

 

Well, I got it all ported and hit a major snag when I tried to run it. I immediately got a “full stack” error. It did not take me long to figure out (I think) what was wrong and why writing Forth words in this scenario will not work with SAMS mapping happening in the >F000 block. As soon as one begins to compile a word at >F000, the new “HERE” is above the stack (>EFA0). I may be off with my explanation because the word headers are supposed to be contiguous with the rest of the dictionary lower down (below the stack), but, without detailed probing, that is all that makes sense at the moment. If that is the problem, I could leave the stack at >FFA0 and use >E000 for paging SAMS banks, but that reserves almost 4 KiB for the stack, which usually does not need that much space, which means that the dictionary will get short shrift.

 

If you really need the complete functionality of @Willsy's word-writing library for SAMS, I can probably work something out. If, on the other hand, you only need a few of those words (or words like them) to make it easier to swap banks, that should be easy enough. Though, I am not sure what could be easier than the >MAP word. That is pretty much all you need after initial setup. I suppose you might want a word like SETBANK that, once you decide on a 4 KiB RAM block for swapping, would only require a bank number that always banks to your preset block. If that is of any use, I can write such a word that will let you select a bank and error out if you choose too high or too low. Let me know what functionality you would like to augment the current SAMS package.

 

...lee

Share this post


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

If, on the other hand, you only need a few of those words (or words like them) to make it easier to swap banks

In the case of SNP, I only need the bank for data swapping, not words definition.

But, as in my essential disk, I use it for words definition only. So i can probably make things work with data storage.

Edited by GDMike

Share this post


Link to post
Share on other sites
13 hours ago, GDMike said:

In the case of SNP, I only need the bank for data swapping, not words definition.

But, as in my essential disk, I use it for words definition only. So i can probably make things work with data storage.

 

@Willsy’s SAMS Programming Library (SPL) should be no problem in fbForth 2.0 because most of the upper 24 KiB is available to the programmer, but in fbForth 1.0, the Forth kernel takes up 8430 bytes before loading any SAMS support! The hit for basic SAMS is an additional 420 bytes and the current SPL, 714 bytes more. HERE is now at >C55C. With SAMS banking in the >E000 block and the stack in the >F000 block, there is only a space of 6820 bytes for the user dictionary to grow. Even though SAMS pages can now be used for word bodies, the main dictionary still grows with the word headers and the SAMS word headers are larger than normal headers because each one holds directions to the word’s SAMS bank. I have some kinks to work out of the SPL before it is usable, but I should be able to do that. It is just too bad that the >F000 block needs to be reserved for the stack alone. I should think it a rare circumstance indeed that the stack would ever grow to 4 KiB. Of course, the programmer could make judicious use of the low end for storage, but I digress....

 

...lee

  • Thanks 1

Share this post


Link to post
Share on other sites

SNP, the assembly version, has been tested for and with SAMs again today.

I'm now able to read the data from the supercart, data made with the SNE program I made last year, and now SNP imports that  8K bank into Sam's memory and it ends up being PAGE 1 of SNP, page 2,3 up to page 9 of SNP "real" screen pages, (not SAMs pages).

But I've yet to finish the complete import routine, as it's gotten late on me tonight.

But something to look forward to tommorow.

I sure hope things go faster now. 

I've got a lot of time to make up 😂

Edited by GDMike

Share this post


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

 

It is just too bad that the >F000 block needs to be reserved for the stack alone. I should think it a rare circumstance indeed that the stack would ever grow to 4 KiB. Of course, the programmer could make judicious use of the low end for storage, but I digress....

 

...lee

Is there a way to find some free space in LOW RAM for two stacks.  You really only need 64 cells for each stack (HEX 100 bytes total) and Forth will run most programs unless somebody is really into recursion.

There is one recursive routine in your Forth... ROLL I believe.  But that's the 11th commandment. 

 

   "Thou shalt not ROLL"

  • Haha 1

Share this post


Link to post
Share on other sites

I myself, know I'm approaching >E000 in my SNP program now, and was using>F000 for my ram swap of 4K, but I've since moved everything to>3000 SAMs use, I should be safe since I've AORG at A000 for SNP to "ROLL" out with.

But I know this is completely different from lee's issues.

 

Edited by GDMike

Share this post


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

There is one recursive routine in your Forth... ROLL I believe.  But that's the 11th commandment. 

 

   "Thou shalt not ROLL"

 

That is not part of the cartridge. Its definition in FBLOCKS is easily changed if necessary.

 

8 hours ago, TheBF said:

Is there a way to find some free space in LOW RAM for two stacks.  You really only need 64 cells for each stack (HEX 100 bytes total) and Forth will run most programs unless somebody is really into recursion.

 

Low RAM free space (available to the return stack) in fbForth 1.0 (5 block buffers) is only 682 bytes. It is 1306 bytes in fbForth 2.0 (4 block buffers). 

 

...lee

  • Like 1

Share this post


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

 

That is not part of the cartridge. Its definition in FBLOCKS is easily changed if necessary.

 

 

Low RAM free space (available to the return stack) in fbForth 1.0 (5 block buffers) is only 682 bytes. It is 1306 bytes in fbForth 2.0 (4 block buffers). 

 

...lee

So could you copy short versions of the stacks into low RAM and then reset SP and RP to that memory and run ABORT?

That might free up F000 for SAMS use no?  I suspect you would never use 682 bytes of stacks  total at least that what the literature says.

  • Like 1

Share this post


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

But I know this is completely different from lee's issues.

Yes it is quite confusing to have two discussions taking place at the same time. 🙂

Share this post


Link to post
Share on other sites
40 minutes ago, Asmusr said:

Yes it is quite confusing to have two discussions taking place at the same time. 🙂

 

Understood, but this discussion is about Supernotes implementation in Forth as well as Assembler, so there is unfortunate (and confusing, I admit) overlap.

 

...lee

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

I think there's only 3 people talking. Sorry to confuse. But usually we are sticking to one OS, but they may mix here and there. 

Edited by GDMike

Share this post


Link to post
Share on other sites

SNP-assy ver: progress note

I successfully have a functional IMPORT routine, that pulls in 1 BANK from the SNE cartridge data into SAMS pages.

I'll be working to finish that routine in it's entirety. And when completed, will allow pages 1-9 from each SNE bank, (3 BANKS), for a total of 27 SNP pages, (1-27). The user should be forewarned that SNP pages 1-27 will be overwritten before they attempt an import.

It sure was nice to see it in action.

I'll do a demo on that routine soon 😜

 

 

 

Edited by GDMike
  • Like 1

Share this post


Link to post
Share on other sites

SNP-assy ver: progress note

successful import of 9 SNE pages into SNP, via SAMs mapping.

But I've got an issue regarding page # at the top right of screen going from 4 to 5 during page up.

it displays 004 then rolls to 005 like normal pg up key, then abruptly changes to 001 shortly after.

ive spent hours yesterday digging and here's what I know.

with my number generator turned off I get no numbers at all until I hit page down 5 times. Then I get 001.

ill be digging again today, it's so funny, I've never had this hard of a Problem to find, except for figuring out SAMs, this ranks #2.

i know that this happens with or without the import being invoked, and with the number generator off that I made.

 

it's very strange. Hmmm possessed.

No code to display, since I don't have an idea where to pull.

Last address of ram being used by my program uses is >D302,

(>A000->D302) so I've got, ram available so I'm not running short, yet. 

NOW, my question is, I'm using the SAMs bank >4004 (3000) area. 

I think the EA book says some of this runs into the def table, now, I am not reaching that far out, but SAMs mapper might since it maps the whole >3000 bank.

But I'll say, Everything is working and my only issue is the page number.

 

Edited by GDMike

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

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

×   Your previous content has been restored.   Clear editor

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

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...