Jump to content

Recommended Posts

So far Supernotes PRO is still lacking the ability to save/load files. But before I could do that I had to create an area, I call "command line". This will give the user a way to call commands such as SAVE DSK#.FILENAME

I've almost got that command line ready to accepting commands. I'm not to far away from that as the video suggest an attempt at saving a file. But actually I have no file function at the moment.

  • Like 4

Share this post


Link to post
Share on other sites

I'll also add some predefined commands that the user can use to, for example, change screen color, delete page(s), copy page to page# and so on.

Share this post


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

Interesting... the command line reminds me a bit of Vim.

Funny you should mention. I am working on a VI like editor for Camel99 Forth TTY version.

It's harder than I thought it would be.

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites
Posted (edited)

I fought for 2 days on my command line keyboard entry point code! Today I completed that section. My problem was that key lift wasn't being recognized in my timing delay and was making me agitated to say the least. But the program would allow correct keys to be hit but I wanted a faster response time, as for example, hitting "one" "two" with one hand two fingers would only give me a "1"not a "12"

My auto-repeat worked flawless and it's funny because usually it's the auto repeat that is a bigger problem to take care of, that is why I was getting agitated. Lol

Example, if you pressed "1" and then pressed "2" slowly then the results would be ok.
Today I corrected that part with a compare of 0000 with >837C(status) and that enabled me to reset R12, my counter for auto repeat, to a zero. This reset would trick the counter and make it look like the repeat key was indeed a new key and that it could start a new repeat counter. Oh I'm Thrilled today!

 

Edited by GDMike
  • Like 3

Share this post


Link to post
Share on other sites

I'm stuck. I've got to compare two strings. One string is located at POSITION 921 of R0 (on the screen) with a length of less than 30 bytes but greater than 1.

The other string is predefined as a label with text that is 9 bytes in length, but could cart from one text length to another as there are multiple text statements I want to compare.

What's a good way to do this?

Could I include all my individual text into a data statement with it's length either on the first byte or last byte? 

 

 

Share this post


Link to post
Share on other sites
34 minutes ago, GDMike said:

I'm stuck. I've got to compare two strings. One string is located at POSITION 921 of R0 (on the screen) with a length of less than 30 bytes but greater than 1.

The other string is predefined as a label with text that is 9 bytes in length, but could cart from one text length to another as there are multiple text statements I want to compare.

What's a good way to do this?

Could I include all my individual text into a data statement with it's length either on the first byte or last byte? 

 

 

Ahh..I think I figured it out here, I pushed my predefined text to pos R0 of 960, off screen. And compared byte for byte for a eq or NE. 

It'll work, but I think there's a smarter way.

 

Share this post


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

located at POSITION 921 of R0

 

2 hours ago, GDMike said:

text to pos R0 of 960

 

????? :?

 

...lee

Share this post


Link to post
Share on other sites

I suppose byte-by-byte or word-by-word are the ways to go in assembly. My first thought would be to move the string from VDP into CPU RAM and compare from there. I suppose VSBR could be used if there isn't a lot of CPU RAM to spare.

 

There are only so many ways to compare within the STATUS REGISTER. In real life there are more, and so need to be broken down into different sets of steps. For instance, finding an exact one-to-one match, might work differently than finding a sub-string.:ponder:

Share this post


Link to post
Share on other sites
1 hour ago, HOME AUTOMATION said:

I suppose byte-by-byte or word-by-word are the ways to go in assembly. My first thought would be to move the string from VDP into CPU RAM and compare from there. I suppose VSBR could be used if there isn't a lot of CPU RAM to spare.

 

There are only so many ways to compare within the STATUS REGISTER. In real life there are more, and so need to be broken down into different sets of steps. For instance, finding an exact one-to-one match, might work differently than finding a sub-string.:ponder:

I guess I was tired when I wrote that, work drunk, anyway, I tried to edit and clarify but couldn't.

Yes, I finally figured that I could move my text I want to compare against into ram. I was struggling to figure out an address for my text. But after about 10 mins of hitting the pillow, the thought occurred to just stuff it into ram and do a byte by byte comparison. Duh.. sorry, Lee picked up on my crazy question with, huh. 

I tried to delete it. 

I'm cooking now. My so called, simple compare works fine.

Share this post


Link to post
Share on other sites

