Oddball request

[snhirsch]

One of my favorite vintage machines is a Corvus Concept desktop. It was sold with a Ball Bros. CRT monitor that could mount in landscape or portrait orientation. A switch on the CPU unit rotates display accordingly. When configured for landscape, the display is "upside down" with the origin at lower right, scanning to left and upwards. In portrait, the display origin is upper right, scanning down and to the left. Short of performing gyrations with the monitor, is there any way to use rgb2hdmi to normalize the output for display? The video output is an otherwise rather standard video/H/V sync. I've been able to use it with an older Extron scaler, but that required the referenced gyrations :-).

[IanSB]

@snhirsch
The Pi has a config.txt option for changing the frame buffer display scan orientation as follows:

I have tried all the above options of this by manually adding the setting to the config.txt file and most of them have issues like flickering menus and screen corruption probably due to the way that RGBtoHDMI works.

For the scanning you mention above, the options would seem be
display_hdmi_rotate=2
or
display_hdmi_rotate=0x10000
or
display_hdmi_rotate=0x20000
and they do seem to work enough to get an idea of if they would be useful. These problems might be overcome with some code changes so I will have a look at this sometime.

You could try the above yourself by adding one of the above lines to config.txt in the Common video settings section

Do you have any further info on the Corvus Concept video like number of bits per pixel or resolution?

[snhirsch]

Thanks for getting back. I'm not actually have any success in getting a display - rotated or otherwise. On my Extron 300A scaler, I get a perfect (rotated) image with these parameters:

• Total pixels per line = 928
• Phase = 4
• Hstart = 70
• Vstart = 126
• Active pixels = 720H x 560V

Hsync is positive going @ 35.5KHz. Vsync is negative @ 30Hz
Monochrome video B&W

With the analog board installed on the rgb2hdmi I tried grounding pins 1,3,5 connected hsync to 2 and video to 4. It complains about "NO SYNC" and presents a totally garbaged display. I could get the no sync warning to disappear by backing down the voltage level in sampling, but I'm unable to successfully dial in the geometry. If I try to set the clock to 35Khz. or change the line length, the screen goes solid green and the unit stops responding. Not sure where to go at this point.

[IanSB]

@snhirsch

Hsync is positive going @ 35.5KHz. Vsync is negative @ 30Hz
Monochrome video B&W
With the analog board installed on the rgb2hdmi I tried grounding pins 1,3,5 connected hsync to 2 and video to 4. It complains about "NO SYNC" and presents a totally garbaged display.

The analog board only has composite sync input with no separate inputs for H/V sync so for full RGB support you would first have to combine the H and V syncs to make composite.
However I recently realised that it would be possible to feed separate H and V and mono video into the analog board in a slightly unusual way because the green input supports sync on green so try the following:
Feed Hsync into the sync input
Feed Vsync into the green input
Feed Video into the blue input.

Set "Palette" to Test 4Lvl B or U in the palette menu (This displays only the blue channel)
Set "Sync type" to +H-V in the geometry menu
Set "Sync on G/V" to Off in the sampling menu (not on as that makes it look for composite sync)
Then adjust the sampling menu DAC levels as follows
DAC A - Disabled
DAC B - Disabled
DAC C RB Hi for video level
DAC D RB Lo Disabled (or can be adjusted for multi level mono video)
DAC-E Sync for hsync level
DAC-F G V Sync for vsync level

Note that a new beta due soon will map the standard mono palettes on the blue channel in a special new mode to support this as the test palette is not really the correct option but it should allow you to test it with the current release.

[snhirsch]

That's a bit better (see attached screen grab), but I'm not able to dial in the geometry properly. If I try to set total line length to anything but the default 1000, I lose the entire screen display - menu included - and have to power cycle to get it back. I do not understand the the difference between H & V size and Max H &V size on the geometry menu. Nothing I do mitigates against the multiple copies of the display.

And, this is not stable. If I exit the menu it starts flashing 2x per second.

Here's the capture:

And this is what the Extron renders:

Any clarifications and/or suggestions appreciated. It would help if you can clarify which base profile I'm supposed to be using. There are (2) RGB profiles in the list.

[IanSB]

@snhirsch

I do not understand the the difference between H & V size and Max H &V size on the geometry menu.

Once you have setup the above things, you should be using the Create Custom Profile menu which auto sets most things like that to sensible defaults based on the incoming sync timing so you would only need to adjust the number of clock cycles per line or the pixel clock.

