DSRLINK Code Tutorial

[+mizapf]

Interestingly, BSS is a widely-known concept for object code: https://en.wikipedia.org/wiki/.bss

 

[GDMike]

41 minutes ago, mizapf said:

Interestingly, BSS is a widely-known concept for object code: https://en.wikipedia.org/wiki/.bss

 

BSS (from Block Started by Symbol) is a pseudo-operation in UA-SAP (United Aircraft Symbolic Assembly Program)

say WHAT?

 

[GDMike]

I finished out coding MY DSR just like the DSR routine just as its described in pages 84,85 of introduction to A.L. Book.

with the error handling.

now, im back to the STATEMENT following the first DSR Call as listed in prev post.

 

[GDMike]

* DO THE WRITE!
 
       LI   R0,PBAD
       LI   R1,FSPAB
       LI   R2,20
       BLWP @VMBW
       BL   @DSR
       MOVB @READ,R1     * SET TO OPEN!
       LI   R0,PBAD
       BLWP @VSBW
       CLR  R4           * RECORD COUNTER
 
READF

ok, so NOW at this point, im ready to write the READF structure

this is where things get hairy.

im totally LOST now. 

Somehow, i need to get my 4 SAMS pages buffered into VRAM from CRAM.

 

My PAGES of DATA are stored at SNPS1,SNPS2,SNPS3 and SNPS4 and each of those are 1000 bytes of data exactly .

(and to change out those 4 pages with the NEXT bank, I set bank to 2 and so on until bank =240

and of course increment my SAMs page).

What would be my next move to do or to think about here, as I ponder READF?

 

 

[apersson850]

2 hours ago, GDMike said:

Like this.

FSPAB EQU >79E

And, correct. I'm using TEXT mode.

 

********************  code

* DO THE WRITE!
 
       LI   R0,PBAD
       LI   R1,FSPAB
       LI   R2,20   Your PAB is longer than 20 bytes. 10 bytes for the first DATA statements, one byte for the count and 16 for the filename. If you want to fill in the file name later, then you only need to transfer 10 bytes here.
       BLWP @VMBW

 

If you intend to save data in a file, you must also have the buffer prepared here. Plus you have to run through this section X times, replacing buffer data and updating the PAB each time, if you want to save more than one record. Which seems likely in your case, as a record is only 128 bytes.

IM SUPPOSED TO DO A BL @ DSR FROM HERE   Normally you call it DSRLNK, since it will establish a link to the DSR, which actually does the work.
   WHICH I NEED TO CREATE.          Due to the DSRLNK's rather complex task, the call is usually via BLWP, not BL, to give the DSRLNK a workspace of its own, more or less.

 

Now if you instead are reading text from a file, you need to move the read record from the buffer here, advance the record pointer, send the new PAB to VDP RAM (at least what changed in it) and do it again, until you reach the end of the file or have read a desired number of records.

 

SBUFF  EQU  >1000             * BUFFER ADDRESS
PBAD   EQU  >79E              * PAB ADDRESS
FSPAB  DATA >0012,SBUFF,>8000,>0000,>0000   Here you have 10 bytes
*             OP DV     128
COUNT  BYTE 0     Here is one byte. You are now on an odd boundary. But this is wrong, since this is the file name character count. It should be in PAB+9, but this will place it in PAB+10.
FLNM   BSS  16     Here is 16 bytes. You're still on an odd boundary
STATUS EQU  >837C
POINT  EQU  >8356
READP  BYTE >02     Here is one byte. You're even.
CLOSEP BYTE >01    Here is one more byte, and you're odd again.

      EVEN
EOFP   DATA 0     Here you define a word, which must be on an even boundary. To make sure the word is correctly allocated, and that the label EOFP actually points to it, not one byte before it, using the EVEN directive to realign to a word boundary is recommended.
ERRM   TEXT '* I/O ERROR * '     This text string has 14 characters, so it will stay on a word boundary. But adding EVEN after it implies that even if you modify the text later, you are still certain the next thing starts on an even address.
CPUBF  BSS  80
LENP   BSS  2   Which is equivalent to saying DATA 0 instead of BSS 2. But DATA allows you do to a DATA COUNT, for example, if you want the value of the COUNT label stored here already when the program is loaded into memory.

