dsrlnk Toward a Better (and Better-Documented) DSRLNK

[+TheBF]

55 minutes ago, Lee Stewart said:

Back to the DSRLNK subject of this thread...

 

For consistency, I am thinking that, even though my new PAB has an extra address pointer (PAB parameter block in CPU RAM) at its head, I should still put the name-length byte pointer (old PAB+9; new PAB+11) in >8356 instead of the pointer to the beginning of the new PAB as it currently stands—that is, after all, what gets passed to the DSR. It should then be no difficulty to modify DSRLNK to handle it. That would make one less conceptual change for the programmer. What do you think?

 

...lee

Yes. I think you are correct in keeping the programmer/system interface the same but letting your code do the improvements behind the scenes.

[Gary from OPA]

I going to look through my archives and publish separately soon my own special dsrlnk and utilities I wrote a while ago it has a lot of unique properties and makes management easier as well for assembly programmers. I also wrote a special scanner program that would take an existing program already released without source code and patch it to use the faster and better dsrlnk as well which helps add support to older programs.

[+Lee Stewart]

OK—Here is the current DSRLNK with the requirement that the programmer point SCNAME (>8356) to the PAB’s Device/Subprogram Name Length byte and more clarification in the comments:  DSRLNK_LES02.a99

 

Post #1 also contains the current DSRLNK routine and will be updated in the future, as well.

 

...lee

[+FarmerPotato]

7 hours ago, Lee Stewart said:

Back to the DSRLNK subject of this thread...

 

For consistency, I am thinking that, even though my new PAB has an extra address pointer (PAB parameter block in CPU RAM) at its head, I should still put the name-length byte pointer (old PAB+9; new PAB+11) in >8356 instead of the pointer to the beginning of the new PAB as it currently stands—that is, after all, what gets passed to the DSR. It should then be no difficulty to modify DSRLNK to handle it. That would make one less conceptual change for the programmer. What do you think?

 

...lee

Your new field is just relative to the pointer.   I too would continue to point at the name-length byte. 

 

 

It is typical for library code to hide fields below where the user will look.  For example, a heap. malloc(size) can return ptr, but stash 'size' at ptr-2. There might even be a linked list pointer down there...

 

Of course, the caller still needs to make the PAB bigger. 

 

[apersson850]

There are many ways...

The p-system uses something called a peripheral control block, PCB. It's a couple of data items followed by the normal PAB. The extra data stores information about the CRU base and entry address to use, since the p-system pre-scans the required DSR locations as boot time and remembers where they are, to speed up access when they are actually used.

[+Lee Stewart]

I now have an extensively modified version of the Miller-Warren DSRLNK that is almost the same as the Bagnaresi-Sullivan-Stewart DSRLNK in this thread. The only difference is that it cannot catch the Call Instance important to a second RS232 card because the relevant register is trashed before return. I handle that contingency by arbitrarily storing a 1 for the Call Instance upon a successful DSRLNK return, testing a subsequent failed direct call to a DSR/Subprogram by testing the stored Call Instance, making it 2 if it was 1, and running it again. If it fails the second try, the error return is taken. This should be OK because the direct call should never occur until after a successful initial call.

 

As I mentioned in an earlier post, the advantages to the Miller-Warren DSRLNK are that it saves code by using the Console DSRLNK, and handles cassette tape and GROM DSRs that are not handled by other DSRLNKs.

 

The only drawback I see is that it has grown in size. The original code was 120 bytes and, with the direct call routine and Call Instance handling, it has grown to 290 bytes. The good news is that it is still less than the 360 bytes of the Bagnaresi-Sullivan-Stewart version. Here, for your delectation, is the current incarnation:

DSRLNK_fbForth.a99  <<====Superseded. Get the latest code in post #1.

 

...lee

Edited February 29 by Lee Stewart
update

[+TheBF]

Congratulations Lee.

It will take me some time to digest this.

 

I had to touch my own version to put back the R15 save restore and of course now you have me wondering about improving mine. 

 

 

[+Lee Stewart]

I should add that the ALC I posted of the Miller-Warren-Stewart DSRLNK includes the Miller-Warren GPLLNK called by the MWS DSRLNK.

 

...lee

[+Lee Stewart]

I cleaned up the Miller-Warren-Stewart DSRLNK a bit (updated here and in Post #1):     DSRLNK_fbForth02.a99  <<====Superseded. See latest code in post #1.

 

The code at the end of the DSRAGN section after “BL *GR9” seems a bit bloated, but I am not sure I can get it any smaller—now at 282 bytes.

 

Next, we need to put it through its paces to see what errors shake out.

 

...lee

Edited March 22 by Lee Stewart
update

[+Lee Stewart]

I now have a working Miller-Warren-Stewart DSRLNK! See post #1 for the latest version. It now stands at 290 bytes. There may be a few bytes I could save somewhere, but I think I am done with that effort. It is 70 bytes less than the Bagnaresi-Sullivan-Stewart DSRLNK, so I think I will continue using the Miller-Warren-Stewart version.

 

I should note one error I found in the original Miller-Warren code. The COC instruction in the routine cannot possibly work as intended:

       COC  @GSTAT,R8      else, test CND bit for Link Error (00)

 

The source operand (a general address) is the mask for testing bits of the destination operand (must be a register). The mask is >2000, which is in R8 (original was R12, but I had to use a different register), should be the source operand. But, since the destination operand must be a register, @GSTAT cannot be that operand. Since R4 was not used after return from executing the DSR/subprogram, I copied the contents of GSTAT to R4 and used R4 as the destination operand:

       MOV  @GSTAT,R4      copy GPL status byte for error processing
*       .
*       .
*       .
       COC  R8,R4          else, test CND bit of GSTAT$ for Link Error (00)

 

Now it properly tests R4 (GSTAT copy) for the single bit (>2000) in the R8 mask.

 

Again, the latest code for the Miller-Warren-Stewart DSRLNK is in post #1.

 

...lee

[+TheBF]

Looks amazing Lee, with just a quick skim. I will have to make a real study of it. 

Thanks for doing what most of us would consider impossible.