Understanding the (in)famous copper's lost cycle (PAL all line, NTSC short line).

[ross]

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

Example:

 00045548: fedb fffe [0fe 0d8]	;  Wait for vpos >= 0xfe and hpos >= 0xda
                        	;  VP fe, VE 7f; HP da, HE fe; BFD 1
 0004554c: 0180 0fff [0fe 0dc]	;  COLOR00 := 0x0fff
*00045550: 0180 0888 [0fe 0e1]	;  COLOR00 := 0x0888
 00045554: 0180 0000 [0ff 002]	;  COLOR00 := 0x0000

 00045548: fedd fffe [0fe 0da]	;  Wait for vpos >= 0xfe and hpos >= 0xdc
                        	;  VP fe, VE 7f; HP dc, HE fe; BFD 1
*0004554c: 0180 0fff [0fe 0de]	;  COLOR00 := 0x0fff
 00045550: 0180 0888 [0ff 000]	;  COLOR00 := 0x0888
 00045554: 0180 0000 [0ff 004]	;  COLOR00 := 0x0000

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,

[dissident]

Originally Posted by ross

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

Example:

 00045548: fedb fffe [0fe 0d8]    ;  Wait for vpos >= 0xfe and hpos >= 0xda
                            ;  VP fe, VE 7f; HP da, HE fe; BFD 1
 0004554c: 0180 0fff [0fe 0dc]    ;  COLOR00 := 0x0fff
*00045550: 0180 0888 [0fe 0e1]    ;  COLOR00 := 0x0888
 00045554: 0180 0000 [0ff 002]    ;  COLOR00 := 0x0000

 00045548: fedd fffe [0fe 0da]    ;  Wait for vpos >= 0xfe and hpos >= 0xdc
                            ;  VP fe, VE 7f; HP dc, HE fe; BFD 1
*0004554c: 0180 0fff [0fe 0de]    ;  COLOR00 := 0x0fff
 00045550: 0180 0888 [0ff 000]    ;  COLOR00 := 0x0888
 00045554: 0180 0000 [0ff 004]    ;  COLOR00 := 0x0000

You can see a copper slice of 6px and not 4.
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,

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.

[ross]

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

[dissident]

Originally Posted by ross

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

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?

[ross]

Originally Posted by dissident

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.

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.

[ross]

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!)

[ross]

Originally Posted by dissident

All right, 2nd try.
HRM says that at position $e0 horizontal line data fetch stops. It seems this is only meant for the bitplane datafetch.

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

bye

[Toni Wilen]

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.

[ross]

Originally Posted by Toni Wilen

It is very special, if copper wants it, no one gets it!

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.

[Toni Wilen]

Originally Posted by ross

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

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

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

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

[ross]

Originally Posted by Toni Wilen

There is no guarantee programmed modes are correct.

It's in WinUAE to do list?

Also $E0 "feature" seems to be PAL-only.

Corrected Title of thread.

Thanks!