Latest release does not let me navigate the OSD menu.

[HenrikErlandsson]

With switch attached to Rpi 2-pin header,

Long press: toggles scanlines. Single/double-press: toggles menu on/off.

No way to move the cursor.

Also, default is Acorn Electron with NOT RGB over HDMI. Unhelpful to most users.

Also, card contains 3x config.txt none of which correspond to OSD menu settings which users will want to change as soon as they run the software.

[HenrikErlandsson]

In :Profiles/Default.txt, set

single_button_mode=1

and thank me later. It's rather mad that it's default 0, or maybe this hardware driver is purely for the emulation crowd and not even for real Acorn users. I have an Acorn Atom and an Acorn Archimedes (sold my Risc PC sadly) which I programmed.

This is open source software. I'm a GitHub user, and I'm a top coder on any system. I can change the default to a sane one, and no-one will have a problem, isn't that right?

For anyone reading this, then set HDMI mode to RGB with the OSD menu (there is no file on the card to do this, certainly not in the mentioned file).

Black is middle gray, but it scrolls at full framerate and the weird default randomcolor pixel edges are gone. It's a start.

Glad to help.

[HenrikErlandsson]

In the main menu, change the default to RGB Full, not Limited, and in the Palette menu, change to RGB. Middle gray instead of black is gone, poof.

Not sure why the defaults are set away from this. It's great that this project support all the alternatives to just RGBtoSCART, but if RGBtoHDMI should be a solution, it should replace the jack that's not there anymore!

And not be set to a not RGB system as default, and not prevent menu navigation to fix it as default.

So I've complained (that was an annoying experience.)

I'd like to help. So which files do I edit in the repo to make these the default, and release a new version? I want to save time for all fellow computer users.

No menu nav, Acorn Electron, RGB Limited, and not RGB palette is about the most unhelpful I can think of. >:((((

[IanSB]

@HenrikErlandsson

What hardware are you trying to run this on? e.g. standard RGBtoHDMI c0pperdragon style simple Amiga board (no CPLD) CPLD based internal Amiga board (linuxjedi style) etc.

[HenrikErlandsson]

I'm running a piece of software on the platform it supports. Specifically, RGBtoHDMI on RPi Zero WH.

I complain about really bad software defaults. The current defaults assume 3 things: 1) If you use HDMI, you do not want RGB over HDMI (contrary to the project name). You must change from the default to get it. 2) Everyone who downloads this archive wants as default to connect it to an Acorn Electron. You must change from the default to not get primary colors as first impression. 3) This solution accepts menu navigation by an RPi header pin connected to a switch, and despite the RPi sitting inside an existing computer case with a keyboard, the default is to use this pin to toggle scanlines, and require attaching a second keyboard via microUSB to navigate the menu.

I did not do that. I edited the file mentioned above.

This let me control the menu and set up RGB over HDMI.

My suggestion at the very least is to allow menu control without plugging a keyboard into the RPi, this will fix 3).

But 1) and 2) are also bad defaults. Because of the name of the project.

[IanSB]

@HenrikErlandsson

I'm running a piece of software on the platform it supports. Specifically, RGBtoHDMI on RPi Zero WH.

The primary supported platform is the standard external CPLD based RGBtoHDMI board as described in the wiki on this site which has three buttons and the menus are configured to operate with that.

I later added support with one button operation using long and short presses for a couple of internal Amiga configurations designed by others which are:

1. The c0pperdragon non-CPLD design and variants This board is automatically detected and the software is automatically configured for one button operation with "Amiga" as the default profile.

2. The linux jedi style CPLD based design and variants. This appears to the software as a standard three button CPLD board so is not autodetected and thus defaults to standard three button operation and Electron profile. (This project was originally created for the Acorn computers so defaults to those systems) To aid in configuring this type of board there is a folder on the SD card "Amiga CPLD readme" which contains a set of files that can be copied over the originals to set the default to one button operation with either Amiga or Amiga 2000 as the default profile. See Amiga_Readme.txt in that folder for more details.

I'm not aware of any other hardware variants that require additional support.

If you use HDMI, you do not want RGB over HDMI (contrary to the project name). You must change from the default to get it.

The default HDMI output is RGB using DVI signalling protocols for backwards compatibility with DVI monitors. In theory that should work with all HDMI monitors but it was discovered that some HDMI devices like capture cards and a few more recent 4K TVs don't support DVI backwards compatibility and display wrong colours so the HDMI mode setting was added to allow switching to true HDMI signalling and you can select from four different types.