Having space for 16 characters in a file name makes no sense, since a valid file name on a disk is up to 25 bytes long. Like DSK.DISKNAMEIS.FILENAMEIS

Placing the new PAB 50 bytes before the previous one doesn't make sense either, if it's only 27 bytes long. What are you going to do with the 23 bytes in between? They aren't enough for a buffer anyway.

I would recommend allocating the PAB with mixed BYTE and DATA directives, matching the actual use of the data. That makes the program easier to understand.

Edited October 29, 2020 by apersson850

[apersson850]

44 minutes ago, GDMike said:

* DO THE WRITE!
 
       LI   R0,PBAD
       LI   R1,FSPAB
       LI   R2,20
       BLWP @VMBW
       BL   @DSR
       MOVB @READ,R1     * SET TO OPEN!
       LI   R0,PBAD
       BLWP @VSBW
       CLR  R4           * RECORD COUNTER
 
READF

ok, so NOW at this point, im ready to write the READF structure

this is where things get hairy.

im totally LOST now. 

Somehow, i need to get my 4 SAMS pages buffered into VRAM from CRAM.

 

My PAGES of DATA are stored at SNPS1,SNPS2,SNPS3 and SNPS4 and each of those are 1000 bytes of data exactly .

(and to change out those 4 pages with the NEXT bank, I set bank to 2 and so on until bank =240

and of course increment my SAMs page).

What would be my next move to do or to think about here, as I ponder READF?

Since you load a READ command, you are going to read data from a file and place it in SAMS memory, not the other way around. Or you used the wrong command. If you want to store your SAMS pages in a file, you want to write.

Whichever, to store the data on disk, you have to read one record (128 bytes) from memory to VDP RAM buffer, do a write operation (call the DSR), increment the record counter in the PAB in VDP memory and do it again, until you've stored everything you want to store.

Since you, for some reason I don't know, have decided to have 1000 characters in a page, not 1024, but have chosen to use a record length of 128, which isn't an integer fraction of 1000, you have to deal with the mess that you have to move seven records 128 bytes long and one 104. Or in each record store 125 valid bytes and three garbage, then just don't care about the garbage. It's inefficient programming, whichever you do.

Edited October 29, 2020 by apersson850

[+9640News]

I pulled this individual file, FILESEARCH, from the AfterHours BBS source code I referenced earlier in one of our exchanges.  It reads in text from a DIS/VAR 80 file and looks for a string, and then goes onto another read.

 

What you do not know about the text file that it reads is there is one line of characters I believe every 4th line I do not evaluate as it is either "=====================", or some such individual breaks.  Either way, it shows open, reading, and all the VSBR and VMBW reads/writes that are necessary.

 

The entry into this program is at the label FILESEARCH.  The routine for the BLWP @ONECHR retrieves either a key from the keyboard or a keypress received from a TIPI socket.  I also indicated earlier you should really plan on a filename with a length of at least 40 characters as either the TIPI or Myarc HFDC support longer filenames and it is better to support that now, than modify things later.

 

 

 

 

FILESEARCH

[GDMike]

28 minutes ago, apersson850 said:

Since you load a READ

Sorry this is supposed to be a write., I was thinking that the value in read was 02 for writing and 01 for reading.

I have no clue why I placed a read here. Stupid.

I'll straighten this out., But I need some time to think about what's going on here, prior to this.

Edited October 29, 2020 by GDMike

[GDMike]

5 minutes ago, BeeryMiller said:

I pulled this individual file, FILESEARCH, from the AfterHours BBS source code I referenced earlier in one of our exchanges.  It reads in text from a DIS/VAR 80 file and looks for a string, and then goes onto another read.

 

What you do not know about the text file that it reads is there is one line of characters I believe every 4th line I do not evaluate as it is either "=====================", or some such individual breaks.  Either way, it shows open, reading, and all the VSBR and VMBW reads/writes that are necessary.

 