Update on SNP:
(The video demonstrates I'm reading the word call beep from a memory location and pushing it to the screen(test location only). I first want to see if it indeed does read it correctly so that's why I'm displaying it. Reason: because if the user types this word I then look into memory of the words in my library to compare to. This test is successful).
 I've added a command line by pressing F5 along with a command library of 1 item.
The list of words that isn't complete, but it'll probably be something like call screen(#) and delete page(#), copy page(#,#) a utility for copying from page to page etc ... and other commands.
My biggest NEED for creating it, was I need a place to call DSR text, like SAVE DSK#.filename
Or OLD DSK#.filename..
I'm hoping to include DIR DSK# and DEL DSK#.filename also.  So far I was making progress until our house AC heatpump compressor locked up, but after I ran out of words showing my displeasure the dog pees on my new carpet.

Share this post


Link to post
Share on other sites
Posted (edited)

Update on SNP:
(The video demonstrates I'm reading the command "call beep" from a memory location and pushing it to the screen(test location only). I first want to see if it indeed does read it correctly so that's why I'm displaying it. Reason: because if the user types this word I then look into memory of the words in my library to compare to. This test is successful).
 I've added a command line by pressing F5 along with a command library of 1 item.
The list of words that isn't complete, but it'll probably be something like call screen(#) and delete page(#), copy page(#,#) a utility for copying from page to page etc ... and other commands.
My biggest NEED for creating it, was I need a place to call DSR text, like SAVE DSK#.filename
Or OLD DSK#.filename..
I'm hoping to include DIR DSK# and DEL DSK#.filename also.  So far I was making progress until our house AC heatpump compressor locked up, but after I ran out of words showing my displeasure the dog pees on my new carpet.

Edited by GDMike
  • Like 1

Share this post


Link to post
Share on other sites

Yes, I did attach the famous"HONK" sound to the error message. 

I couldn't resist. 

M!kE

Share this post


Link to post
Share on other sites
On 5/17/2020 at 2:40 PM, Lee Stewart said:

 

 

????? :?

 

...lee

What I meant was, I am placing my library words, "CALL BEEP" for example at location 961 which is just off screen. This was how I could then move it to a ram address for permanent operation later. Anyway, it works. I don't know what information is sitting at vdp ram 960-1000 but I've been moving stuff in and out of it like a type of scratchpad. So far my program hasn't gone haywire.

Share this post


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

What I meant was, I am placing my library words, "CALL BEEP" for example at location 961 which is just off screen. This was how I could then move it to a ram address for permanent operation later. Anyway, it works. I don't know what information is sitting at vdp ram 960-1000 but I've been moving stuff in and out of it like a type of scratchpad. So far my program hasn't gone haywire.

 

Interesting—and I understand where the screen is usually located in Graphics Text mode, but, to TMS9900 Assembly Language programmers, R0 is a register, so its use here needs to be explained if you expect the reader (me) to understand what you are talking about.

 

...lee

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)
19 minutes ago, Lee Stewart said:

 

Interesting—and I understand where the screen is usually located in Graphics mode, but, to TMS9900 Assembly Language programmers, R0 is a register, so its use here needs to be explained if you expect the reader (me) to understand what you are talking about.

 

...lee

R0 is my pointer to my screen location.

I've set it to look like this LI R0,960

Then I can stuff my 16 characters that define my "CALL BEEP" or whatever text is defined as LIBW# keeping it  = or <16 characters.

("stuff" meaning

LI R0,960

LI R1,LIBW1L

LI R2,16 then BLWP @VMBW).

 

I've made this, the 25th row,  a temp Area so I can further read this and MOV it to ram address >FFE0 which increments 16 bytes in order to setup the next LIBW# of my library of words. 

But regardless of that last bit, I'm encroaching on something, not sure what, but writing my data below that 24th row might not be wise. I'm just grabbing 16 bytes from it.

Oh, btw. I'm using text mode.

 

 

 

 

Edited by GDMike
  • Thanks 1

Share this post


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

I'm encroaching on something, not sure what, but writing my data below that 24th row might not be wise. I'm just grabbing 16 bytes from it.

 

The VDP Rollout Area is located there. It is 32 bytes, but I think it is only used by the console’s transcendental floating point (FP) math functions, which you are probably not using. The 128 bytes following the Rollout Area is the Value Stack used by most all of the console’s FP math functions. I am not sure anything else uses the Value Stack, so I am not sure what you might be stepping on there. By the way, you can move the Value Stack by changing >836E to point somewhere else in VRAM more convenient for you.

 

Where in VRAM are you putting your PABs for file I/O or are you not there, yet?

 

...lee

  • Like 1

Share this post


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

Where in VRAM are you putting your PABs for file I/O or are you not there,

I'm not there yet. I've got some studying to do, as Home automation has sent me a study packet regarding, "everything I wanted to know about PAB" regarding my use of that"roll out" area you talk about:

I'm only using 39 bytes of that"roll out" area, and I'm not using any of the fp at all that I know of, unless by way of a util function might, as I wouldn't know, but I'm happily working and my program seems ok. 

Ha, which leads me to laugh because I did a "beep" command, it's basically the data >0034 or 36 with a call to gpllnk prior, and it only beeped at me after pressing a key, but my key routine was way after my call to the beep. Then I remembered,

"Lee said something about interrupts being enabled for any sound generated" in an earlier post, and I assumed that was why the beep, call from gpllnk, worked after hitting my kscan as I have a limi 2,0 there, and so I went looking for you're remark, can't remember where it is now, but it definitely reminded me. And of course putting that interrupt level right there in my call beep fixed that little issue.

See.. good docs helps my memory issue!

 

 

  • Haha 2

Share this post


Link to post
Share on other sites
Posted (edited)

Hmm maybe most was addressing, I haven't gone through the extensive material yet. I can't wait though really and seriously! 

I just gotta get through this user text input to my library stuffed in memory compare routine then I'll be sooo ready.

I think this will be done by next week, so maybe next weekend will be PAB DSRLNK weekend.

 

Edited by GDMike

Share this post


Link to post
Share on other sites
Posted (edited)

My second library element works, "CALL HONK"

Now I'm working on adding the third.

The third through ?? , I'm not sure yet how many, but these are "CALL COLOR(#)" so I'm not sure how many I can get that still make the screen readable.

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...