Quick way of changing (pen) colors in mode 1

[arnolde]

Hi eveyone,

I'm here with what might be an interesting problem, but maybe also something that can be done much easier and I just can't see the nose in front of my face:
In a mode 1 graphic, I need an assembly routine that quickly changes the pen colors as follows:
0 [00] -> 0 [00]
1 [01] -> 2 [10]
2 [10] -> 3 [11]
3 [11] -> 1 [01]
Working with the proverbially witched way the bitmaps are encoded on the CPC (if you don't know it yet, go see this page), I tried to find a simple sequence of shifts and bit operations that can be applied to a whole byte (=4 px), so I don't have to work on every single pixel.
I came up with the following plan: (o=original color bit, n=new color bit)
n0 = o1
n1 = o0 xor o1
and ended up with this routine:

Code Select Expand

;(assuming a holds the original byte)
ld b,a               ;backup
rlca:rlca:rlca:rlca  ;switch bits 0 and 1 of all 4 pixels
ld c,a               ;backup this shifted byte
xor b                ;n1 = o0 xor o1
and #f0              ;isolate bits 0
ld b,a               ;backup
ld a,c               ;restore shifted original byte
and #0f              ;isolate bits 1 (n0 = o1)
or b                 ;put the two halves together
;done
...but somehow I have the feeling that I'm not seeing the wood for the trees and there must be a much simpler solution...
Any thoughts?
Have a nice evening! 

[roudoudou]

Use tables, precompute your changes

[arnolde]

Yes, of course, but I forgot to mention that it should be quick AND memory economic  

[andycadley]

My first thought is why rotate the actual pixel choice rather than just rotate palette entries?

Beyond that, yeah probably just a 256 byte, page aligned, precomputed table of results is the best way. Shifting and computing, even if you can use RLD, is probably going to be a lot slower.

[arnolde]

My first thought is why rotate the actual pixel choice rather than just rotate palette entries?

Well, there is a reason ;-) 

Beyond that, yeah probably just a 256 byte, page aligned, precomputed table of results is the best way. Shifting and computing, even if you can use RLD, is probably going to be a lot slower.

I tought about using RLD, but it would have to be done twice in order to reset (hl) to the original byte.

As for the timing: It isn't really THAT critical, it's not inside, say, a sprite routine. It's a drawing thing that can take some nops. Anyway, maybe I'm over-optimizing, I just love these kinds of puzzles...

[norecess464]

Use tables, precompute your changes

@arnolde (@arnoldemu, is that you?!)

Exactly what @roudoudou said. Since your data source will always provide the same destination data, use a simple translation table for that. And since the size of that table is exactly 256 bytes, there is a perfect opportunity of aligning your data on a 256 bytes boundary (huge optimisation here).

Regarding the memory consumption, depending of the context you can eventually generate those tables at program startup (with Z80 code).

And if really you don't want to go the table-route: I noticed that your original code does not use D and E registers, so I would suggest using at least AND D and AND E instead of AND #F0 and AND #0F (saving 2 NOPs in the process)

[McArti0]

LD L,(HL)

[McArti0]

One moment...

This document has error

Mode 1
    bit7    bit6    bit5    bit4   bit3    bit2   bit1   bit0
    p0(0) p1(0) p2(0) p3(0) p0(1) p1(1) p2(1) p3(1)

First is Low bit.

[roudoudou]

Yes, of course, but I forgot to mention that it should be quick AND memory economic 

With 4 pens, it cannot be memory expensive
Or i miss something in your request

[McArti0]

LD C,A

AND #0F

LD B,A

LD A,C

RLCA : RLCA : RLCA : RLCA

XOR B

[McArti0]

LD A,(HL)

RRD

AND 0F

XOR (HL)

LD (HL),A