12/20/09: Composite Artifacting Sample NTSC by Potatohead, | Category: Pictures | 7 comments - (Comments are closed)

Composite Artifacting Sample NTSC

Composite Artifacting Sample NTSC

threefourAll 256 byte patterns, composite mode artifacting, 640 pixel mode, palette entries are 0, 16, 32, 64.

Effective resolution is 160x200x~256

7 comments to Composite Artifacting Sample NTSC

  • Hi Potatohead,

    What was your reason for choosing 64 as full white instead of 48?
    There is some ambiguity about the CMP colors as 0=black not 15. xxIIPPPP CMP colors. 0 intensity and 0 phase is used for black not 0 intensity 15 phase which is a shade of green.
    Run up the intensity from black and you have 0, 16, 32, 48 all with phase = 0 and see grays to white.
    I admit that you can’t tell the difference between 48 and 63 on a composite monitor but if the Coco circuitry was accurate, 63 ought be a very pale blue-green.

    Would you post the number table that created the image?

  • Jason

    Wow, Potatohead, they look great :D Nice work!

    Juat a tip, if you edit the main post it lets you add more images, like the extra ones from here:

    Other Images

    You can also edit my comments and delete this. Feel free to fix any typos if you find any :P

  • I didn’t know about the editing.

    …and thanks! I thought some color patches and palette entry changes would better highlight what is being discussed here.

    Robert, I was operating off some old memory. 64 was a mistake, and probably should have been 48. It seems that basic mangles that to white, so no harm done. If it was not white, I think it would have shown up in the captures I did.

    The number patterns are easy. Start with the 640 pixel mode HSCREEN, or 6809 GIME setup, and load the palette. However you get there, you start with the screen memory filled with zeros.

    I used four nested FOR — NEXT loops to draw the boxes. Each box is 8 pixels by 8 pixels high, for a total of 64 pixels, or 64 bytes. They are the same.

    The upper left color patch is the same as the background color, and is value zero. The next one located vertically down is value 1, the next value 2, …. until the bottom of the first column is reached, which is value 15.

    Next column is the same, value 16 at the top, 17 is the next down, 18 … filling in column by column with sequential values eventually reaching lower right, which is 255.

    Since each byte represents a pixel, I just used LPOKE to “plot” those pixels with a “color” equal to the byte value. The display does the rest.

    Here is a retype of the quick ‘n dirty BASIC program I used. (Running this takes about 5 minutes in slow mode…)


    5 PALETTE CMP
    10 HSCREEN 4
    20 PALETTE 0,0
    30 PALETTE 1, 16
    40 PALETTE 2, 32
    50 PALETTE 3, 64
    60 C = 0 (UPPER LEFT SWATCH)
    100 FOR I = 0 TO 150 STEP 10
    105 FOR K = 10 TO 160 STEP 10
    110 FOR J = (I+2) TO (I+8)
    120 FOR M = (K+2) TO (K+8)
    140 LPOKE (393216 + 1440) + (M*160)+J, C
    150 NEXT M
    160 NEXT J
    175 C = C + 1
    180 NEXT K
    190 NEXT I

    THE + 1440 WAS ME LOCATING IMAGE ON SCREEN

    Ok, so I think I got the images sorted. Other edits don’t really make any sense, so I’ll leave well enough alone. You guys probably read my dissertation on the older thread. It was while writing that I realized perhaps a few screenies would really help.

    Really what is needed is a color lookup table that sorts them out a bit better. That would be just one 8 bit page in RAM somewhere, indexed with an 8 bit value to associate the colors in a more linear way. There is no changing what results on the screen, but what is programmed can be changed.

    The other thing needed is to sample at least the first one to get RGB averages for a palette to be used for development.

  • The picture is a Propeller simulation to be replaced with an actual CoCo capture.

    Quality is spot on, tint is not, just FYI.

  • briza

    Hi PotatoHead.

    Well I can say 1 thing about a little comparison I made between your pic and the coco 3. The coco 3 display looks way better I mean it is 100 times better.
    For a start The Red in the coco 3 is bright and vibrant. The white is also bright and sharp look at it too long and you will suffer eye soreness that is how good the white looks on the coco 3.
    On the coco 3 I see a nice touch of blues in the background. The Post is a nice creamy brown with tinges of other colors mixed in. The red on her lips looks brilliant I was to meet that girl I would want to do some things to her mouth Lol.
    The girls skin color looks so good. The blond hair looks real. I’m amazed just how good this pic looks on a coco 3.
    What has me beat is why is the pixels look so tight and compact. I was expecting a blocky pixel result. But it looks just like a 320×192 mode. But it is 160x192x200 artifact colors.
    Will be sending some pics from the coco 3 displaying this effect to Jason and he will be uploading the pics. Then you can sit back and admire this quirky artifact mode.

    laters

    Briza

  • Yes, the tint is not accurate on that one. I tossed it up for people to understand picture quality. The CoCo is going to look way better for sure.

    Maybe Jason’s .cas images load today, and I’ll replace it.

    :)

  • Briza, 320 x 192 = 0.6 aspect ratio

    160×192 = 1.2 aspect ratio.

    The screen is 4:3

    That makes the pixels squarish enough for good detail.