Supernotes

[GDMike]

Finally! Sorry it took so long, but yes, I've finally been able to create a file with my test program, DSRS today. The user file will be a display fixed 120 - but that is not in concrete yet. It's all still early in my progress.  Look, a turtle just passed me

 

[GDMike]

I'm just reiterating here, that after importing to SNP through classic 99, pressing F9 will get your cursor back.

And I'm finally making progress on our file SAVE routine, a little at a time.

Edited January 24, 2021 by GDMike

[Tursi]

Why do you need some special code to "import" through Classic99 - what's actually happening there?

 

I try to discourage any software specifically written to support Classic99 idiosyncrasies, since I may change them without warning. 

 

[GDMike]

let me look at the code..I can't remember what I did... ?

 

 

Edited January 24, 2021 by GDMike

[GDMike]

Ahh. It's really all about how I'm entering text via keyboard in SNP, I run certain keys pressed through a routine first before I display it. And I handle the character 13 different too, so it's on my side.

I'm not just doing a kscan / display in SNP because other things run within the GETKEY (my routine for checking key press),

Now, my adjustment to that IS a simple KSCAN / DISPLAY while handling EOPage.

I can't go past 960 so I restrict before overflow to top of screen.

It's a simple thang.

Edited January 24, 2021 by GDMike

[GDMike]

I've bypassed the SAMs init in this version for my programming comfort as It's a wip.

 

SNP

Edited January 24, 2021 by GDMike

[GDMike]

I could probably look for another way to DETECT if a user wants to paste text in from the clipboard I suppose, but I don't know off hand what that would look like. But if I had that I wouldn't need the"pause" menu, for import and it would be seamless. Maybe in the future I'll make some adjustments, for now I'm working on dsrlnk and getting that.

I've got 4K left to code with and it's pretty much done.

Edited January 24, 2021 by GDMike

[GDMike]

Congratulations to me!

I just created my first ever, user created file on a tipi path.

Filename can now be defined by the user.

It hasn't been easy getting to understand dsrlnk, but I've been working through it. I know you guys are banging your heads about now on the table, because you've gone over this, but reading text and trying to understand what's trying to be told isn't ideal. But I do appreciate the attempt to get it through my brain.

So far, though l, I've only seen one example that helped me, and that was when lee described in a word or two, it's the PAB Address, dummy!!

Ok, got it lee. Lol

Video to follow.

Edited January 24, 2021 by GDMike

[GDMike]

Ok, celebrating early, but I'm still thrilled I got this far. But when trying to save to a deeper directory, I got an error.

My path is DSK3.BASIC.FILENAME

Digging into why..

I can save to any of the tipi drives, 1,2,3,4 but not to a deeper directory.

Hmmm

 

Edited January 24, 2021 by GDMike

[GDMike]

Seems that my PAB Address doesn't like the"." Period seperator.

Weird, I can create a file with the name I choose on disk 1-4 but not to a deeper directory, even though it's a valid path.

Edited January 24, 2021 by GDMike

[GDMike]

Ok. I figured out what is going on.

My R2 contains the length of the path.

But when I go to write the file, it subtracts the length of the directory name and only provides an R2 value that isn't enough to cover the full filename.

I am able to write the file out to the directory of my choice now, but my filename is being chopped.

Edit

... and something else is going on I haven't found

Edited January 24, 2021 by GDMike

[Tursi]

8 hours ago, GDMike said:

Ahh. It's really all about how I'm entering text via keyboard in SNP, I run certain keys pressed through a routine first before I display it. And I handle the character 13 different too, so it's on my side.

I'm not just doing a kscan / display in SNP because other things run within the GETKEY (my routine for checking key press),

Now, my adjustment to that IS a simple KSCAN / DISPLAY while handling EOPage.

I can't go past 960 so I restrict before overflow to top of screen.

It's a simple thang.

I think I understand... so it's not a Classic99 bug, it's just bypassing some of your extra processing...

 

[GDMike]

Right. It's all on my weeding through certain keys and spending extra processing time for those.

Haha..at first I was blaming you for all my trouble, even that time in elementary school in the lunchroom, but then I realized, your not old like me, and that couldn't of been you in the lunchroom that day! BwhahahBwhahah

 

 

 

whoa, this is my own doing.

Thx for checking.

Edited January 24, 2021 by GDMike

[GDMike]

Ok, I found what I hope will help.

Byte 9: Name length:
* Length of the file descriptor following the PAB
Byte 10+: File descriptor:
* device name and, if required, the filename and options.
* the length of this descriptor is given in 9.

Edited January 24, 2021 by GDMike

[GDMike]

Byte 10, file descriptor, device name and, if required,a filename or options?

This is confusing. So where are the options discussed?

 

 

 

[+Lee Stewart]

1 hour ago, GDMike said:

