8bpp LUT mode work with HDMI? Update: YES
Rayman
Posts: 14,646
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.
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
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 .endSee 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...
It's close in a way, but the palette is off...
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.
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 .endAndyUnfortunately, 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.
Seems it pulls from LUT starting at offset of 32 instead of offset of 0.
Easy to fix.
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.
1st byte: BLUE component;
2nd byte : GREEN component;
3rd byte : RED component;
4th byte: $FF (not $00, as expected).
The Offset 32 into the LUT comes from this line in the HDMI code:
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
25 MHz dot clock (250 MHz system clock)
3. 640 x 400 @ 70 Hz
4. 640 x 350 @ 70 Hz (extra v-blanking)
Question: Is the blanking encoded into DVI signalling in some way? The TV seems very good at measuring whatever resolutions I send it.
Guess there's nothing wrong with the HDMI hardware after all...