English Amiga Board Understanding the (in)famous copper's lost cycle (PAL all line, NTSC short line).
 Register Amiga FAQ Rules & Help Members List  /  Moderators List Today's Posts Mark Forums Read

 13 March 2017, 14:07 #1 ross Defendit numerus   Join Date: Mar 2017 Location: Crossing the Rubicon Age: 52 Posts: 3,846 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 18:45. Reason: pixels count corrected (thanks dissident)
13 March 2017, 15:01   #2
dissident
Registered User

Join Date: Sep 2015
Location: Germany
Posts: 245
Quote:
 Originally Posted by ross 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."

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.

 13 March 2017, 15:55 #3 ross Defendit numerus   Join Date: Mar 2017 Location: Crossing the Rubicon Age: 52 Posts: 3,846 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..
13 March 2017, 16:36   #4
dissident
Registered User

Join Date: Sep 2015
Location: Germany
Posts: 245
Quote:
 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?

13 March 2017, 16:38   #5
ross
Defendit numerus

Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 52
Posts: 3,846
Quote:
 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.

 13 March 2017, 16:51 #6 ross Defendit numerus   Join Date: Mar 2017 Location: Crossing the Rubicon Age: 52 Posts: 3,846 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!)
13 March 2017, 17:03   #7
ross
Defendit numerus

Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 52
Posts: 3,846
Quote:
 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

 13 March 2017, 17:36 #8 Toni Wilen WinUAE developer   Join Date: Aug 2001 Location: HĂ¤meenlinna/Finland Age: 47 Posts: 25,564 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.
13 March 2017, 17:59   #9
ross
Defendit numerus

Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 52
Posts: 3,846
Quote:
 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.

13 March 2017, 18:21   #10
Toni Wilen
WinUAE developer

Join Date: Aug 2001
Location: HĂ¤meenlinna/Finland
Age: 47
Posts: 25,564
Quote:
 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..)

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.

13 March 2017, 18:50   #11
ross
Defendit numerus

Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 52
Posts: 3,846
Quote:
 Originally Posted by Toni Wilen There is no guarantee programmed modes are correct.
It's in WinUAE to do list?

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

Thanks!

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

 Similar Threads Thread Thread Starter Forum Replies Last Post h0ffman Coders. Asm / Hardware 21 14 March 2017 21:59 BarryB support.Hardware 10 03 August 2016 15:41 Zilog request.UAE Wishlist 4 03 August 2014 00:08 BippyM Coders. Tutorials 38 04 September 2010 13:18 kipper2k Hardware pics 2 29 March 2009 08: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 Rules
 Forum Jump User Control Panel Private Messages Subscriptions Who's Online Search Forums Forums Home News Main     Amiga scene     Retrogaming General Discussion     Nostalgia & memories Support     New to Emulation or Amiga scene         Member Introductions     support.WinUAE     support.WinFellow     support.OtherUAE     support.FS-UAE         project.AmigaLive     support.Hardware         Hardware mods         Hardware pics     support.Games     support.Demos     support.Apps     support.Amiga Forever     support.Amix     support.AmigaOS     support.Other Requests     request.UAE Wishlist     request.Old Rare Games     request.Demos     request.Apps     request.Modules     request.Music     request.Other     Looking for a game name ?     Games images which need to be WHDified abime.net - Hall Of Light     HOL news     HOL suggestions and feedback     HOL data problems     HOL contributions abime.net - Amiga Magazine Rack     AMR news     AMR suggestions and feedback     AMR data problems     AMR contributions abime.net - Home Projects     project.Amiga Lore     project.EAB     project.IRC     project.Mods Jukebox     project.Wiki abime.net - Hosted Projects     project.aGTW     project.APoV     project.ClassicWB     project.Jambo!     project.Green Amiga Alien GUIDES     project.Maptapper     project.Sprites     project.WinUAE - Kaillera Other Projects     project.Amiga Demo DVD     project.Amiga Game Factory     project.CARE     project.Amiga File Server     project.CD32 Conversion     project.Game Cover Art         GCA.Feedback and Suggestions         GCA.Work in Progress         GCA.Cover Requests         GCA.Usefull Programs         GCA.Helpdesk     project.KGLoad     project.MAGE     project.Missing Full Shareware Games     project.SPS (was CAPS)     project.TOSEC (amiga only)     project.WHDLoad         project.Killergorilla's WHD packs Misc     Amiga websites reviews     MarketPlace         Swapshop     Kinky Amiga Stuff     Collections     EAB's competition Coders     Coders. General         Coders. Releases         Coders. Tutorials     Coders. Asm / Hardware     Coders. System         Coders. Scripting         Coders. Nextgen     Coders. Language         Coders. C/C++         Coders. AMOS         Coders. Blitz Basic     Coders. Contest         Coders. Entries Creation     Graphics         Graphics. Work In Progress         Graphics. Finished Work         Graphics. Tutorials     Music         Music. Work In Progress         Music. Finished Work         Music. Tutorials

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

 -- EAB3 skin ---- EAB2 skin ---- Mobile skin Archive - Top