As instructions are really similar, I've tried many loops or other ways of coding it, but at best I get the exact same amount of bytes (and a much more complicated code ).
Note: JSR forbidden, except to use ROM1.1 calls (I need the routine to be easily moved anywhere in RAM)
Thanks!

I don't see many ways, maybe by playing with the carry flag and using ROL/ROR directly on the values, but obviously it means you have perfect control on what was there so it does not get transformed in horrible attributes that break the display

Without the rest of the code, it's kind of difficult to know what can be done

Actually, that was the very beginning of the code of my progress bar. It displays the boundaries before the progress bar begins to run.

I was hoping to earn 1 or 2 bytes to keep it as small as possible, it felt strange to have to use 20 bytes to invert 2 bits.
But gave up, asking because I was wondering if there was some magic trick I might not be aware of (I'm stil not very clever in assembler optimization )

So I assume the XOR is there so the progress bar does not impact whatever was displayed there before the loading?

Exactly.
I could use another "look" but I wanted a first version that would be as "universal" as possible (slow or fast, redefined chars or not, hires or text, letting a screen pre-loaded visible).
It will only be messy in case of TEXT screen loading (and of course not universal at all on ROM 1.0)

I thought about doing this but it won't work if a screen is being loaded over the progress bar. You'd then restore the previous screen state over the new
So I just save a single byte (the one flashing). It has the other advantage of using less memory and let me load the progress bar program in the stack (page 1).

There's nothing too wrong anyway, if a screen loads over the progress bar as it is now, I think it will just delete the already-reversed progress bar, and then the progress bar would carry on inverting the newly-loaded bytes.
That should look a bit strange on the single-saved byte, but that being said, if it's only a text or hires screen loading, the progress bar isn't very useful as one can already see the data loading...