Copperlist crash?

[TCH]

I have a small Copperlist here:

UWORD copperlist[22] =
{
	0x4401, 0xfffe,
	0x0188, 0x0000,
	0x018a, 0x0010,
	0x018c, 0x0020,
	0x018e, 0x0030,
	0x4801, 0xfffe,
	0x0188, 0x0040,
	0x018a, 0x0050,
	0x018c, 0x0060,
	0x018e, 0x0070,
	0xffff, 0xfffe
};

But when i try to "start" it

*((ULONG *)0xdff080) = (ULONG)(&copperlist);

the machine crashes with a black screen and does not responds to anything - aside from reset. I believe the list itself is fine, but i am not sure about the "start" part; do i need to do anything more than write the address of the list to 0xdff080? Or i just write it the wrong way? I see in the manual, that it's splitted into 5+15 bits, but if i do that way

*((UWORD *)0xdff080) = ((ULONG)(&copperlist)) >> 15;
*((UWORD *)0xdff082) = ((ULONG)(&copperlist)) & 0x7fff;

it yields the same result.

Any ideas are appreciated.

[roondar]

The first question would be whether or not the OS is still running at this point. If it's up, changing the Copperlist pointer will probably not work (though it normally doesn't crash the system). The second question is whether or not the Copperlist is actually situated in Chip RAM or not as I can't tell from the source code you've provided. The third one is whether or not you're showing GFX that actually use colours 4-7.

The last question I'd have right now is how you're updating the bitplane pointers. With the CPU? These need to be updated every frame and your Copperlist doesn't seem to do this.

[jotd]

it probably doesn't crash, but display is completely broken so you can't do anything besides rebooting

[TCH]

Originally Posted by roondar

The first question would be whether or not the OS is still running at this point. If it's up, changing the Copperlist pointer will probably not work (though it normally doesn't crash the system).

It is running, i can pull the screen down, if i don't "start" the Copperlist. I have to close the WB to use the Copper on a separate screen?

Originally Posted by roondar

The second question is whether or not the Copperlist is actually situated in Chip RAM or not as I can't tell from the source code you've provided.

It is, there is no FastRAM in the machine.

Originally Posted by roondar

The third one is whether or not you're showing GFX that actually use colours 4-7.

Yes i am, if the list has not been "started" then the GFX is perfectly visible.

Originally Posted by roondar

The last question I'd have right now is how you're updating the bitplane pointers. With the CPU? These need to be updated every frame and your Copperlist doesn't seem to do this.

You mean, i have to update them, if i use the Copper? Because if don't use the list, everything else is works. I simply opened a screen with

OpenScreen()

and wrote the data to

screen->RastPort.BitMap->Planes

.

Originally Posted by jotd

it probably doesn't crash, but display is completely broken so you can't do anything besides rebooting

You mean, it killed the sprites and the WB screen too?

[roondar]

Originally Posted by TCH

It is running, i can pull the screen down, if i don't "start" the Copperlist. I have to close the WB to use the Copper on a separate screen?

If the OS is running, you may need to use the OS's Copper functions. I'm not entirely sure what happens if you have just a single screen showing, but it could be that the OS still wants to use the Copper for itself. Overall, mixing the OS and your own hardware accessing is not a good idea. I'd suggest either using the OS for the hardware or do it all yourself.

It is, there is no FastRAM in the machine.
Yes i am, if the list has not been "started" then the GFX is perfectly visible.

Ok, we can disregard those potential issues

You mean, i have to update them, if i use the Copper? Because if don't use the list, everything else is works. I simply opened a screen with

OpenScreen()

and wrote the data to

screen->RastPort.BitMap->Planes

.
You mean, it killed the sprites and the WB screen too?

Yes, if you directly access the hardware, you become responsible for doing things like updating the bitplane pointers. There's a high likelihood that the OS uses a Copperlist to update the bitplane pointers normally, so when you overwrite the OS Copperlist with your own Copperlist the pointers no longer get updated and that causes issues.

It occurs to me that the black screen may also be caused by other display registers not being set up correctly when you use your own Copperlist. I'd guess the OS doesn't reset stuff like the BPLCON registers, but I can't be sure. Again, mixing the OS and directly accessing the hardware is a pretty good cause for issues and problems.

[TCH]

I had no idea that i can do Copperlists in a system-friendly way, thanks for pointing out. I have to check out how to do that. Back to the manuals...

[redblade]

http://aminet.net/search?query=rkmcompanionIs an official demo by Commodore for Kick 1.3 how to create a custom copper list in C.

There is also one for OS 2 in the later RKM companions that are also on aminet.

If you look for Fred Fish disk 58 there is a Marauder II (Copy program) style example copper list program called Rainbow with source by John Hodges.

Hope that helps

[DMWCashy]

Drop your reference, copperlist is already a pointer. So you are writing a pointer to your pointer into the custom chip

[TCH]

@redblade:
Thanks for the tip, i found it in

