Supernotes

[GDMike]

Ahh. Good to know.

So ill probably be able to store some executable code in SAMs too. 

I'm just thinking out loud...

Alright, I'll work up a plan for Sam's and DSR over the next couple days.

 

 

[+Lee Stewart]

3 hours ago, GDMike said:

And another question, do I need to save all 100 pages all the time, or do I need to scan those 100 pages and only save the pages with data on them.

 

With a page scenario, there is no reason not to save just the pages that are dirty, i.e., changed. Of course, you need a way, then, to keep track of changed pages. You could do this with a table in RAM or by adding a word (2 bytes) at the beginning of the RAM buffer. This is the way Forth does it, i.e., a word before the first editable byte of a buffer contains the block # (page #) and the dirty (update) flag in the leftmost bit. Forth also places a null word after the last editable byte of the buffer as an interpreter fence, but you would not need that here. Forth handles large blocks files with only a handful of block buffers. In your case, you want to load the entire file into RAM and, possibly, save only dirty pages. Like I said, you have lots of options. You just need to decide on the best way for your program.

 

...lee

[GDMike]

Very good to know. I'll be planning around that 

 

[Asmusr]

You could also save each page in a separate 'program' file. Then you don't have to deal with records, it will be faster to save and load (I think), and you can easily save only the modified pages.

[GDMike]

I don't know what that means. Haha...what's new? But plz, elaborate. I would think that speed would be up to the controller more than the type of format, talking in relative terms. 

I'd figure the more data, no matter how it's presented as long as the buffer or queue was full for majority of time would be sufficient, be it, DF 128, DV 80, is there a df 255? Maybe... but does that even Matter?

Thanks so much for your knowledge.

 

[+9640News]

Rather than writing DIS/VAR 80 files, or some other record format, you could setup your PAB to save a block of memory say something like 4K or 8K as a Program Image file. Your filename could be the construed as the "Project name" & "Bank Order#", so something like SUPER001 to SUPER255.  That way, one PAB call after copying the data to VDP, and you save a whole block at one time.  Then, when you go to load the project, you are loading the Filename "SUPER" which could be the "control" block that lets your program know how many blocks you have and any other pertinent details you may want to have to load.

 

Beery

 

 

[+Lee Stewart]

52 minutes ago, GDMike said:

I don't know what that means. Haha...what's new? But plz, elaborate. I would think that speed would be up to the controller more than the type of format, talking in relative terms. 

I'd figure the more data, no matter how it's presented as long as the buffer or queue was full for majority of time would be sufficient, be it, DF 128, DV 80, is there a df 255? Maybe... but does that even Matter?

 

The record size definitely matters because you must read/write each record. The more records processed for the same amount of data, the longer it takes. Level 2 direct file read and write would probably be fastest, but you cannot do that on TIPI. What @Asmusr is referring to is level 3 SAVE (opcode 6) and LOAD (opcode 5), which TIPI can probably handle. As @Asmusr implied, you could set up a VRAM page buffer of 840 bytes into which to copy each page to save to a user-determined file name with the page number appended—DSK1.SNPFILE001 for page #1, etc. You could also do this in page blocks, say 10 pages/block, which would require a VRAM buffer of 8400 bytes. You would need to devise some file-serializing scheme to keep track of which block of pages you were dealing with at save/load time. Of course, whatever buffer size you choose is limited to available VRAM. The larger you can make this page block, the faster your save and load operations will be and the fewer files you will need. Lots of wiggle room here!

 

...lee

[GDMike]

2 hours ago, Lee Stewart said:

Of course, whatever buffer size you choose is limited to available VRAM. The larger you can make this page block, the faster your save and load operations will be

 

So, it's possible to expand the VRAM by including the entire area that's used for character definitions and just redefine chars as I come out of the load/save DSR? Creating charset is fast anyway.

Or will that not be enough space? 

[HOME AUTOMATION]

28 minutes ago, GDMike said:

 

So, it's possible to expand the VRAM by including the entire area that's used for character definitions and just redefine chars as I come out of the load/save DSR? Creating charset is fast anyway.

