English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 13 March 2017, 13:07   #1
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 50
Posts: 2,837
Understanding the (in)famous copper's lost cycle (PAL only).

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

Example:

Code:
 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,

Last edited by ross; 13 March 2017 at 17:45. Reason: pixels count corrected (thanks dissident)
ross is offline  
Old 13 March 2017, 14:01   #2
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 234
Quote:
Originally Posted by ross View Post
Everyone facing advanced copper programming got the 'imprecise' timing on end of lines.

Example:

Code:
 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.
dissident is offline  
Old 13 March 2017, 14:55   #3
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 50
Posts: 2,837
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..

ross is offline  
Old 13 March 2017, 15:36   #4
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 234
Quote:
Originally Posted by ross View Post
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?
dissident is offline  
Old 13 March 2017, 15:38   #5
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 50
Posts: 2,837
Quote:
Originally Posted by dissident View Post
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 is offline  
Old 13 March 2017, 15:51   #6
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 50
Posts: 2,837
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 is offline  
Old 13 March 2017, 16:03   #7
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 50
Posts: 2,837
Quote:
Originally Posted by dissident View Post
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
ross is offline  
Old 13 March 2017, 16:36   #8
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 45
Posts: 24,177
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.
Toni Wilen is offline  
Old 13 March 2017, 16:59   #9
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 50
Posts: 2,837
Quote:
Originally Posted by Toni Wilen View Post
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.

ross is offline  
Old 13 March 2017, 17:21   #10
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 45
Posts: 24,177
Quote:
Originally Posted by ross View Post
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..)

Quote:
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.
Toni Wilen is offline  
Old 13 March 2017, 17:50   #11
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 50
Posts: 2,837
Quote:
Originally Posted by Toni Wilen View Post
There is no guarantee programmed modes are correct.
It's in WinUAE to do list?


Quote:
Also $E0 "feature" seems to be PAL-only.
Corrected Title of thread.

Thanks!
ross is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Copper - waiting for the end of a line h0ffman Coders. Asm / Hardware 21 14 March 2017 20:59
How to switch PAL Rev 6A A500 between PAL/NTSC? BarryB support.Hardware 10 03 August 2016 14:41
Keep Active control panel "Line Mode" and "Interlaced Line Mode" Zilog request.UAE Wishlist 4 02 August 2014 23:08
Understanding the Copper BippyM Coders. Tutorials 38 04 September 2010 12:18
NTSC A500 Pal/NTSC mod pics kipper2k Hardware pics 2 29 March 2009 07:56

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 07:50.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Page generated in 0.09108 seconds with 12 queries