On 2 Apr 2012, at 23:58, Thomas Harte wrote: > I think that used a tight loop of something like (i) load next palette index, > next colour and next delay length; (ii) push colour to palette index; > (iii) perform a busy loop of the desired length; (iv) repeat.
That's closer the approach I was originally aiming for, but the conversion is far more complicated. For a first attempt I restricted it to changing the CLUT when the raster was outside the image, which still gives a noticeable improvement over a static palette. My ideal approach would even eliminate steps (i) and (iii), and just use a huge unrolled loop of OUTI instructions. That would update 1 CLUT entry per instruction in reverse order, in a continuous loop. The converter would be tracking a rolling window colours, with knowledge of colours no longer needed and look-ahead to what can be set up in advance. It also needs to understand the instruction timing, which varies across the scanline. Thinking of implementing that still makes my head hurt! > but you could instead, say, change a single palette index several > times over the course of a single scan line, or anything in between. I considered individual CLUT updates for my current viewer, but it took too much time away from the actual updating — the extra LD B,n needed costs about the same has half an OUTI. Instead I grouped the dynamic colours together and updated them with a small unrolled OUTI block. > If you have portions of the image with only four colours (especially > once the colour aliasing forced by the 128-colour palette is accounted > for) then switching to mode 3 for a portion of a line could be the smarter > thing to do, and would presumably cost basically nothing to implement? Unless you need the extra resolution, I don't think there's anything to gain from using mode 3. It uses a subset of the mode 4 CLUT, so it doesn't help with fast access to an alternative colour set. Or am I missing something? Si
