21.7khz 350-line EGA

[rasteri]

Does, or can, gbs-control support 21.7KHz 350-line EGA? I've tried hooking it up straight to the output of my EGA card (actually a PC1640), with separate H and V sync lines, and I can't get it to sync at all. It just results in a garbled image.

Here is a photo of the garbled output (running qbasic editor) :

Here's an oscilloscope capure of the Hsync and Vsync signals to verify that it is detecting the frequency and polarity correctly :

I've also included for reference a photo of the qbasic editor running in 200-line mode perfectly :

Here is a few lines of output from "print infos" in 350-line mode:

h: 308 v: 33 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0685 m:14 ht:2176 vt: 365 hpw: 235 u: 0 s:ff S:13 W:-78 h: 308 v: 33 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0602 m:14 ht:2175 vt: 365 hpw: 233 u: 0 s:ff S:13 W:-78 h: 308 v: 33 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0612 m:14 ht:2177 vt: 365 hpw: 234 u: 0 s:ff S:13 W:-79

And in 200-line mode, for reference : h: 429 v:1695 PLL:0 A:7b7b7b S:02.18.20 H+V+ I:00 D:0600 m:14 ht:2558 vt: 261 hpw: 180 u: 0 s:ff S:13 W:-76 h: 429 v:1695 PLL:0 A:7b7b7b S:02.18.20 H+V+ I:00 D:0600 m:14 ht:2558 vt: 261 hpw: 180 u: 0 s:ff S:13 W:-76

[rasteri]

If this is technically possible but not implemented yet, I'd be happy to help contribute code if you can point me in the vague direction of how this might be implemented.

[ramapcsx2]

This is a good bug report, thanks for that :)

So if you want to try working on this, you need to connect your ESP8266 to your PC via USB cable, and have the Arduino IDE serial monitor open (or any other terminal to access the ESP).
You have several commands available (sorry, no documentation, but you can look it up in loop()). First, disable syncwatcher by sending: m Then this looks like an ADC out of operating frequency error to me, so try to toggle the ADC clock gain bit: t5t11t5
You can also try to set a different charge pump current: s5s17s05 j
^ exchange the 05 with 01 .. 07 (weakest to strongest)

Please report back if any of those help.

[rasteri]

After running t5t11t5 I'm able to recognise some features, it seems to be fitting the frame in vertically but horizontal sync is still way off. Altering the charge pump seems to change the flicker frequency but not much else.

Any other ideas of options I could tweak?

I took some pictures, this is with "Freeze Capture" on. When freeze capture is off it's just a flickering mess in the horizontal direction (although relatively vertically stable).

Here's before running t5t11t5, for reference :

And here's after, with different values of s5s17sxx j (starting at 01 and going up to 07, I run out of fingers eventually but you get the idea haha) along with their info dumps :

S5R17 (was 0x7) is now: 0x1 unknown command A h: 308 v:1693 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0602 m:14 ht:1575 vt: 365 hpw: 170 u: 0 s:ff S:13 W:-78 h: 308 v:1693 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0602 m:14 ht:1579 vt: 365 hpw: 170 u: 0 s:ff S:13 W:-78 h: 308 v:1693 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0602 m:14 ht:1575 vt: 365 hpw: 169 u: 0 s:ff S:13 W:-78

S5R17 (was 0x1) is now: 0x2 unknown command A h: 308 v:1693 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0602 m:14 ht:1581 vt: 365 hpw: 171 u: 0 s:ff S:13 W:-79 h: 308 v:1693 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0602 m:14 ht:1578 vt: 365 hpw: 169 u: 0 s:ff S:13 W:-79 h: 308 v:1693 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0602 m:14 ht:1586 vt: 365 hpw: 171 u: 0 s:ff S:13 W:-79

