Big restriction in AmigaOS for UserCopper lists ?

[lordv]

You know what ? It was visisble on the screen that for color change it took more than eight lowres pixels (probably 16 HiRes ones or more ).

My question is, is this an AmigaOS restriction on Copper lists?

It seems to be hardware restriction. The simple $180,0,$180,$fff,$180,0,$180,$fff-like copper instructions started in specific part of screen, display 8 lowres pixels wide strips.  When num of bitplanes increases for 0 to 8, some strips become longer (up to 12 or even 16 lowres pixels).

Is there any way of achieving the maximum resolution without banging directly the hardware?

My results were obtained on a 'banged' copper list without any intervention of system.

I don't quite understand why don't you want to 'bang the hardware'. If you're using copperlists even with library functions, your program won't work on video cards or different ppc-with-pc-peripherals boards. So the banging gives the same results in a simpler way. One can easily combine fully custom, hardware-banged screen with multitasking and even screen switching (lamiga-m).

[lordv]

Was that on AGA ? How many bitplanes?

Of course - aga with maximum burst mode possible (fmode=3). Bitplanes were varied from 0 to 8

I guess it's not worth to try to bang the hardware myself then if the results are the same

But hardware screens are smth easier to create, I guess. Absolutely no OS interferention and limitations, no tons of graphics.library calls. =)

Question, why do some programs claim to make more than 100 changes per line then?

Don't know. Maybe some magic with bplcon4 ?

By the way, like Thomas said, the hardware manual mentions 4 horizontal pixels, or 8, for lo and hires screens respectively.

If copper reads his words every 4 lores pixels, it needs 8 lores pixels to load 1 palette register.

...When changing from ecs/ocs, the only enhancement was 8 bpls and 32/64bit enhanced bitplane/sprite fetch modes. Unfortunately no enhancements were made for blitter or copper, so they became no faster...

[lordv]

Yes, 4 lores pixels wait resolution and 8 lores pixels command execution. Somewhere near your citation point it must be written about length of memory cycle - 280ns (2 lores pixels). 8 lores pixels per move arise from here.