Hardwarescroll BPLCON1 timing question

Rock'n Roll · 23 March 2023, 20:47

I made some tests with BPLCON1 on one line

Code:

HW_SCROLL:
	dc.w $2c3d,$fffe	; first wait - if $2c3f - BPLCON1 change is 16 pixel later
	dc.w $102,$ff
	dc.w $2c4d,$fffe		
	dc.w $102,$00
	
	dc.w $2c5d,$fffe	; horizontal wait +$10
	dc.w $102,$ff
	dc.w $2c6d,$fffe		
	dc.w $102,$00

	dc.w $2c75,$fffe	; horizontal wait +$8
	dc.w $102,$ff
	dc.w $2c7d,$fffe		
	dc.w $102,$00
	
	dc.w $2cdf,$fffe	; end of line
	dc.w $102,$00

From my investigation I get following results:
- the change of BPLCON1 can be made every 16 pixels.
- i.e. 20x per 320x256 lowres screen
- with a Copper-Wait and Move spacing horizontally $10 (Wait + Move = 16 pixels)
- or with 40 copper moves in a row, only every second copper move, as a copper move requires 8 pixels
- the gap of one pixel remains after a scroll of $ff (15px) and back $00 because we can not scroll 16 pixel
- by a smaller hardware scroll value, the pixels from the previous word are then cut off on the right

- this procedure must be correct timing between copper move and screen data fetch for synchronizing.
But what is the formula for the beginning of the first Wait-Position?

DIWSTRT ist $2c81 and DDFSTRT ist $0038
Through my test I see $2c3d,$fffe matches good, but how can I calculate the first and all the other
possible Wait-positions in a row for Copper Wait/Copper-Move for BPLCON1?

Rock'n Roll · 24 March 2023, 21:45

The main problem has something to do with the zooming effect.
Their is something strange for me in the program and I don't understand why it not works
as I would aspect. I analyze but in the moment I can not explain what happens.

I believe their ist a timing problem between copper and data fetch.

So maybe one problem is solved. I said a proper wait position is dc.w $2c3d,$fffe.
Maybe better would be dc.w $2c39,$fffe, because:

DIWSTRT is $2c81 and DDFSTRT is $0038
a Copper-Move needs 8 Pixel, so I calculate ($80/2)-8=$38 (for wait)

dc.w $2c39,$fffe
dc.w $0102,$ff

I analyze with dma-debugger but it confused me.
Normaly I would see the last bitplane data is data for BPL1 and the Copper-Move
with changing BPLCON1 is in the last free Copper Cycle before BPL1 data.

But with the dma debugger I get strange info.

WinUAE 4.9.10

Code:

>v $40 $80
Line: 40  64 HPOS 80 128:
 [80     0]   [81     0]   [82     0]   [83     0]   [84     0]   [85     0]   [86     0]   [87     0]
 COP    08C                COP    1FE   BPL1   110   COP    08C                COP    102   BPL2   112
       01FE                      0000         01FF         0102                      0000         FFFF
   0003D018                  0003D01A     0003E070     0003D01C                  0003D01E     00040872

  10C   0E8                 10D   0E8    138   0F0    10E   0E8                 10F   0E8    039   104

 [88     0]   [89     0]   [8A     0]   [8B     0]   [8C     0]   [8D     0]   [8E     0]   [8F     0]
 COP    08C                COP    1FE   BPL1   110   COP    08C                COP    1FE   BPL2   112
       01FE                      0000         03FF         01FE                      0000         FFFF
   0003D020                  0003D022     0003E072     0003D024                  0003D026     00040874

; COP 1FE BPL1 110 COP 08C COP 102 BPL2 112
; why is BPL1 before BPL2 ?

WinUAE 4.4

Code:

