DSRLINK Code Tutorial

[GDMike]

But I don't seem to be getting past setting up the pab.

I have, like I mentioned earlier.

FLNM BSS 48 - and it's located right after the FSPAB definition.

And somewhere, not sure if it matters where I put this, either before or after the pab setup, but I have.

 

PBAD EQU >79E

Apparently it makes a difference on where the pab is in relation to its counter parts when defining, at least when defining the filename.

 

 

 

Edited November 3, 2020 by GDMike

[+Lee Stewart]

22 minutes ago, GDMike said:

But I don't seem to be getting past setting up the pab.

I have, like I mentioned earlier.

FLNM BSS 48 - and it's located right after the FSPAB definition.

And somewhere, not sure if it matters where I put this, either before or after the pab setup, but I have.

 

PBAD EQU >79E

Apparently it makes a difference on where the pab is in relation to its counter parts when defining, at least when defining the filename.

 

The filename (pathname) is part of the PAB and, wherever you store it temporarily in CRAM, it must be located in VRAM with its tenth byte (byte 9) containing the filename length byte followed immediately by said filename from byte 10 on. DSRLNK and the DSR do not care how you have set up CRAM excepting for the pointer at >8356.

 

...lee

[GDMike]

BUT I thought, and I keep confusing, byte 9 of FSPAB here but I made that value a higher value to cover the path size.

So I made it >30 and the filename followed it as a FLNM BSS 48

And I think I was told it's wrong.

So I'm not getting anywhere

 

Edited November 3, 2020 by GDMike

[+Lee Stewart]

Just now, GDMike said:

BUT I thought, and I keep confusing, byte 9 of FSPAB here, but I made that value a higher value to cover the path size.

So I made it >30 and the filename followed it as a FLNM BSS 48

And I think I was told it's wrong.

So I'm not getting anywhere

 

 

Byte 9 is NOT the value 9 it is the location in the PAB of where you must put the filename’s length. If the full “filename” is DSK2.ABCDEFGHIJ, byte 9 must contain the value 15 because that is how long the filename is.

 

...lee

[GDMike]

1 minute ago, Lee Stewart said:

 

Byte 9 is NOT the value 9 it is the location in the PAB of where you must put the filename’s length. If the full “filename” is DSK2.ABCDEFGHIJ, byte 9 must contain the value 15 because that is how long the filename is.

 

...lee

Yes, I understand. But here I have a case where I don't know the length.

[GDMike]

Just now, GDMike said:

Yes, I understand. But here I have a case where I don't know the length.

so I thought it should equal the number I have in my BSS statement following the FSPAB.

[+Lee Stewart]

10 minutes ago, GDMike said:

Yes, I understand. But here I have a case where I don't know the length.

 

9 minutes ago, GDMike said:

so I thought it should equal the number I have in my BSS statement following the FSPAB.

 

 You must reserve enough space for your PAB in VRAM, but, you do not need to copy the reserved length of bytes to the PAB. You just need to copy the actual counted string for the actual file before you call DSRLNK—and, you cannot call DSRLNK without knowing the length of the filename of the file you want to open/create.

 

...lee

[GDMike]

1 minute ago, Lee Stewart said:

 

 

 

  You must reserve enough space for your PAB in VRAM, but, you do not need to copy the reserved length of bytes to the PAB. You just need to copy the actual counted string for the actual file before you call DSRLNK.

 

...lee

So I take it that the  byte 9 should be >09

No matter. 

And then..

"You just need to copy the actual counted string for the actual file before you call to DSRLNK.

If this is true. I've got it!

[GDMike]

So after the PAB is defined, what should be defined next in my code..

The filename or the count.

Sorry but this is gotta be understood.

Better yet, can you give me an example of a pab with no defined filename. This way I can see what byte 9 looks like and what follows the pab.

Lol ?

Edited November 3, 2020 by GDMike

[+Lee Stewart]

2 minutes ago, GDMike said:

So I take it that the  byte 9 should be >09

No matter. 

And then..

"You just need to copy the actual counted string for the actual file before you call to DSRLNK.

If this is true. I've got it!

 

No—The only reason byte 9 should be >09 is if the filename has that many bytes. DSK1.MYFILE001 has 14 characters. You would store >0E.

 

...lee

[GDMike]

Just now, Lee Stewart said:

 

No—The only reason byte 9 should be >09 is if the filename has that many bytes. DSK1.MYFILE001 has 14 characters. You would store >0E.

 

...lee

Oh..I thought your silence was saying my >30 in byte 9 was wrong.

So I'm assuming there's nothing wrong with my PAB and it's following information.

Ok

[+TheBF]

I might be making things worse but to make things clearer you could consider laying out your CPU RAM image of the PAB so that it is easy to remember what is what.

