RGBtoHDMI icon indicating copy to clipboard operation
RGBtoHDMI copied to clipboard

Some settings in Pallette Menu don't work...

Open gelo291 opened this issue 11 months ago • 19 comments

Hello, I try to change settings in Pallette Menu, like: Brightness, Contrast, Saturation etc., but whatever I set I can't see any changes on the screen. Settings are changed and saved properly, but as I said: no changes are visible. Even when I change Pallette type it is still the same pallette visible. I use Amiga 50Hz profile. What could be the problem? Thanks a lot, Greg

gelo291 avatar Feb 26 '24 10:02 gelo291

@gelo291

I use Amiga 50Hz profile.

The palette menu adjustments only work in 4bpp or 8bpp palettised frame buffer modes. The Amiga uses 16bpp frame buffer mode (for 12bpp RGB) so there is no palette table and the RGB bits are written direct to the frame buffer.

IanSB avatar Feb 26 '24 16:02 IanSB

Ok, thanks a lot, now everything is clear. To be honest, it is a shame, but what can we do...

gelo291 avatar Feb 26 '24 20:02 gelo291

I am using a MegaSTE and I find the colour is off - VERY red - I was trying to make palette changes as well. SO the colour the source provides is the colour we get?? There is no way with the device to make colour adjustments? Then I have a problem with my RGB2HDMI I guess, because this is WAY TOO RED.

Biker1bob avatar May 19 '24 13:05 Biker1bob

@Biker1bob

Maybe you have some R, G or B bits either stuck high or low or you have wired them up out of order. Is there a video test program for the STE similar to the Amiga Test Kit that produces a colour gradient test image like this:

capture0

Here is a similar example from my test jig that generates video test patterns: capture1

If there are any bits wrong they will usually be visible with this kind of test pattern and if not further investigation can be done by examining a screencap of the test pattern (using SW2) If you don't have such a program then you should be able to use a paint program to paint blocks of each red, green or blue intensity 0-15 in turn in a similar way.

If the bits are all OK then check your monitor's colour temperature setting etc which can usually be set differently for each input.

IanSB avatar May 19 '24 13:05 IanSB

This is from the MegaSTE diagnostic cartridge. The first is the RGB out to VGA The 2nd is the RGBtoHDMI - something is wrong. But I dont know where to look. I did have an issue before with green and that was a problem with the soldering on the CPLD. But no idea where to look for this red. PXL_20240518_121804770 PXL_20240518_121826086

Biker1bob avatar May 21 '24 03:05 Biker1bob

@Biker1bob

Yes, it looks like the bits are being picked up in the wrong order although it's difficult to judge exactly what's wrong from a photo. Please post a screencap (Press SW2, the file will be in /captures on the SD card)

IanSB avatar May 21 '24 11:05 IanSB

capture0 capture1

Biker1bob avatar May 21 '24 22:05 Biker1bob

@Biker1bob

Youve got all the red, green and blue groups of 4 bits correct but within each group, nearly all your connections are to the wrong bits:

The Green and Blue channels look to be the same: Atari bit 0 is connected to RGBtoHDMI bit 3 Atari bit 1 is connected to RGBtoHDMI bit 0 Atari bit 2 is connected to RGBtoHDMI bit 1 Atari bit 3 is connected to RGBtoHDMI bit 2

i.e. they are all rotated by 1

The red channel is different:

Atari bit 0 is connected to RGBtoHDMI bit 2 Atari bit 1 is connected to RGBtoHDMI bit 0 Atari bit 2 is connected to RGBtoHDMI bit 1 Atari bit 3 is connected to RGBtoHDMI bit 3 (The only right one!)

i.e. bit 3 is right but the other three bits are rotated by 1

IanSB avatar May 21 '24 22:05 IanSB

OK, thanks.. I will look up the build thread I followed again.. Check all my connections again.

Biker1bob avatar May 21 '24 22:05 Biker1bob