Or will that not be enough space? 

It only takes about 1 sec. on my TIPI to SAVE or RESTORE all 16k of VDP!

 

So SAVE the current VDP state... MOVE/SAVE/LOAD your pages... re-LOAD the previous VDP state.

 

Oh, you might want to use the "screen blanking" while doing this!

[GDMike]

Sure, don't wanna show my underware.

Edited August 13, 2020 by GDMike

[+Lee Stewart]

1 hour ago, GDMike said:

 

So, it's possible to expand the VRAM by including the entire area that's used for character definitions and just redefine chars as I come out of the load/save DSR? Creating charset is fast anyway.

Or will that not be enough space? 

 

Unless you are using VRAM for other stuff, you should have from >1000 (just above the character table) to whatever address is in >8370 (should be >37D7 for 3 simultaneous files—the default). That is 10,200 bytes—should be more than enough.

 

...lee

[GDMike]

Ok Lee, I've taken everything said:

SAMs information pointers, DSR information. Both.

I think I've got enough to start , plus the 1 percent inspiration, and the sweat from my brow, I'll try to come up with something and I'll never show my face in public until it's working! Oh, that's already going on... pretty much these days.

Well, I'll hit hard AND Never give up! 

Unless the kids need something in the next room.. but regardless!! Onward!!

Wish me lots of luck.

At least Stevie Nick's is blasting, stop dragging my....cart around?

Sounds familiar

[+Lee Stewart]

If you are thinking at all of using my suggestion over in post #159 of the SAMS thread, you might consider making your SNP page-size 800 bytes (twenty 40-char lines) because, then, you could get 10 SNP pages in each 8 KiB set of SAMS swaps, wasting only 192 bytes as opposed to 632 bytes wasted with nine 840-byte SNP pages per SAMS swap. By the way, you could use the extra space for storing information relevant to each set of SNP pages that could be conveniently saved with the file.

 

...lee

[GDMike]

Version 1.2 of SNE

This would still use the original menu program, seperate download, as well as instructions.

 

SNE

Edited August 14, 2020 by GDMike
Information

[GDMike]

Well it's a great time for a video. SAMs paging is almost in place.

I've  added a message on boot that if detected to display a message, another if SAMs card not found.

Thanks again, automation for being patient and assisting me through SAMs low level access routine. 

Even small things can stop the show.

 

Next, I'll be adding the ability to add many pages to SNP.

Yayhoooo

 

 

[GDMike]

I'm thinking about the search routine. Maybe I need to scan each page for complete emptiness before the routine starts for a page. Would it help speed things up. I'll try it.

 

[+9640News]

A page will only be empty if it was never written to in the first place. If there is data leftover from a previous loaded file/document that wasn't cleared, you may get a false report.

 

Beery

 

[GDMike]

This is the first time I've ever encountered this.

I had this code and for the life of me it wouldn't jump to my routine.

MOV @KYBUF,R1

LI R2,>9C00

CB R1,R2

JLT KFF

 My register 1 was always the letter A, >41, even though I tried hitting the keyboard with letters b c d no matter what I did I could not get my code at kff

To work.

I finally put the word EVEN prior to my first line here, and wholla, it works. I thought I was going crazeee

 

 

Edited August 20, 2020 by GDMike

[+TheBF]

On 8/18/2020 at 10:41 PM, GDMike said:

I'm thinking about the search routine. Maybe I need to scan each page for complete emptiness before the routine starts for a page. Would it help speed things up. I'll try it.

 

I took the safe route of purging memory before loading a file. That might help (?)

You can purge SAMS quickly by doing 4K at a time.

[GDMike]

Yes, I definitely do that. I have to Provide"blank" spaces in order to prepare for text. I do that for the supercart prior to anything, well the program asks the user if they'd like to initialize the cart. But they don't have to, as sometimes there just reinstalling but still have good data on the cart.

In the case of using SAMs, I'll be doing the, "SHAZSAM" treatment. Initializing all 4K and moving through the banks.

 

I'm working on something rt now, that you might like, but...I can't tell you yet!!

But I think you might have a use for this.