The entry into this program is at the label FILESEARCH.  The routine for the BLWP @ONECHR retrieves either a key from the keyboard or a keypress received from a TIPI socket.  I also indicated earlier you should really plan on a filename with a length of at least 40 characters as either the TIPI or Myarc HFDC support longer filenames and it is better to support that now, than modify things later.

 

 

 

 

FILESEARCH 8.63 kB · 1 download

Ok thank you for this. I'll review

[+9640News]

In the example above, the filename length above is fixed by design for the program to access specific directories on the TIPI, in this case, for a BBS.  So, I do not need to adjust the filename length each time I call the routines.  There is nothing wrong with writing a 60 byte PAB even when the filename because it may be very short is something as simple as DSK1.A with a filename length of >06h.  The extra characters will not be used in the DSR.

 

So, what I am saying is you do not need to count the full length of your PAB each time someone enters a different length filename for the VMBW write.  Just stick with something that is the maximum one would/could encounter, and stick with it.

 

Not sure if Matt is following this thread, but I do not know what the maximum filename length would be for the TIPI, and do not have the notes to know if the maximum filename length for the Myarc HFDC is either 40 characters (>28h) or 80 characters (>50h).  Anyone know???

 

Beery

[GDMike]

"So, what I am saying is you do not need to count the full length of your PAB each time someone enters a different length filename for the VMBW write.  Just stick with something that is the maximum one would/could encounter, and stick with it".

 

this is why i chose address 50 bytes seperation  from my previous PAB address.  do you mean, Beery, that I still need to squeeze my PAB addresses closer or am I good at this seperation?

 

TIPIPAB EQU >7D0 and PBAD EQU >79E

or is this NOT what you mean?

 

Edited October 29, 2020 by GDMike

[GDMike]

2 hours ago, apersson850 said:

  LI   R2,20   Your PAB is longer than 20 bytes. 10 bytes for the first DATA statements, one byte for the count and 16 for the filename. If you want to fill in the file name later, then you only need to transfer 10 bytes here.
       BLWP @VMBW

or is this what @BEERY is talking about? i have this information, its in COUNT.

and the FILENAME is in FLNM.

or can I simply do LI R2,COUNT+10

Edited October 29, 2020 by GDMike

[apersson850]

OK, that makes sense to allocate 50 bytes for PAB data plus the name. But the FLNM block is only 16, so that doesn't match, then. It's not futureproof in the same way.

Edited October 29, 2020 by apersson850

[GDMike]

1 minute ago, apersson850 said:

OK, that makes sense to allocate 50 bytes for PAB data plus the name. But the FLNM block is only 16, so that doesn't match, then. It's not futureproof in the same way.

and that was because everything says filenames are 10 in length. SO do i just make my FLNM BSS 50 or even 60?

[+9640News]

2 minutes ago, GDMike said:

or is this what @BEERY is talking about? i have this information, its in COUNT.

and the FILENAME is in FLNM.

 

Me personally, I would have made FILENAME or FLNM in the above example, longer at either 40 or 80 characters, whatever is the maximum length for a filename the Myarc HFDC and/or the TIPI can handle.  Then, the LI R2,20 would have been much longer to move the full PAB into VDP.  Whether that overlaps >07D0 from >079E, you would have to count.  Myself, unless VDP memory space / PAB buffers are tight, I would have established things at easier to see boundaries like >0800 and >0870'ish.  That is me though.  Remember, you are in assembly so you do not have the constraints of extended basic, mini memory, etc.

 

Beery

[GDMike]

OH, and I need to prepare the BUFFER PrIoR! to calling DSR..ahhhhh. makes sense to me now!

[apersson850]

Yes, when you save data you have to put it in the buffer, then call the DSR. If you read data, you have to call the DSR then handle the data it placed in the buffer for you.

And each time, you only move one record at a time (128 bytes in this case). So you need to do it many times if you have a lot of data on a SAMS card.

 

