English Amiga Board


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

 
 
Thread Tools
Old 20 November 2019, 21:24   #1
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 489
Copper lists are hard

I'm trying to build a copper list that changes colour 0 at the start and end of each line, complicated by also changing bit depth part way through. It's nearly there, but in trying to fix one bit (circled in orange in the first picture, I end up with everything falling apart in a way that I just don't understand.

Could someone please fill this gap in my knowledge?

In the "before" picture things look like they're working, with colour changes before and after the rollover being taken care of, but with some stuff going wrong within the orange circle.

When trying to fix the orange circle by adding an extra wait:

Code:
        // I thought this would fix it
        //
        COP_INSTR(0x80db, 0x80fe)
        COP_INSTR(COLOR00, 0xccf)
        //
        // but it made it worse
All the stuff after the rollover stops happening, even though the bit I fixed was way before that.

I don't understand, and I don't know where to look apart from the HRM.

I've attached the code I use to generate the copper list and a hex dump of the results.
Attached Thumbnails
Click image for larger version

Name:	before.png
Views:	92
Size:	11.8 KB
ID:	65233   Click image for larger version

Name:	after.png
Views:	71
Size:	8.9 KB
ID:	65234  
Attached Files
File Type: txt code.txt (4.7 KB, 20 views)
File Type: txt broken-copper-list.txt (7.0 KB, 18 views)

Last edited by deimos; 20 November 2019 at 21:31.
deimos is offline  
Old 20 November 2019, 22:52   #2
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 2,230
Sure the change from y=80 to y=00 is at roll-over?

Can you post an exe?

Last edited by ross; 20 November 2019 at 22:58.
ross is offline  
Old 20 November 2019, 23:11   #3
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 489
Quote:
Originally Posted by ross View Post
Sure the change from y=80 to y=00 is at roll-over?

Can you post an exe?
I can post an exe tomorrow, everyone's in bed here now.

I'm not getting this rollover thing. I get that there's only 8 bits and it starts counting over when it gets past 255, but I thought that happened when the I start showing red in the before picture, long after the code I added.
deimos is offline  
Old 20 November 2019, 23:16   #4
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 2,230
Quote:
Originally Posted by deimos View Post
I can post an exe tomorrow, everyone's in bed here now.

I'm not getting this rollover thing. I get that there's only 8 bits and it starts counting over when it gets past 255, but I thought that happened when the I start showing red in the before picture, long after the code I added.
I'm sure that with the exe I can tell you what happens

At tomorrow.
ross is offline  
Old 20 November 2019, 23:41   #5
a/b
Registered User

 
Join Date: Jun 2016
Location: europe
Posts: 153
Based on generator code, it looks like your split screen starts at line $dc.
And based on copper list dump, you are changing a bunch of bitplane stuff right at the very end of line $db leading into line $dc (bplcon0, modulos, bitplane pointers), all while display DMA is still enabled. I'd try setting $0100 (bplcon0) to $0200 first, then change stuff, and finally set $0100 to $3200.
Plus there's also a $008a trigger, so maybe check if you can squeeze all that stuff within horizontal blanking, otherwise you'll need an empty line.
a/b is offline  
Old 20 November 2019, 23:43   #6
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 2,230
hmm, I downloaded the image and zoomed in because I didn't see it well

And I realized that you change too many registers with the copper and therefore the color is changed to a point far from the edge.
Change all others first and then COLOR00 when the time is right.

EDIT: OK, a/b before me
ross is offline  
Old 20 November 2019, 23:48   #7
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 2,230
But I think the problem is at first 0x8037 0x80FE after bplcon0, modulos, bitplane ptrs changes.
ross is offline  
Old 21 November 2019, 09:27   #8
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 489
Here is the executable for the "before" image.
Attached Files
File Type: zip before.zip (6.1 KB, 7 views)
deimos is offline  
Old 21 November 2019, 09:41   #9
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 489
Quote:
Originally Posted by a/b View Post
Based on generator code, it looks like your split screen starts at line $dc.
And based on copper list dump, you are changing a bunch of bitplane stuff right at the very end of line $db leading into line $dc (bplcon0, modulos, bitplane pointers), all while display DMA is still enabled. I'd try setting $0100 (bplcon0) to $0200 first, then change stuff, and finally set $0100 to $3200.
This made almost no difference. There is now a tiny black dot near the start of the first line after the split. But it sounds like you don't like me changing bitplane stuff while display DMA is running, so I should leave it in?

Code:
        ...
        COP_INSTR(COPJMP2, 0x0000)

        COP_INSTR(BPLCON0, COLORON)

        COP_INSTR(BPL1MOD, INSTRUMENTS_DISPLAY_MODULO - 2)
        COP_INSTR(BPL2MOD, INSTRUMENTS_DISPLAY_MODULO - 2)

        COP_INSTR(BPL1PTH, HIGH_WORD(secondaryBuffer))
        COP_INSTR(BPL1PTL, LOW_WORD(secondaryBuffer))
        COP_INSTR(BPL2PTH, HIGH_WORD(secondaryBuffer + DISPLAY_WIDTH_IN_BYTES))
        COP_INSTR(BPL2PTL, LOW_WORD(secondaryBuffer + DISPLAY_WIDTH_IN_BYTES))
        COP_INSTR(BPL3PTH, HIGH_WORD(secondaryBuffer + 2 * DISPLAY_WIDTH_IN_BYTES))
        COP_INSTR(BPL3PTL, LOW_WORD(secondaryBuffer + 2 * DISPLAY_WIDTH_IN_BYTES))

        COP_INSTR(BPLCON0, INSTRUMENTS_DISPLAY_DEPTH << PLNCNTSHFT | COLORON)

        COP_INSTR(0x8037, 0x80fe)
        ...
Attached Thumbnails
Click image for larger version

Name:	tiny-black-dot.png
Views:	27
Size:	8.9 KB
ID:	65243  
deimos is offline  
Old 21 November 2019, 10:00   #10
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 489
Quote:
Originally Posted by ross View Post
But I think the problem is at first 0x8037 0x80FE after bplcon0, modulos, bitplane ptrs changes.
So, currently, with a/b's changes, I get black until the edge of the display window, 3 pixels of 999 light grey, 1 pixel of black, a bunch of 777 grey, then 8? pixels of 070 green before 977 pink.

So that big chunk of 777 grey is from line 4 to end - 2 below:

Code:
        COP_INSTR(BPLCON0, INSTRUMENTS_DISPLAY_DEPTH << PLNCNTSHFT | COLORON)

        COP_INSTR(0x8037, 0x80fe)
        COP_INSTR(COLOR01, BLACK_RGB) // deliberate ordering
        COP_INSTR(COLOR00, 0x777)

        COP_INSTR(COLOR02, 0xccc)
        COP_INSTR(COLOR03, 0x999)

        COP_INSTR(COLOR04, 0x444)
        COP_INSTR(COLOR05, 0xfff)
        COP_INSTR(COLOR06, 0x0f0)
        COP_INSTR(COLOR07, 0x00f)

        UWORD row = 0;

        for (UWORD i = 0xdc; i <= 0xff; i++) {
            COP_INSTR(0x8037, 0x80fe)
            COP_INSTR(COLOR00, 0x070) // replace with something useful
            COP_INSTR(COLOR00, 0x977) //// pink grey
So, basically the first 0x8037 0x80fe in the loop is triggering. I need to finish the line I'm on before entering the loop. Which must have been what I was trying to do with 0x80db 0x80fe, COLOR00 0xccf, but that broke everything.

Attached is an executable with those extra lines added.
Attached Files
File Type: zip after.zip (6.1 KB, 6 views)
deimos is offline  
Old 21 November 2019, 10:44   #11
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 489
Quote:
Originally Posted by ross View Post
Sure the change from y=80 to y=00 is at roll-over?
No, if I fiddle with the number of iterations the first loop does so that the change to y=00 occurs one row earlier, things look like they work. But now I'm not sure my maths adds up.

Code:
        COP_INSTR(COLOR05, 0xfff)
        COP_INSTR(COLOR06, 0x0f0)
        COP_INSTR(COLOR07, 0x00f)

        // this does fix it
        
        COP_INSTR(0x80db, 0x80fe)
        COP_INSTR(COLOR00, 0xccf)
        
        // if I start the loop below from dd instead of dc

        UWORD row = 0;

        for (UWORD i = 0xdd; i <= 0xff; i++) {
            COP_INSTR(0x8037, 0x80fe)
            COP_INSTR(COLOR00, 0x070) // replace with something useful
            COP_INSTR(COLOR00, 0x977) //// pink grey
deimos is offline  
Old 21 November 2019, 11:10   #12
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 2,230
Your code is working now?
ross is offline  
Old 21 November 2019, 11:22   #13
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 489
Quote:
Originally Posted by ross View Post
Your code is working now?
Yes, I think so. I've even managed to fix the black dot that disabling the bitplanes during the split introduced.

I'm going to work on it a bit more before calling it done though.
Attached Thumbnails
Click image for larger version

Name:	maybe.png
Views:	49
Size:	8.9 KB
ID:	65245  
deimos is offline  
Old 24 November 2019, 12:53   #14
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 489
So, everything works until I actually try to use it.

My current problem is bad screen glitches when I swap in a new copper list for my triple buffering. This glitch only lasts for a screen refresh before it corrects itself. I know the copper list isn't changed between when it's glitched and when it's back to working. It doesn't happen all the time, or consistently either.

I change my copper lists during a copper interrupt at the bottom of the screen, before the vertical blank happens, and I just update cop1lc, I don't touch copjmp1.

I do do some timing sensitive stuff in the copper lists, like changing colours at exactly the right place, and I've fiddled with bplcon1 to get the colour changes to line up just so, but I don't why that would affect anything, or if it did, why it would only be for a millisecond.
Attached Thumbnails
Click image for larger version

Name:	glitchy.png
Views:	37
Size:	10.9 KB
ID:	65292  
Attached Files
File Type: zip glitchy.zip (20.4 KB, 5 views)
deimos is offline  
Old 24 November 2019, 14:03   #15
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 489
Quote:
Originally Posted by deimos View Post
So, everything works until I actually try to use it.
Nevermind, it works now.
deimos 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
Best way to mix blitting with copper and copper effects roondar Coders. Asm / Hardware 3 12 September 2016 14:12
MUI and Lists tygre Coders. System 1 05 September 2015 22:17
Couple of questions about Copper Lists jimmy2x2x Coders. General 2 21 November 2014 18:03
Combining copper scrolling with copper background phx Coders. Asm / Hardware 14 16 June 2013 08:26
Games lists vertigo New to Emulation or Amiga scene 2 20 November 2003 22:24

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 20:52.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.08040 seconds with 16 queries