Shop Learn
8bpp LUT mode work with HDMI? Update: YES — Parallax Forums

8bpp LUT mode work with HDMI? Update: YES

RaymanRayman Posts: 11,835
edited 2020-12-08 14:33 in Propeller 2
I've adapted this 16bpp 640x480 HDMI code for 8bb.
It seems to sorta work, but the colors are wrong.

If I try to set all the colors to a fixed value, it kinda works, but some of the LUT colors seem not to being set.
Anybody see what's wrong?

Update: Ok, @Ariba figured out that my "xcont" line had the wrong source value.
Should have been 0, but was 1. This caused LUT values not to start from zero.

Comments

  • cgraceycgracey Posts: 13,385
    The data should be 5:6:5 R:G:B. PC format may have the data arranged as B:G:R.
  • RaymanRayman Posts: 11,835
    edited 2020-12-07 00:32
    I think something is wrong with HDMI and 8bpp LUT mode.

    The LUT colors seem to mostly behave like R:G:B:0, same as VGA, but when I set them all to white, the screen is just mostly white...
    Here's code, modified to set all colors to white:
    ' LUT
    
                    mov     x,#0
                    rdfast  #0,##($1000-$400)         'load .bmp palette into lut
                    rep     @.end,#$100
                    rflong  y
                    mov     y, ##$FFFFFF 'set to white instead
                    shl     y,#8
                    wrlut   y,x
                    add     x,#1
    .end
    

    See attached photo for resulting screenshot. It's mostly white although it looks mostly pale green in photo...

    Similar result when setting all colors to red, green, or blue...
    3024 x 4032 - 2M
  • RaymanRayman Posts: 11,835
    Just for reference, here's what it looks like when I don't override the colors.
    It's close in a way, but the palette is off...
    4032 x 3024 - 3M
  • RaymanRayman Posts: 11,835
    As a work around, I guess I can use another cog to construct a 16-bpp scanline from 8bpp data.
  • cgraceycgracey Posts: 13,385
    If you are dealing with a BMP file, you need to be sure that you are loading the palette from the right offset in the file. If I remember, it is either starting at $36 or $86.
  • RaymanRayman Posts: 11,835
    edited 2020-12-07 02:08
    I'm pretty sure that is not the problem as I copied this from a working VGA example.
    Also, setting all LUT colors manually should result in a constant color screen, but it doesn't.

    I'd love to be proven wrong though.
  • AribaAriba Posts: 2,439
    I get the same result.
    It looks like it switches between the lower 256 and the higher 256 LUT words, depending on something.
    If I write the 256 colors 2 times in higher and lower part of the LUT, I get a fully white screen, and also the bird looks better, if I don't overwrite the colors to white.
                    ' LUT
    
                    mov     x,#0
                    rdfast  #0,##($1000-$400)         'load .bmp palette into lut
                    rep     @.end,#$100
                    rflong  y
                    'mov     y, ##$FFFFFF
                    shl     y,#8
                    wrlut   y,x
                    add     x,#256
                    wrlut   y,x
                    sub     x,#256
                    add     x,#1
    .end
    
    Andy
  • RaymanRayman Posts: 11,835
    @Ariba Nice Find! I didn't think of that.

    Unfortunately, palette is still wrong even when copied to upper LUT.
    However, this does seem to show that the colors are coming from the LUT and have the RGB0 format.

    Guess we just need to figure out the mapping between color index and LUT index.
  • didn't @rogloh already have working 8bpp HDMI?
  • RaymanRayman Posts: 11,835
    I've seen some 8bpp HDMI codes, but they are not with indexed color...
  • RaymanRayman Posts: 11,835
    edited 2020-12-07 14:36
    Figured it out! It's not so bad...

    Seems it pulls from LUT starting at offset of 32 instead of offset of 0.
    Easy to fix.
  • Yup, recreating that palette offset in software recreates the effect

    bitmap2_corrupted.png
    640 x 480 - 131K
  • roglohrogloh Posts: 2,957
    edited 2020-12-07 22:07
    Wuerfel_21 wrote: »
    didn't @rogloh already have working 8bpp HDMI?

    Yes and also 16bpp and 24/32bpp (all the P2 colour formats are supported in my driver). Mostly at standard VGA resolution for DVI/HDMI. You can also experiment with timing and push out SVGA to DVI/HDMI if your monitor accepts the reduced blanking. I think Chip has had success at 720p@24fps if you overclock the P2 even more.
  • rogloh wrote: »
    Wuerfel_21 wrote: »
    didn't @rogloh already have working 8bpp HDMI?

    Yes and also 16bpp and 24/32bpp (all the P2 colour formats are supported in my driver). Mostly at standard VGA resolution for DVI/HDMI. You can also experiment with timing and push out SVGA to DVI/HDMI if your monitor accepts the reduced blanking. I think Chip has had success at 720p@24fps if you overclock the P2 even more.

    There are at least two DVI/HDMI resolutions known to work on the P2 with 297 MHz system clock:

    1. 1280 x 720 @ 24 Hz (possibility of slower clock with reduced blanking?)
    2. 960 x 540 @ 50 Hz

    It would be useful to have a full list of working DVI/HDMI modes with H & V display & blanking values and frequencies.
  • RaymanRayman Posts: 11,835
    1080p at 11Hz worked with my projector
  • I'm not sure if it really matters or could explain anything, but, anyway, by inspecting the single-multicolored-bird bitmap file, used at the above examples, its color palette (start: @ offset $36; end: @ offset $435) comprises (256 x 4-byte) entries, stored sequentially, as follows:

    1st byte: BLUE component;
    2nd byte : GREEN component;
    3rd byte : RED component;
    4th byte: $FF (not $00, as expected).
  • RaymanRayman Posts: 11,835
    Ok, that can be. The fourth byte is not used here, but can be used for alpha. $ff means opaque and 0 means transparent.
  • Thanks Rayman! Good to know. :smile:
  • AribaAriba Posts: 2,439
    Rayman

    The Offset 32 into the LUT comes from this line in the HDMI code:
        xcont   m_rf,#1                 'do visible line
    
    Just change the S value to #0 and the colors begin at LUT address 0. Or to #8 for a second 256 colors in upper half of the LUT.

    Andy
  • evanhevanh Posts: 10,419
    edited 2020-12-08 04:19
    TonyB_ wrote: »
    There are at least two DVI/HDMI resolutions known to work on the P2 with 297 MHz system clock:

    1. 1280 x 720 @ 24 Hz (possibility of slower clock with reduced blanking?)
    2. 960 x 540 @ 50 Hz

    It would be useful to have a full list of working DVI/HDMI modes with H & V display & blanking values and frequencies.

    25 MHz dot clock (250 MHz system clock)
    3. 640 x 400 @ 70 Hz
    4. 640 x 350 @ 70 Hz (extra v-blanking)

  • evanhevanh Posts: 10,419
    edited 2020-12-08 05:11
    My TV picks up 768 x 432 @ 60 Hz but the monitor doesn't.

    Question: Is the blanking encoded into DVI signalling in some way? The TV seems very good at measuring whatever resolutions I send it.

  • RaymanRayman Posts: 11,835
    @Ariba Nice catch! Must have been a copy and paste error...

    Guess there's nothing wrong with the HDMI hardware after all...
Sign In or Register to comment.