Use the CPU PAB as a mirror image of the VDP PAB. Use the mirror for all control and copy it into VDP RAM before calling dsrlink.

 

For I notice that your CPU PAB does not make it clear where the filename text goes (at least to me) and how much space is allocated for the text.

SBUFF  EQU  >1000             * BUFFER ADDRESS
SBUFF1 EQU  >1FE4             * PADDED WITH 28 SPACES
VDPPAB EQU  >79E              * PAB ADDRESS
*********************************************************
* PAB DATA STRUCTURE MIRROR IN CPU RAM
CPUPAB                     * used for writing entire CPUPAB to VDPPAB
POPCOD BYTE 00             * error bits & op code
PFLAG  BYTE 02             * status flag field
PBUFF  DATA SBUFF          * pointer to  VDP file buffer
PLEN   BYTE >80            * record length for fixed length records
PCHARS BYTE >00            * no. bytes to write or no. bytes read from file
PRECRD DATA 0000           * relative files record number to read/write
OFFSET BYTE 00             * cassette use only
FNAML  BYTE 09             * filename length
FNAME  BSS  32             * extra room for long device strings
********************************************************

 

The idea is you now have each field of the PAB available as a named label.

Each field is there to get at it by name.

 

When the CPU PAB image is all set the way you want you blast the whole thing over to VDP RAM with a VMBW and call DSRLINK.

 

To get the results READ the VDP back into your CPU RAM mirror PAB and you can check status for example.

 

You can also create lists of opcodes to make it clearer when you are using the PAB to read,write, rewind etc.

* FILE OPERATION CODES 
FOPEN  	BYTE 00
FCLOSE 	BYTE 01
FREAD  	BYTE 02
FWRITE 	BYTE 03
FRWIND 	BYTE 04
FLOAD  	BYTE 05
FSAVE  	BYTE 06
FDELET 	BYTE 07 


* EXAMPLE
		MOVB @FOPEN,@POPCOD
        
 		

This kind of thing helps my old brain remember what is going where.

[+Lee Stewart]

5 minutes ago, GDMike said:

Better yet, can you give me an example of a pab with no defined filename

 

You can do whatever you want to the PAB before you call DSRLNK. There is no magic happening when you copy stuff to the PAB location. It just needs to have all of the proper information WHEN you call DSRLNK.

 

...lee

[GDMike]

 

FSPAB  DATA >0012,SBUFF,>8000,>0000,>0030
*             OP DV     128
FLNM   BSS  48

Edited November 3, 2020 by GDMike

[GDMike]

7 minutes ago, TheBF said:

I might be making things worse but to make things clearer you could consider laying out your CPU RAM image of the PAB so that it is easy to remember what is what.

Use the CPU PAB as a mirror image of the VDP PAB. Use the mirror for all control and copy it into VDP RAM before calling dsrlink.

 

For I notice that your CPU PAB does not make it clear where the filename text goes (at least to me) and how much space is allocated for the text.

SBUFF  EQU  >1000             * BUFFER ADDRESS
SBUFF1 EQU  >1FE4             * PADDED WITH 28 SPACES
VDPPAB EQU  >79E              * PAB ADDRESS
*********************************************************
* PAB DATA STRUCTURE MIRROR IN CPU RAM
CPUPAB                     * used for writing entire CPUPAB to VDPPAB
POPCOD BYTE 00             * error bits & op code
PFLAG  BYTE 02             * status flag field
PBUFF  DATA SBUFF          * pointer to  VDP file buffer
PLEN   BYTE >80            * record length for fixed length records
PCHARS BYTE >00            * no. bytes to write or no. bytes read from file
PRECRD DATA 0000           * relative files record number to read/write
OFFSET BYTE 00             * cassette use only
FNAML  BYTE 09             * filename length
FNAME  BSS  32             * extra room for long device strings
********************************************************

 

The idea is you now have each field of the PAB available as a named label.

Each field is there to get at it by name.

 

When the CPU PAB image is all set the way you want you blast the whole thing over to VDP RAM with a VMBW and call DSRLINK.

 

To get the results READ the VDP back into your CPU RAM mirror PAB and you can check status for example.

 

You can also create lists of opcodes to make it clearer when you are using the PAB to read,write, rewind etc.

* FILE OPERATION CODES 
FOPEN  	BYTE 00
FCLOSE 	BYTE 01
FREAD  	BYTE 02
FWRITE 	BYTE 03
FRWIND 	BYTE 04
FLOAD  	BYTE 05
FSAVE  	BYTE 06
FDELET 	BYTE 07 


* EXAMPLE
		MOVB @FOPEN,@POPCOD
        
 		

This kind of thing helps my old brain remember what is going where.

Yup. I've got this understood already too.