However it looks like the pixel clock rate for this screen is quite high and if it is >30Mhz then you will need to reduce the bits per pixel from 6BPP to 3BPP

So, make the above changes, set the Sample mode to 3 bits per pixel in the sampling menu then go into the create custom profile menu and change the clock cycles per line to the correct value or the pixel clock to the correct value (the other will auto adjust based on the sync timing)

You can then make other tweaks like the offsets.

[snhirsch]

Thanks, I followed your advice and was able to dial in a beautiful display. Unfortunately it starts flashing on and off when I exit the menu. So something is still not right. What I do not understand is why the display is stable when the menu is visible. If it can lock to it under those circumstances then why not when I exit?

Here's the capture of the flashing display:

And here is my saved configuration:
Custom_Profile_0_.txt
If there's a way to stabilize this it would be great.

[IanSB]

@snhirsch

What I do not understand is why the display is stable when the menu is visible. If it can lock to it under those circumstances then why not when I exit?

When the menu is on some code to do with detecting problems with the timing is disabled so you can actually make adjustments without the screen flashing but when the menu is off that code is enabled and that makes the screen flash indicating there is a timing problem. (note when the menu is on every other frame is being dropped and if that happens when the menu is off then the screen will flash)
There are two types of causes for flashing, as detailed in the help menus in the info menu under "help flashing screen". One is due to the screen capture size being too large which can be addressed by reducing the max H and V sizes and the other is timing related.
First try reducing the Max H and V sizes to match the Min sizes or make them only slightly larger (which guarantees that the edges get captured when there is slight timing misalignment).
Currently the max V size is set to 610 which is greater than the number of lines per frame (588) which could cause frame drops.
If that doesn't work then post a screencap of the source summary page (press up and down buttons to screencap the page)

[IanSB]

@snhirsch
To explain further about the min/max sizes, the min size is set to the actual pixel resolution and the max size is set to the overall active video size including any coloured border. Your particular screen doesn't seem to have any border so they can be set the same but that then means that the H and V offsets in the geometry menu and the Pixel H offset in the sampling menu have to be set very accurately to capture the image so having the max values a few pixels larger than the min can help if there is any misalignment.

[snhirsch]

Thanks so much for all the help! I have a crisp, stable display now. Here are some screen shots and the config file. Please let me know if anything looks out of place?
concept.zip
Just FYI: I think the wording about "screen size too large.." in the "Flashing Screen" help should be clarified to explicitly mention the exact settings under geometry. The word "size" is heavily overloaded. I originally thought it was referring to the frame buffer and didn't quite get it.

The only nit I noticed is that screen capture failed when I tried to grab a full display of the Concept word processor. When I press the 'down' button it flashes... something on the screen too quickly to read. In the capture directory I found a 75 byte file that represented the header of a PNG, but was corrupt and could not be viewed. A grab of the empty screen did work correctly.

[snhirsch]

I moved on to try rotating the display. Unfortunately adding:

display_hdmi_rotate=1

to config.txt in the root of the SD card has no effect at all. Am I misunderstanding something?

[IanSB]

@snhirsch

Please let me know if anything looks out of place?

The FB Bits/pixel in geometry should be 8bpp or 4bpp rather than 16bpp (4bpp might help with screen rotation)
The clock multiplier in sampling should be x4
Both of the above have been auto limited anyway if you look at the source summary page as the existing settings are out of range but they should be set correctly in the menus.

The only nit I noticed is that screen capture failed when I tried to grab a full display of the Concept word processor.

Maybe changing from 16bpp to 8bpp or less will fix the screencap but if not, try a screencap then go to the info menu and use save log and EDID and post log.txt from the SD card which might show an error message or other info to help fix that.

BTW the problem with the too large max values when you created your profile had already been fixed in the forthcoming beta as the create profile menu now has separate border settings which default to 0:

I moved on to try rotating the display. Unfortunately adding:
display_hdmi_rotate=1
to config.txt in the root of the SD card has no effect at all. Am I misunderstanding something?

If you put it in the wrong place it might get ignored, try at this location: (you have to reboot after editing)

# =====================
# Common video settings
# =====================

display_hdmi_rotate=1

# Allow framebuffer to have it's aspect ratio warped when scaling
# (needed for mode 7, 504x540 with 4/3 aspect ratio pixels)
framebuffer_aspect=-1