Oh I can't wait to show it off. But it's not done yet..

[GDMike]

Ok, I'll explain my excitement.. and not keep it from ya.

I've created a way to set a character to inversed color, I did this awhile back, but I thought about other uses for it.

So I've set up a table that contains this:

Page number left byte and character location in the LSB.

The next byte is the storage in memory location address and following is, if available date stamp gathered by TIpi clock.

I've set a hot key and if the cursor is sitting on top of an inverse character, pressing fctn h, copies the current page and creates a 20X5 line window that allows a user to enter text data regarding, I suppose, information relating to the inversed character, that would be the first character of a complete word.

This acts as a hypertext link that a user can open and view and close when not wanting to view.

If the user deletes the hypertext character, there is a routine that can be run to either confirm the deletion or recover the deletion, since I don't want to store text if not necessary, but don't want to delete on accident.

I'm moving right along with this and can't wait to get a demo up.

Thx

 

Edited August 21, 2020 by GDMike

[GDMike]

I've added, ok, maybe a little late but it's finally in. 

As SNP boots, it NOW formats 239 BANKS with >2020, or 935K space, or around that number.

 

Well, I had to get SAMS understood and working, and now I'm able to proceed on making SAMs SNP pages.

That's 4 SNP pages for 1 SAMs bank, with 164 bytes per bank unused, well I say unused, but I'm thinking to allow 1 hypertext word to exist per SNP page and that hypertext space is, hahaha 120 bytes in length. So I really only waste 24 bytes per Bank page, saving for reserve, but I think that's rt.

 

My math figured like this:

840 bytes per SNP page

120 bytes available for hypertext per SNP page.

4096 bytes per SAMs bank

239 SAMs banks available for SNP pages.

I think I got that right, I'll have to really DBL, Tripple check though.

I'm using SAMs addresses >E000->EFFF.

I have 3 variables for pointers:

"Page" which is actually a real number between 1-nnn of user SNP pages.

This provides page number to be displayed on the screen.

"BANK" the real bank number, which tracks 1-239 banks.

And "BP" which is a value of 1-5, for tracking the SAMs address in 840 byte increments.

If BP=1, then the Sam's address is >E000

If BP=5,(hyptext data), then 120 bytes are appointed to the last address between  >E000 and  >EFFF.

 

 

 

 

 

 

 

 

 

 

Edited September 1, 2020 by GDMike
Updated from 860 bytes to 840..I dunno why I keep saying 860?

[GDMike]

After adjusting my "in-between" page bytes and doing the math, I came up with 1 byte left over, not 24.

 

SAMs pages are 840 bytes each with

>E000->E35C for page 1

>E35E->E6BA for page 2

>E6BC->EA18 for page 3

>EA1A->ED76 page 4. 

Then I'll use 160 bytes for hypertext

>ED77->EE18 hyp text P1

>EE1A->EEBA hyp text p2

>EEBC->EE5C hyp text p3

>EE5E->EEFE for hyp text p4

 

With one byte to spare

If course I seperated out each page by two bytes.

This will provide, hopefully, my SAMs pages.

 

 

 

Edited September 1, 2020 by GDMike

[GDMike]

Ok. Good news. SNP is no longer using just 32k local ram, as a matter of fact, it won't run on Just 32k. It now requires the SAMS card.

I've been able to page up/down through 29 pages. And even after power off/on my pages were still intact. But I'm sure it dissolves after some time. Hehe, but

I've still got issues to work out with SAMs, but I'm making good progress.

This is the first attempt at providing SAMs pages. Whohoo

 

 

 

Edited September 1, 2020 by GDMike

[+TheBF]

36 minutes ago, GDMike said:

Ok. Good news. SNP is no longer using just 32k local ram, as a matter of fact, it won't run on Just 32k. It now requires the SAMS card.

I've been able to page up/down through 29 pages. And even after power off/on my pages were still intact. But I'm sure it dissolves after some time. Hehe, but

I've still got issues to work out with SAMs, but I'm making good progress.

This is the first attempt at providing SAMs pages. Whohoo

 

 

 

Congrats! That is a real break through.