gbs-control: Will it work with RGBS output from Marconi Spectrum Analyser?

[brian-mk]

This is a question rather than an issue with GBS-Control...

I have a CRT based Marconi 2380 Spectrum Analyser that provides an RGBS output. The composite sync output is: horiz: 15.625kHz, vert: 48.2Hz, non-interlaced. i.e. 324 lines.

I have tried a standard GBS-8200 (V4) to convert this to VGA. Using default GBS-8200 auto settings I get a stable image that is slightly too large in the vertical direction i.e. some lines are missing from the top and bottom of the image. If I try to reduce the vertical size using the menu buttons, the missing lines become visible but they appear to be out of sync / garbled. (more so at the bottom).

(See example image below)

Should this 324 line input signal be expected to work with standard GBS-8200 firmware? If not then if I add an ESP8266 with GBS-Control firmware, could I make this work? Will it mean making changes to some of the TVIA 5725 registers to suit the 324 line input?

The composite sync signal is shown below. (0v ref is center of screen. vert scale: 1v per div, horiz scale: 5uS/div). It is nominally 2V pk, ac coupled via a 75 Ohm resistor. It required a pull up resistor to 3.3V to give levels to meet the TVIA 5725 requirements.

[ramapcsx2]

I'd say give it a try. The line count may be odd (forgot the PAL specs.. 325 lines?), but the firmware will try to work with it :)

[brian-mk]

I added the ESP8266 module to the GBS-8200 and successfully flashed the GBS-control firmware.

I connected the Spectrum Analyser RGBS output and fed the VGA into a laptop using OBS and a VGA->USB capture device. This is the same setup I used before with the stock GBS-8200. The OBS window remains completely black.

Here is the gbs-control developer mode diagnostic output after powering up the Spectrum Analyser.

====

Activity detected, input: RGB .***** no signal h: 430 v: 647 PLL:0 A:7b7b7b S:07.10.00 H- I:00 D:05e5 m:0 ht: 0 vt: 0 hpw: 0 u: 96 s: 0 S: 6 W:-71

---

no signal h: 430 v: 647 PLL:0 A:7b7b7b S:07.10.00 H- I:00 D:05e5 m:0 ht: 0 vt: 0 hpw: 0 u:384 s: 0 S:13 W:-74

---

====

It appears from the diagnostic output that the TVIA 5725 is trying to sync using 647 lines (assuming that 'v: 647' refers to the number of lines?). Based on the horiz & vert frequencies (15.625kHz & 48.2Hz, non-interlaced) , the analyser output is actually 324 or 325 lines.

Is there a way I can force GBS-control to sync to this signal - perhaps by modifying some registers in the TVIA 5725?

[ramapcsx2]

GBSC tries to work out what the sync parameters are, and goes through a few variations, trying to lock onto something. If nothing works out, the firmware isn't clever enough (or there are bugs). I'd say try an older firmware for this. The format doesn't sound too tricky.

[brian-mk]

Yes - I figured that out by looking at the source code.

There are a few things I don't understand about the diagnostics information:-

1) What does 'no signal' actually mean when using GBSC?

With the original GBS-8200 firmware, this apparently indicates 'no composite sync' signal. I know that composite sync is present and yet GBSC still displays 'no signal' when attempting to sync.

2) What does 'h: 430 v: 647' mean? I assume it refers to the input resolution currently being used to attempt to sync. A typical CRT monitor has a 4:3 aspect ratio with the horizontal dimension being wider than the vertical. So 430, 647 would mean 647 dots horizontally and 430 lines vertically. Logically (to me at least) this would be labelled v: 430 h: 647. Yet the diagnostics output labels it the other way round i.e. h: 430 v: 647 ?

3) What do the remaining diagnostic values indicate?

4) What is the maximum time that GBSC software should take to identify the input format and sync? i.e. how long should I need to wait?

5) The GUI doesn't appear to update correctly after parameter 'on/off button' changes. It works as expected for a couple of buttons, but most still indicate 'off' after they have been changed to 'on'. The diagnostics indicates that the underlying parameter has changed state and yet the button display remains unchanged. Is this a bug? (I am using Firefox browser on a Win 10 laptop).

6) I am intrigued to know why much of the C++ source code is contained within include files? Normally, include files are only used to hold definitions needed by more than one source file.

[ramapcsx2]

I'm sorry, replying to all of that properly is out of scope atm ><

Couple things though, maybe that gets you further: The 'h: 430 v: 647' values are read out of the ASICs format detection unit. They are a hint to the software what it should attempt to get a sync lock, but they aren't a hard rule. These values can and do get misdetected. In this case, it looks like it sees double the actual video lines, and never seems to recover from that. The problem is likely in the CSync separation units, such that the VSync is not correct.

