search

hoglet67 / RGBtoHDMI

Bare-metal Raspberry Pi project that provides pixel-perfect sampling of Retro Computer RGB/YUV video and conversion to HDMI
GNU General Public License v3.0
807 stars 112 forks source link

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

Open gelo291 opened 4 months ago

gelo291 commented 4 months ago

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

IanSB commented 4 months ago

@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.

gelo291 commented 4 months ago

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

Biker1bob commented 1 month ago

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.

IanSB commented 1 month ago

@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.

Biker1bob commented 1 month ago

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

IanSB commented 1 month ago

@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)

Biker1bob commented 1 month ago

capture0 capture1

IanSB commented 1 month ago

@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

Biker1bob commented 1 month ago

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

Biker1bob commented 1 month ago

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

IanSB commented 1 month ago

@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?

Biker1bob commented 1 month ago

capture2

IanSB commented 1 month ago

@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.

Biker1bob commented 1 month ago

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

IanSB commented 1 month ago

@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

Biker1bob commented 1 month ago

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

IanSB commented 1 month ago

@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

Biker1bob commented 1 month ago

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

IanSB commented 1 month ago

@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.