There is a screen with opened bottom border on Timer B. Occasionally the Shifter shows shifted bitplanes. I guess it's caused by delayed Timer B by other MFP Timer and BLiTTER activity. We have no time to track it before an event and we're looking for temporary workaround, something like the Shifter reset or stabilizer on every VBL.Do you have any ideas?

Is it possible to move the blitter parts earlier in the vbl? Try that. Even if you have a additional stabilizer on every vbl you will drop the border that particular frame. But it's better than constantly shifted bitplanes.

While working on EmuTOS resolution change routines, I noticed that the plane shift bug occurred sometimes. I inserted a Vsync() before changing the resolution, and it definitely fixed the problem. My conclusion was that, for reliability, the resolution must not be changed when the beam is drawing something.

However, I don't know how this applies when the lower border is opened.I would suggest to try the following as workaround:- wait for the VBL- switch to medium resolution- switch to low resolution

What I normally do here is schedule the timer B a couple of lines in advance, pause the blitter (which takes a varying amount of time, but less than the padding time you're providing) and monitor the timerb data until it decays to the correct line. You can then sync properly. Sounds like you're saying there's no time for that padding?

And this still doesn't work with HOG blits - unless they are super short and/or timed. There's no solution to that one except to move the blits away from the timecritical region.

A left/right border style toggle might clean up the mess after the fact but I doubt you can do it with less than 1 dead line. It's already too late. Maybe someone else has tried it.

I used practically same what dml suggesting - activating Timer-B 1 line earlier, but it may be more if there is some very long uninterruptable blitter activity. Then perform only NOPs for 1 or more lines, what assures short Timer-B response-at desired line, with always same delay. May need to disable other interrupts during those lines. That will of course insert some inactive CPU time, what is not much, normally under 1% .Extra accurate synchronization is possible by trick used in hi-color displaying,

Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

There is a screen with opened bottom border on Timer B. Occasionally the Shifter shows shifted bitplanes. I guess it's caused by delayed Timer B by other MFP Timer and BLiTTER activity. We have no time to track it before an event and we're looking for temporary workaround, something like the Shifter reset or stabilizer on every VBL.Do you have any ideas?

Thanks!

Are you just opening bottom border, or also changing STE video address at the same time in the bottom border ?If the latter, it's *very* important to change video address while the shifter displays color 0 in the border (ie DE signal is OFF), else changing video address at the same time as shifter is reading data will cause this kind of shifted planes.

Lower border is opened by timer B which is scheduled a couple lines in advance (as DML mentioned) in order to avoid BLiTTER's disturbance.

As Nicolas suggested, it appeared changing STE video address was from time to time a few cycles toolate (it overlapped with the left border edge). The code was moved dozen cycles earlier and voila - no more bitplanes shifts.

Lower border is opened by timer B which is scheduled a couple lines in advance (as DML mentioned) in order to avoid BLiTTER's disturbance.

As Nicolas suggested, it appeared changing STE video address was from time to time a few cycles toolate (it overlapped with the left border edge). The code was moved dozen cycles earlier and voila - no more bitplanes shifts.

nanard wrote:how to be sure the timing of 95 nop's and 28 nop's are ok ?

By sync locking, as I wrote. The jitter from the timer you use can surely cause your code to go to 60Hz at cycle 372 and thus create an early line end (1 word less) which will create shifted bitplanes.