S5R17 (was 0x2) is now: 0x3 unknown command A h: 308 v:1693 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0602 m:14 ht:1575 vt: 365 hpw: 169 u: 0 s:ff S:13 W:-79 h: 308 v:1693 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0602 m:14 ht:1578 vt: 365 hpw: 170 u: 0 s:ff S:13 W:-79 h: 308 v:1693 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0602 m:14 ht:1574 vt: 365 hpw: 169 u: 0 s:ff S:13 W:-79

S5R17 (was 0x3) is now: 0x4 unknown command A h: 308 v:1693 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0602 m:14 ht:1579 vt: 365 hpw: 171 u: 0 s:ff S:13 W:-78 h: 308 v:1693 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0602 m:14 ht:1581 vt: 365 hpw: 170 u: 0 s:ff S:13 W:-78 h: 308 v:1693 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0602 m:14 ht:1578 vt: 365 hpw: 170 u: 0 s:ff S:13 W:-78

S5R17 (was 0x2) is now: 0x5 unknown command A h: 308 v:1693 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0687 m:14 ht:1583 vt: 365 hpw: 170 u: 0 s:ff S:13 W:-79 h: 308 v:1693 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0602 m:14 ht:1582 vt: 365 hpw: 171 u: 0 s:ff S:13 W:-79 h: 308 v:1693 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0602 m:14 ht:1572 vt: 365 hpw: 170 u: 0 s:ff S:13 W:-79

S5R17 (was 0x4) is now: 0x6 unknown command A h: 308 v:1693 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0602 m:14 ht:1585 vt: 365 hpw: 170 u: 0 s:ff S:13 W:-79 h: 308 v:1693 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0602 m:14 ht:1577 vt: 365 hpw: 169 u: 0 s:ff S:13 W:-78 h: 308 v:1693 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0602 m:14 ht:1584 vt: 365 hpw: 170 u: 0 s:ff S:13 W:-78

S5R17 (was 0x6) is now: 0x7 unknown command A h: 308 v:1693 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0602 m:14 ht:1575 vt: 365 hpw: 169 u: 0 s:ff S:13 W:-77 h: 308 v:1693 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0602 m:14 ht:1574 vt: 365 hpw: 170 u: 0 s:ff S:13 W:-77 h: 308 v:1693 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0602 m:14 ht:1575 vt: 365 hpw: 169 u: 0 s:ff S:13 W:-77

[ramapcsx2]

Okay, that doesn't look like it's going to work with current settings. I'll have to simulate the timings and work out something. That'll take a while, but I'm sure it can be done, eventually.

[rasteri]

Awesome - proper EGA support has been one of the historical weaknesses of the GBS and I think it would be a useful feature for a lot of people.

If you need anything from me like oscilloscope or logic analyzer captures or want me to try anything else please let me know.

I'm not familiar with the TV5727 but I'll look through your code and the register documentation and have a play too. Do you have any hunches about what area the problem might be in?

[ramapcsx2]

Well, the thing with PC standards is their wild variation of horizontal and vertical refresh.
The H-PLL and derived ADC sampling clock need to be adjusted dynamically, and those are the foundation of all following stages.

Because we don't have proper documentation (the available docs are minimalistic), it becomes very hard to figure out suitable clocks. For example, what works at 640x200@60 will fail at 640x200@72.
I've come up with some test bus measurements that kind of indicate what to do, but this doesn't work in all cases, this "EGA" being one of them, apparently.

It's great that you want to work on it!
I recommend you take a look at registers 5_12/13 for the H-PLL clock, together with 5_16 for the derived sampling clock for the ADC.
Look at the info mode readouts and watch the "ht:1575" stat.
It should be the same as the (Hex) value set in 5_12/13, and if it's not (as in this case), the H-PLL or ADC are out of their working range.
Once the ADC is stable, the foundation is set and the real work begins ><

[ramapcsx2]

It's a bummer though with these early monitor timings. I've recently added medium resolution support, which is at 24/25kHz, and quite a pain to work with.
Now this timing set is ~22kHz, apparently out of the work window of even such a close standard.

I will start this by extending medium resolution to this 364 vtotal (350 visible, but we only really care about vtotal).
I wonder why this doesn't already work though..