Now, I'm able to create a new file but I'm not able to make the filename larger than 10 characters, including DSK#. what would a PAB look like for a 25 character filename? What role does the value in MSB of byte 9 play because I know LSB of byte 9 controls the filename length.

 

is that what I'm missing? Because I'm using 0 in my MSB of byte 9        thx

 

Byte 9 of the PAB is only 1 byte. It does not have a Most Significant Byte (MSB) or a Least Significant Byte (LSB). I use those terms for 2-byte words such as what TMS9900 registers and your COUNT variable happen to be. Your COUNT certainly has an MSB and an LSB because you have stored the pathname length there—probably with MOV. That is why I used MOVB to copy 1 byte from COUNT’s LSB, which address is COUNT+1 to PAB+9. There was never any need to set COUNT’s MSB to 0—it should have been 0 by the MOV.

 

The contents of the PAB for a file named “MYTI99FILE” on a disk named “MYTI99DISK” that you plan to reference by the disk name (DSK.MYTI99DISK) rather than a disk number (DSK1) would have a pathname of “DSK.MYTI99DISK.MYTI99FILE” preceded by its length (25):

PAB byte: 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34
---------------------------------------------------------------------------------------
PAB HEX:  19 44 53 4B 2E 4D 59 54 49 39 39 44 49 53 4B 2E 4D 59 54 49 39 39 46 49 4C 45
ASCII:    --  D  S  K  .  M  Y  T  I  9  9  D  I  S  K  .  M  Y  T  I  9  9  F  I  L  E

Were you to refer to the file as “DSK1.MYTI99FILE” instead, the PAB would be

PAB byte: 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
---------------------------------------------------------
PAB HEX:  0F 44 53 4B 31 2E 4D 59 54 49 39 39 46 49 4C 45
ASCII:    --  D  S  K  1  .  M  Y  T  I  9  9  F  I  L  E

...lee

[+Lee Stewart]

9 minutes ago, GDMike said:

Byte 10, file descriptor, device name and, if required,a filename or options?

This is confusing. So where are the options discussed?

 

This refers to how the options for the RS232 card are put in the PAB.

 

...lee

[GDMike]

39 minutes ago, Lee Stewart said:

Byte 9 of the PAB is only 1 byte

Ahh. So I'm supposed to be asking, what is byte 8 for? 

[+Lee Stewart]

26 minutes ago, GDMike said:

Ahh. So I'm supposed to be asking, what is byte 8 for? 

 

???  You should not be messing with the PAB’s byte 8 except to read it after calling DSRLNK with the STATUS opcode (PAB byte 0 = 9 ).

 

...lee

[GDMike]

1 minute ago, Lee Stewart said:

 

???  You should not be messing with the PAB’s byte 8. That is the status byte for the STATUS opcode (PAB byte 0 = 9 ).

 

...lee

No I'm not changing it, I just wanted to know what it did. Cool

[+TheBF]

1 hour ago, GDMike said:

Byte 10, file descriptor, device name and, if required,a filename or options?

This is confusing. So where are the options discussed?

 

 

 

I find it helpful to think of PAB byte 9 and onward as simply a byte counted string. Just like you would see in Forth or Pascal.  

 

1st byte is length, then a string of characters.

But... it lives in VDP RAM.

 

TI-99 DSR wants that string to be DSK1.MYFILE or PIO  or  RS232  

Like that.

 

[GDMike]

It's hard to explain to you what's going on by simply texting.

Here I've included a file, called FILEM

And I run to this program after I've already typed on the screen the file name that I want to save the file as for example, "DSK3.FILENAME"

but when I key in the file name, it creates a file on my disk 3 fine if it's a 4-5 character filename.

but the file name is short for longer names I created. it's like five characters long it's not the complete six characters or eight characters or ten characters if a filename I create. even after I put in byte 9 of my pab an >0A.

 

This program expects on screen(40 col mode)

position 929,  "3.filename" without parentheses.

 

 

 

FILEM

Edited January 25, 2021 by GDMike
Update file. Use this

[GDMike]

I updated the file, use this new one I just updated #601 with.

There basically the same file, there's just some leftover stuff I removed, but the file acts just like the other file, so basically same files.

Edited January 25, 2021 by GDMike

[GDMike]

31 minutes ago, TheBF said:

I find it helpful to think of PAB byte 9 and onward as simply a byte counted string. Just like you would see in Forth or Pascal.  

 

1st byte is length, then a string of characters.

But... it lives in VDP RAM.

 

TI-99 DSR wants that string to be DSK1.MYFILE or PIO  or  RS232  

Like that.

 

Yes. I got that. Lol

But I'm wondering what is wrong with my adding >0A to my byte 09 of my PAB when I'm still only creating a 5 character or less filename after entering a 10 character name? As in this file.

Edited January 25, 2021 by GDMike

[GDMike]

Hahaha... i just created an 8 character filename by using>D in byte 9, maybe I'm about to get it.

Edited January 25, 2021 by GDMike