English Amiga Board


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

 
 
Thread Tools
Old 18 October 2021, 20:18   #1
chadderack
Registered User

chadderack's Avatar
 
Join Date: Jul 2021
Location: Sandy, UT
Age: 53
Posts: 230
FIXED! Scroll/horizontal delay issue (with copper split)

Single playfield (4 bps) is split in the copper with waits; before the wait there are one set of bitplane pointers; after the wait, another set. The "split" moves up and down with the vertical scroll, etc. Partially scrolled down so that the vertical split is visible in the horizontal middle of the screen.

The problem is that the horizontal scroll delay is fine for the top half of the split; but it has that characteristic "jerk" in the bottom half. The confusing part is that I don't reset the scroll delay after the wait. It should be the same as before the wait, because I only set it at the top of the copperlist.

The data in the top split is from the same source buffer as the bottom--the pointers are just pointing at the "top" of the bitmap.

Any thoughts as to why this bug might happen?

A video demonstrating the problem (don't mind the unblitted blocks... I'm just trying to solve scroll delay). Thanks!

https://www.dropbox.com/s/l6nfkso43kcycxd/bug.mp4?dl=0

Last edited by chadderack; 19 October 2021 at 00:16.
chadderack is offline  
Old 18 October 2021, 20:58   #2
chadderack
Registered User

chadderack's Avatar
 
Join Date: Jul 2021
Location: Sandy, UT
Age: 53
Posts: 230
Additionally, I did check each frame in WinUAE debug, and the copperlist pointers are synced after each blit (one is $5800 below the other--the height of the split in bytes).

I was thinking maybe the pointers got out of sync for a single frame.

Also thought that maybe the copper didn't get to the bottom of the copperlist for a single frame, but that's not true. I set the yellow color in the bottom split at the very end of the copperlist... and the yellow background is there in the frame that glitches. This means that the copperlist finishes every frame.
chadderack is offline  
Old 18 October 2021, 21:07   #3
Photon
Moderator

Photon's Avatar
 
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,174
Looks like the bitplane pointers increase/decrease at the split are mismatched to the scroll value by 1px. (E.g. the calculation has a neg instead of a not or similar.)

Note that if you poke the Copper from code running on the VBI or after a wait for vertical blank, you get a race condition unless you put a CWAIT before writing to sprite/bitplane registers. (VPOS $19 PAL, $13 NTSC).
Photon is offline  
Old 18 October 2021, 21:26   #4
DanScott
Lemon. / Core Design

DanScott's Avatar
 
Join Date: Mar 2016
Location: Tier 5
Posts: 1,100
yep, looks like a race condition to me too...

if your screen starts at (for example) line $2c.. then consider setting you bitplane pointers and other BPLCON registers after a wait for start of line $2b... this gives you plenty of time after the VBI starts to update bitplane pointers, scroll values etc...
DanScott is offline  
Old 18 October 2021, 23:14   #5
chadderack
Registered User

chadderack's Avatar
 
Join Date: Jul 2021
Location: Sandy, UT
Age: 53
Posts: 230
Quote:
Originally Posted by Photon View Post
Looks like the bitplane pointers increase/decrease at the split are mismatched to the scroll value by 1px. (E.g. the calculation has a neg instead of a not or similar.)
Thank you Photon. I can confirm this with a screenshot. Single stepping shows that the bottom split is out of sync by an entire tile (2 bytes off in the bitplane) for a single frame.

Quote:
Note that if you poke the Copper from code running on the VBI or after a wait for vertical blank, you get a race condition unless you put a CWAIT before writing to sprite/bitplane registers. (VPOS $19 PAL, $13 NTSC).
Interesting. Was not aware of that. It just shows more of my unfamiliarity with the Amiga hardware. Thank you.

Yep; I was pretty much manipulating the entire list in the vertical blank--AND doing the scroll code.

In terms of the error, the bitplane pointer values showing in copperlist memory in the debugger appear to line up exactly every frame, although visually I can screenshot the single frame when they are not. It shows all of the tiles shifted to the right by exactly 16 pixels--so it's not a horizontal delay bug.

I assume the race condition causes the problem, and by the time I see the bitplane pointers in WinUAE debug, they are in sync again.

Quote:
Originally Posted by DanScott View Post
yep, looks like a race condition to me too...

if your screen starts at (for example) line $2c.. then consider setting you bitplane pointers and other BPLCON registers after a wait for start of line $2b... this gives you plenty of time after the VBI starts to update bitplane pointers, scroll values etc...
Thank you, Dan. More expertise I lack, as of yet, in the hardware. I'll try as you suggest.