Edit: From your logs, gbscontrol is in the upscaling path, not the special medium res path. The crucial stuff happens here: https://github.com/ramapcsx2/gbs-control/blob/master/gbs-control.ino#L6380

[rasteri]

OK I'll do some debugging and try to figure out why it's not going to the medium res path. If I'm reading the code correctly, "m:" in the debug output should be 8 rather than 14?

[ramapcsx2]

I think so, yeah. Sorry for not giving all the various modes proper names yet :p You'll get to the medium res code path when resetting the ESP8266, and the video mode is recognized initially.
This won't happen though, as the responsible Mode Detect unit only works with CSync, not your separate sync.

So with your RGBHV, you'll get either mode 15 for RGBHV bypass / passthrough, or mode 14 for "generic upscaling path when VSync is present". In the end, all the code bloat around RGBHV comes down to these details piling up.

[rasteri]

If I hack getVideoMode() to ALWAYS return 8, then the video becomes completely stable in the H-axis but rolls vertically :

I noticed this mode calls itself "25khz mixed rgbs" so I generated a composite sync signal using some 74 series logic, and this stablized the V-Axis too! (now detected as "25khz pure rgbs"). I was able to use the picture controls to move it into the correct position :

Although the very left of the picture is cut off and I can't find a way to fix that. Also the picture is pretty unstable, there are wavy lines and it often goes blank. These problems might be because I'm generating a technically non-standard CSYNC signal (I didn't have any XOR gates) :

I'll pick up an XOR gate from work tomorrow and try again with a correct sync signal.

[rasteri]

Here's the startup and print infos output from that last mode, BTW

startup (WiFi): still connecting.. Station disconnected, reason: 8 no ext clockgen

Chip ID: 1A 1 Activity detected, input: RGB 25khz pure rgbs 2345678 Format change: 8 ADC offset: R:40 G:40 B:40 Active FrameTime Lock enabled, disable if display unstable or stays blank! Method: 1 (vtotal only) preset applied: 1280x1024 for Medium Res HTotal Adjust: 7, source Hz: 59.703, output Hz: 59.709 (WiFi): STA mode connected; IP: 192.168.1.80 (WiFi): Access 'http://gbscontrol:80' or 'http://gbscontrol.local' (or device IP) in your browser h: 308 v: 731 PLL:0 A:7b7b7b S:07.10.20 H- I:00 D:0508 m:8 ht:2345 vt: 353 hpw: 251 u: 0 s:ff S:13 W:-81 h: 308 v: 731 PLL:0 A:7b7b7b S:07.10.20 H- I:00 D:0584 m:8 ht:2345 vt: 353 hpw: 252 u: 0 s:ff S:13 W:-81 h: 308 v: 731 PLL:1 A:7b7b7b S:07.10.20 H- I:00 D:0508 m:8 ht:2345 vt: 353 hpw: 252 u: 0 s:ff S:13 W:-81 h: 308 v: 731 PLL:1 A:7b7b7b S:07.10.20 H- I:00 D:0584 m:8 ht:2345 vt: 353 hpw: 252 u: 0 s:ff S:13 W:-81 h: 308 v: 731 PLL:2 A:7b7b7b S:07.10.20 H- I:00 D:0584 m:8 ht:2345 vt: 353 hpw: 250 u: 0 s:ff S:13 W:-81 h: 308 v: 731 PLL:2 A:7b7b7b S:07.10.20 H- I:00 D:0584 m:8 ht:2345 vt: 353 hpw: 252 u: 0 s:ff S:13 W:-81 h: 308 v: 731 PLL:3 A:7b7b7b S:07.10.20 H- I:00 D:0500 m:8 ht:2345 vt: 353 hpw: 252 u: 0 s:ff S:13 W:-81 h: 308 v: 731 PLL:3 A:7b7b7b S:07.10.20 H- I:00 D:0500 m:8 ht:2345 vt: 353 hpw: 252 u: 0 s:ff S:13 W:-81 h: 308 v: 731 PLL:3 A:7b7b7b S:07.10.20 H- I:00 D:0584 m:8 ht:2345 vt: 353 hpw: 252 u: 0 s:ff S:13 W:-81 h: 308 v: 731 PLL:4 A:7b7b7b S:07.10.20 H- I:00 D:0584 m:8 ht:2345 vt: 353 hpw: 252 u: 0 s:ff S:13 W:-81 h: 308 v: 731 PLL:4 A:7b7b7b S:07.10.20 H- I:00 D:0584 m:8 ht:2345 vt: 353 hpw: 252 u: 0 s:ff S:13 W:-81

[ramapcsx2]

Nice work :)
The "PLL:" reading is going up, so the H-PLL is able to lock on to your signal well.
You should disable FrameTime Lock while debugging, as that tends to cause loss of signal.