>v $40 $80
Line: 40  64 HPOS 80 128:
 [80 128]  [81 129]  [82 130]  [83 131]  [84 132]  [85 133]  [86 134]  [87 135]
 COP  08C            COP  102       112  COP  08C            COP  1FE       110
     0102                0000      FFFF      01FE                0000      03FF
 0003D01C            0003D01E  00040872  0003D020            0003D022  0003E072
 521C6400  521C6600  521C6800  521C6A00  521C6C00  521C6E00  521C7000  521C7200

 [88 136]  [89 137]  [8A 138]  [8B 139]  [8C 140]  [8D 141]  [8E 142]  [8F 143]
 COP  08C            COP  1FE       112  COP  08C            COP  1FE       110
     01FE                0000      FFFF      01FE                0000      07FF
 0003D024            0003D026  00040874  0003D028            0003D02A  0003E074
 521C7400  521C7600  521C7800  521C7A00  521C7C00  521C7E00  521C8000  521C8200

; COP 08C BPL4 116 BPL6 11A BPL2 112 COP 180 BPL3 114 BPL5 118 BPL1 110 COP 08C BPL4 116 BPL6 11A BPL2 112

Toni Wilen · 25 March 2023, 13:01

I don't know what you are really asking but for last question: check cycle $7F.

Rock'n Roll · 25 March 2023, 16:59

1. general:
The question is when to change BPLCON1 if you want to be in sync with reading the 16 pixels?

DMA-Time Slot Diagramm: for a part of 16 Pixel: DDFSTRT $38
Bitplane-and Coppercycles:

Code:

DDFSTRT on $38
 [38  56]  [39  57]  [3A  58]  [3B  59]  [3C  60]  [3D  61]  [3E  62]  [3F  63]       
    1          2        3          4        -       BPL4      BPL6      BPL2
  (free)              (free)              (free)	     (steal)
   COP                 COP                  COP                COP
  
 [40  64]  [41  65]  [42  66]  [43  67]  [44  68]  [45  69]  [46  70]  [47  71]	  [48  72]  [49  73]
 COP  08C   BPL3       BPL5     BPL1						    1		2
  (free)              (steal)							  (free) 
   COP                 COP                  COP                COP		   COP	     Data shown on Screen

$38 - DDFSTRT
$43 - DFFSTRT finished
$48 - then 5 cylces wait
$49 - data shown on screen (17 pixel later then DDFSTRT or 8,5 cycles)

2. Which is the last Copper Position which the the Hardwarescroll Value with BPLCON1 changes?

Code:

  DDFSTRT on $38
 [38  56]  [39  57]  [3A  58]  [3B  59]  [3C  60]  [3D  61]  [3E  62]  [3F  63]       
 COP  08C     2      COP  102    4       COP  08C    BPL4    COP  102    BPL2
      102	         0055		      102	         0044
  (free)              (free)              (free)	      (steal)
   COP                 COP                  COP                 COP
  
 [40  64]  [41  65]  [42  66]  [43  67]  [44  68]  [45  69]  [46  70]  [47  71]	  [48  72]  [49  73]
 COP  08C   BPL3     COP  102   BPL1	 COP  08C	     COP  102		    1	        2
      102	         0033		      102	         0022
  (free)              (steal)							  (free) 
   COP                 COP                  COP                 COP		   COP	     Data shown on Screen

3. For this example which value would be take from the videologic?
the last one? dc.w $102,$0022 ? and all the previous are ignored?

4. if so, then I have to make a wait on: $44?
dc.w $2c45,$fffe ; a copper move needs 8 pixel lowres
dc.w $0102,$0022

5. this would be also synchronized with all the other in a row of 40 Copper Moves
dc.w $01FE,$0000
dc.w $01FE,$0000
dc.w $01FE,$0000
dc.w $0102,$0011 ; new value this is in distance: + HH=$20

6. or if I want no row of 40 copper moves
find (calculate not empiric) the correct wait-position for the next
copper move dc.w $0102,$00xx for all (or certain) from the other 19x16 pixels (320x256) in the row.

Rock'n Roll · 28 March 2023, 21:19

Thanks, to the DMA-Debugger. I found the answers by myself.

1. always the last BPLCON1 value before BPL1-DMA-Cycle sets actual hardwarescrollvalue
2. the closest wait-position for a normal lowres-screen would be dc.w $VV3d,$fffe
3. the calculation for all possible wait-position follows this rule:

HH=BPL1+1 eg. $3B+1=$C --> copper wait $3D
or general BPL1_Start=$2b $2b+n*8+1 (+1 Copper-Wait)
eg. for the 6. 16 pixel group $2B+6*8+1 --> dc.w $3a55,$fffe

$2B - 1. dc.w $3a2d,$fffe (1. 16. pixel group) ; overscan
$33 - 2. dc.w $3a35,$fffe (2. 16. pixel group)
$3B - 3. dc.w $3a3d,$fffe ; normal diwstrt: $2c81 or ddfstrt: $38
$43 - 4. dc.w $3a45,$fffe
$4B - 5. dc.w $3a4d,$fffe
$53 - 6 dc.w $3a55,$fffe
$5B - 7. dc.w $3a5d,$fffe
...
$d3 - 22. dc.w $3ad5,$fffe (22. 16. pixel group) ; overscan

4. with a wait-position and copper move it is only possible to change the BPLCON1 value every 32 pixel
because wait+move needs 8+4 CCKs = 24 pixel
--> that means: no 16 pixel synchronisation is possible

dc.w $3a3d,$fffe ; horizontal wait
dc.w $102,$ff
dc.w $3a45,$fffe ; results in a wait for dc.w $3a4d,$fffe
dc.w $102,$00

Code:

[30  48]  [31  49]  [32  50]  [33  51]  [34  52]  [35  53]  [36  54]  [37  55]
                               BPL1 110
                                   FFFF                      W
                               0006A9DA
 FFF28E00  FFF29000  FFF29200  FFF29400  FFF29600  FFF29800  FFF29A00  FFF29C00

 [38  56]  [39  57]  [3A  58]  [3B  59]  [3C  60]  [3D  61]  [3E  62]  [3F  63]	; 8 CCK = 16 Pixel
 COP  08C            COP  102  BPL1 110  COP  08C            COP  08C
     0102                000F      FFFF      3A45                FFFE
 0006CD60            0006CD62  0006A9DC  0006CD64            0006CD64
 FFF29E00  FFF2A000  FFF2A200  FFF2A400  FFF2A600  FFF2A800  FFF2AA00  FFF2AC00

 [40  64]  [41  65]  [42  66]  [43  67]  [44  68]  [45  69]  [46  70]  [47  71]	; after 8 CCK = 16 pixel
                               BPL1 110
                                   FFFF                      W
                               0006A9DE
 FFF2AE00  FFF2B000  FFF2B200  FFF2B400  FFF2B600  FFF2B800  FFF2BA00  FFF2BC00

 [48  72]  [49  73]  [4A  74]  [4B  75]  [4C  76]  [4D  77]  [4E  78]  [4F  79]	; after 8 CCK = 16 pixel = sum 32 pixel
 COP  08C            COP  102  BPL1 110  COP  08C            COP  08C
     0102                0000      FFFF      5A55                FFFE
 0006CD68            0006CD6A  0006A9E0  0006CD6C            0006CD6C
 FFF2BE00  FFF2C000  FFF2C200  FFF2C400  FFF2C600  FFF2C800  FFF2CA00  FFF2CC00

5. with a copper move in a row it is possible to change BPLCON1 to every $8
that means: 16 pixel synchronisation is possible (copper-move needs 8 pixel)

dc.w $3a35,$fffe ; horizontal wait
dc.w $102,$ff
dc.w $102,$ff ; could be a dc.w $01FE,$0000 (Copper Nop)
dc.w $102,$00 ; last before BPL1 wins

Code:

[30  48]  [31  49]  [32  50]  [33  51]  [34  52]  [35  53]  [36  54]  [37  55]
 COP  08C            COP  102  BPL1 110  COP  08C            COP  102
     0102                000F      FFFF      0102                000F
 0006CD60            0006CD62  0006A9DA  0006CD64            0006CD66
 68FEC200  68FEC400  68FEC600  68FEC800  68FECA00  68FECC00  68FECE00  68FED000

 [38  56]  [39  57]  [3A  58]  [3B  59]  [3C  60]  [3D  61]  [3E  62]  [3F  63]
 COP  08C            COP  102  BPL1 110  COP  08C            COP  08C
     0102                0000      FFFF      5A55                FFFE
 0006CD68            0006CD6A  0006A9DC  0006CD6C            0006CD6C
 68FED200  68FED400  68FED600  68FED800  68FEDA00  68FEDC00  68FEDE00  68FEE000

