Copper list execution start.

[nandius_c]

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!

[Photon]

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.

[nandius_c]

Originally Posted by Photon

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!

[Toni Wilen]

Originally Posted by Photon

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)

[Photon]

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.

[Toni Wilen]

Originally Posted by Photon

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

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.

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

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!

[nandius_c]

Thank you so much for your comments, dudes!

[mc6809e]

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.

[Lonewolf10]

Originally Posted by mc6809e

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?

[mc6809e]

Originally Posted by Lonewolf10

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.

[pandy71]

Originally Posted by Lonewolf10

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]

Originally Posted by mc6809e

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