Copper, Horizontal Blanking, and DMA

[AlexBruger]

I'm trying to reconcile various information from different sources:

Abbreviations:
HRM: Hardware Reference Manual
HBG: Horizontal Blanking Gap
[x-y[ = End Exclusive List


Video Info

                     | NTSC         | PAL          |
---------------------+--------------+--------------|
Bus Cycles per Line  |   227.5      |   227        |
HiRes Pixel per Line |   910        |   908        |
Bus Cyle Duration    | ~ 279.365 ns | ~ 281.937 ns |

Observation 1

Looking at the Horizontal Line Blanking Info

                             | NTSC                  | PAL              | PAL-I               |
-----------------------------+-----------------------+------------------+---------------------|
The Line-Blanking Intervals  | 10.9±0.2 micro s      | 12±0.3 micro s   | 12.05±0.25 micro s--|
Front Porch                  |  1.27 to 2.22 micro s |  1.5±0.3 micro s |  1.65±0.1  micro s--|
Synchronizing Pulse          |  4.7±0.1 micro s      |  4.7±0.2 micro s |  4.7 ±0.2  micro s--|

The Synchronization Pulse duration of 4.7 ?s / 280ns si about 17 Bus Cycles
That fits exactly with Fat Agnus Specification (318070/1-01) (NTSC/PAL) (p. 39): Horizontal Sync Pulse is from HC (Horizontal Count) [18 - 35[ making it 17 Bus Cycles.

HRM: Coprocessor Hardware (p. 23) says that the Horizontal blanking falls in the range of $0F to $35.
That makes 39 cycles which is 39 * 280 ns = 10.920 ?s fitting well with the NTSC value of 10.9±0.2 micro s.

Also the Front Porch should be at least 1.27 ?s which is 4.5 Bus Cycles.
Now with the information from the HRM and the Agnus Specification the Front Porch would only be 3 Cycles (HC 15,16,17) unless the HRM assumes a HC starting with 0.
Since the Diagram in the Agnus Specification starts the HC at 1 we would then have a Front Porch of 4 cycles.


Observation 2

HRM: Coprocessor Hardware (p. 23) states:
"The standard screen (320 pixels wide) has an unused horizontal portion of $04 to $47 (during which only the background color is displayed)."
This makes 67 bus cycles per line in BG Color.
With 908 Pixels in PAL that leaves 908 - 4 * 67 = 640 HiRes Pixel = 320 LoRes Pixel.

So my assumption would be that the area filled with BG color ends with DDFSTRT for the nominal values given in the HRM.

BG Color : $04 - $47
DDFSTRT/STOP: $38 - $D0 (HRM: Playfield Hardware (p. 59): Nominal Values for a 320 Resolution Screen)

But we have a 16 bus cycles difference ($48-$38).


Observation 3

Let's assume for the sake of argument that the difference is indeed 16 bus cycles.

Then translating The HBG from Observation 1 into DMA cycles gives us:
[15-54[ => [-1-38[

Now Photon states in
http://eab.abime.net/showthread.php?t=45691
That using a DDFSTRT of $20 (32) the first 14 pixels aren't visible.
Since with the calculation above 6 Cycles (32-37) are still in the HBG I would have assumed that 12 px aren't visible.
But it's too close to be a coincident.

Although with the HBG ending only at Cycle 38 this would leave 908/2 - (38 + 8.5)*2 = 454 - 93 = 361 Pixels for display. (Using the formula from HRM: Playfield Hardware (p. 59))
According to Photon its should be 384-14 = 370.

Looking a the DDFTSRT/DDFSTOP used $20 - $D8 that doesn't seem right.
My understanding is that cycles DC-DF can't be used for the bit-plane DMA, leaving $DC-$20 = 188 Cycles or 376 pixel.
With the first 14 pixel not displayed we should end up with 362.



That leaves my Questions:

Question 1

HRM: Figure 6-9: DMA Time Slot Allocation
a. $40 Data fetch completed for cycle $38
b. Five clocks must occur before the data fetched for a particular position can appear on· screen.
For example. If data fetch start is $38. data will not be available for display until clock number $45.
It is available at $45 because display processing does not begin until all of the bit·planes for a particular Pixel have been fetched.

Statement b. says that there are 5 bus cycles between "fetch complete" and actual display.
The formula from HRM: Playfield Hardware (p. 59) suggests that it's 0.5.
Which one is right?


Question 2

Does the offset between HC and DMA Cycles of 16 cycles make any sense?

The data seems to fit too good to be a mere coincident.
This also places the start of the HGB exactly at the first DMA cycle (-1).
Which may also explain the cryptic message in the Diagram from HRM: Figure 6-9: DMA Time Slot Allocation:
"This cycle 0 appears to exclude one of the memory refresh cycles.
This is not the case. Actual system hardware demands certain specific values for data fetch start and display start.
Therefore this timing chart has been „adjusted“ to match those requirements."

So I guess the DMA Cycles in the diagram have been adjusted to match the start of the HBG.

But I don't get how the Copper would work properly since a wait on position x would mean a wait on position x-16 in DMA-Cycles.
Even taking the 8 Cycles processing time into consideration it would be off by 3 or 7.5 cycles depending on the answer to question 1.

[Toni Wilen]

Some answers, not sure if they help..

Originally Posted by AlexBruger

BG Color : $04 - $47
DDFSTRT/STOP: $38 - $D0 (HRM: Playfield Hardware (p. 59): Nominal Values for a 320 Resolution Screen)

But we have a 16 bus cycles difference ($48-$38).

Assuming lores, actual start is $38 + 8 (single bitplane "block") + 4 (*) + 1. (and actual end is $D8 due to way DDFSTOP works, see below)

*) Not sure where this comes from. Probably documentation error, or they mixed hires and lores (hires would be $38 + 4 + 1)

My understanding is that cycles DC-DF can't be used for the bit-plane DMA, leaving $DC-$20 = 188 Cycles or 376 pixel.
With the first 14 pixel not displayed we should end up with 362.

Bitplane DMA is not inhibited after $D8 ($D8 and DDFSTOP actual behavior was not documented very well). $D8 is position when DDFSTOP condition is forced, even if DDFSTOP value is larger. When current bitplane "block" (4 DMA slots if hires, 8 if lores) ends due to DDFSTOP condition, final bitplane "block" starts. I don't remember exact details but I think last bitplane DMA fetch (to plane 0) can happen at cycle $DF (or $E1).

With some DDFSTRT/STOP tricks it is possible to force bitplane DMA to continue on next line, possibly conflicting with refresh slots causing graphics corruption.

This also places the start of the HGB exactly at the first DMA cycle (-1).
Which may also explain the cryptic message in the Diagram from HRM: Figure 6-9: DMA Time Slot Allocation:
"This cycle 0 appears to exclude one of the memory refresh cycles.
This is not the case. Actual system hardware demands certain specific values for data fetch start and display start.
Therefore this timing chart has been „adjusted“ to match those requirements."

Yeah, cycle "-1" is technically the first cycle, it is also location of first refresh slot. Agnus also uses this slot to send strobe (using strobe RGA registers) to Paula and Denise that next horizontal line (or vsync strobe if first line) starts.

I am not sure why the "adjustment". Perhaps they wanted to hide something

[ross]

Interesting thread

We have discussed of similar thing, in off-topic way, on another thread:
http://eab.abime.net/showthread.php?t=86338

[AlexBruger]

@Toni Wilen

Assuming lores, actual start is $38 + 8 (single bitplane "block") + 4 (*) + 1. (and actual end is $D8 due to way DDFSTOP works, see below)

*) Not sure where this comes from. Probably documentation error, or they mixed hires and lores (hires would be $38 + 4 + 1)

As far as I understand what you are saying is that DDFSTRT at $38 leads to the first pixel (in LoRes) being displayed with cycle $45 just as the HRM says.
And that the $D8 is the final bitplane block. Since it hase 8 cyles the last 16 pixels are displayed with $D8 + 8 + 5 = $E5.
This makes the first pixel not coming from DMA $E5 + 8 = $ED (237).

Also you have shown that the first refresh cycle is indeed -1:
http://eab.abime.net/showpost.php?p=436749&postcount=25

Other interesting observation in the thread:
HPOS in VHPOS is slightly ahead of the VPOS (about 3-4.5 cycles) showing 0 already with the VPOS of the previous line.
Which is also the reason that copper can't use this cycle.
http://eab.abime.net/showpost.php?p=441327&postcount=29
http://eab.abime.net/showpost.php?p=441615&postcount=30

I have put 4 of the diagrams together into one for easier viewing:


Also there seems to be a delay between write to BPL1DAT and the Denise output change of about 2 - 2.5 cycles.
http://eab.abime.net/showpost.php?p=445680&postcount=37
Actually the Signals in the diagram look strange to me.
The data on the data bus seems to be half a cycle late. According to this the data fetch for HiRes would be 5 cycles and not 4.
Although the throughput would still be 4 bitplanes / 4 cycles.

Also I can't follow your conclusion in:
http://eab.abime.net/showpost.php?p=445971&postcount=40

"Yeah, of course, so there is no mysterious Denise delay after all, my theory can still work if delay is before first DMA fetch starts. (mysterious delay is still documented in HRM and same delay is needed in emulation, 9 hires pixels)".

How can a delay before the data fetch be responsible for a delay between the data fetch and the output from Denise.

So putting it all together we have
* DDFSTRT triggers
* about 4 cycle delay (Delay 1)
* Data fetch (8 Cyles LoRes; 4 for HiRes and SuperHiRes) (Delay 2)
* about 2.5 cycles Denise delay (Delay 3)
* Display (after 14.5 cycles LoRes; 10.5 HiRes)

Theory by yaqube for the Delay 1 is that the comparison logic for comparing to a not 0 value is more complex and takes more than one cycle. (http://eab.abime.net/showpost.php?p=446415&postcount=43)
FrenchShark added

"Yep, I agree with yaqube, comparing HPOS with 0's is just a NAND gate.
Comparing it with a value must be done in two stages : XOR's and a NAND gate."

(http://eab.abime.net/showpost.php?p=446548&postcount=46)

Theory by Toni Wilen (http://eab.abime.net/showpost.php?p=446738&postcount=49)
There is an internal bitplane counter that triggers the bitplane block cycles.
Bit 3 for LoRes (8 cycles), Bit 2 for HiRes (4 cycles).
Superhires = perhaps some hack that also uses 4 cycles because it wasn't originally implemented


In http://eab.abime.net/showpost.php?p=446699&postcount=48 a test was performed by writing into the STRHOR register with the copper in the middle of the line.
Leading to 9-10 cycles normal display then display gets blanked for ~38-39 cycles, after that the normal display continues.
39 is the length of the HBG according to my calculations from the first post.
9-10 cycles delay seems long can you tell me exactly from where the cycles have been measured.
According to the above findings I would have expected 4+2.5.


Now we have the problem that the formula from HRM: Playfield Hardware (p. 60)

DDFSTRT = DIWSTRT/2 - 8.5 (LoRes)
DDFSTRT = DIWSTRT/2 - 4.5 (HiRes)

DIWSTRT = (DDFSTRT + 8.5) * 2 (LoRes)
DIWSTRT = (DDFSTRT + 4.5) * 2 (HiRes)

only takes part of the delay into consideration, suggesting that they are offset to each other.
Either DIWSTART 0 is in fact a negative x value in final pixels or that DDFSTRT can't start at pixel 0.

Also could you elaborate on

"With some DDFSTRT/STOP tricks it is possible to force bitplane DMA to continue on next line, possibly conflicting with refresh slots causing graphics corruption."

How exactly?

@ross:
Interesting idea to use the values from the backward compatibility section in the AAA Documentation to find the originals OCS values.

Parameter     NTSC    PAL

BRSTSTART     27      27   (Burst start)
BRSTSTOP      30      30   (Burst stop)
EQU1STOP      1C      1C
EQU2STOP      8D~     8D
HSSTRTX       12      12
HSSTOPX       23      23
HBSTRTX       08      08
HBSTOPX       2B~     2B~
HCENTERX      71~     71~
HTOTALX       E3      E3

~ These events actually occurred the half count after that value.

Values mostly match with what I would expect, except HBSTRTX/HBSTOPX.
The given values would put the burst partly outside the HBG.
Unless there is again an offset involved which would be about 7 cycles in this case.

I also checked the values used in Minimig Source Code:

parameter	HBSTRT_VAL      = 17+4+4;	// horizontal blanking start
parameter	HSSTRT_VAL      = 29+4+4;	// front porch = 1.6us (29)
parameter	HSSTOP_VAL      = 63-1+4+4;	// hsync pulse duration = 4.7us (63)
parameter	HBSTOP_VAL      = 103-5+4;	// back porch = 4.7us (103) shorter blanking for overscan visibility
parameter	HCENTER_VAL     = 256+4+4;	// position of vsync pulse during the long field of interlaced screen

The clock seems to be twice as fast so we have:

HBSTRT : 25/2 = 12.5
HBSTOP : 102/2 = 51
HSSTRT : 37/2 = 18.5
HSSTOP : 70/2 = 35

HBSTRT/HBSTOP is off to what I would expect by about 2-2.5 cycles.
HSSTR/HSSTOP is off to what I would expect by 0.5 cycles.


So this is all the information I could gather on the topic.
I'm still very confused.

[AlexBruger]

Talking to myself, but if people are still interested I think i figured out where the 16 cycles offset from my first post comes from.

In the LogicPort Scans from Toni it's quite visible that the Horizontal Sync Pulse is between the DMA Cycles [15-32[.
According the the Agnus Specification it should be at HC [18-35[.

Now HC starts with 1 and the DMA Cycles start with 0 making this in fact only 2 Cycles Offset but for the calculations from by original post it qualifies as 3 cycles.

Additionally we have for LoRes the 8 Cycles Data Fetch and the 5 Cycles delay described in the "HRM: Figure 6-9: DMA Time Slot Allocation".

Giving us 13 +3 = 16 Cycles.

As you can see in the attachment everything aligns now nicely.

The statements:
HRM: Coprocessor hardware (p. 23):
"Horizontal blanking falls in the range of $0F to $35.
The standard screen (320 pixels wide) has an unused horizontal portion of $04 to $47 (during which only the background color is displayed)."
hold.

The delays described in "HRM: Figure 6-9: DMA Time Slot Allocation" are correct.
And the Agnus Specification Diagram matches too.

Also Photons pixel can now be visible, according to the given information it should even be possible to have another 4 pixels before it.

Still not sure where that leaves the "Copper Wait" listening to HC.

[Toni Wilen]

Originally Posted by AlexBruger

Also there seems to be a delay between write to BPL1DAT and the Denise output change of about 2 - 2.5 cycles.
http://eab.abime.net/showpost.php?p=445680&postcount=37
Actually the Signals in the diagram look strange to me.
The data on the data bus seems to be half a cycle late. According to this the data fetch for HiRes would be 5 cycles and not 4.
Although the throughput would still be 4 bitplanes / 4 cycles.

I didn't include delay after Denise has decided pixel color. Color coming out of Denise + digital to analog conversion probably explains the extra delay.

Also I can't follow your conclusion in:
http://eab.abime.net/showpost.php?p=445971&postcount=40

I wouldn't trust all very old posts when there was more unknown variables left to found.

In http://eab.abime.net/showpost.php?p=446699&postcount=48 a test was performed by writing into the STRHOR register with the copper in the middle of the line.
Leading to 9-10 cycles normal display then display gets blanked for ~38-39 cycles, after that the normal display continues.
39 is the length of the HBG according to my calculations from the first post.
9-10 cycles delay seems long can you tell me exactly from where the cycles have been measured.
According to the above findings I would have expected 4+2.5.

I can recheck this later.

It would be much easier and accurate if there would be externally available blank pin..

I can also do measurements with my logic analyzer and scope if needed. Just describe required test case extremely well

With some DDFSTRT/STOP tricks it is possible to force bitplane DMA to continue on next line, possibly conflicting with refresh slots causing graphics corruption.

Set "unaligned" DDFSTRT so that "block" end becomes cycle $D4 and DDFSTOP to >$D4. $D4+8+8=E4 -> overrun. Even easier with ECS/AGA because you can set end to $D6. Extremely easy with AGA 32/64-bit fetch modes