Toffee · 20 April 2023, 23:02

Rock'n Roll I hope you are working on a nice zoomer for a demo ??

In your experiments have you tried 102/BPLCON1 zooming with dual playfield? I think copper write speed drops to a move every 16 pixels with > 4 bitplanes. Not sure how this effects the timing of spamming BPLCON1.

Toffee · 21 April 2023, 00:06

This might also be worth a read:-
https://www.stashofcode.fr/zoom-hard...on1-sur-amiga/

"It should be noted that such solicitation of the Copper constrains the number of bitplanes, therefore the number of colors on the screen. The reason for this has already been presented here : beyond 4 bitplanes, the hardware steals cycles from the Copper, so that the latter loses the possibility of executing as many MOVEs per line:"

Rock'n Roll · 21 April 2023, 15:24

yes, correct https://www.stashofcode.com/hardware...-on-the-amiga/
and zoom2.s was the cause of the question.
In the lesson Yragael brings the question itself into play. search for "Mais où attendre ?"

But my initial question was this graphic with the theoretical hardwarescroll values:
https://www.stashofcode.fr/wp-conten...-8-400x247.png

And I asked me why looks the table "zoom" in the program different to the graphic and is not synchron?
I mean this:

DC.B 11,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,1,0,1,0,1,0,1,1,1,0,1,0,0,0,0,0,0,0,0,0,0,0,0 ; BPLCON1 : $000B -> $0003

and I asked me why not so:

DC.B 11,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,0,0,0,0,0,0,0,0,0

23 March 2023, 20:47	#1
Rock'n Roll German Translator Join Date: Aug 2018 Location: Drübeck / Germany Age: 48 Posts: 103	Hardwarescroll BPLCON1 timing question I made some tests with BPLCON1 on one line Code: HW_SCROLL: dc.w $2c3d,$fffe ; first wait - if $2c3f - BPLCON1 change is 16 pixel later dc.w $102,$ff dc.w $2c4d,$fffe dc.w $102,$00 dc.w $2c5d,$fffe ; horizontal wait +$10 dc.w $102,$ff dc.w $2c6d,$fffe dc.w $102,$00 dc.w $2c75,$fffe ; horizontal wait +$8 dc.w $102,$ff dc.w $2c7d,$fffe dc.w $102,$00 dc.w $2cdf,$fffe ; end of line dc.w $102,$00 From my investigation I get following results: - the change of BPLCON1 can be made every 16 pixels. - i.e. 20x per 320x256 lowres screen - with a Copper-Wait and Move spacing horizontally $10 (Wait + Move = 16 pixels) - or with 40 copper moves in a row, only every second copper move, as a copper move requires 8 pixels - the gap of one pixel remains after a scroll of $ff (15px) and back $00 because we can not scroll 16 pixel - by a smaller hardware scroll value, the pixels from the previous word are then cut off on the right - this procedure must be correct timing between copper move and screen data fetch for synchronizing. But what is the formula for the beginning of the first Wait-Position? DIWSTRT ist $2c81 and DDFSTRT ist $0038 Through my test I see $2c3d,$fffe matches good, but how can I calculate the first and all the other possible Wait-positions in a row for Copper Wait/Copper-Move for BPLCON1?

