Supernotes

[GDMike]

On 6/10/2020 at 5:39 PM, mizapf said:

Example:

 

LI   R3,0
LI   R4,101
LI   R2,4
DIV  R2,R3

 

Result should be R3 = 25, R4 = 1.

 

Ahhh.. now I seeeeee

[GDMike]

Added the"search" routine to F5 CALL SEARCH command that was presented in the assembly"routines" Atariage area Early last month, it really adds to the beauty of this program.

I hope to have this completed by Friday.

 

[GDMike]

Ok, I'm not done with search, but while I was thinking about the TIpi clock, I wondered if there was a way to read the date/time. So I went over to https://github.com/jedimatt42/tipi/wiki

And found that in basic you could read it.

So I applied that to the SNP program.

I only had room for one of the items, either the date or time, but not both.

So I'll just make a couple hot keys that will display one or the other or neither.

 

 

[GDMike]

Ok, a change to the change while I figure this out.

I'll get my thoughts together and come up with a better plan, AND I need to add a hot key for inserting the date/time stamp into the notes body, like windows' notepad F5 key.

Then I need to get back to work on finishing my search routine.

[GDMike]

I placed the date and time in the upper left of the screen. I added Ctrl Q for toggling the date/time on or off.

If someone does not have a TIpi running and they hit Ctrl Q to start the clock, the program locks, waiting for a TIpi connection.

I tried reading byte 1 of the PAB for error, and nothing gets reported, I got zero as a error code, but the pi was rebooted. Hmm. I guess that's why? It sees the TIpi and thus no error as it's the pi not online.

Anyway, I'll worry about that in a later time. I gotta finish SEARCH up.

 

Edited August 11, 2020 by GDMike

[GDMike]

I'll be uploading the latest version tommorow.

 

Edited August 11, 2020 by GDMike

[GDMike]

Success!!

Search is finding words pages 1-9.

Still wip

 

I'm still working on it...

Edited August 11, 2020 by GDMike

[GDMike]

Hurray!

Here is the latest SNP. Program D/F80

Called SNP, program name SNP

Please remember, if you don't have a TIpi card then don't try the Ctrl Q clock command. It will wait until a connection, like, forever, looking for TIpi. Just reboot if you do.

 

SNP

Edited August 12, 2020 by GDMike

[GDMike]

The search routine uses around 3 seconds to scan each page. 

Edited August 12, 2020 by GDMike

[GDMike]

I just did add this, but it's not in the new file.

Edited August 12, 2020 by GDMike

[GDMike]

Ok. I'm ready to move to the DSRLNK util.

This ought to be fun. Just a side note,  I've got, or had 15 pages to work with, but I'm going to knock it down to 10.

Reason is, I'm running out of ram.

And in order to fulfill the DSRLNK, I'll need ram. 

That leaves me with a working program and 10 pages of user space.

Then my last job will be to create page 11 in SAMs. And have it become my overflow pages.

It needs to be 860 bytes in length, then I'll just keep making overflows from that page 11, and hopefully get hundreds of accessible pages. 

This way I have minimal adjustments to make in my search routine and other areas.

 

 

Edited August 12, 2020 by GDMike

[HOME AUTOMATION]

3 hours ago, GDMike said:

The search routine uses around 3 seconds to scan each page. 

That sounds way too long....................

...are you using delays!

[GDMike]

No sir. Let me think, well, firstly I'm not using delays, nor using the code wide open. My first address, and each search is 860 bytes long until receiving a non find or a find.

asI do have a comparison at the end of each NON find after looking at 860 bytes. If there's a no find, I have to add a new address, search length etc and restart. But it's merely just adding 860 bytes to the existing address and restarting. I do have a comparison looking to see if I've reached page 9 yet, and I change my address at that point to an entirely different address and restart the test and if a no find, then just merely add another 860 to the address again and restart. 

So two, simple comparison running.

Now, yesterday I added a kyscan to allow break out. But, I dunno- hardly noticeable.

It takes like, hmm 3-4 seconds before it detects the key(space bar) for interrupt.

I had the idea to look for a space in the beginning of the search routine and possibly speed things up, but haven't,

My search starts at page 1 and continues until found, or interrupted.

Once I have a find, I just rt because I've already got everything I need.

And most of my pages were blank. So I had a blank stare at my screen thinking, hmm I'm looking through this...then

because I fell asleep and, well just remember this, Lindsey Buckingham is out now, and things don't sound The same.

Edited August 12, 2020 by GDMike

[GDMike]

I'll add this, why not place the first pages 1-9 as one lump search?

Well, it's because I'm incrementing the variable"page" after each 860 byte search, so that once my position is calculated with R0 I can send everything back to the Calling program and continue running with "PAGE" already known.

I could redesign, and just do a search of Everything, then try to find out which page R0 formulates to I suppose.

But I'll bet the search is faster, but my calculations in trying to find what page that R0 returns would be about the same.

I'll probably move on to DSR and maybe come back to this at a later time.

I'm not displeased with the speed as when I use the search routine in the editor assembler editor, I noticed that it's pretty slow too, but I think this speed is useable.

When I get a moment, I'll upload a text file of my code regarding search.

Not a photo. Unless you just wanna see the code, then I can send quick photos.

 

