![]() |
![]() |
#1 |
Registered User
Join Date: May 2020
Location: Austria
Posts: 11
|
Copper, Horizontal Blanking, and DMA
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 Code:
| 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 Code:
| 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--| 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. Last edited by AlexBruger; 18 July 2020 at 06:14. |
![]() |
![]() |
#2 | |||
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,612
|
Some answers, not sure if they help..
Quote:
*) Not sure where this comes from. Probably documentation error, or they mixed hires and lores (hires would be $38 + 4 + 1) Quote:
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. Quote:
I am not sure why the "adjustment". Perhaps they wanted to hide something ![]() |
|||
![]() |
![]() |
#3 |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,536
|
Interesting thread
![]() We have discussed of similar thing, in off-topic way, on another thread: http://eab.abime.net/showthread.php?t=86338 |
![]() |
![]() |
#4 | ||||
Registered User
Join Date: May 2020
Location: Austria
Posts: 11
|
@Toni Wilen
Quote:
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 Quote:
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 Quote:
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 Quote:
@ross: Interesting idea to use the values from the backward compatibility section in the AAA Documentation to find the originals OCS values. Code:
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. 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: 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 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. |
||||
![]() |
![]() |
#5 |
Registered User
Join Date: May 2020
Location: Austria
Posts: 11
|
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. |
![]() |
![]() |
#6 | ||||
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,612
|
Quote:
Quote:
Quote:
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 ![]() Quote:
![]() |
||||
![]() |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
Combining copper scrolling with copper background | phx | Coders. Asm / Hardware | 16 | 13 February 2021 12:41 |
Copper Horizontal Wait Problems | mcgeezer | Coders. Asm / Hardware | 5 | 21 May 2020 16:45 |
Copper instructions and dma | Jherek Carnelia | Coders. Asm / Hardware | 4 | 05 December 2019 22:33 |
Best way to mix blitting with copper and copper effects | roondar | Coders. Asm / Hardware | 3 | 12 September 2016 13:12 |
Horizontal Blanking | sandruzzo | Coders. General | 18 | 17 January 2012 09:27 |
|
|