Also you might get better results by changing the existing disable_l2cache setting from 1 to 0 in config.txt
Note however this can cause problems with other profiles so should not be left that way.

# Don't allow ARM to use Level 2 Cache - this actually speeds up cache misses
disable_l2cache=0

Note however that the 90 and 270 degree rotations are messed up but you can get usually get something to give you an idea of what it will look like with the menu on.

I do intend to add proper support for rotated portrait screens but don't know how long that will take.
BTW I will add you finalised profile to the next beta

[snhirsch]

I made the changes you suggested to sampling and geometry - thanks. Rotate does take effect when it's ahead of all the other video settings. It actually looks quite good, but I cannot get it to lock (flashing). Do I need to transpose the dimensions manually - or should I generate a new configuration? Recalibrating did not help with the flashing.

Regarding corrupted screen capture - it seems to have something to do with scanlines. If I turn off scanlines it claims to have captured the image, but there is nothing in the capture directory. After reverting the rotation mods I'll take another run at it.

And, sorry to be dense, but can I actually log into the Pi Zero when it's running rgb2hdmi? I thought the video code ran on bare metal.

[IanSB]

@snhirsch

It actually looks quite good, but I cannot get it to lock (flashing). Do I need to transpose the dimensions manually - or should I generate a new configuration? Recalibrating did not help with the flashing.

I don't think there is anything you can do to get it to work any better at the moment, some code changes will be required.
The main problem is there is too much memory contention causing dropped lines or frames because you have to have one side reading or writing across the memory rather than sequentially and that requires a lot more cycles.

can I actually log into the Pi Zero when it's running rgb2hdmi? I thought the video code ran on bare metal.

No, you can't log in as it is bare metal and there is no OS.
It does generate a 3.3v serial log which you can view live by connecting a terminal program to TxD on the 40 way header (115200 baud 8 data 1 stop no parity) or you can save the accumulated log to the SD card using the Save log feature.

[snhirsch]

Hi, Ian. I tried using a 180-degree Pi rotation with the Concept landscape mode (more practical for contemporary monitors) and it works perfectly aside from the upside-down rgb2hdmi menus. Along the way I discovered that Concept video has an extra pixel or two in the horizontal direction and bumped up the 'max' setting accordingly. This may well have helped with the rotated image but I didn't go back to verify. I discovered it using one of the Concept's diagnostic features to put up an alignment grid.

Attached is my final working configuration file along with setup and cabling notes.

Thanks SO much for the help and input. You folks have designed a great gadget!

concept_setup.zip

[IanSB]

@snhirsch
Thanks for the update. I have included your profile in the latest beta65 which I have uploaded on my fork of the project here:
https://github.com/IanSB/RGBtoHDMI/releases

You will still need to edit the config.txt for the rotate and l2cache settings but the profile now makes use of a new setting in the palette menu "Mono Palette" which switches mono usage between the green, blue and red channels so you can then use the standard mono palette with any option and don't need the test palette.

I have updated your profile with that setting and put it in the "Other" section of the profiles so can you test that and confirm it still works.

[snhirsch]

It's not working properly for me. The bottom of the display sort of comes and goes periodically - not flashing but simply invisible some of the time. Also, for some reason my custom saved profiles are not appearing in the select list. I did copy the entire Saved_Profiles tree but it's not recognized.

[IanSB]

@snhirsch

It's not working properly for me. The bottom of the display sort of comes and goes periodically - not flashing but simply invisible some of the time

Thanks for the feedback. I'll have to figure out when that got broken.

Also, for some reason my custom saved profiles are not appearing in the select list. I did copy the entire Saved_Profiles tree but it's not recognized.

Saved profiles are only visible if there is a matching named profile in the Profiles folder tree which there won't be on a new install so put your saved profile in the Profiles folder tree at the same location instead.

[snhirsch]

Let me know if you need any more information on the "comes and goes" lower screen display. Certainly strange behavior. There is no sync instability at all and it looks perfect when the bottom 1/3 of the screen deigns to become visible.

[IanSB]

@snhirsch
This happened because I made some internal changes so the software which now drives the hardware directly rather than going through the Pi's embedded firmware as that freed up one of the VPU processor cores for other things and those changes can't cope with the rotated image.
However I ultimately intend to solve the rotation by adding dedicated capture code for those orientations which would mean that the menus would always be the right way up so it will be fixed by that but it may be some time as I have other things to address first.

In the meantime, stick with the current stable release and I will @ you when I have a new beta with those features implemented.