Supernotes

[GDMike]

About 24 hours and my clock continues to function. Looks like I was setting up a PAB for the clock early in my program boot up and later something damaged the PAB. So I relocated the PAB setup to such a time as right before the clock is activated by the user.

Works much better...

 

[GDMike]

Getting back to how byte 06 writes a DSR file as a program type file, that is, 8192 bytes in the file. Am I responsible for having to create additional files? Because I pushed 8192 bytes to my buffer and called my DSR and a file was created, but I subsequently created another call inside my loop calling DSR twice but adding different data to my 8k buffer on the second round and calling DSRlink again before exiting. I thought another file would automatically be created with the last letter incremented by one.? But that didn't happen, I only got one file of 8192 bytes with the last buffer update intact.

So Im assuming if that's going to be the case, then I'll have to manage the filename as well. Which isn't a problem, I'm just looking for clarity.

Edited February 1, 2021 by GDMike

[+TheBF]

Yes you have to bump the last character of the file name, Move the next chunk into VDP RAM and pull the trigger again.

 

[GDMike]

Figures..lol.i can do that. I just didn't know if it was something in the DSR that made it happen..

Ok, good to know, then everything I've got going on is correct! Wow how about that that's amazing! how about I take the day off!

On a side note,  my Geneve is on its way!! 

I wonder if I could still code SNP for the ti on the Geneve? Ooh..no tipi..

That sucks...

 

 

Edited February 1, 2021 by GDMike

[apersson850]

When creating such files, it's common to include a word at the beginning of the file which indicates if it's the last one or not. So if you create three files, FILEA, FILEB and FILEC, at the beginning of the files you have a word that's TRUE in the first two, then FALSE in the last one. Thus you can check the files and see if you need to load another one or not.

The file headers should also include some information about where the data should be placed. Like page numbers in your Supernotes program, or whatever is appropriate.

[+Lee Stewart]

 

17 hours ago, GDMike said:

So I’m assuming if that's going to be the case, then I'll have to manage the filename as well. Which isn't a problem, I'm just looking for clarity.

 

Yeah—one model for this is how the E/A SAVE utility manages this for E/A Option 5 (“Run Program File”). SAVE puts 6 control bytes at the front of each file saved (8 KiB for each, except ≤8 KiB for the last one). The first 2 bytes (0 and 1) contain >FFFF when another file must be loaded or >0000 for the last file in the series (as @apersson850 suggested you do for SNP). Bytes 2 and 3 contain the number of bytes to load from this file. Bytes 4 and 5 contain the RAM address where the load will begin. SAVE serializes the filenames by incrementing the last character in the filename for the next file to save. Obviously, the filename you choose should not end with a letter at the end of the alphabet!

 

...lee

[GDMike]

48 minutes ago, Lee Stewart said:

Obviously

 

48 minutes ago, Lee Stewart said:

Obviously, the filename you choose should not end with a letter at the end of the alphabet!

Hehe.. isn't that the truth.

In this case, I've calculated 88 files would be created. And I'm gonna force a drop of the last two characters,(or add 2, depending on file length before hand), and just place a blunt 2 digit number, 1-88 at the end. I'll track the name within my loop, as I'll be looking for that 9th-10th  loop transaction and make that change, user can control Characters 1-8.

As my load program will be looking for this as well.

Edited February 1, 2021 by GDMike

[GDMike]

9 hours ago, apersson850 said:

When creating such files, it's common to include a word at the beginning of the file which indicates if it's the last one or not. So if you create three files, FILEA, FILEB and FILEC, at the beginning of the files you have a word that's TRUE in the first two, then FALSE in the last one. Thus you can check the files and see if you need to load another one or not.

The file headers should also include some information about where the data should be placed. Like page numbers in your Supernotes program, or whatever is appropriate.

Yes, I think you briefly touched on this before, but not to this detail. but I gotcha

Edited February 1, 2021 by GDMike

[apersson850]

13 hours ago, GDMike said:

In this case, I've calculated 88 files would be created.

Does this involve saving all pages you have available for the "notes"? Is it a good idea to save all of them each time? Is it not reasonable to consider a user's selection of which pages to save, and/or an automatic save of dirty pages only?

[GDMike]

4 hours ago, apersson850 said:

Does this involve saving all pages you have available for the "notes"? Is it a good idea to save all of them each time? Is it not reasonable to consider a user's selection of which pages to save, and/or an automatic save of dirty pages only?

This saves all, later, though, I will create an option for the user to save sections.

Note: I'm not using all SAMs for filing..

Edited February 2, 2021 by GDMike

[apersson850]

20 hours ago, GDMike said:

This saves all, later, though, I will create an option for the user to save sections.

That's the wrong approach, I'd say.

Focus on being able to save an arbitrary screen to begin with. Create a subroutine which, given a screen number and a pointer to the PAB, can save a single screen.

