Supernotes

[GDMike]

Yeah, I had some issues

I have 4 stages for setting up my SAMs. Pages. The first is

 

SAMON, which turns on the card, I found lots of sources on how this is done and is the simplest of all my call instructions.

 

Then I made "ADPG", I found three or four different sources on how this is accomplished and I really got so turned around on getting this right. This is just an ADD BANK routine. It just increments the previous bank number without going past a predefined bank.

 

And then I made "SBZ" this just makes the current bank - bank 2, I call home bank. I can quickly reset my bank to this number.

 

And lastly, "SAMOFF" this was as easy as turning on the card, but there were variations on getting this accomplished.

 

So now I can get to any bank within my >E000 - >EFFF address range.

I'm finally getting somewhere, I think..

Hehe...

 

 

 

 

 

 

 

 

 

[+TheBF]

What do you keep in low RAM for your editor?

Just asking, but sometimes it's better to use 3000..3FFF for SAMS data and keep hi RAM for more features in your CODE.

 

[GDMike]

I'm pulling supercart data, I have an import function that pulls in 9 SNE (supernotes express) pages, which are still 840 bytes of user data per user screen.

And then I have my library for CALLS, such as call color, call char, call beep, etc.., all located in FE00-hmm like 40 bytes or so.

So I think I'm safe there for that since I'm not loading ANYTHING around that area.

But originally, when SNP wasn't using SAMs, I was using that >3000 area for pages too.

I've release some ram in that area though and since I've been so focused on just getting Sam's to work, I may have to revisit that LRam area again.

And I've still gotta get DSR disk save/load invoked. My calculations say SNP user pages = 1000 bytes, that's 840 bytes for individual screen pages and a 160 byte area for hypertext user data per screen page, just one per SNP page allowed.

So maybe that's an area I can use for my pab buffer.

 

 

 

Edited September 2, 2020 by GDMike

[+TheBF]

It's probably worth doing to give you a straight run of memory in upper RAM for all your code.

To change your SAMS code you just change the address you use to put your bank number in. 

To use >3000 as your swap page write the SAMS page number data to >4006. 

Right now for >E000 you are using >401C as the SAMS register.

[GDMike]

Double edit: I meant>3000 geeeees

Edit:

Ok, I think I see your point and I think you're concerned about program space running into >E000.. ok, that does make more sense now that I thought about that.

So I'll be moving Sam's page to>3000

It's only a block, so no big deal. And my program can grow.

-----------

Original message below

 I chose E000 because I knew at the time that nothing was going on there and was good for my "SNP pages" since I'm only looking at 1ea 840 byte area at any given time. And possibly another 160 byte for hypertext that sits at the top of each SNP page, basically the last 160 bytes.

 

But I see what you're saying, and luckily, I've learned real well how to manipulate that Sam's address, so yes, easy to move it to another from>E000(401C). 

That's kinda why I've not continued yet on my page up/down and SAVE page,(referring to SNP screen pages), on an exact route with addressing until I get it thought out more, like with what your suggesting. 

I'm also thinking on the lines of expansion, as if an 80 column card becomes available to the masses, how to handle that data, so I thought I didn't want to be stuck in the middle of low ram for that, or what about larger supercarts, as I'm using a four bank now for my test, but what if... this, that..

 

I kinda probably want to keep things higher. And as far as time and data access, Sam's isn't slow to me, it initialized 235 banks in like, snap of a finger. That's like a second or less.

In my scientific world. A snap back is quick. I thought my init was cheating but I went back and pulled random addresses between>E000->EFFF and found my test word was in fact true.

So I don't have issues, at this time in speed for read/write.

 

I can't wait to get back at it! I'm just not so fast..

 

 

 

 

Edited September 2, 2020 by GDMike

[GDMike]

How cool is AORG >6000!!!!

 

... program BL routines

...

...

RT

When you have an extra 8K sitting there in a supercart and you have 8K of code to push to it.

Im having a blast rt now with trying to make decisions on how the SNP and SNE 32K, (4X banks of 8K), can be effective and still retain user data but using 1 bank for either the SNP or SNE programs. 

 

This doesn't change the way that SNE currently works, BUT it would mean that SNE would need it's program reloaded prior to use AND will not alter the user data in the other 3 banks. This way I can use that 1st bank, currently SNE program for program space for SNP.

uh yeah! Like 8K contiguous.

I mean yes I have SAMs but I don't have 8K without bank switching.

I could get a lot of BL routines in that 8K space.

 

