Jump to content
TheBF

DSRLINK Code Tutorial

Recommended Posts

Lee helped me figure it out I'm going to use text dsk1.file and push my filename and count later before calling DSRLNK.

Share this post


Link to post
Share on other sites
11 hours ago, Lee Stewart said:
       LI   R0,VDPPAB+9
       LI   R1,COUNT  * Note that this will load the address of COUNT, not the content, in R1
       MOVB @COUNT,R1   * This will work, though, to get the file name length into the PAB in VDP RAM
       BLWP @VSBW     * Then send the most significant byte of the address to the PAB in VDP RAM 

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

 

Here's my suggestion how to move the filename, when it has been updated by user input, to VDP RAM.

* Here's a piece of code which is equivalent to what the above one should have accomplished (at least that's what I think)

       LI   R0,VDPPAB+9	* Writes only the length and file name
       LI   R1,COUNT	* Fetch it starting from COUNT (which should be the tenth byte in the PAB in CPU RAM)
       MOVB *R1,R2		* Get the value of the count, make it 16-bit and add one, to account for that not only the file name, but also the count itself, should be transferred
       SRL  R2,8
       INC  R2
       BLWP @VMBW

 

Edited by apersson850
  • Like 2

Share this post


Link to post
Share on other sites

Yes, I think lee just wanted to provide something I could understand with my limited knowledge of AL..lol

But I get ya. Ty

Share this post


Link to post
Share on other sites

I'll get the data into position first, as I need only 128 bytes in the buffer as pointed out instead of 1028. 

I'll make sure I have a routine that provides that buffer constantly with a call to DSRLNK to process it in-between.

 

And once I get that working, up to the call to DSRLNK, then I'll work on getting the FLNM, (filename),and COUNT (length of filename), pushed into VRAM PAB.

I'll probably use a simpler formula but I understand I need to do what @APERSSON850 is suggesting.

  • Like 1

Share this post


Link to post
Share on other sites

I'm not much for providing ready code to people trying to learn programming. They just use it, but never understand it. However, the code I did provide above, to move the count and file name into the PAB in VDP RAM, is only six instructions long. Use that. It's about as simple as it gets. You have to define the PAB image in CPU RAM correctly first, of course. Please put that piece up here when you've done it, so we/I can verify that you fully understand that before you proceed. Otherwise your problems will be eternal.

  • Like 2

Share this post


Link to post
Share on other sites
On 11/2/2020 at 7:43 PM, GDMike 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

This is nice and it does break each piece down to little sections, but I still don't know how I'd use it?

You said when I've got it setup then blast it to vdp. I still need an example. So I can actually see what is going on. 

Btw, it's a 128 byte record length not 80. 

Doesn't matter, I see the setup. 

I do like this approach. 

Could you create an artificial write of 128 bytes of code that's sitting at >1000 VDPRAM for me whenever you have time.

Then everything might click. Thank you.

 

 

Share this post


Link to post
Share on other sites

Let's see if this clicks, then.

Now you are doing something like this.

 

prepare general PAB in CPU RAM;

write PAB to VDP RAM;

do things;

update filename and length in PAB in VDP RAM;

do things;

update opcode in PAB in VDP RAM;

do things;

update record number in PAB in VDP RAM;

do things;

call DSRLNK;

 

Writing to VDP RAM is complex and takes time, compared to changing things in CPU RAM. So the suggestion is to do like this instead.

 

prepare general PAB in CPU RAM;

do things;

update filename and length in PAB in CPU RAM;

do things;

update opcode in PAB in CPU RAM;

do things;

update record number in PAB in CPU RAM;

do things;

write PAB to VDP RAM;

call DSRLNK;

 

With this strategy, you only mess with moving the PAB to VDP RAM once per DSRLNK call, instead of updating small pieces of it ever so often. You still update pieces of it, but in CPU RAM most of that is a simple MOV or MOVB. No need to BLWP the VDP data transfer routines each time.

It does mean that some parts you'll copy in spite of them not being changed, but due to the overhead for each small transfer, it's probably faster anyway, and definitely simpler.

Edited by apersson850
  • Like 7
  • Thanks 1

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