24 March 2023, 21:45	#2
Rock'n Roll German Translator Join Date: Aug 2018 Location: Drübeck / Germany Age: 48 Posts: 103	The main problem has something to do with the zooming effect. Their is something strange for me in the program and I don't understand why it not works as I would aspect. I analyze but in the moment I can not explain what happens. I believe their ist a timing problem between copper and data fetch. So maybe one problem is solved. I said a proper wait position is dc.w $2c3d,$fffe. Maybe better would be dc.w $2c39,$fffe, because: DIWSTRT is $2c81 and DDFSTRT is $0038 a Copper-Move needs 8 Pixel, so I calculate ($80/2)-8=$38 (for wait) dc.w $2c39,$fffe dc.w $0102,$ff I analyze with dma-debugger but it confused me. Normaly I would see the last bitplane data is data for BPL1 and the Copper-Move with changing BPLCON1 is in the last free Copper Cycle before BPL1 data. But with the dma debugger I get strange info. WinUAE 4.9.10 Code: >v $40 $80 Line: 40 64 HPOS 80 128: [80 0] [81 0] [82 0] [83 0] [84 0] [85 0] [86 0] [87 0] COP 08C COP 1FE BPL1 110 COP 08C COP 102 BPL2 112 01FE 0000 01FF 0102 0000 FFFF 0003D018 0003D01A 0003E070 0003D01C 0003D01E 00040872 10C 0E8 10D 0E8 138 0F0 10E 0E8 10F 0E8 039 104 [88 0] [89 0] [8A 0] [8B 0] [8C 0] [8D 0] [8E 0] [8F 0] COP 08C COP 1FE BPL1 110 COP 08C COP 1FE BPL2 112 01FE 0000 03FF 01FE 0000 FFFF 0003D020 0003D022 0003E072 0003D024 0003D026 00040874 ; COP 1FE BPL1 110 COP 08C COP 102 BPL2 112 ; why is BPL1 before BPL2 ? WinUAE 4.4 Code: >v $40 $80 Line: 40 64 HPOS 80 128: [80 128] [81 129] [82 130] [83 131] [84 132] [85 133] [86 134] [87 135] COP 08C COP 102 112 COP 08C COP 1FE 110 0102 0000 FFFF 01FE 0000 03FF 0003D01C 0003D01E 00040872 0003D020 0003D022 0003E072 521C6400 521C6600 521C6800 521C6A00 521C6C00 521C6E00 521C7000 521C7200 [88 136] [89 137] [8A 138] [8B 139] [8C 140] [8D 141] [8E 142] [8F 143] COP 08C COP 1FE 112 COP 08C COP 1FE 110 01FE 0000 FFFF 01FE 0000 07FF 0003D024 0003D026 00040874 0003D028 0003D02A 0003E074 521C7400 521C7600 521C7800 521C7A00 521C7C00 521C7E00 521C8000 521C8200 ; COP 08C BPL4 116 BPL6 11A BPL2 112 COP 180 BPL3 114 BPL5 118 BPL1 110 COP 08C BPL4 116 BPL6 11A BPL2 112

25 March 2023, 16:59	#4
Rock'n Roll German Translator Join Date: Aug 2018 Location: Drübeck / Germany Age: 48 Posts: 103	1. general: The question is when to change BPLCON1 if you want to be in sync with reading the 16 pixels? DMA-Time Slot Diagramm: for a part of 16 Pixel: DDFSTRT $38 Bitplane-and Coppercycles: Code: DDFSTRT on $38 [38 56] [39 57] [3A 58] [3B 59] [3C 60] [3D 61] [3E 62] [3F 63] 1 2 3 4 - BPL4 BPL6 BPL2 (free) (free) (free) (steal) COP COP COP COP [40 64] [41 65] [42 66] [43 67] [44 68] [45 69] [46 70] [47 71] [48 72] [49 73] COP 08C BPL3 BPL5 BPL1 1 2 (free) (steal) (free) COP COP COP COP COP Data shown on Screen $38 - DDFSTRT $43 - DFFSTRT finished $48 - then 5 cylces wait $49 - data shown on screen (17 pixel later then DDFSTRT or 8,5 cycles) 2. Which is the last Copper Position which the the Hardwarescroll Value with BPLCON1 changes? Code: DDFSTRT on $38 [38 56] [39 57] [3A 58] [3B 59] [3C 60] [3D 61] [3E 62] [3F 63] COP 08C 2 COP 102 4 COP 08C BPL4 COP 102 BPL2 102 0055 102 0044 (free) (free) (free) (steal) COP COP COP COP [40 64] [41 65] [42 66] [43 67] [44 68] [45 69] [46 70] [47 71] [48 72] [49 73] COP 08C BPL3 COP 102 BPL1 COP 08C COP 102 1 2 102 0033 102 0022 (free) (steal) (free) COP COP COP COP COP Data shown on Screen 3. For this example which value would be take from the videologic? the last one? dc.w $102,$0022 ? and all the previous are ignored? 4. if so, then I have to make a wait on: $44? dc.w $2c45,$fffe ; a copper move needs 8 pixel lowres dc.w $0102,$0022 5. this would be also synchronized with all the other in a row of 40 Copper Moves dc.w $01FE,$0000 dc.w $01FE,$0000 dc.w $01FE,$0000 dc.w $0102,$0011 ; new value this is in distance: + HH=$20 6. or if I want no row of 40 copper moves find (calculate not empiric) the correct wait-position for the next copper move dc.w $0102,$00xx for all (or certain) from the other 19x16 pixels (320x256) in the row. Last edited by Rock'n Roll; 25 March 2023 at 17:40.

