Understanding the (in)famous copper's lost cycle (PAL only).
 

Everyone facing advanced copper programming got the 'imprecise' timing on end of lines.

Example:

You can see a copper slice of 10 lores pixels and not 8 (1 copper cycle delay).
The lost cycle seems to be $E0.
But, why?

It would be logical to mantain $E0 and exclude $E1... (an odd copper cycle?!?!)
So the sequence $DE(y) $DF(n) $E0(y) $E1(n) $E2(-1,n) $00(y) was regular.. with only $E2(-1) as a lost cycle.

Someone enlight me.

Thanks, :great

This might help you. It's a passage out of the hardware reference manual chapter coprocessor hardware/horizontal beam position:

"All lines are not the same length in NTSC. Every other line is long line (228 color clocks, 0-$E3), with the others being 227 color clocks long. In PAL, they arre all 227 long. The display sees all these lines as 227 1/2 color clocks long, while the copper sees alternating long and short lines."

See http://amigadev.elowar.com/read/ADCD.../node004C.html

If I rember right, PAL with 227 colorclocks has 1 missed colorclock compared with NTSC. This missing 1 colorclock is displayed at the right border and so the copper colourchange is once 10 lores pixels (not 12) wide instead of 8 lores pixels.

Hi dissident,
all was clear about PAL/NTSC long/short line and cycle but my question was why lost cycle is $E0 (making a strange Copper odd cycle use). When AHRM suggest 227 1/2 I think is related to Denise double Agnus internal counter (227.5*2->455).
But not explain cycle $E0..

:great

All right, 2nd try. ;)

After some e-mail-digging I found this: Some years ago, I asked Toni Wilen this question:

"And while we are at his theme, I don't understand why colourchanges after lores position $1c7 work in general. The last memory slot is at position $e0. How can the copper do MOVEs after this position when there are no memory slots. HRM says that at position $e0 horizontal line data fetch stops. It seems this is only meant for the bitplane datafetch. Other devices can allocate memory slots after position $e0. Am I right or not?"

He gave me the following answer:

"PAL slots are 0 to E2 (E2 is not usable, it is first refresh slot)

Color changes can happen later because normal PAL/NTSC hsync is not athpos=0 but at hpos=13 or so. (don't remember the exact value)(=copper horizontal positions 0 to 7 or so are visible in _right_ border)

In other words copper DMA is actually using slots from 0-> near the edge of right border."

Does this information helps you, ross?

The 10 lores pixels is not related to the PAL missing cycle.
Is related to the resynchronization of the copper in a odd (227) line division slice; that was simple the right count for a 64us (281,94ns*227) PAL line signal.
So the cycle in not missing but unusable.
;)

But I'd like to know what actually happens in the final part of the video line.

:great

Thanks dissident for the info and discussion.

But something is missing.. and Toni or yaqube probably can answer.

Maybe a test with beamcon0 and htotal change?
I'm curious what would be the cycle lost in this situation (unused $E0 and used $E1 is really strange!)

:great

mmh, and if the answer was simply a silicon saving?
$E0 hard fetch stop AND copper cycle inhibited?

bye :great

I don't remember where I posted this but E0 is special cycle, it is not available for copper (reason unknown). It is very special, if copper wants it, no one gets it! It is not any kind of hard stop because it is possible to set DDFSTRT/STOP pair so that it conflicts with first refresh slot, even if chipset is OCS.

E2 is first refresh slot and also not available for copper but following cycle (0) is again available.

Thanks Toni, this is valuable information!
So if I make a copperlist that would use $E0, i can lose even 313 cycle/frame (copper/blitter/cpu) for nothing!

Good to know (and be careful in the construction of the copper list ;))

----

Some test with beamcon0 and PAL simulation.
Strange result at end of line...
With HTOTAL=$E2 the result is not the same.

:great

Yes. (I think there is at least one demo that depends on this. Accidentally as usual..)

There is no guarantee programmed modes are correct. Also $E0 "feature" seems to be PAL-only.

It's in WinUAE to do list?


Corrected Title of thread.

Thanks!