I'm just trying to figure out my pab before I send it to vram.

I have COUNT that contains the length of the file name.

And I have FLNM that contains the actual file name with the DSK#. In front.

[GDMike]

If I set byte nine of the PAB to hex 30 wouldn't that cover any size of my file name that I come across under or equal to 48 bytes as in if the actual file name was really 10 bytes long can't my Pab still function correctly with the > 30 number in byte nine?

Edited November 3, 2020 by GDMike

[+Lee Stewart]

9 minutes ago, GDMike said:

If I set byte nine of the PAB to hex 30 wouldn't that cover any size of my file name that I come across under or equal to 48 bytes as in if the actual file name was really 10 bytes long can't my Pab still function correctly with the > 30 number in byte nine?

NO, NO, NO.  DSRLNK must have the correct file length at the time you call it. You cannot anticipate it except to reserve the space. That number is not a reservation. It is information you are handing off to DSRLNK about the file you hope to open/create, or whatever operation you intend.

 

...lee

Edited November 3, 2020 by Lee Stewart

[GDMike]

Ahahhaa!

Exactly.

Okay now we're getting somewhere.

So I might as well set PAB byte 9 to 10

And use DSK1.file1 for FLNM in a TEXT like.

       TEXT 'DSK1.FILE1

 And now, the question becomes how do I plug in the new file name and the new file length prior to calling DSR link?

When FLNM contains "DSK5.FRUIT.APPLES"

And

COUNT contains 17?

Edited November 3, 2020 by GDMike

[+Lee Stewart]

2 minutes ago, GDMike said:

Ahahhaa!

Exactly.

Okay now we're getting somewhere.

So I might as well set PAB byte 9 to 10

And use DSK1.file1 for FLNM in a TEXT like.

       TEXT 'DSK1.FILE1

 And now, the question becomes how do I plug in the new file name and the new file length prior to calling DSR link?

When FLNM contains "DSK5.FRUIT.APPLES"

And

COUNT contains 17?

       LI   R0,VDPPAB+9
       LI   R1,COUNT
       BLWP @VSBW

       LI   R0,VDPPAB+10
       LI   R1,FLNM
       CLR  R2
       MOVB @COUNT,R2
       SWPB R2            count byte to LSB
       BLWP @VMBW

 

...lee

[+Lee Stewart]

Gotta run. I will check in later.

 

...lee

[GDMike]

Thank you!

This is what I was missing for some reason. Thank you for spending the time ? and bearing with me.

 

[GDMike]

1 hour ago, TheBF said:

* PAB DATA STRUCTURE MIRROR IN CPU RAM

I wrote my code already that pushes my pages to >1000 vram, then I found out later that I can only put as much as I need in a record, meaning my 1028 bytes I put in it, I can't use. So I'll rewrite that portion tommorow, putting only 128 bytes before moving in another 128 for the next record.

Well, that's part of learning.

I do have an understanding of that.

Shhooooo.

Thanks for the help.

[+TheBF]

45 minutes ago, GDMike said:

I wrote my code already that pushes my pages to >1000 vram, then I found out later that I can only put as much as I need in a record, meaning my 1028 bytes I put in it, I can't use. So I'll rewrite that portion tommorow, putting only 128 bytes before moving in another 128 for the next record.

Well, that's part of learning.

I do have an understanding of that.

Shhooooo.

Thanks for the help.

Yes the file system is record based, not memory block based   

(Well... except for programs using the LOAD/SAVE commands . They can do 8K blocks at a time but that's not typically for data)

 

So if you use DV80 files you can only read 80 bytes max at a time.

You literally read the file one line at a time for DV80 files. Each time you do a read command a new line appears in the VDP buffer and the number of chars read appear in what I called the PCHARS field as a byte.

 

For fixed files you read 1 fixed size record at a time.

So your VDP buffer does not need to be bigger than 128 bytes.

 

[GDMike]

Well I should have working code tommorow then.

I'll be back on my SNP posting.

 

Thx ❣️ all

[apersson850]

8 hours ago, GDMike said:

Yup. I've got this understood already too.

I'm just trying to figure out my pab before I send it to vram.

I have COUNT that contains the length of the file name.

And I have FLNM that contains the actual file name with the DSK#. In front.

No, you have not understood. Look in your code. Your COUNT (which, to add to the confusion, you somtimes call COUNTP) is outside the PAB.

First you had this definition

PAB Data statements

Count

Filename

 

Then you went to this definition

PAB Data statements

Filename

Count

 

Both of these are wrong. The COUNT is a part of the PAB data, not something hanging after it.

I showed you how to define the PAB several posts ago, and now TheBF has done it again, to get it right. In his definition, FNAML is equivalent to what you call COUNT/COUNTP.