uCopperExample.c

.

@DMWCashy:
Damn, you are right. What an amateur mistake. To my excuse, it was late night. Thanks for pointing out. (Of course still crashes, because what roondar said, but nevertheless, it was an unnecessary referencing.)

[TCH]

Okay, i've managed to complete the program. It displays all the 4096 colours on the screen.

The image in PNG:


In WinUAE:


On my A500+ (without flash):


On my A500+ (with flash):

[TCH]

In

uCopperExample.c

there is the part where the Copperlist is generated:

#define NUMCOLORS      32

...

CINIT(uCopList, NUMCOLORS);   /* Initialize the Copper list buffer. */
for (i=0; i<NUMCOLORS; i++)    /* Load in each color. */
    { 
    CWAIT(uCopList, (i*NUMLINES_EACH), 0);
    CMOVE(uCopList, custom.color[0], colors[i]);
    }
CEND(uCopList);    /* End the Copper list */

Now, the manual for

CINIT()

says, that

cl = CINIT( ucl , n )

...

n - number of instructions buffer must be able to hold

Which means i have to allocate as much number of entries as much Copper instructions i have, but in

uCopperExample.c

the allocation only allocate 32 entries (

NUMCOLORS

, the number of colour changes), while it will have 64 instructions (one

WAIT

and one

MOVE

instruction per colour change), plus the terminating command, so it should be 65, right? Is it a bug in the example program and it was just sheer luck that it did not crashed after putting 65 instructions into a 32 instruction sized buffer, or did i interpreted the manual wrongly?

[roondar]

TBH, that feels like pure luck to me. Amiga OS does not have memory protection, so if your code writes outside of it's allocated bounds no errors are thrown. Well, unless you happen to overwrite something critical. Then the system tends to just crash

[DMWCashy]

Originally Posted by TCH

@redblade:
Thanks for the tip, i found it in

uCopperExample.c

.

@DMWCashy:
Damn, you are right. What an amateur mistake. To my excuse, it was late night. Thanks for pointing out. (Of course still crashes, because what roondar said, but nevertheless, it was an unnecessary referencing.)

99% of C errors are usually a single character lol

Any C/C++ coder that says they do not make such errors are just liars, when you are hammering away it is easy to do this, C is so versatile that it makes compile time validation weak.

[TCH]

Originally Posted by roondar

TBH, that feels like pure luck to me. Amiga OS does not have memory protection, so if your code writes outside of it's allocated bounds no errors are thrown. Well, unless you happen to overwrite something critical. Then the system tends to just crash

I know there is no memory protection that's why i suspected that it was merely luck. So, it's a bug in

uCopperExample.c

.

BTW, the program works on KickStart 2.0+ and AGA machines too. Do creating a Copperlist in a system-friendly way has different mechanisms above KS2.0?

Originally Posted by DMWCashy

99% of C errors are usually a single character lol

Any C/C++ coder that says they do not make such errors are just liars, when you are hammering away it is easy to do this, C is so versatile that it makes compile time validation weak.

Ain't the truth... But that comes from it's flexibility, so it's something for something. Any powerful tool can be dangerous. Sometimes even in adept hands.

[pink^abyss]

Depending on compiler and optimizer options your code may still break, as your hardware register writes are not declared as volatile:
*((UWORD *)0xdff080) -> *((volatile UWORD *)0xdff080)

[TCH]

That is good to know, thank you.

[Thomas Richter]

Originally Posted by TCH

n - number of instructions buffer must be able to hold[/CODE]Which means i have to allocate as much number of entries as much Copper instructions i have, but in

uCopperExample.c

the allocation only allocate 32 entries (

NUMCOLORS

, the number of colour changes), while it will have 64 instructions (one

WAIT

and one

MOVE

instruction per colour change), plus the terminating command, so it should be 65, right? Is it a bug in the example program and it was just sheer luck that it did not crashed after putting 65 instructions into a 32 instruction sized buffer, or did i interpreted the manual wrongly?

In this particular example, it is not "pure luck". The graphics user copper lists use a self-extending data structure, so whenever more copper instructions are needed, graphics extends the structure as necessary. Would be hard otherwise as otherwise the number of screens the Os is able to display on one monitor would be limited, or it would be hard to pre-compute the number of copper instructions for it.

[TCH]

Then why does it need to be initialized with the theoretical number of Copper instructions?

[redblade]

Originally Posted by TCH

Then why does it need to be initialized with the theoretical number of Copper instructions?

Probably to calculate how much CHIPMEM it needs to allocate and if it fails to return the error. It could have saved the programmers bytes in the 256K rom.

Also the later RKM examples for OS 2+ modify the UCopperList to open up on a custom screen, code is 90% identical tho.

Glad the battery didn't destroy your 500+

[roondar]

Huh, I didn't even realize the graphics library Copper structure worked like that. That's actually quite nice. There's lots of nice things like that in the OS. Not bad for a system from 30 years ago