News Team Current issue History Online Support Download Forum @Pouet

01 - 02 - SE - 03 - 04 - 05 - 06 - 07 - 08 - 09 - 10 - 11 - 12 - 13 - 14

Alive 12
16 Bit per Pixel Interlaced

Truecolour  on the Atari TT

       Recently I dealt with the idea of improving my interlaced C2P 
       which provides an interlaced 12bit (444) mode on the TT in order 
       to reduce the flicker a bit. Well, after playing around with 
       some ideas it occurred to me that it should be possible to 
       actually display 65536 colours on a TT even if its video's DAC 
       only provides a 444 resolution and thus a maximum amount of 4096 
       So how can you achieve 16bit colour you might ask. Well, there 
       have always been simple tricks yielding to great effects in the 
       demo coding scene, right? Just look at Paradox' recent 
       achievement to make up an interlaced 14bit resolution providing 
       640x400 pixels which of course is far beyond the shifter's 
       original specifications.
       Now the trick that I came up with on the TT is quite easy, not
       requiring any synced code or anything similar, just plain 
       interlacing between two half-images based on the Jaguar's CrY
       colourspacewhere colours get divided into a cyan-red part (Cr,
       4-4bit) and into a luminance (Y, 8 bit) which was basically 
       chosen despite its non-standardness to implement fast and easy 
       gouraud-shading in the machine's Blitter AFAIR.
       The CR table (which resides in the jaguar's video chip) can be 
       thought of as a colour-cube whose outline has been distorted to 
       fit a square so that a certain (CrY) colour's chroma value can 
       be addressed in a 2 dimensional array from two 4bit coordinates. 
       Illustration coming up:
       It seemed obvious that I could use the TT's 8bpp greyscale mode 
       in order to fake the luminance layer in my interlacing scheme 
       and use the 2nd half-image to render the CR part with in a 
       palette taken from the Jaguar's ROM table. 
       Converting from RGB to CrY can be done by computing the RGB
       colours luminance, use that one to normalize the RGB vector and 
       then find the closest match to the 256 ROM table entries. hint: 
       It's completely safe to use Y = max(R,G,B) as the luma and 
       normalization value instead of any perceptual formula or similar 
       as it gives better results in connection with CrY images... 
       However, there are convenient tools, such as TGA2CRY.TTP to 
       convert from RGB to CrY.
       To demonstrate the capabilities of the emulated CrY mode I've 
       made up a little tool called CRYVIEW.TTP which is supposed to 
       run only on the Atari TT and which you should find in this 
       issue's "Filez" folder.
       As you may notice there are some drawbacks: for one thing 
       there's obviously a lot of flicker involved, but I am already 
       working on a method that switches between colour and grey-mode 
       each scanline and flips grey and coloured lines over each VBL so
       the flicker doesn't become that much laminar. 
       Secondly, using an interlaced grey half-image causes the Y layer 
       to be mixed in additively instead of multiplicative which means 
       that a luminance of 0 can't be achieved so that colours can't be 
       darkened completely. The third disadvantage is that the TT's 
       shifter uses palette register 0 to determine the screens border 
       colour which would be a bright blue in the CR table and black in 
       the Y ramp which produced pretty much unacceptable contrast and 
       flicker results. Hence I dropped colour 0 in the CR palette so 
       that colours with a CR value of 0x00 are rendered to the next 
       closer match (0x01) so that the amount of displayable colours is 
       reduced by 256 to 65280 which doesn't make a noticeable 
       difference anyway.
       Ah and btw, a nice thing working in CrY mode is that you can 
       abuse the 68030 pack/unpk instructions which are actually meant 
       for converting BCD numbers to ASCII strings to quickly extract 
       the Cr channels bitfields into high and low byte order and 
       reorder them just as easily. The unpacked version provides you 
       with a pixelformat that lets you mix, average or filter your 
       image data for free. Just take a look into 
       "filez/cryview/cry.s" -> "antialiasImage" to get an idea of 
       what i'm talking about here. there are similar instrucions in 
       the jaguar's GPU suited to process CrY image data, but with the 
       68030 it works as follows:
       ; packed Cr pixels d0.w = **** **** C1C1 R1R1
       ;                  d1.w = **** **** C2C2 R2R2

          unpk        d0,d0,#0    ; #0 specifies an additional offset
          unpk        d1,d1,#0

       ; now unpacked d0.w = **** C1C1 **** R1R1
       ;              d1.w = **** C2C2 **** R2R2

          add.w       d1,d0       ; Average the two pixels
          lsr.w       #1,d0

          pack        d0,d0,#0    ; Reorder into CCCC RRRR format
       As you see the unpacked format reserves a field of four blank 
       pixels above each channel so that you can mix up to 16 pixels. 
       The Y channel can be filtered pretty much straighforward once 
       it's been extracted because it is nothing more than a plain 8bpp 
       channel so you don't need any packing/unpacking in its case. 
       Note: You can replace unpk by 'lsl.w #4,dx; lsr.b #4,dx' and 
       pack by 'lsl.b #4,dx; lsr.w #4,dx' in this special case on CPUs
       lacking those instructions but this document is aimed at the 
       TT030, anyway.

       If you have any questions regarding that CrY mode or if you are
       interested in a double-pixeled (speed issues) c2p that converts
       from a 16bpp CrY to an interlaced screen on the TT drop me a
       line via ray(at)tscc(dot)de or via IRC (#atariscne) if you
       manage to catch me up there.

       Keep it real, stay Atari.
Ray / tSCc for Alive, 2005-12-20
Alive 12