Algorithm for Scroll

Page 2/2
1 |

By Rogerup

Resident (38)

Rogerup's picture

08-04-2019, 05:08

Manuel wrote:

Try it also in openMSX on an MSX1 like the Toshiba HX-10. It looks different (worse) than in WebMSX.

Thanks Manuel, for reminding me to test the program on a more accurate emulator. This specific problem was not in the scrolling routine, it was in how I was loading the images into RAM (reading VDP too fast).

thegeps wrote:

noises are caused by OTIR instruction. It's too fast and if it run out of the vblank it cause VRAM garbage.

Thanks thegeps, your tip helped to clean the garbage when I tested the program in OpenMSX. But the real problem, which also occurs in WebMSX, is not accessing too fast the VDP when out of the blank. I used the word "noise" incorrectly, because the image is not corrupted in VRAM. The problem is that there is not enough time to transfer the 2304 bytes in the same vblank, so part of the screen (3 lines in the intersection of the banks) is updated in the next retrace, and this difference in the presentation can be viewed.

I've updated the links with the new version that works correctly in the OpenMSX emulator.

By thegeps

Master (254)

thegeps's picture

08-04-2019, 08:10

Why 2304 bytes? Don't you scroll 8 pixel (1 tile) each time? For such scrolling you need to move only 768 bytes...

By thegeps

Master (254)

thegeps's picture

08-04-2019, 12:44

Well I know why, 768 + 32*8*6 (32 tiles x 8 lines x(3 banks x 2 cause shapes and colors). You are right, you haven't enough time. And you'll never have. There aren't enough cycles in the vblank to write (even at max speed using OTIR) to move all these bytes. So yoi have to write out of the vblank slowing the write way. Do as I told you using outi loops instead of OTIR

By thegeps

Master (254)

thegeps's picture

08-04-2019, 12:49

Outi 18 cycles
Jp 11 cycles
Total 29 cycles, exactly the max writing speed allowed out of the vblank. And consider that you'll have to do for sure more things during vblank than accessing vdp, so your available cycles will be less than you expect. Trust me, use outi+jp Wink

By Rogerup

Resident (38)

Rogerup's picture

08-04-2019, 16:44

thegeps wrote:

Trust me, use outi+jp Wink

Hi thegeps, I already use outi + jp when out of vblank. If not, garbage would appear. The problem we see is not garbage. The problem is that we see an image being updated in 2 different frames, so the part that is updated in the second frame causes the visual problem.

I will try to update all in the same frame with something weird, like starting to write a little before the vblank (Calculating the time since the last interrupt). Always using a sequence of outi when in vblank, and outi+jp when out of vblank. Theoretically, is possible to write the 2304 bytes in VDP in less than 1/60s.

By Grauw

Ascended (8387)

Grauw's picture

08-04-2019, 17:07

If you update the top part of the screen before the blanking period ends, you can take your time updating the bottom part during active display for as long as it takes for the beam to reach it.

By hit9918

Prophet (2866)

hit9918's picture

09-04-2019, 00:51

Rogerup wrote:

I will try to update all in the same frame with something weird, like starting to write a little before the vblank (Calculating the time since the last interrupt)

there is another 1k vram free for a second nametable. you can write into the hidden nametable before the vblank. this needs no weird timing.

By PingPong

Prophet (3435)

PingPong's picture

09-04-2019, 20:28

you can do nametable update even in active area, for example, if you start 8 lines after the current scanline the vdp will not catch your updates, that is because the z80 can push about 7 bytes in the time the vdp draw a scanline. So after 8 scanlines the z80 will pushed 7*8=56 bytes of nametable, and the vdp will start read the second nametable row that is only 32 bytes far . situation is different if you need to apply changes on pattern or color table

By Rogerup

Resident (38)

Rogerup's picture

10-04-2019, 03:21

Grauw wrote:

If you update the top part of the screen before the blanking period ends, you can take your time updating the bottom part during active display for as long as it takes for the beam to reach it.

Thanks Graw, this helped me to improve the screen update. I was updating the entire name table first, then the pattern and color tables. Now I update each block in order.

hit9918 wrote:

there is another 1k vram free for a second nametable. you can write into the hidden nametable before the vblank. this needs no weird timing.

Thank you hit9918 for reminding me of this 1k vram free, I will use it if necessary.

PingPong wrote:

you can do nametable update even in active area, for example, if you start 8 lines after the current scanline the vdp will not catch your updates, that is because the z80 can push about 7 bytes in the time the vdp draw a scanline. So after 8 scanlines the z80 will pushed 7*8=56 bytes of nametable, and the vdp will start read the second nametable row that is only 32 bytes far . situation is different if you need to apply changes on pattern or color table

Thanks for the info PingPong, my problem was in transferring 1536 bytes to pattern and color tables, in order to scroll full images (images without repeated characters in the 3 banks).

By improving the program with the tips I got here and a few other little things, the scroll of full images is ok. I realize that I can update the vram during vscan with a delay of less than 29 cycles, I tried 28, 26 and only had the problem with 25 cycles in OpenMSX. I do not have a real hardware to test it.

Another thing I read somewhere is that when using sprites, access to the vram when out of vblank needs to wait for the 29 cycles, at least in OpenMSX I did not see any difference when I added sprites.

On blueMSX and WebMSX the garbage does not appear when writing to vram during vscan with the interval of 25 cycles, I only saw the problem in OpenMSX.

On a 60Hz machine (Japan / Brazil) when using the interval of 29 cycles, you can see the last line being changed in scrolling down; using 28 cycles you see only one risk; and using 26 cycles the whole image is updated in time.

New version

Z = Decrease the number of cycles between outi's when out of vblank
X = Increase the number of cycles between outi's when out of vblank
S = Show 32 big/enlarged sprites moving
Arrows = Scroll
Esc = Quit

If someone wants to test the speed on real hardware, the link has the zip with all the files.

Page 2/2
1 |