Improving transfer time to VERA in BASIC

[rje]

It's not (noticeably) slower or faster, and technically it's a demonstration of the autoincrement, so I'm keeping it. ?

 

[Ender]

On 10/12/2021 at 9:55 PM, Scott Robison said:

VPOKE will set an address (I don't think it's documented as to whether it will set addr 0 or 1), but I don't think it sets the increment. Regardless, VPOKE will always reset the address every time it is used. By avoiding VPOKE completely you can set the address, pick whether it is 0 or 1, and target the port. Whether it is a net improvement will depend on how much overhead is involved in the multiple POKE statements and how many bytes you write with auto incrementing addresses. I feel confident that my solution is technically correct (though I didn't try running it), but it might not be more efficient than a series of VPOKE statements. That would probably be a good test. Run the 8 VPOKE based version 1000 or so times and time it, then run the 12 POKE only version 1000 or so times and time it and see if one is definitively better than the other.



Now I'm curious. Testing. ?

If you look at the source code of VPOKE, all it does is put the first argument in to $9f22, the second argument into $9f20 and $9f21, and the third argument in to $9f23.  So yes, you can use VPOKE to set the increment, and arguably it's faster than doing three POKEs to set up the address, since you're parsing and executing two less BASIC commands.

[Scott Robison]

On 10/12/2021 at 8:02 PM, Ender said:

If you look at the source code of VPOKE, all it does is put the first argument in to $9f22, the second argument into $9f20 and $9f21, and the third argument in to $9f23.  So yes, you can use VPOKE to set the increment, and arguably it's faster than doing three POKEs to set up the address, since you're parsing and executing two less BASIC commands.

Ah, good to know, thanks. In my testing just now, my version is definitely slower because the extra pokes do math on P that isn't necessary in the VPOKE version, so don't use it even though it is "technically correct" but "slow". ? And I realized that if P is greater than 32767 AND is going to fail with it and AND only works with valid signed integers.

Edited: removed screen shot in favor of next message.

There is the test code, and the numbers under RUN are the number of jiffies to execute the pure VPOKE and the number of jiffies to execute the pure POKE.

 

[Scott Robison]

Here is a better test case that is more apples to apples based on Ender's comment.



So 322 jiffies to use pure VPOKE, 590 jiffies to use pure POKE, 218 to use hybrid approach that should autoincrement. Replace %10001 with a variable to make it even faster, probably.

Edit: Oh, I put one too many POKE commands in the final loop. That is just a typo. Remove one of them to get the exact 8 VRAM pokes you wanted. That gets the time down to only 199 jiffies.

[Scott Robison]

So by using VPOKE 8 times in a loop, each statement will average 0.67 ms per VPOKE (plus extra time for any calculations since I'm just poking values of 0).

By using one VPOKE and 7 POKE statements in a loop, the average time is only 0.42 ms per VPOKE/POKE. 37% speed increase.

[Scott Robison]

Yep, replace P+0 with P and replace %10001 with a variable defined earlier and I got the third loop down to 170 jiffies, or 0.36 ms per VPOKE/POKE. 46% speed increase.