Support for older Analog boards?

[hoglet67]

Hi Ian,

I have a couple of V2 analog boards that I would like to bring back into use.

I'm currently testing with an RGBtoHDMI issue 2, the BBC CPLD v7.9, the BBC Profile and the latest Beta56.

I've hit a couple of issues.

Issue 1: The analog board is incorrectly detected as a V3 board this can't be changed manually.

Looking at the code, it seems that it's not possible to differentiate between the following boards:

   FRONTEND_ANALOG_ISSUE3_5259
   FRONTEND_ANALOG_ISSUE2_5259
   FRONTEND_ANALOG_ISSUE1_UA1
   FRONTEND_ANALOG_ISSUE1_UB1

That's fine, except there is no longer a way to manually set the interface, because the interface setting is now hidden due to:

 HIDE_INTERFACE_SETTING

Would it be possible to decide at run time whether to hide the interface setting, based for example on whether the frontend info returns a range of possible interfaces?

For now, I've commented HIDE_INTERFACE_SETTING in defs.h so I can continue testing.

Issue 2: The green clamping is not working on the V2 Analog board with the latest BBC CPLD

What's happening is the CLAMP signal on pin 4 of the P2 connector is always ow:

        clamp_int <= not(csync1 or csync2) and sp_data;
        analog <= 'Z' when version = '0' else clamp_int;

In this case it's sp_data (GPIO0) that low.

Looking a cpld_rgb.c I think this is happening because of the supports_bbc_9_12 flag.

          switch(config->rate) {
                      default:
              case RGB_RATE_3:
              case RGB_RATE_6:
                    if (supports_bbc_9_12) {
                        RPI_SetGpioValue(SP_DATA_PIN, 0);   //no ac coupling
                    } else {
                        RPI_SetGpioValue(SP_DATA_PIN, coupling);
                    }
                    break;

So it looks like V 7.8 of the BBC CPLD uses SP_DATA to enable 9/12 bit capture modes rather than controlling AC Coupling?

Is this all expected?

I've got a couple of workarounds:

• Revert to a version of the BBC CPLD older than 7.8
• Switch to the RGB CPLD and use the Electron profile (as the BBC profiles are not present)

What's the main use case for the 9 and 12 bit modes with the BBC CPLD? VideoNuLA?

Dave

[IanSB]

@hoglet67

That's fine, except there is no longer a way to manually set the interface, because the interface setting is now hidden

I hid it by default on current builds as there were so few boards around (I think only you and I have them) that it was more likely to lead to support issues due to users playing with that setting, forgetting about it and then later finding their analog board didn't work. (Especially as that setting is saved immediately unlike profiles)

Would it be possible to decide at run time whether to hide the interface setting, based for example on whether the frontend info returns a range of possible interfaces?

If you use a standard release build but edit the config.txt file (after first boot has set things up) to change the appropriate #interface_X=Y settings to the values that have been set with the custom build then it should maintain those settings so that is another way to specify Issue 1/2 interfaces without needing a custom build.

I suppose it might be possible to display the menu after reading back such a manually edited config.txt but it would only be informational as editing the config.txt file will have already set it to issue 2. (There are multiple #interface settings, one for each CPLD)

So it looks like V 7.8 of the BBC CPLD uses SP_DATA to enable 9/12 bit capture modes rather than controlling AC Coupling? Is this all expected?

Yes, I sacrificed analog green clamping on the BBC CPLD in order to support 9/12 bit for Video Nula as Analog clamping was already available on the RGB and YUV CPLDs and there weren't any profiles in the BBC profile set that used it anyway. (This affects all analog boards, not just Issue 2)

I think this was due to lack of space in the CPLD to add another bit to the serial control register.

I've got a couple of workarounds: Revert to a version of the BBC CPLD older than 7.8

This should work but doesn't get tested very often these days as the current CPLD is now enforced on a clean install. (i.e. after a clean install you have to upgrade to the current CPLD but you can downgrade after that until the next clean install)

Switch to the RGB CPLD and use the Electron profile (as the BBC profiles are not present)

This was the design choice.

BTW It recently occurred to me that another way of passing the control bits into the CPLD would be to do it in parallel using the 12 bit data bus bidirectionally rather than serially but I don't know if that would be any less complex than the existing method. (If it was less complex it might free up some space in the CPLDs). Any thoughts on that?

[IanSB]

@hoglet67

As mentioned above, if you add the following to the bottom of config.txt replacing any existing #interface values, that should permanently set the configuration to an Issue 2 board on a standard software install and it should show in the system summary menu as issue 2. (Interface_3 is YUV and Interface_C is BBC / RGB)

interface_3=12

interface_C=6

(The numbers might change if any further interface designs are added)

[hoglet67]

BTW It recently occurred to me that another way of passing the control bits into the CPLD would be to do it in parallel using the 12 bit data bus bidirectionally rather than serially but I don't know if that would be any less complex than the existing method. (If it was less complex it might free up some space in the CPLDs). Any thoughts on that?

I don't think that would be any more efficient - it will still take one macrocell per config register.

I've just had a quick look at the vhdl_RGB_6bit build (which I think it's what's used for the "BBC" CPLDs). The hot spot is FB1, running out of product terms before all the macrocells are used. This is what's preventing the design from fitting. The high product term usage is down to the complexity of the psync and counter logic. It's possible that constraining the locations of some of the internal registers might perturb things enough to allow successful fit, but that's somewhat random. Alternatively, if it were possible to reduce the complexity of either psync or counter logic, it might fit. I might have a fiddle with this tomorrow.

interface_C=6

Thanks, that worked.

What's the reason the clamp output of the CPLD needs to be enabled/disabled under software control? What would break if it were enabled all the time?

Dave

[IanSB]

What's the reason the clamp output of the CPLD needs to be enabled/disabled under software control? What would break if it were enabled all the time?

On the issue 3 boards the clamp is permanently connected to the video path via C1 irrespective of the setting of the AC/DC switch U6 and I recall it introduced a noticeable disturbance in the DC level of the green/Y channel when DC coupled if the source was high impedance.