It is not possible to default to true HDMI signalling because you will get no display at all on a DVI monitor so not be able to change the setting. However I am planning to auto detect which type of monitor is connected and switch the signalling automatically in a future update.

[HenrikErlandsson]

The following will happen when each buyer gets his RGBtoHDMI home and the archive has the default settings set to OSD menu button=toggle scanlines and HDMI mode = not RGB:

1. They will not get RGB over HDMI, resulting in wrong colors.
2. They will not even be able to get into the menu to set the mode to RGB over HDMI.

The following will happen when each buyer gets his RGBtoHDMI home and the archive has the default settings set to OSD menu button=OSD menu button and HDMI mode = RGB:

1. They get correct RGB colors over HDMI. It works instantly.
2. They can make any number of tweaks to the picture including toggling scanlines, without having to consult documentation and edit configuration files. Because it works instantly, they might not even have to attach the menu button.

Currently, the default configuration files are made for users of RGBtoHDMI who want to attach a Blu-Ray or something, and never want to navigate the menu. These must be a vast minority, which is what makes them bad defaults.

[IanSB]

@HenrikErlandsson You still haven't mentioned what hardware you are using but from your description I have assumed an Amiga CPLD RGBtoHDMI and a 4K monitor.

Currently, the default configuration files are made for users of RGBtoHDMI who want to attach a Blu-Ray or something,

The reason that the HDMI mode is set to "DVI Compatible" is so that old 4:3 lcd monitors work, not Blu Ray!
If it had been set to "HDMI RGB" then DVI monitors would not work at all (black screen).

The vast majority of HDMI monitors are compatible with the default DVI setting and display colours correctly. A tiny minority of monitors like yours don't display the DVI RGB colours correctly so you have to change the setting. So most users would not have a problem with the default and you are the only one so far to mention this.

However I have now implemented auto detection of the HDMI mode. When connected to a DVI monitor it selects DVI Compatible When connected to a HDMI monitor it selects HDMI RGB

So this should solve your monitor problem without affecting users with old DVI monitors.

and never want to navigate the menu. These must be a vast minority, which is what makes them bad defaults.

The project is designed for the general purpose three button 12bit converter which is used by the vast majority of users so the settings are defaulted for that: https://raw.githubusercontent.com/wiki/hoglet67/RGBtoHDMI/images/12bit.jpg

The software cannot tell the difference between this board and the single button Amiga CPLD board which is used by a small number of people so it is not possible to auto configure the buttons which is why the "Amiga_CPLD_Readme" update files must be manually copied. The only other option would be a separate release file just for the Amiga but even that would still need some manual configuration to select between the original Amiga profile with composite sync and the later Amiga 2000 etc with separate sync.

There is an alpha version of the software here (Alpha 61E) if you want to try the auto HDMI mode detection: (Note this hasn't had much testing yet)

https://github.com/IanSB/RGBtoHDMI/issues/21#issuecomment-1781599238

Please let me know if this fixes your monitor problem.

[HenrikErlandsson]

4:3 monitors were before HDMI and DVI. Timeline: VGA, DVI, HDMI, DP. 16:9 came during the VGA period, then there were no more 4:3 monitors. If you doubt me, websearch "history of monitor connection types" and "when did vga switch to 16:9".

DVI over HDMI is for consumer equipment connected to a TV.

Solution is called RGBtoHDMI, so RGB over HDMI is expected as default. Plenty of consumer equipment including video equipment, consoles and computers output RGB while they have no DVI or HDMI output. It may very well be that my monitor can display DVI over HDMI, but if the default is Acorn Electron this would explain the wrong colors (primary or close to primary colors). So IDK if the autodetect will make a difference, if I reset to default.

The files I transferred to the card at date of post are the same as every single other user has transferred, and showed Acorn Electron as default, once I made the menu button work. I did so just by changing the default off to on.

So for single button OSD navigation, the solution is easy. Simply enable the option. If no button present it works as expected and one is, it works as expected.

I support this project but history shows bad defaults can be all it takes to make or break, so I want to help. Acorn Electron users possessing a 4:3 computer monitor with HDMI, wanting to toggle scanlines a lot and never use the OSD menu can't be right.