English Amiga Board


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

 
 
Thread Tools
Old 05 August 2014, 14:30   #1
nandius_c
Fernando Cabrera

 
Join Date: Oct 2013
Location: Spain
Posts: 100
Copper list execution start.

A basic doubt but something I'd really like to fully understand, so any help would be appreciated. This is what the AHRM says:

"At the start of each vertical blanking interval, COP1LC is automatically used to start the program counter. That is, no matter what the Copper is doing, when the end of vertical blanking occurs, the Copper is automatically forced to restart its operations at the address contained in COP1LC."

So: when does the copper exactly begin executing the copper list? "At the start" or "when the end of vertical blanking occurs"? I guess it has to be at the start (as soon as COP1LC is used to init de PC) because display setup has to be ready when the vertical blank ends (not very lucky that sentence from the AHRM... or maybe I dindn't understand it!).

But, if this is the case: why is it always said that changes to the copper list should be made during the vertical blank? For example, double buffering: after exchanging back and front buffer pointers, when is the right moment to poke the "new" front buffer pointer into the copper list? Is it possible that the copper sets the bitplane pointers before the new address is poked into the copper list? Is it recommended to disable copper DMA at the beginning of the vertical blank, do any copper list modifications needed and, after that, enable copper DMA again?

Thanks in advance!

Last edited by nandius_c; 05 August 2014 at 15:24.
nandius_c is offline  
Old 05 August 2014, 15:37   #2
Photon
Moderator

Photon's Avatar
 
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,172
You can change any instruction in the copper list as soon as that instruction has been executed and any time before it's read again.

You can make any changes to COP1LCH during a frame, and it will be copied to an on-chip counter after the next vblank.

Note that vblank!=VERTB interrupt. Vblank here and in the HRM is the hardware signal sent to a CRT to send its photon beam back up to the top. This takes a few milliseconds and happens completely in the background. After that, VERTB is fired and COP1LCH read.

If you have a VERTB interrupt that changes the top of the copperlist, put the instructions you want to modify after a WAIT like dc.w $2807,$fffe. Then you have a few milliseconds to make the changes.
Photon is offline  
Old 08 August 2014, 11:43   #3
nandius_c
Fernando Cabrera

 
Join Date: Oct 2013
Location: Spain
Posts: 100
Quote:
Originally Posted by Photon View Post
You can change any instruction in the copper list as soon as that instruction has been executed and any time before it's read again.

You can make any changes to COP1LCH during a frame, and it will be copied to an on-chip counter after the next vblank.

Note that vblank!=VERTB interrupt. Vblank here and in the HRM is the hardware signal sent to a CRT to send its photon beam back up to the top. This takes a few milliseconds and happens completely in the background. After that, VERTB is fired and COP1LCH read.

If you have a VERTB interrupt that changes the top of the copperlist, put the instructions you want to modify after a WAIT like dc.w $2807,$fffe. Then you have a few milliseconds to make the changes.
OK, I didn't know the difference between vblank and VERTB, though I couldn't find the word "vblank" in the HRM... I've taken good note of your advice about putting a little wait in the copper list before the instructions I want to modify. Thank you!
nandius_c is offline  
Old 08 August 2014, 11:58   #4
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 46
Posts: 25,241
Quote:
Originally Posted by Photon View Post
Note that vblank!=VERTB interrupt. Vblank here and in the HRM is the hardware signal sent to a CRT to send its photon beam back up to the top. This takes a few milliseconds and happens completely in the background. After that, VERTB is fired and COP1LCH read.
I forgot to reply.. But this is wrong.

It is same thing. Vertical blank interrupt triggers (and copper starts) exactly (interrupt is delayed a bit due to relatively long 68000 interrupt exception startup) when vsync signal changes (vpos wraps around to zero) and signal goes to TV/monitor which tells it to deflect electron beam back to top/left corner. It is called "vertical blank" because electron beam is blanked during this time.

Note that horizontal deflection is still running normally, technically when Amiga vpos=0, retrace starts, vpos=13 or so is about in the mid screen during retrace/vblank, line 25 is end of vblank and line 26 is first line from top that is "drawn" normally again. (PAL numbers, NTSC is slightyl different)
Toni Wilen is offline  
Old 08 August 2014, 14:42   #5
Photon
Moderator

Photon's Avatar
 
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,172
It was just a clarification from a programming viewpoint. "vblank!=interrupt" was to clarify that the vertical blanking is a hardware signal that lasts for many raster lines of time, and this is what HRM assumes that you know when not referring specifically to VERTB, which is a different signal. That assumption is not obvious to a reader not having the electronics knowledge from the 80s.

As a side note from memory horizontal deflection is not running normally but much slower during vblank than during hblank.

From a hardware programmer standpoint, when VERTB interrupt code runs, either way you look at it and even if the beam has just started to fly back upwards, you could consider yourself at the "top of the screen", of a new frame. Especially since from memory the LOF longframe bit has been toggled at this point in time. Probably as you write, VPOS is just reset to 0 instead at the bottom of the screen (end of frame), and the programmer is deceived with the VPOS staying at 0 until $19 while the HPOS contains changing values. A VERTB interrupt that logs out the HPOS should determine whether HPOS is actually decreasing (as it indeed should if VERTB is fired at start-of-flyback).

It would be interesting to know if the whole kaboodle (COP1JMP, VERTB, LOF toggle, ...) takes place at rasterline "$138.5", and in which order. I wouldn't be surprised if the trigger is (end-of-copper-wait-instruction) AND (VPOS $xxx reached), and the trigger is for a COP1LC latch+COP1JMP, and that the COP1JMP is what triggers the rest, VERTB LOF etc. It's "hidden" behavior, so some speculation, but some of it can be measured with a test program. Or better yet with a multichannel logging oscilloscope, of course.
Photon is offline  
Old 08 August 2014, 15:04   #6
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 46
Posts: 25,241
Quote:
Originally Posted by Photon View Post
It was just a clarification from a programming viewpoint. "vblank!=interrupt" was to clarify that the vertical blanking is a hardware signal that lasts for many raster lines of time, and this is what HRM assumes that you know when not referring specifically to VERTB, which is a different signal. That assumption is not obvious to a reader not having the electronics knowledge from the 80s.
I read your original post as verb interrupt comes after vblank ends: "takes few milliseconds..then vertb fires".

Quote:
As a side note from memory horizontal deflection is not running normally but much slower during vblank than during hblank.
I am sure it is same all the time. (Why would they make TV electronics more complex than required?). Pulse shape can be different due to equalizing pulses etc.. but h-deflection rate will not change.

Quote:
From a hardware programmer standpoint, when VERTB interrupt code runs, either way you look at it and even if the beam has just started to fly back upwards, you could consider yourself at the "top of the screen", of a new frame. Especially since from memory the LOF longframe bit has been toggled at this point in time. Probably as you write, VPOS is just reset to 0 instead at the bottom of the screen (end of frame), and the programmer is deceived with the VPOS staying at 0 until $19 while the HPOS contains changing values. A VERTB interrupt that logs out the HPOS should determine whether HPOS is actually decreasing (as it indeed should if VERTB is fired at start-of-flyback).
Staying at 0? Perhaps I misunderstood but it counts normally (as I explained above).

Quote:
It would be interesting to know if the whole kaboodle (COP1JMP, VERTB, LOF toggle, ...) takes place at rasterline "$138.5", and in which order. I wouldn't be surprised if the trigger is (end-of-copper-wait-instruction) AND (VPOS $xxx reached), and the trigger is for a COP1LC latch+COP1JMP, and that the COP1JMP is what triggers the rest, VERTB LOF etc. It's "hidden" behavior, so some speculation, but some of it can be measured with a test program. Or better yet with a multichannel logging oscilloscope, of course.
LOF toggles few cycles before end of scan line (I thin it was either exactly 2 or 3 cycles before next refresh slot, I did post about this in some thread, or at least in winuae changelog. I did check this with logic analyzer some time ago by reading LOF and checking in which cycle it changed)

Paula knows when vsync is triggered by checking refresh cycle for vertical sync strobe which is earlier than copper's first available cycle.

So technically it is copper that is last but because it has priority over CPU and Paula interrupt getting to CPU takes about 2 cycles and CPU finally running the interrupt code takes 40+ cycles, copper is always the first one to "wake up"

(Copper wakeup from vertical blank vs writing to COPJMP has slightly different timing too, I explained it in some thread too)

There are code that modify copper list in CPU vertical blank routine and some of them only work accidentally, even 2-4 cycle difference would break it and copper would read the modified data too early or too late!
Toni Wilen is offline  
Old 13 August 2014, 14:54   #7
nandius_c
Fernando Cabrera

 
Join Date: Oct 2013
Location: Spain
Posts: 100
Thank you so much for your comments, dudes!
nandius_c is offline  
Old 13 August 2014, 21:32   #8
mc6809e
Registered User
 
Join Date: Jan 2012
Location: USA
Posts: 331
The eab fileserver has two files, one for NTSC and one for PAL, called "Specifications_AGNUS..." that shows the relationship between vblank/vsync/hsync signals in a timing diagram (Specifications_AGNUS_png0039.png is the image).

Official documentation is always suspect and the state of the signals as seen by the CPU can vary but according to the timing charts for interlaced PAL (which could be wrong):

at the end of long fields and beginning of short fields

vblank begins at vpos 312 hpos 1 and ends at vpos 25 hpos 1
vsync begins at line 2 hpos 132 and ends at vpos 5 hpos 18

at the end of short fields and beginning of long fields

vblank begins at vpos 311 hpos 1 and ends at vpos 25 hpos 1
vsync begins at vpos 3 hpos 18 and ends at vpos 5 hpos 132

Again, above is only from the timing chart. Vpos values might be off by one or the the vblank interrupt/copper reset event might happen one line after actual analog vblank or something else might be off.

The point is that the relation between vsync and vblank can change. Vblank only turns off the electron beam so that when vsync begins at some point later, lines do not appear to streak across the screen when as the vertical position is reset by the vsync pulse.

This is due to the analog nature of CRTs. The electromagnet in the yoke responsible for the vertical position needs time to reset the beam position to the top of the screen. If the electron beam is still on while this happens, streaks occur as because the electromagnet can't change instantly.

Same thing happens with hsync. Hblank first turns off the beam, then the hsync pulse moves the beam to the left of the screen. After the hsync pulse, the beam position begins to move again from left to right and the electron beam comes back on to display the scanline.

The timing of vsync is responsible for the vertical position of the horizontal lines on the screen and the total number of lines per field. Changing the timing of vsync each field makes an interlace display possible.

On a CRT, the vertical position of the beam changes continuously after a vsync pulse and independently of hsyncs. This causes "horizontal" lines to actually slope down slightly from left to right (this is compensated for by turning the yoke itself a little counter-clockwise). By changing vsync by half a scanline, scanlines will mesh and form an interlace display.
mc6809e is offline  
Old 13 August 2014, 23:20   #9
Lonewolf10
AMOS Extensions Developer
Lonewolf10's Avatar
 
Join Date: Jun 2007
Location: near Cambridge, UK
Age: 42
Posts: 1,924
Quote:
Originally Posted by mc6809e View Post
This is due to the analog nature of CRTs. The electromagnet in the yoke responsible for the vertical position needs time to reset the beam position to the top of the screen. If the electron beam is still on while this happens, streaks occur as because the electromagnet can't change instantly.
This is all very interesting. I am curious as to whether there are actual images available to show what the streaking looks like if the electron beam is never switched off. I don't suppose you have any?
Lonewolf10 is offline  
Old 14 August 2014, 00:26   #10
mc6809e
Registered User
 
Join Date: Jan 2012
Location: USA
Posts: 331
Quote:
Originally Posted by Lonewolf10 View Post
This is all very interesting. I am curious as to whether there are actual images available to show what the streaking looks like if the electron beam is never switched off. I don't suppose you have any?
Do an image search for retrace lines. A few images will come up.
mc6809e is offline  
Old 14 August 2014, 13:57   #11
pandy71
Registered User
 
Join Date: Jun 2010
Location: PL
Posts: 1,904
Quote:
Originally Posted by Lonewolf10 View Post
This is all very interesting. I am curious as to whether there are actual images available to show what the streaking looks like if the electron beam is never switched off. I don't suppose you have any?
pandy71 is offline  
Old 14 August 2014, 23:28   #12
Lonewolf10
AMOS Extensions Developer
Lonewolf10's Avatar
 
Join Date: Jun 2007
Location: near Cambridge, UK
Age: 42
Posts: 1,924
Quote:
Originally Posted by mc6809e View Post
Do an image search for retrace lines. A few images will come up.
Aha! I tried searching yesterday, but I was using the wrong words



pandy71, thanks for the image. That neatly demonstrates the retrace lines
Lonewolf10 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
Combining copper scrolling with copper background phx Coders. Asm / Hardware 16 13 February 2021 13:41
Can anyone here hack a single load Amiga game to add a copper list please? ImmortalA1000 Amiga scene 10 19 January 2012 09:20
Slave Execution using Dopus 4 Zetr0 project.WHDLoad 93 01 February 2011 14:59
Copper list setup for runtime library Samurai_Crow Coders. General 7 26 August 2010 17:14
cud i start a list of 'cycle exact' needing games please kirk support.Games 4 26 April 2009 00:11

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 19:07.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, vBulletin Solutions Inc.
Page generated in 0.09052 seconds with 13 queries