For image positioning, try modifying the register at segment 1, 0x1a: g1g1a (reads out the current value in Hex)
s1s1asXX (XX a value a bit more or a bit less than your readout)

The CSync signal itself should work, even if the 74 logic places the VSync falling edge together with an HSync falling edge. H-PLL coasting will prevent this eventual glitch there.

I'm nervous about the getVideoMode() hack. Bypassing the chance of it reporting 0 disables a lot of the dynamic adjustments that may be required.
You could change it so that it reads the "vt:" value, and only returns mode 8 if vt is in a range 351 ... 367.
uint16_t lineCount = GBS::STATUS_SYNC_PROC_VTOTAL::read();

[rasteri]

Something like this :

static uint8_t getVideoMode() {
    uint16_t lineCount = GBS::STATUS_SYNC_PROC_VTOTAL::read();
    if (lineCount >= 351 && lineCount <= 367)
        return 8;

... And then the rest of getVideoMode()?

I'll try all of this tonight, thanks for your help, this has been fun so far :)

[ramapcsx2]

Yep, that'll do it :)

[rasteri]

Unfortunately when using composite sync the line count is always zero until you force mode 8, I guess the composite sync detection only happens in mode 8. It manages to detect the linecount when using separate H/V sync but then the screen rolls vertically again.

Doing proper XNOR sync does actually make a difference - now the right side of the picture is missing instead of the left side haha.

Register 1-1A just moves the screen left and right, it doesn't display any missing pixels.

I'll do some more playing with various registers and stuff, I'm sure we can get this working.

[ramapcsx2]

It should work with CSync with the latest update :)

I couldn't reproduce the separate sync (mode 14) issue here, so if you could test that as well, that'd be great!

[rasteri]

I'm testing the new code today.

With csync, the code now correctly detects mode 8! Yay! :

h: 308 v: 365 PLL:7 A:7b7b7b S:07.10.20 H+ I:00 D:0500 m:8 ht:2345 vt: 364 hpw:2092 u: 0 s:ff S:13 W:-77 h: 308 v: 365 PLL:7 A:7b7b7b S:07.10.20 H+ I:00 D:0500 m:8 ht:2345 vt: 364 hpw:2092 u: 0 s:ff S:13 W:-77 h: 308 v: 365 PLL:8 A:7b7b7b S:07.10.20 H+ I:00 D:0500 m:8 ht:2345 vt: 364 hpw:2092 u: 0 s:ff S:13 W:-77 h: 308 v: 365 PLL:8 A:7b7b7b S:07.10.20 H+ I:00 D:0500 m:8 ht:2345 vt: 364 hpw:2092 u: 0 s:ff S:13 W:-77 h: 308 v: 365 PLL:8 A:7b7b7b S:07.10.20 H+ I:00 D:0500 m:8 ht:2345 vt: 364 hpw:2092 u: 0 s:ff S:13 W:-77 h: 308 v: 365 PLL:7 A:7b7b7b S:07.10.20 H+ I:00 D:0500 m:8 ht:2345 vt: 364 hpw:2092 u: 0 s:ff S:13 W:-77

