Improving transfer time to VERA in BASIC

[rje]

Today I opened up the old "Rogue Forest" game I wrote a year ago, and I thought that this snippet could be sped up:

         if y>8 and y<40 then ff=int(rnd(1)*3)

         vpoke 1,P,fo(ff) :rem character index

         vpoke 1,P+1,cl   :rem bg/fg color nybbles

         if y>8 and y<40 then ff=int(rnd(1)*3)

         vpoke 1,P+2,fo(ff)

         vpoke 1,P+3,cl

         if y>8 and y<40 then ff=int(rnd(1)*3)

         vpoke 1,P+4,fo(ff)

         vpoke 1,P+5,cl

         if y>8 and y<40 then ff=int(rnd(1)*3)

         vpoke 1,P+6,fo(ff)

         vpoke 1,P+7,cl

P, P+1, P+2, P+3... P+7.  I mean, that sounds like a shoo-in for using the auto-increment with Port 0, for example.

Anyone think that sounds reasonable?  I THINK I should be able to do something like this:

         vpoke %10000, P, 0 :rem set up autoincrement

         if y>8 and y<40 then ff=int(rnd(1)*3)

         poke $9f23, fo(ff) :rem character index

         poke $9f23,cl   :rem bg/fg color nybbles

         if y>8 and y<40 then ff=int(rnd(1)*3)

         poke $9f23, fo(ff)

         poke $9f23, cl

         if y>8 and y<40 then ff=int(rnd(1)*3)

         poke $9f23, fo(ff)

         poke $9f23, cl

         if y>8 and y<40 then ff=int(rnd(1)*3)

         poke $9f23, fo(ff)

         poke $9f23, cl

 

 

[Scott Robison]

I haven't looked at reference material to ensure all the numbers are exactly correct, but that seems reasonable in theory.

[rje]

Thanks.  It's not exactly correct, so I have to hunt around for the right way.

 

In particular, the initial VPOKE has something wrong with it.

 

 

[Scott Robison]

Given a base address P I think what you want to replace the VPOKE with:

POKE $9F25, PEEK($9F25) AND 254 : REM SELECT ADDR 0

POKE $9F22, %00010000 OR INT(P / 65536) : REM INCR 1 AND VRAM ADDR BIT 16

POKE $9F21, INT(P / 256) AND 255 : REM VRAM ADDR BITS 15:8

POKE $9F20, P AND 255 : REM VRAM ADDR BITS 7:0

REM NOW THE ADDR IS SETUP SO DO EVERYTHING AFTER VPOKE LINE...

[Scott Robison]

With the solution above, I am assuming P is the complete VRAM address from $00000 to $1FFFF. The second line doesn't have to do the "OR INT(P/65536)" part if the address will always be $FFFF or smaller.

[rje]

On 10/11/2021 at 10:14 PM, Scott Robison said:

With the solution above, I am assuming P is the complete VRAM address from $00000 to $1FFFF. The second line doesn't have to do the "OR INT(P/65536)" part if the address will always be $FFFF or smaller.

Thanks for that.  Managing the bitfields (and understanding what they do) is the full problem.  It looks to me like I was POKEing above $10000, so the OR is probably needed.

 

[desertfish]

you can always poke a short assembly routine into ram somewhere and SYS to it to do the tight loop, if you want to speed up things?

[rje]

You're right.  

For now, though, I'm seeing what it can do when I stay in BASIC, to serve as a demo of what you can do with BASIC.

Ah, but I am currently using that tiny interrupt-driven sound library by Dusan.  Even as simple as it is, it's adding a great bit of "color" to the game!

 

 

[Ender]

If you're using the initial VPOKE just to set up the address, that won't work since it will increment on that write as well, and it will end up starting at P+1 on the next line.  You need to start at P-1 (assuming that it's ok to put a 0 there), or somehow VPOKE only on the first actual data write that you do.

[Scott Robison]

On 10/12/2021 at 6:57 PM, Ender said:

If you're using the initial VPOKE just to set up the address, that won't work since it will increment on that write as well, and it will end up starting at P+1 on the next line.  You need to start at P-1 (assuming that it's ok to put a 0 there), or somehow VPOKE only on the first actual data write that you do.

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