Then develop a routine which can put together a few adjacent screens in the same buffer. Call the saving routine to save them.

Then develop a routine which can handle a large range of screens, sectioning them to fit in 8 K files, and manage their file names. Call the rotine above to save them.

 

Now you are ready. By this approach, you have structured your program to build routines which can call each other in a meaningful manner. You have also developed all the functionality you need, with all of it in mind to begin with. No need to go back and change things, just because you didn't think of something needed for the next step.

 

By embedding information about which screen(s) are saved in each file you save, and if there are linked files, you only need one type of file loading procedure. It will know by looking in the file what to do with it.

[GDMike]

4 hours ago, apersson850 said:

Then develop a routine which can put together a few adjacent screens in the same buffer. Call the saving routine to save them.

I'm already doing this

[GDMike]

4 hours ago, apersson850 said:

Then develop a routine which can handle a large range of screens, sectioning them to fit in 8 K files,

I'm already doing this too

[GDMike]

13 hours ago, apersson850 said:

you have structured your program to build routines which can call each other in a meaningful manner. You have also developed all the functionality you

I've got to build a 1 way Street. Because Ive got 3200 bytes left and I've still got to build a LOAD routine and other stuff...

But this will suffice, this builds 1 group of around 88 files for the user to always work out of. No need to change filenames once created, unless the user WANTS to for something else, but this would handle all SAMs pages saved, and can be changed over and over again. The user is instructed to backup workfiles.

Let's go with this and try it. If I need or can change things, we will setup for the change, as Lee also suggested a block type file and the file is update as a user travels through pages..

Which I also like, especially with tipi, because it's not that slow and forth"flushes" are fast in tipi, I suppose they'd be fast in SNP too.

 

Ty

 

 

 

Edited February 4, 2021 by GDMike

[apersson850]

I'm sure refactoring your code could save you a thousand bytes. If you want to add more features.

[Asmusr]

On 2/3/2021 at 5:14 PM, GDMike said:

I've got to build a 1 way Street. Because Ive got 3200 bytes left and I've still got to build a LOAD routine and other stuff...

Is that because your program is running from 8K cartridge space? Since you're using SAMS anyway there must be other options.

 

[Asmusr]

35 minutes ago, apersson850 said:

I'm sure refactoring your code could save you a thousand bytes. If you want to add more features.

Refactoring assembly code can be almost as difficult as writing it in the first instance. It helps to have good tools, but AFAIK GDMike is working retro style.

[GDMike]

1 hour ago, Asmusr said:

Is that because your program is running from 8K cartridge space? Since you're using SAMS anyway there must be other options.

 

Nope, I'm running from>A000->FFE0.

 I'm just not utilizing SAMs yet.

But I may later.

 

[GDMike]

Here is the latest save. 

Here I'm saving 800 SNP pages, wrapped in 88 files. This is fine for me ? while I match up a loader for it.

This way I have a working program, and then I can modify changes that need to happen over time, since I'm not going to have a lot of time soon to spend on this, as things happen... like broken cars...etc...

I just need to get a file option out, that is my goal these days.

 

[Asmusr]

1 hour ago, GDMike said:

Nope, I'm running from>A000->FFE0.

 I'm just not utilizing SAMs yet.

But I may later.

 

But what about >2000->3fff?

[GDMike]

1 hour ago, Asmusr said:

But what about >2000->3fff?

I'm using e/a utils... if there in that area, then I'm not touching that, of course, BUT if it's open, I haven't checked, but if it's open..then whohoooo.

[+Lee Stewart]

1 hour ago, Asmusr said:

But what about >2000->3fff?

 

42 minutes ago, GDMike said:

I'm using e/a utils... if there in that area, then I'm not touching that, of course, BUT if it's open, I haven't checked, but if it's open..then whohoooo.

 

Once your program is loaded, you can use the area from >23BA (E/A loader) – >3FFF for 7238 bytes of storage. That is enough room for one SAMS paging area (>3000 – >3FFF) and 3142 bytes more for other storage (>23BA – >2FFF).

 

...lee

[GDMike]

Thank you. 1 bank is 3440 for me, so I can squeeze 2 banks from what I gather.

Edited February 4, 2021 by GDMike

[+Lee Stewart]

1 hour ago, GDMike said:

Thank you. 1 bank is 3440 for me, so I can squeeze 2 banks from what I gather.

 

????     One SAMS bank takes 4096 (>1000) bytes and the only place in low RAM you can map it is at >3000—hence my comment about having 3142 (>0C46) bytes left.

 

...lee

[GDMike]

Oh, right. Duh..I'm in the middle of a geneve troubleshooting and thinking about the Geneve I'm working on and reading this at the same time,( damn bubble gum sux rt now...)

and totally forgot about my SAMs mapped pages...sorry bout that...

I see what you're saying..

Edited February 5, 2021 by GDMike