I'm glad there are actual experts here to help Thanks again.
chadderack is offline  
Old 18 October 2021, 23:29   #6
chadderack
Registered User

chadderack's Avatar
 
Join Date: Jul 2021
Location: Sandy, UT
Age: 53
Posts: 230
Thanks to Dan and Photon, I'm definitely seeing some improvement in the bug.

An extra wait at the beginning of the CLIST seems to alleviate the issue somewhat; $1901,$fffe seems too early still... the out-of-sync happens only every 3rd frame or so. $2b01,$fffe seems to be too late... the top split starts to lag a little there, too.

Suggests to me that I'm doing too much in the VBLANK. I'll have to move code to the busy wait that the CPU is doing. All it's currently doing is waiting for a left mouse button. Surely it can do some of the scrolling code, though I don't want it to get out of sync with what the copper is doing. Again this just points to my lack of experience on the Amiga hardware. I'll get it eventually, with a little help
chadderack is offline  
Old 19 October 2021, 00:19   #7
chadderack
Registered User

chadderack's Avatar
 
Join Date: Jul 2021
Location: Sandy, UT
Age: 53
Posts: 230
Thanks to Dan and Photon of Scoopex, I was able to squash the bug.

Turns out I was doing this in the Vertical Blank:

Code:
VBint:                                                      ;Blank template VERTB interrupt
    movem.l d0-a6,-(sp)                                     ;Save used registers
    lea $DFF000,a6
    btst #5,INTREQR(a6)                                     ;INTREQR check if it's our vertb int.
    beq.s .notvb

    moveq #$20,d0                                           ;poll irq bit
    move.w d0,INTREQ(a6)
    move.w d0,INTREQ(a6)

;naughty
    move.w #vert_display_start<<8+h_display_start,DIWSTRT(a6)
    move.w #vert_display_stop<<8+h_display_stop,DIWSTOP(a6)
    move.w #DMA_fetch_start,DDFSTRT(a6)                     ;$28 for 22 columns; $38 for 20 columns (etc)
    move.w #DMA_fetch_stop,DDFSTOP(a6)                      ;$d0 for 22 columns; $c0 for 20 columns

    move.w #screen_modulo,BPL1MOD(a6)
    move.w #screen_modulo,BPL2MOD(a6)

    bsr TESTVBCode
    bsr VBCode

.notvb:
    movem.l (sp)+,d0-a6                                     ;restore
    rte
Taking that out, and putting it at the head of the copper list with a healthy wait ($2b01 seems fine)... produced a very smooth result.

Code:
Copper:

    dc.w $0180,$0111
    dc.w $2b01,$fffe

    dc.b 0,DIWSTRT,vert_display_start,h_display_start
    dc.b 0,DIWSTOP,vert_display_stop,h_display_stop
    dc.w DDFSTRT,DMA_fetch_start                            ;$28 for 22 columns; $38 for 20 columns (etc)
    dc.w DDFSTOP,DMA_fetch_stop                             ;$d0 for 22 columns; $c0 for 20 columns

    dc.w BPL1MOD,screen_modulo
    dc.w BPL2MOD,screen_modulo
Thanks guys!
chadderack is offline  
Old 19 October 2021, 15:18   #8
defor
Registered User

 
Join Date: Jun 2020
Location: Brno
Posts: 88
You may consider using two copper-lists (double buffering) -- modify one while displaying the other. That way you won't affect currently generated picture. You then swap copper-lists by writing to COP1LC (don't strobe -- Agnus automatically loads your stored address at the beginning of VBLANK for you).

Last edited by defor; 19 October 2021 at 20:27.
defor is offline  
Old 22 October 2021, 13:50   #9
Photon
Moderator

Photon's Avatar
 
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,174
Glad you got it working
Photon 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
Horizontal Copper WAIT on multiple lines KONEY Coders. Asm / Hardware 8 26 August 2021 19:13
Horizontal split screen with modulo trick ovale Coders. Asm / Hardware 37 13 August 2021 20:11
Copper, Horizontal Blanking, and DMA AlexBruger support.Hardware 5 19 July 2020 17:31
Copper Horizontal Wait Problems mcgeezer Coders. Asm / Hardware 5 21 May 2020 16:45
Half pixel copper delay on A1200 hardware FSizzle Coders. Asm / Hardware 89 17 November 2018 19:45

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 13:01.


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