It looks like this when it first powers on :

Then I'm able to use the "Move Picture" controls in the "Picture Control" and "development" menus to get it positioned correctly :

But as you can see I'm still missing the rightmost three columns of text. In fact one column of pixels appears to be smeared across them.

I've tried playing with all the move picture commands, as well as poking the IF_HB_SP2 and IF_HB_ST2 registers directly. Nothing is able to get those extra columns to display.

My csync signal now looks like this, btw :

In separate sync, I'm getting the exact same garbled results as my very first post. This is the output :

h: 308 v: 207 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0702 m:14 ht:2009 vt: 365 hpw: 216 u: 0 s:ff S:13 W:-78 h: 308 v: 207 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0702 m:14 ht:2014 vt: 365 hpw: 217 u: 0 s:ff S:13 W:-78 h: 308 v: 207 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0700 m:14 ht:2013 vt: 365 hpw: 217 u: 0 s:ff S:13 W:-78 h: 308 v: 207 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0702 m:14 ht:2016 vt: 365 hpw: 217 u: 0 s:ff S:13 W:-78 h: 308 v: 207 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0702 m:14 ht:2018 vt: 365 hpw: 217 u: 0 s:ff S:13 W:-78 h: 308 v: 207 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0702 m:14 ht:2019 vt: 365 hpw: 217 u: 0 s:ff S:13 W:-78

[ramapcsx2]

ht:2009, ht:2014, ht:2018 , etc. This is the H-PLL out of range for the charge pumpe current and gain. Try toggling 5_11_5 again, and also combine it with 5_17. If you find something that works, please tell me :)

It seems the base preset I use for medium res is hitting some limits with EGA timings. Some boards fare much better in edge cases, so I suppose mine does it well and yours doesn't. Have you added some SMD caps yet? :)

[rasteri]

Sorry for the lack of updates, I've been out of town. When I get a chance I'll play with the registers you mentioned.

I haven't done any hardware mods, but I'll try that too. Does this page cover the most important ones? : https://github.com/ramapcsx2/gbs-control/wiki/GBS-8200-Variants

[ramapcsx2]

Feel free to browse through the Wiki for inspiration, but this is the one you want :) https://github.com/ramapcsx2/gbs-control/wiki/Power-supply-bypass-capacitors

[rasteri]

Unfortunately even with those capacitors I'm still getting the same result :(

Here are the results before and after enabling the gain bit : h: 308 v: 171 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0602 m:14 ht:1977 vt: 365 hpw: 213 u: 0 s:ff S:13 W:-79 h: 308 v: 171 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0602 m:14 ht:1976 vt: 365 hpw: 213 u: 0 s:ff S:13 W:-79 h: 308 v: 171 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0602 m:14 ht:1978 vt: 365 hpw: 213 u: 0 s:ff S:13 W:-79 h: 308 v: 171 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0602 m:14 ht:1974 vt: 365 hpw: 212 u: 0 s:ff S:13 W:-79 h: 308 v: 171 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0602 m:14 ht:1977 vt: 365 hpw: 213 u: 0 s:ff S:13 W:-79 h: 308 v: 171 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0602 m:14 ht:1978 vt: 365 hpw: 213 u: 0 s:ff S:13 W:-79 h: 308 v: 171 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0687 m:14 ht:1976 vt: 365 hpw: 213 u: 0 s:ff S:13 W:-79 h: 308 v: 171 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0602 m:14 ht:1980 vt: 365 hpw: 213 u: 0 s:ff S:13 W:-79 T5R11 Bit: 5 (was 0xB2) is now: 0x92 h: 308 v: 171 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0602 m:14 ht:1481 vt: 365 hpw: 159 u: 0 s:ff S:13 W:-79 h: 308 v: 171 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0602 m:14 ht:1481 vt: 365 hpw: 159 u: 0 s:ff S:13 W:-79 h: 308 v: 171 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0602 m:14 ht:1484 vt: 365 hpw: 160 u: 0 s:ff S:13 W:-79 h: 308 v: 171 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0602 m:14 ht:1484 vt: 365 hpw: 159 u: 0 s:ff S:13 W:-79 h: 308 v: 171 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0687 m:14 ht:1482 vt: 365 hpw: 160 u: 0 s:ff S:13 W:-80 h: 308 v: 171 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0602 m:14 ht:1482 vt: 365 hpw: 159 u: 0 s:ff S:13 W:-80 h: 308 v: 171 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0602 m:14 ht:1481 vt: 365 hpw: 160 u: 0 s:ff S:13 W:-79