So not sure what to say .. but the only wires I changed were red 3 to 2 and 2 to 3 - now correct bit 3 to 3 on board and 2 to 2. Colour is now fixed. Thanks for the direction though. I used a blue and a green wire for those two.. so somehow I got them reversed. Because it is hardwired I have to disconnect everything each time I take the machine apart for anything. I guess the last time I got the wires reversed.

James

Biker1bob avatar May 22 '24 03:05 Biker1bob

@Biker1bob

So not sure what to say .. but the only wires I changed were red 3 to 2 and 2 to 3 - now correct bit 3 to 3 on board and 2 to 2.

Can you post another screencap of the test gradient?

IanSB avatar May 22 '24 12:05 IanSB

capture2

Biker1bob avatar May 22 '24 13:05 Biker1bob

@Biker1bob Well that still looks screwed up compared to the analog output but at least the red is now the same at the other two so they are all rotated by 1. This might look somewhat OK on a lot of software that was written for the ST because that only uses 3 bits per colour so you would only be using every other value and that would have the right relative intensities but only at half overall brightness. If your connections match the build thread then I would have to guess that those wiring instructions are wrong. I don't have an STE but it is possible whoever came up with the wiring details got confused with the ST connections which are only 9 bits but use the lower bits 0-2 rather than 1-3. To get it to match the analog output you will have to rotate all the connections by 1.

IanSB avatar May 22 '24 14:05 IanSB

https://atari-forum.com/viewtopic.php?p=423189#p423189 Is the thread and this is the diagram I went from. I guess I could review the schematics as well. Nothing was ever posted that this was not a complete and working setup. megaste-shifter

Biker1bob avatar May 22 '24 15:05 Biker1bob

@Biker1bob That's definitely wrong and would not work properly with the STE profile as you have discovered although it might appear to look vaguely OK without using the gradient test pattern especially if running software designed for the ST.

I can see where the problem has arisen: Looking at an STE schematic, the pinout of the shifter refers to the least significant bits as R3,G3,B3 instead of R0,G0,B0. I guess that is so that RGB0-RGB2 correspond to the same bit numbering as the ST. However that is very non-standard and that labelling doesn't match the RGBtoHDMI labelling so you can't connect like for like and you would have to connect Atari 2, 1, 0, 3 to RGBtoHDMI 3, 2 ,1, 0

To avoid confusion use the resistor values instead. The highest value resistor is the lowest bit number and the lowest value resistor is the highest bit number so:

RGBtoHDMI R0, G0, B0 should be connected to the 12K resistors RGBtoHDMI R1, G1, B1 should be connected to the 6.2K resistors RGBtoHDMI R2, G2, B2 should be connected to the 3K resistors RGBtoHDMI R3, G3, B3 should be connected to the 1.5K resistors

There is another photo here which appears to be from a different board so the layout is different and not directly useful for you but that matches the above resistor connections: https://www.sellmyretro.com/uploaded/img/61574_s-l1600.jpg

IanSB avatar May 22 '24 16:05 IanSB

capture3

And we have it. I also posted your last post to the same thread I found the build. This way anyone else can adjust.

Thanks so much!!!

James

Biker1bob avatar May 22 '24 22:05 Biker1bob

@Biker1bob Looks good! As you can see it's always a good idea to use a gradient test pattern after fitting an RGBtoHDMI as it really shows up any problems very easily. BTW can you give the latest Alpha65G a try to see if the HDMI audio test works on your monitor: https://github.com/IanSB/RGBtoHDMI/issues/29#issuecomment-2099613155

IanSB avatar May 22 '24 22:05 IanSB

Never tried audio out? is there something I have to wire up?

Biker1bob avatar May 22 '24 23:05 Biker1bob

@Biker1bob

Never tried audio out? is there something I have to wire up?

No, it's just a test of HDMI audio output in preparation for full audio support with a plugin audio capture device which should hopefully be due soon. At the moment it just plays WAV files to check if the HDMI output is compatible with all monitors.

IanSB avatar May 22 '24 23:05 IanSB