When it says "no signal", translate that as "having trouble, working on it" ;p

GUI stuff should update, if the internal state is fine. With sync issues, that is not given. Some might work, some won't.

Edit: So yeah, try working on the sync signal a bit. Maybe condition it more? Adding resistors, removing them, etc.

[brian-mk]

I spent some considerable time going through both the GBSC source code and the 5725 Programming Guide and Register Definitions. The 5725 documentation is appalling! A lot of information is sketchy or missing. Hats off to ramapcsx2 for managing to figure any of it out. I found some of the GBSC source code difficult to follow, so replaced some of the 'constants in code' with enums. This makes the code easier to understand - especially the video modes.

I wasn't able to figure out why the detected no of lines (v: 647) is double what it should be (324 or 325). I found the same problem when I tried feeding a monochrome composite video output from the spectrum analyser into the GBS-8200 green RCA input socket. I think there must be an issue with the internal 5725 sync separation.

Even if the sync separation worked correctly, It looks to me that the 5725 would not handle 325 input lines properly. It appears to be designed to only handle a few standard modes. The internal Mode Detection logic is not intended to work with an unknown input format such as this.

At this point I almost gave up. However, I discovered that if I disabled the syncWatcher and applied the presets for PAL 240p using the diagnostics commands, I could get a stable image. As with the original GBS-8200 firmware, the image appeared too large in the vertical direction. However, I was able to adjust the vertical position and size without the extra lines appearing garbled (which is what happened in the original GBS-8200 firmware).

The output captured from OBS now appears as it should:-

All I need to do now is figure out the best way to modify the GBSC code to keep this as a default setting (including the v size & position parameters).

BTW: It would be really useful if the list of GBSC diagnostics commands were documented and made available in the repository.

[ramapcsx2]

In the very high register ranges, there are chunks allotted for the format detection unit. If you can find out which of those the chip chooses for the input, you can try modifying that chunk, in an attempt to get the line count to the proper 324. The chip is designed to take these kinds of formats, all of them. It's all about the software ;p

[brian-mk]

There are some registers mssing from the TV5725 Registers Definition v1.1 PDF file (REG_S1_2B -> REG_S1_2D)

There are some definitions for the missing registers in the include file tv5725.h:- typedef UReg<0x01, 0x2B, 0, 7> GBS_PRESET_ID; typedef UReg<0x01, 0x2B, 7, 1> GBS_PRESET_CUSTOM; typedef UReg<0x01, 0x2C, 0, 1> GBS_OPTION_SCANLINES_ENABLED; typedef UReg<0x01, 0x2C, 1, 1> GBS_OPTION_SCALING_RGBHV; typedef UReg<0x01, 0x2C, 2, 1> GBS_OPTION_PALFORCED60_ENABLED; typedef UReg<0x01, 0x2C, 3, 1> GBS_RUNTIME_UNUSED_BIT; typedef UReg<0x01, 0x2C, 4, 1> GBS_RUNTIME_FTL_ADJUSTED; typedef UReg<0x01, 0x2D, 0, 8> GBS_PRESET_DISPLAY_CLOCK;

I am thinking that maybe I need to make use of the 'User Defined Mode' described in S1_80 and S1_81 to detect 325 lines. S1_2B defined in TV5725.h includes bits for GBS_PRESET_ID and GBS_PRESET_CUSTOM but these are not described in TV5725 Registers Definition v1.1.

[ramapcsx2]

Ah right, these are all empty space that I use for extra storage. I forgot about those. It's register space that exists, but isn't used by the ASIC, so it's a neat trick to put some stuff there :)

"'User Defined Mode' described in S1_80 and S1_81" sounds right, but nearby should be all the specified modes. They are not set in stone, and can be modified the same as the custom slot.

[brian-mk]

It looks like there could be a potential problem using S1_80 & S1_81 to detect user defined modes for low resolutions:-

For 325p lines & 15.625 kHz, S1_80 (MD_USER_DEF_VCNTRL) needs to be set to (325 * 2) / 16 = 40.625 i.e. 0x28. That seems ok. S1_81 (MD_USER_DEF_HCNTRL) needs to be set to 6750000 / 15625 = 432 i.e. 0x1B0. However the register is only 8 bits!

Unless the MD_USER_DEF_HCNTRL register can be ignored, that suggests user defined modes can only be used for higher resolutions?

[ramapcsx2]

Honestly, I don't remember how that works.. But you don't need that custom slot. You want to try fixing whatever slot your device is supposed to be using, and it sounds a whole lot like the standard PAL one, allbeit with slightly low vertical refresh.

[brian-mk]

I am still struggling to get the software do what I want.

Currently I have two issues:-