One thing I forgot to mention earlier. When in this mode (seperate sync) my old acer 1280x1020 monitor refuses to display the signal ("Input not support") so I have to plug it into a newer dell 1080p display, which reports it as 1280x1024x50hz. In C-sync mode, it works on both monitors, which report it at 1280x1024x60hz. I don't know if this means anything more than my Acer just not supporting as many modes.

My board calls it'self a V4.0 :

[rasteri]

Oho... I noticed the voltage on my power supply was sagging a little. Using a better one I'm getting a more stable picture with separate sync... more in a second

h: 308 v:1890 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0602 m:14 ht:2341 vt: 365 hpw: 252 u: 0 s:ff S:13 W:-86 h: 308 v:1890 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0602 m:14 ht:2341 vt: 365 hpw: 252 u: 0 s:ff S:13 W:-86 h: 308 v:1890 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0602 m:14 ht:2341 vt: 365 hpw: 251 u: 0 s:ff S:13 W:-86 h: 308 v:1890 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0602 m:14 ht:2341 vt: 365 hpw: 252 u: 0 s:ff S:13 W:-86 h: 308 v:1890 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0602 m:14 ht:2341 vt: 365 hpw: 251 u: 0 s:ff S:13 W:-86

[rasteri]

OK so the combination of additional capacitors and new power supply have made the picture more-or-less stable on separate sync. In this mode I have several columns of text missing on both the left and right sides of the picture, and no amount of playing with the picture controls and IF_HB_SP2/IF_HB_ST2 registers fixes this.

It also stilldoesn't work on my old Acer 1280x1024 monitor. The newer Dell monitor again detects it as 1280x1024@50hz, I guess my Acer doesn't support 50hz. Not a problem though.

Also, running t5t11t5 makes the picture WORSE rather than better as it did in Csync mode. 5_17 has no effect.

This is what it looks like now after bootup :

And here's the log :