[HOME AUTOMATION]

      Yes, Sir. ...I want some more code please.

     ...I still --so huuunngry.

[GDMike]

I'm looking at how to setup a pab.

And my question is, since I have multiple pages in ram, and each page is 860 bytes, am I supposed to push my 860 bytes into vdp ram address>1000,

(my pab bufadr equ >1000)

And perform the DSR in writes of  80 bytes at a time?

I know how to setup the PAB, I'm just confused on how to get my pages written out.

Ooops, sorry bout that.. just found an example.

Photo

 

 

Edited August 12, 2020 by GDMike

[GDMike]

I think I'm getting it.

In the e/a manual, I see how there moving a read data to cpu buffer and how they update the read to a write if needed.

These are the questions I had. But it looks like I'm getting there...slowly

Now I'll go review the information that automation gave me a while back.

This should clarify a few things. But I think I'm getting it!

 

Edited August 12, 2020 by GDMike

[GDMike]

Automation said earlier in a pm and just right before that terrible song from the 70s, mentioned

 

Hmm, 840x17=14.2K, so, all pages could be saved to a single file, if that sounds better.

I think, the one page at a time, method, might be easier, though.

 

But to clarify, it's now going to be 9 pages with the 10th page being a Sam's page I'll work on in the future, but for now I'm going to just say 9 pages and each page is 840 bytes.

I think I like the 1 page at a time method.

Basically Because after I get Sam's memory working for pages 10-???, Then I can add that functionality in later.

 

 

Edited August 12, 2020 by GDMike

[+Lee Stewart]

40 minutes ago, GDMike said:

I'm looking at how to setup a pab.

And my question is, since I have multiple pages in ram, and each page is 860 bytes, am I supposed to push my 860 bytes into vdp ram address>1000,

(my pab bufadr equ >1000)

And perform the DSR in writes of  80 bytes at a time?

 

You want to use DV80 files, which means each record can be 80 bytes or less. When reading this type of file, the DSR READ opcode reads the next sequential record into your VRAM buffer pointed to by your PAB, which should be 80 bytes to accommodate the largest record. It is up to you, then, to copy that record to its RAM destination. The READ operation returns the number of characters read to the file’s PAB+5 byte.

 

To write a record to the file, you must write the next record to the VRAM 80-byte buffer and provide in PAB+5 the number of bytes to write to the next file record.

 

I am wondering if this is really the way you want to handle your 860-byte pages. How exactly are your pages organized in memory? Are they 860 bytes of contiguous characters or are you treating them as variable-length lines? It looks to me like the former and that it happens to be 21 lines by 40 characters/line, which is 840 characters per screen. If so, what are the extra 20 bytes for?

 

Sorry for all the questions you may have already answered, but I figured it would be a lot quicker to ask than to reread this thread to discover the answers.

 

...lee

 

[GDMike]

 Lee I've been confusing that"page" block as 860 bytes, but I stand corrected, as it's 840.

sorry to get that confused.

The pages are a block of contiguous bytes.

And actually pages 1-8 run from one address to another without a gap.

Pages 9 and up will be in limbo as I work that out in Sam's.

Late note: page 1 starts at >23A4 

 

Edited August 12, 2020 by GDMike

[GDMike]

I'm in the process of checking available ram. If I've got enough, I'll adjust those pages from 1-8 to 1-9.

Stand by, wip

[+Lee Stewart]

17 minutes ago, GDMike said:

Lee I've been confusing that"page" block as 860 bytes, but I stand corrected, as it's 840.

sorry to get that confused.

The pages are a block of contiguous bytes.

 

There are a lot of ways to skin this cat, but I would do something akin to what I do in fbForth for blocks files and that is to use DF128 files. Your 840-byte pages will each occupy seven 128-byte records, unfortunately wasting the last 56 bytes of the seventh record. You would need to process the seventh record differently from how you do it for the first six—easy enough to do, but an irritation, nonetheless.

 

...lee

[GDMike]

I've got 8 pages of 840 bytes for now, and 6K and change of free ram, (program space).

Like I say, I'll be needing program space and I'll adjust my user pages in SAMs while building the DSR and testing that, as the two go hand in hand.

 

 

 

Edited August 12, 2020 by GDMike
Typo

[GDMike]

Lee, what would be the best practice for large files. If i incorporate Sam's and my pages become 1-8 local ram and 9- 100 Sam's, let's say about 840K worth.

I wonder what others are doing in Sam's file management as far as saving data.

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.

Hmmm....

I haven't had time to plan DSR yet.

I'm there, here and now.

So it looks like I've got to answer the question, how to save 840k of Sam's SNP text pages.

 

 

 

 

Edited August 12, 2020 by GDMike
Typo

[+Lee Stewart]

26 minutes ago, GDMike said:

Lee, what would be the best practice for large files. If i incorporate Sam's and my pages become 1-8 local ram and 9- 100 Sam's, let's say about 840K worth.

I wonder what others are doing in Sam's file management as far as saving data.

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.

Hmmm....

I haven't had time to plan DSR yet.

I'm there, here and now.

So it looks like I've got to answer the question, how to save 840k of Sam's SNP text pages.

 

That is only 32 bytes more than 82 KiB (not 840 KB!), which, in my scenario, would take 87.5 KiB. That would fit on one 90 KiB diskette with 1.75 KiB to spare!

 

...lee