Does it mean that the supercart would have to be part of the whole deal, well yeah, but SNP is related to SNE and SNE uses the 4 banks in the cartridge.

So why not extend this out to SNP as a MUST have, SAMs is already a must have item.

SNP is already using A000-D840 for program space. 

SNP doesn't allow writing to any banks in the supercart, but SNE writes to 3 of them so I wouldn't have to worry about user corruption occuring by accident, unless someone pulled the cartridge out.

It's just an idea for now.

 

 

 

 

Edited September 3, 2020 by GDMike
Updated Last sentence

[GDMike]

There is an UPDATE to SNE to 1.2.1

EA df80 files, option 3,

load(not run) MENU, then F9 and  load SNE, and run program name: SNE

Both cartridge switches down and press CTRL 1, this pushes the SNE program utils into the cartridge

Reboot, follow on screen instructions.

This latest update just correctly instructs the user during install that both bank switches must be down.

 

 

MENU SNE

Edited September 4, 2020 by GDMike

[+TheBF]

16 hours ago, GDMike said:

How cool is AORG >6000!!!!

 

... program BL routines

...

...

RT

When you have an extra 8K sitting there in a supercart and you have 8K of code to push to it.

Im having a blast rt now with trying to make decisions on how the SNP and SNE 32K, (4X banks of 8K), can be effective and still retain user data but using 1 bank for either the SNP or SNE programs. 

 

This doesn't change the way that SNE currently works, BUT it would mean that SNE would need it's program reloaded prior to use AND will not alter the user data in the other 3 banks. This way I can use that 1st bank, currently SNE program for program space for SNP.

uh yeah! Like 8K contiguous.

I mean yes I have SAMs but I don't have 8K without bank switching.

I could get a lot of BL routines in that 8K space.

 

Does it mean that the supercart would have to be part of the whole deal, well yeah, but SNP is related to SNE and SNE uses the 4 banks in the cartridge.

So why not extend this out to SNP as a MUST have, SAMs is already a must have item.

SNP is already using A000-D840 for program space. 

SNP doesn't allow writing to any banks in the supercart, but SNE writes to 3 of them so I wouldn't have to worry about user corruption occuring by accident, unless someone pulled the cartridge out.

It's just an idea for now.

 

 

 

 

You can also put the primary program at >6000 and load different sub-routine overlays into A000 and Page A000 into SAMS pages.

Maybe a list of sub-routine addresses could go into a table at that top of A000 on each page. 

You could then pull in a SAMS page and call the sub-routines with indexed addressing. The main program would have to remember the bank and subroutine numbers for each bank.

 

(forgive my poor knowledge of Assembly language syntax. Not sure what it would take to keep something like this straight.)

 

SUBTAB   DATA   SUB0,SUB1,SUB2,SUB3,SUB4,SUB5,SUB6

 

              LI         R1,3                 * select sub-routine 3

              BL        SUBTAB@(R1)   * call the sub-routine

 

 

You are the architect.  

 It is pretty cool to have that extra memory in the cartridge for sure.

[GDMike]

I'm just using a set bank to home 

Then rolling a loop for the bank number I need. Since nothing special Except getting to the bank has to happen.

 

But it's an interesting concept there. Thx

[+Lee Stewart]

17 hours ago, TheBF said:

(forgive my poor knowledge of Assembly language syntax. Not sure what it would take to keep something like this straight.)

SUBTAB DATA SUB0,SUB1,SUB2,SUB3,SUB4,SUB5,SUB6
       LI   R1,3          * select sub-routine 3
       BL   SUBTAB@(R1)   * call the sub-routine

 

 

DATA operands are words (2 bytes), so you need to double the selection number to get the proper index into the table. Also, your BL will try to execute that word. You need to load that word into a register:

SUBTAB DATA SUB0,SUB1,SUB2,SUB3,SUB4,SUB5,SUB6
       LI   R1,3             * select sub-routine 3
       SLA  R1,1             * double R1 to get proper index
       MOV  SUBTAB@(R1),R1   * load the sub-routine address
       BL   *R1              * branch to it

 

...lee

[GDMike]

Always a great day when Lee is clarifying

Of course the idea is brilliant, and so is the clarification. 

Thanks you guys for this idea

[apersson850]

The correct syntax is like this:

SUBTAB DATA SUB0,SUB1,SUB2,SUB3,SUB4,SUB5,SUB6
       LI   R1,3             * select sub-routine 3
       SLA  R1,1             * double R1 to get proper index
       MOV  @SUBTAB(R1),R1   * load the sub-routine address
       BL   *R1              * branch to it