startup
(WiFi): STA mode connected; IP: 192.168.1.80
(WiFi): Access 'http://gbscontrol:80' or 'http://gbscontrol.local' (or device IP) in your browser```

no ext clockgen
<reset>
Chip ID: 1A 1
<reset>
Activity detected, input: RGB
VSync: present
HSync: present
RGB/HV 
 RGB/HV upscale mode
59.70
ADC offset: R:40 G:40 B:40

preset applied: 1280x1024 for scaling RGB (HV Sync)
Note: scaling RGB is still in development

(H-PLL) rate: 1365 state (no change): 2
ABHT: large diff
h: 308 v:  87 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0702 m:14 ht:2269 vt: 365 hpw: 244 u:  0 s:ff S:13 W:-77
h: 308 v:  87 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0702 m:14 ht:2268 vt: 365 hpw: 244 u:  0 s:ff S:13 W:-77
h: 308 v:  87 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0712 m:14 ht:2269 vt: 365 hpw: 244 u:  0 s:ff S:13 W:-77
h: 308 v:  87 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0702 m:14 ht:2269 vt: 365 hpw: 244 u:  0 s:ff S:13 W:-77
h: 308 v:  87 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0702 m:14 ht:2269 vt: 365 hpw: 244 u:  0 s:ff S:13 W:-77
h: 308 v:  87 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0702 m:14 ht:2269 vt: 365 hpw: 244 u:  0 s:ff S:13 W:-78
h: 308 v:  87 PLL:0 A:7b7b7b S:02.18.20 H+V- I:00 D:0702 m:14 ht:2269 vt: 365 hpw: 244 u:  0 s:ff S:13 W:-79

With some adjustment I can get it centred but the left and right of the picture is missing :

[ramapcsx2]

Okay, this is a limitation of having to use generic parameters for the RGBHV mode, due to the wide range of timings it can have.

It's really best if you used CSync, because then gbscontrol can get an idea of the timings and optimize the base preset to the task. Even then, the variety is still huge, but any remaining issues can be dealt with.

It's interesting that it (probably?) was the power supply. The chip doesn't require a lot of juice, but the supply has to be clean. I suppose that was the issue then.

[rasteri]

Yeah sorry I didn't try the power supply thing earlier, it's just that the old supply worked in all the other modes I tested including 21KHz Csync...

But yeah I'll stick to Csync for now. Any ideas why the right side of the picture is missing?

[ramapcsx2]

Theory: There are 2 main modules to deal with when taking the raw ADC sampled scanlines and scale them to the output DAC for display.

The sampled data needs to be formatted so that the chip can work with it (Input Formatter module, register segment 1).
The VDS module (Video Display or some such, register segment 3) takes in that data and scales / positions it for output. VDS also clocks that final image out to the DAC.

This staged design is very flexible, but there are countless limitations to consider, mainly the length of singe line buffers (FIFOs).

To maximize image quality, we want lots of visible pixel data, so the FIFOs are fully utilized.
I do this by choosing clocks and scaling parameters that are good for the expected video mode. This base set can be extended a bit, in case the timings are slightly different.

Now to the problems of cut-off or wrong colored sides:
Here one of the FIFOs ran out of space for the scaling / positioning requested.
The source uses timings that are too far off from the expected ones. The fix would be to figure out which FIFO overflows, and then correct it by either changing scaling parameters, or by repositioning the start/end positions of that FIFO, relative to its particular source canvas (there are many).
This is not something I would expect users to do. It requires me doing it.

In praxis: So you see, I can't give you an answer on how to fix the problem, only some suggestions.
You need to start by not changing the scaling too much (not at all, if possible).
You can move the picture you get around, using the available methods.
Once (if) everything is visible, you can use your monitor's auto adjust to center the display for you.

[rasteri]

Yeah no combination of resizing/scaling/etc can make the whole picture appear.

I will try and understand the FIFO stuff by looking at your code.

If you want me to do any more tests let me know :)

[ramapcsx2]

Hmm, there's little code that directly deals with the FIFOs. They're just inherent restrictions, hard to explain :p You see it here (though commented out): https://github.com/ramapcsx2/gbs-control/blob/master/gbs-control.ino#L3481 This would move the input formatter "hblank" position, which basically means where in the canvas the FIFO should start. This tries to skip all the source black pixels that are in a scanline (source sync pulse and hblank).

Scaling in the IF stage is done by the chosen ADC pixel clock and a simple x2/x4 divider.

Your glitch looks like a VDS issue though, and that's done with the VDS "hblank (memory)" controls. You get access to those in the web ui Development tab.

[Dethernal]

I have same problem. small part of image on the left are captured and then discarded, but main problem that part of image on the right not captured at all. No combination of scaling and moving cannot get more fragments of image on the right. Right now I don't understand what to do and what I can mess with. I have logic analyzer and oscilloscope so I can check something if it's needed so.

[fandjelo]

Hi guys, I'm currently playing with this as well. Thank you rama for the software, thank you rasteri for the great youtube video. I made a custom adapter, similar to the one rasteri made in his video. In theory it supports CGA, EGA and MDA, however, there seem to be an issue with H-Sync as well. I would like to play around with this. Did you guys already commit the code into the main repo? Or is is floating around somewhere on your machines? With current master I get CGA and EGA @15kHz working, but MDA/Hercules @ 18kHz does not, as well as EGA in hires @ 21kHz is total sync garbage....