I loaded a preset (1280x1024). That results in a stable picture that is too large in the vertical direction. So I adjusted the vertical size & position and saved the configuration by creating a custom preset. If I then load the saved preset, the size & position revert back to the original. I don't understand what is going on here. Is the size & position information not saved?

Another issue is that having saved a preset, I can find no way to delete or rename it.

[brian-mk]

I found a fault in getVideoMode(): The code I added to detect a new 'pal_324p' mode wasn't working correctly. That had unexpected consequences. Having fixed that, the system now appears to save and restore the position and size information correctly. For some reason tho', the vertical and horizontal positions change slightly after power cycling. I have yet to work out why.

I discovered how to rename a preset - although not how to delete it.

There are some things I still do not understand...

1) Why are there doubled up preset IDs? For example 1280x960 exists as 0x1 and 0x11, 1280x1024 exists as 0x2 and 0x12 etc. The code checks for both ID values in many places.

2) I am confused by user created presets labelled as 'custom' vs presets labelled with a particular resolution such as '1280x1024'. Am I right in thinking that 'custom' refers to a saved preset that is not associated with a known videoMode?

[ramapcsx2]

Iirc, the preset IDs double up for variations of the same source format. Was it like, 1280x960 for PAL and for NTSC? I think so.. :)

Sounds about right with the custom. Each preset requires a source format for it to work. Trying to apply something made for NTSC wouldn't work on PAL, etc.

[brian-mk]

While attempting to detect the 324 line mode, one of the things I tried was to make use of the existing code in getVideomode() that detects a stable, but unrecognised, number of lines. It reads STATUS_SYNC_PROC_VTOTAL a couple of times in succession. If it appears stable (+/- 1 line) then it increments a 'notRecognized' counter, otherwise it resets the counter to 0. Either way it returns 'unknown mode' (=0). On subsequent calls to getVideomode(), if the 'stable' counter reaches 255 it returns 'unrecognised mode' (=9).

I thought this existing mechanism would be more flexible than adding code that expliciltly tests for 324 lines. It should be able to handle inputs with almost any number of lines (within reason).

What I found is that STATUS_SYNC_PROC_VTOTAL only gives a stable result (=323) when in sync. When not in sync the register value varies considerably: The 'notRecognized' counter keeps being reset and never reaches 255. The mode remains set to 'unknown mode' (=0) and the system never manages to sync.

I ended up checking the VPERIOD_IF register instead. At least that appears to remain stable. It indicates twice the expected number of lines, so I have to test for 647 (+/- 1). Once in sync and the associated custom preset is loaded, if I enable 'print info' in the diagnostics, STATUS_SYNC_PROC_VTOTAL remains stable and always indicates 323. This method works but it's not as flexible as the existing 'unrecognised mode'.

Is an unstable STATUS_SYNC_PROC_VTOTAL when not in sync something you would expect?

[ramapcsx2]

Yes, definitely! And welcome to the fun part of developing this ASIC firmware :D I don't remember the details, but you basically have the major processing blocks that each can feed their data down the chain. The top level for syncs is the sync processor, and it sees unfiltered line counts, all depending on the sync separation performance. When this is not stable, the firmware should try to tweak the sync separation or sync level parameters. At the next stage, the sync processor feeds the created h/v syncs to the IF unit (input formatter), which prepares the digital processing. The IF has logic to filter the sync processor inputs, hence you see a stable signal here, but it can also lock into using an actually unstable signal and not notice it.

I'd say, use whatever works for you. If you can work with the IF line count, then go for it :)

[brian-mk]

Years ago, I used to work for Crosfield Electronics as an embedded software engineer. One of the projects was a 'Colour Retouch Accelerator Board (CRAB)' deigned to speed up desktop workstations so that they could compete with high end Crosfield Studio Systems. That card also used an ASIC. The documementation provided by the ASIC designers was also 'poor' to say the least. Luckily we were able to talk to them directly to figure out how they expected the system to operate and ask about 'features' that were not written down. Unfortunatley, getting answers that way is not posible with the 5725.

An example is the SP_DLT_REG. The only information given in the registers definition document is:- "Sync separation control. Sync pulse width difference threshold." It doesn't tell you what that actually means, what effect it has or even which sync pulse (or pulses) it is refering to. It doesn't tell you what the units are - is it no of clocks? (if so, which clock) or is it msec or usec?

I mention that one because I noticed that it gets adjusted in updateSpDynamic() when the video mode is 'unknown'.

if (rto->videoStandardInput == 0 && vidModeReadout == 0) {
    if (GBS::SP_DLT_REG::read() > 0x30)
        GBS::SP_DLT_REG::write(0x30); // 5_35
    else
        GBS::SP_DLT_REG::write(0xC0);
    return;

[ramapcsx2]

Ehhh, something with units of the ADC part of the sync processor output.. but it's important. This is a major sync separation parameter.