Apple ][europlus / PAL

[JPT77]

Hi,

I modified one of my Apples to NTSC so the image is color. Now I realized the PAL Apple's output is shown in color, too. So there would not have been any need to mod the apple...

But: It doesn't work great. Is this because PAL-Color isn't really implemented in the RGBtoHDMI?

The problems are: there are color waves traveling up or downwards (vertically), depending on the tuning of the color poti. The B&W image jitters a single pixel horizontally (left/right) The detection if the picture should be colored or BW does not work great.

any idea? thanks Jan

[IanSB]

@JPT77

RGBtoHDMI decodes the NTSC artifacts based on pixel patterns, not actual frequencies so it will work on any monochrome image at any pixel frequency and there is no need to modify the Apple II but if you have a PAL colour card, that should be removed (unless it has a separate output and the normal mono output is unencoded.) I can't recall if the colour burst is disabled on the PAL II in mono mode but if it is, auto detect of colour burst won't work unless you modify the hardware to turn it back on.

If you are trying to connect to a PAL colour card then the 4.43Mhz PAL signal is likely the cause of the patterns but if you are looking at the mono output then something else might be wrong with the profile.

Similarly with the PAL Apple IIe you have to disable the PAL encoder using a switch on the motherboard to get a mono output for RGBtoHDMI. I'm pretty sure the PAL IIe colour burst is disabled in mono mode so no auto detect.

[JPT77]

No PAL color card. Just the onboard PAL. I do not really understand what you are saying ;)

[IanSB]

@JPT77

No PAL color card. Just the onboard PAL.

The "PAL" version of the Apple II+ (Euro+) doesn't output PAL encoded colour, just a monochrome image which RGBtoHDMI can decode to colour using the monochrome pixel patterns. The only major difference with the PAL board is that it uses a different crystal frequency and generates 312 lines per frame @ 50Hz rather than 262 lines per frame @ 60Hz.

I do not really understand what you are saying ;)

The original NTSC Apple II generates colours using NTSC artifacts. It effectively has a monochrome video output and the pixels can either be black or white. However when such a monochrome video signal is fed to an NTSC TV, it interprets different patterns of black and white pixels as colour information so you can get up to 16 different colours that way. This trick doesn't work in PAL mode so the standard "PAL" system was only capable of mono video output. A separate PAL encoder card could be added and that decoded the NTSC pixel patterns and re-encoded the colours to PAL. RGBtoHDMI can similarly decode the pixel patterns to colours.

The PAL version of the later Apple IIe had that PAL encoder built into the motherboard but it could be disabled with a switch so the computer outputs a monochrome image and that is required for RGBtoHDMI to work.

Have you run an auto calibration? (Long press of SW3 until it starts or use the menu option)

Also I suggest you download the latest beta58 as that has some built in help in the Info menu: https://github.com/IanSB/RGBtoHDMI/releases

If you are still getting problems, post a screencap of the source summary menu (Press SW2 + SW3 - screencap in /captures on the SD card) Also use the Save Log and EDID option and post log.txt from the SD card

[IanSB]

@JPT77

Other things to try adjusting: The Sync detect level (DAC-F in the sampling menu) Video detect level (DAC-A in the sampling menu) colour burst detect level used to switch colour on/off (DAC-B in the sampling menu)

Post your value if that fixes things

(You may have to adjust these if you have been tweaking the video level and colour phase trimmers on the motherboard)