I need to do a VDP command after line 152 is displayed, at each frame.

So I load r#19 with 152, and then poll for FH in s#1, but is that enough ?
What about the IE1 bit in r#0 and r#1 ?
And do I need to refresh something after, so that it can be executed at each frame ?

Thanks

Use interrupts, the right hook is fd9Ah (not fd9f that is called from vblank)
BTW make sure that your code in the interrupt is not executed if the FH is not set or it will be called twice in the same frame,
at line 152 and at Vblank

Thanks, but I don't want to use the interrupt hook.
I just want to wait until the line is traced before making my VDP command.

I have used the HALT opcode so far, thinking that it would time my VDP command with the VBLANK interrupt, but I just realized that interrupts might come from other devices, canceling that synchronization.

Furthermore, the VDP command (LMMM) ends too late if I start it after VBLANK, messing the display. That's why I want to start it earlier (@ line 152) so I can have more time for that command to end before retracing that part of the screen.

Just use the following routine:

loop:
LD a, 159
call INTERUPT
....do whatever...
jp loop


INTERUPT:
OUT (#99),A
LD A,#93
OUT (#99),A

LD A,1
OUT (#99),A
LD A,#8F
OUT (#99),A

WAITINT:
IN A,(#99)
AND 1
JR Z,WAITINT
SUB A
OUT (#99),A
LD A,#8F
OUT (#99),A
RET

Maggoo,

Your code actually does exactly what I thought was only needed :

- put line number in r#19
- poll s#1 until FH is set
- clear r#15 when done

But I'm not sure it works ... I already implemented this code in my program, but it does not seem to work.

OK, let's get a little more specific : I'm doing an horizontal scroll using a LMMM command on a 32 pixel high zone on the screen (from y=120 to y=152). The problem is that the size of bytes moved by the LMMM command increases at each step (think of it as a picture entering the screen from the right side).

I started to sync the command with VBLANK by using HALT, but at some point, the time needed by the LMMM command exceeds the time needed by the VDP to retrace the 120th line at the next frame, resulting in a horizontally "broken" scroll. And I want to make a smooth one ...

So I thought that starting the LMMM command after line 152, instead of VBLANK, would give the VDP more time before arriving at the 120th line of the next frame. So what I did was :

- set r#19 with line 152
- poll s#1 until FH is set
- clear r#15 when done
- do the LMMM command
- prepare the next LMMM command
- loop to the s#1 polling

The result is strange : it seems to work until the computer hangs somewhere in the middle of the scrolling routine. I have the impression that it hangs at the point where the LMMM command is still ongoing (because the size of bytes to move has increased) when the retrace of the 152th line occurs (thus when it takes the time of a full frame). But it is only an impression ...

Is it related to the fact that I set only once the r#19 and then assumes it always stores 152 ?
Or is it related to the settings of the IE0, IE1 or IE2 bits ?

Use an emulator with a debugger and trace what's going on...!

I suggest you to disable all interrupts (as there is no use for them in scroller like this) this way you don't need to even think about IE-bits. After that go and find what is wrong with your scroller. Problem is not in your idea.

Metalion, the problem is not in the line wait code, but the command itself. The VDP is only quick enough to do a scroll of approximately 24 lines (including the second copy for the new part). And this is using HMMM. With LMMM you probably won't get beyond half of that. In other words, even with the wait code, you're starting the new copy before the old one is finished.

Quote:

I suggest you to disable all interrupts (as there is no use for them in scroller like this) this way you don't need to even think about IE-bits. After that go and find what is wrong with your scroller. Problem is not in your idea.

OK, I'll do that.
But just to be sure : is it necessary to reset r#19 to the specified line each time ?

Quote:

Metalion, the problem is not in the line wait code, but the command itself. The VDP is only quick enough to do a scroll of approximately 24 lines (including the second copy for the new part). And this is using HMMM. With LMMM you probably won't get beyond half of that. In other words, even with the wait code, you're starting the new copy before the old one is finished.

Yeah, I thought so ... Anyway, I cannot use a HMMM command because my scroll works by steps of 3 pixels.

I guess the only solution left is to use buffering :

- display page 0 at VBLANK
- do the scroll on page 1
- wait until VDP is done
- display page 1 at VBLANK
- do the scroll on page 0
- wait until VDP is done
- loop

Either that or expand that idea to an R18 scroll. Then you can use HMMM again and doing it smooth should be no problem.

And an extra thought: there is actually no need to 'waste ' a complete page on your scroll. You can have the back-buffer for your scroll in Y-coords 220-251 and use the line interrupt to toggle between displaying either the original lines 120-151 or the back-buffer on line 220-251.

Mode 0:
- show page 0 normally
- do copy stuff in lines 220-251
- when copying finished, switch to mode 1

Mode 1:
- line interrupt on line 120 -> set reg#23 so that line 220- is displayed
- line interrupt on line 252/152 -> set reg#23 to 0 so that display is back to normal
- do copy stuff in lines 120-151
- when copying done, switch to mode 0

That's also a good idea, but I finally dropped the LMMM command to do the scrolling and switched to the more powerful HMMM command like Edwin suggested :

- display page 0
- scroll page 1 by 4 pixels using HMMM
- display page 1 adjusted +1 pixel by r#18 setting
- scroll page 0 by 2 pixels using HMMM
- display page 0 adjusted back to normal by r#18

and that does the trick