You're right in that a filename is often max 10 characters. Like ASMFILETXT or BASICGAME1. But to the system, that's just a partial file name. To actually locate the file BASICGAME1, you need the full file name, which could be DSK2.BASICGAME1. Or even DSK.GAMEDISK.BASICGAME1.

Edited October 29, 2020 by apersson850

[+9640News]

1 minute ago, GDMike said:

and that was because everything says filenames are 10 in length. SO do i just make my FLNM BSS 50 or even 60?

The actual filename itself is limited to 10 characters, but you are placing the full path to the file into that FLNM, so something like TIPI.EDITOR.CODE.PART1.SOURCE1-S is a valid filename with a length of 32 characters.  Now, on a TI, CD, or Myarc FDC you are limited to a length of DSK1.FILENAME12 for maximum length of 15 characters.  The Myarc HFDC allows a Subdirectory on floppies that can have a SUBDIRECTORY length of another 10 characters plus the period to bring it to 26 characters.  On the Myarc HFDC with a hard drive, that pathname length is either 40 or 80 characters maximum, not sure which though.

Beery

 

[GDMike]

1 minute ago, BeeryMiller said:

Me personally, I would have made FILENAME or FLNM in the above example, longer at either 40 or 80 characters, whatever is the maximum length for a filename the Myarc HFDC and/or the TIPI can handle.  Then, the LI R2,20 would have been much longer to move the full PAB into VDP.  Whether that overlaps >07D0 from >079E, you would have to count.  Myself, unless VDP memory space / PAB buffers are tight, I would have established things at easier to see boundaries like >0800 and >0870'ish.  That is me though.  Remember, you are in assembly so you do not have the constraints of extended basic, mini memory, etc.

 

Beery

Im trying NOT to step on my PATTERN TABLE, thats really all I care about I believe and my First PAB Clears it at >7D0. and I was trying to squeeze this in some place. none of this is hard coded, its just me trying to make it work

[apersson850]

That's good. Make a map of what you use, so you don't use one thing for multiple purposes at the same time.

[GDMike]

well, help me resolve what my FLNM length should be, so i can set it in stone, along with the PAB address:

Dont step on the LAST part of my Pattern Table, I use all of it. lol

you know, I ok with TI disk controller rules, i mean theres not many 80 col cards in use yet. I can change it, possible later. (meaning, the user needs space to type all that out..)

Edited October 29, 2020 by GDMike

[GDMike]

8 minutes ago, apersson850 said:

That's good. Make a map of what you use, so you don't use one thing for multiple purposes at the same time.

yes, i have a file, usually holds ALL my EQU and DATA,BSS statements, the FILE is called PREQ

and it details it there.

[GDMike]

Ill make the following changes: and thanks for the super help all yall!!

FLNM BSS 48

 

so what should my LI R2,nn NOW look like

or am I ok with LI R2,COUNT+10?

Edited October 29, 2020 by GDMike

[+mizapf]

7 minutes ago, GDMike said:

so what should my LI R2,nn NOW look like

or am I ok with LI R2,COUNT+10?

No. COUNT is the address of the location where you store the count, not the count itself. This is a typical issue with assembly language that you have to be aware of. You have to work with addresses and with values, and there is no data type to tell them apart.

 

Also, COUNT seems to refer to a byte address. Hence, you have to use MOVB to get it and then shift it into the low byte.

 

MOVB @COUNT,R2
SRL R2,8
AI R2,10

 

Edited October 29, 2020 by mizapf
Have to remove these empty lines in code again

[GDMike]

1 minute ago, mizapf said:

No. COUNT is the address of the location where you store the count, not the count itself. This is a typical issue with assembly language that you have to be aware of. You have to work with addresses and with values, and there is no data type to tell them apart.

 

Also, COUNT seems to refer to a byte address. Hence, you have to use MOVB to get it and then shift it into the low byte.

 

 

MOVB @COUNT,R2

SRL R2,8

AI R2,10

oh RIGHT! a gotcha waiting to happen!

got me!