As I first wrote in another thread, if the index is known, and not passed like a parameter, then you write like this:

SUBTAB DATA SUB0,SUB1,SUB2,SUB3,SUB4,SUB5,SUB6
       MOV  @SUBTAB+(3*2),R1   * load the sub-routine address
       BL   *R1              * branch to it

Here you let the assembler do the math at assembly time, instead of the CPU doing it at runtime.

Edited September 4, 2020 by apersson850

[HOME AUTOMATION]

This Jump Table idea definitely works, as long as its not too long!

 

 

I cribbed it from somewhere!

Edited September 4, 2020 by HOME AUTOMATION
too

[GDMike]

Yup. Got it

[GDMike]

Updated information regarding SNP.

I've decided to NOT create an area in SAMs prior to import SNE pages 1-27.

Instead, I'll let the user understand that they need to move any pages that contain data on pages 1-27 to another area, pages that are blank somewhere in the 900 something SNP pages (840 byte) space.

Because moving 900 something pages 27 page steps/235 banks of 4K in memory just to make room for 27 import pages is a lot of code and the time it takes to process the move is not timely. So with that, the user will be prompted to move switches on the cart, and cautioned about overwriting etc.. , something that happens anyway, then SNE pages can be quickly imported.

SNP will have the ability to move pages.

So, my last 3 days of SAMs work is just going in the trash.

My program was growing too far too fast so I had to come up with this alternative.

But I think it is better anyway.

 

 

Edited September 7, 2020 by GDMike

[+TheBF]

I don't fully understand your trials and tribulations of course, but once you get it working the way you want it would be possible to retry SAMS.

Maybe even to have multiple files in memory that can be selected. Just page out the blocks where the text is located with some other pages.

Keep at it.

[GDMike]

I hear ya,

Well I've got to get the basics done first. 

I've solved the Sam's problems I had earlier.

 

I've got three variables that will help track.

"BANK" tracks the bank number

And "PAGE" tracks the actual real SNE page.

And "PB", (not peanut butter), is a value between 1-4.

If page down happens, then we increment "PAGE" and check if "PB" is greater than 4, if so add 1 to "BANK"

And select the first of 4 addresses in the bank And so on...

I have a routine that updates the current screen with the right data from BANK and PAGE.

It's all coming along,

thanks for good advice

 

Edited September 9, 2020 by GDMike

[GDMike]

Update on SNP, The program MUST have a SAMS card in order to use. It's dedicated now.

As SNP now loads, the user is given a message that it's checking for SAMS and initializes, so far, 240 SAMs pages with a 30 second wait time. You are messaged if no card is found.

 

 

 

Edited September 16, 2020 by GDMike
Clarify

[GDMike]

This is a utility for erasing the supercart.

It's a DF 80 file, program name is SC

Program start name is START

Here's a video on explanation of how and why I needed this program.

 

DSKA0065.dsk

Edited October 5, 2020 by GDMike

[GDMike]

I've noticed on occasion that I couldn't even get to option 2, the editor assembler menu to run the SC program.

If you encounter that, you can do as I do and select 1 for basic and CALL LOAD("DSK#.SC) and then CALL LINK("START")

And the program will launch but you won't be able to read anything on the menu, but just press 1 and spacebar and you'll Clear the Cartridge that way.

Reboot and your e/a menu will appear.

[+TheBF]

11 hours ago, GDMike said:

This is a utility for erasing the supercart.

It's a DF 80 file, program name is SC

Program start name is START

Here's a video on explanation of how and why I needed this program.

 

DSKA0065.dsk 180 kB · 3 downloads

Remember how you would do that in Forth?

 

HEX 6000 2000 0 FILL

 

 

[GDMike]

I actually grabbed the TI Forth disk last night and said, whoa, there hauss!

I don't have time rt now.

But I'd love to try..

Edited October 5, 2020 by GDMike

[GDMike]

Ahhhh. Forth..mmmmm

[GDMike]

1 hour ago, TheBF said:

Remember how you would do that in Forth?

 

HEX 6000 2000 0 FILL

 

 

Ti forth doesn't have fill. I think TF has V!

Though.

[+Lee Stewart]

26 minutes ago, GDMike said:

Ti forth doesn't have fill. I think TF has V! , though.

 

TI Forth does, indeed, have FILL (fills RAM). The same goes for fbForth. TurboForth’s V! stores only one byte and that to VRAM, not RAM.

 

...lee