28 March 2023, 21:19	#5
Rock'n Roll German Translator Join Date: Aug 2018 Location: Drübeck / Germany Age: 48 Posts: 103	Thanks, to the DMA-Debugger. I found the answers by myself. 1. always the last BPLCON1 value before BPL1-DMA-Cycle sets actual hardwarescrollvalue 2. the closest wait-position for a normal lowres-screen would be dc.w $VV3d,$fffe 3. the calculation for all possible wait-position follows this rule: HH=BPL1+1 eg. $3B+1=$C --> copper wait $3D or general BPL1_Start=$2b $2b+n8+1 (+1 Copper-Wait) eg. for the 6. 16 pixel group $2B+68+1 --> dc.w $3a55,$fffe $2B - 1. dc.w $3a2d,$fffe (1. 16. pixel group) ; overscan $33 - 2. dc.w $3a35,$fffe (2. 16. pixel group) $3B - 3. dc.w $3a3d,$fffe ; normal diwstrt: $2c81 or ddfstrt: $38 $43 - 4. dc.w $3a45,$fffe $4B - 5. dc.w $3a4d,$fffe $53 - 6 dc.w $3a55,$fffe $5B - 7. dc.w $3a5d,$fffe ... $d3 - 22. dc.w $3ad5,$fffe (22. 16. pixel group) ; overscan 4. with a wait-position and copper move it is only possible to change the BPLCON1 value every 32 pixel because wait+move needs 8+4 CCKs = 24 pixel --> that means: no 16 pixel synchronisation is possible dc.w $3a3d,$fffe ; horizontal wait dc.w $102,$ff dc.w $3a45,$fffe ; results in a wait for dc.w $3a4d,$fffe dc.w $102,$00 Code: [30 48] [31 49] [32 50] [33 51] [34 52] [35 53] [36 54] [37 55] BPL1 110 FFFF W 0006A9DA FFF28E00 FFF29000 FFF29200 FFF29400 FFF29600 FFF29800 FFF29A00 FFF29C00 [38 56] [39 57] [3A 58] [3B 59] [3C 60] [3D 61] [3E 62] [3F 63] ; 8 CCK = 16 Pixel COP 08C COP 102 BPL1 110 COP 08C COP 08C 0102 000F FFFF 3A45 FFFE 0006CD60 0006CD62 0006A9DC 0006CD64 0006CD64 FFF29E00 FFF2A000 FFF2A200 FFF2A400 FFF2A600 FFF2A800 FFF2AA00 FFF2AC00 [40 64] [41 65] [42 66] [43 67] [44 68] [45 69] [46 70] [47 71] ; after 8 CCK = 16 pixel BPL1 110 FFFF W 0006A9DE FFF2AE00 FFF2B000 FFF2B200 FFF2B400 FFF2B600 FFF2B800 FFF2BA00 FFF2BC00 [48 72] [49 73] [4A 74] [4B 75] [4C 76] [4D 77] [4E 78] [4F 79] ; after 8 CCK = 16 pixel = sum 32 pixel COP 08C COP 102 BPL1 110 COP 08C COP 08C 0102 0000 FFFF 5A55 FFFE 0006CD68 0006CD6A 0006A9E0 0006CD6C 0006CD6C FFF2BE00 FFF2C000 FFF2C200 FFF2C400 FFF2C600 FFF2C800 FFF2CA00 FFF2CC00 5. with a copper move in a row it is possible to change BPLCON1 to every $8 that means: 16 pixel synchronisation is possible (copper-move needs 8 pixel) dc.w $3a35,$fffe ; horizontal wait dc.w $102,$ff dc.w $102,$ff ; could be a dc.w $01FE,$0000 (Copper Nop) dc.w $102,$00 ; last before BPL1 wins Code: [30 48] [31 49] [32 50] [33 51] [34 52] [35 53] [36 54] [37 55] COP 08C COP 102 BPL1 110 COP 08C COP 102 0102 000F FFFF 0102 000F 0006CD60 0006CD62 0006A9DA 0006CD64 0006CD66 68FEC200 68FEC400 68FEC600 68FEC800 68FECA00 68FECC00 68FECE00 68FED000 [38 56] [39 57] [3A 58] [3B 59] [3C 60] [3D 61] [3E 62] [3F 63] COP 08C COP 102 BPL1 110 COP 08C COP 08C 0102 0000 FFFF 5A55 FFFE 0006CD68 0006CD6A 0006A9DC 0006CD6C 0006CD6C 68FED200 68FED400 68FED600 68FED800 68FEDA00 68FEDC00 68FEDE00 68FEE000

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
BPLCON1 AGA - odd behaviour	buzzybee	support.FS-UAE	0	09 April 2022 21:21
Fixing a WHDLoad slave - Timing question	Radertified	Coders. Asm / Hardware	14	04 June 2020 15:40
BPLCON1 Scroll Left & Right	DanielAllsopp	Coders. Asm / Hardware	6	13 February 2020 15:01
BPLCON1 scroll values in HiRes	Yragael	Coders. Asm / Hardware	5	28 September 2018 17:52
timing fix question ACA	trydowave	support.Hardware	5	19 August 2013 18:21

25 March 2023, 13:01	#3
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 48 Posts: 25,940	I don't know what you are really asking but for last question: check cycle $7F.

20 April 2023, 23:02	#6
Toffee Registered User Join Date: Sep 2008 Location: Farnborough Posts: 143	Rock'n Roll I hope you are working on a nice zoomer for a demo ?? In your experiments have you tried 102/BPLCON1 zooming with dual playfield? I think copper write speed drops to a move every 16 pixels with > 4 bitplanes. Not sure how this effects the timing of spamming BPLCON1.

21 April 2023, 00:06	#7
Toffee Registered User Join Date: Sep 2008 Location: Farnborough Posts: 143	This might also be worth a read:- https://www.stashofcode.fr/zoom-hard...on1-sur-amiga/ "It should be noted that such solicitation of the Copper constrains the number of bitplanes, therefore the number of colors on the screen. The reason for this has already been presented here : beyond 4 bitplanes, the hardware steals cycles from the Copper, so that the latter loses the possibility of executing as many MOVEs per line:"

21 April 2023, 15:24	#8
Rock'n Roll German Translator Join Date: Aug 2018 Location: Drübeck / Germany Age: 48 Posts: 103	yes, correct https://www.stashofcode.com/hardware...-on-the-amiga/ and zoom2.s was the cause of the question. In the lesson Yragael brings the question itself into play. search for "Mais où attendre ?" But my initial question was this graphic with the theoretical hardwarescroll values: https://www.stashofcode.fr/wp-conten...-8-400x247.png And I asked me why looks the table "zoom" in the program different to the graphic and is not synchron? I mean this: DC.B 11,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,1,0,1,0,1,0,1,1,1,0,1,0,0,0,0,0,0,0,0,0,0,0,0 ; BPLCON1 : $000B -> $0003 and I asked me why not so: DC.B 11,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,0,0,0,0,0,0,0,0,0

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