search

ramapcsx2 / gbs-control

GNU General Public License v3.0
805 stars 113 forks source link

Atari "ST High" video mode unstable #190

Open beel1 opened 3 years ago

beel1 commented 3 years ago

Hello and thanks for the awesome work put into this project!

I've been using GBS-Control with great results for "ST Low" and "ST Medium" video signals (320x200 and 640x200 50Hz color modes) and wanted to go a little bit further with the monochrome ("High") mode, which is 640x400 71.5Hz / 35.8kHz, composite sync (I could use separate sync but I prefer using composite as it is transistor-protected. For now I routed the monochrome output of the Atari to the RGB inputs of the GBS but I'm planning to use the Y input once the sync problem sorted). I was hoping to use bypass mode, as these timings are supported by my VGA monitor, but didn't manage to make it work through my GBS8200.

So I'm trying the 1280x1024 preset which runs fine... only for a couple of seconds unfortunately, see this video I made by resetting GBS-Control twice: https://imgur.com/a/VoNbxKy The debug pin is wired, I tried syncwatcher off, force PAL 60Hz and several options with no luck, it ends up with this kind of message: no signal h: 188 v:1001 PLL:0 A:7b7b7b S:07.10.00 H- I:00 D:05e4 m:0 ht: 0 vt: 0 hpw: 0 u: 96 s: 0 S: 6 W:-82 or: ABHT: large diff retry ... ABHT: large diff give up

Is there any option I am missing to make it stable? Or maybe it needs registers and/or software tuning? Feel free to ask me for additional measurements/debug output from the serial terminal if it can help. Thanks in advance!

ramapcsx2 commented 3 years ago

It is trying to measure the sync times, sometimes getting them, most of the time not. The timings are too far out of some expected window.

claunia commented 3 years ago

@beel1 can you share the schematics of the cable lead, if you know it?

And fill the missing data on the table I've put on https://github.com/ramapcsx2/gbs-control/wiki/Tested-video-modes ?

Thanks

troed commented 3 years ago

I'm seeing this as well. I use an Ube VGA-connector (basically just routes the mono output signal to the RGB leads) which works great in the STs 15.7kHz 50/60Hz mode but not the high res mode mentioned above. I'm using the GSB Control to end up with HDMI which means I would need the conversion since pass-through isn't understood by the screen.

Is this a case of just matching some values or would these "high" frequencies themselves pose any issues? Where in the code can I start looking?

lovrenco commented 2 years ago

@beel1 Please can you share RGB cable scheme that you used to connect to GBS? I tried yesterday and picture was very blurry.

krupkaj commented 1 year ago

I tried it today and with the same result. Color modes are really great. But mono even in the pass through mode does not work. Which I believed it should, because the monitor displays nice picture when connected directly to the ST in highres mode.

The schema is simple. Monochrome out signal from the ST goes to all 3 RGB inputs and both sync signals are connected to the appropriate inputs.

I have the latest version from git installed in the ESP. And have the external clock installed.

If you need some other info let me know please.

mzryz commented 1 year ago

I know it's been a few years since this post was made, but I have exactly the same issue with my gbs-control and Atari in high res/mono. It seems the author provided all the information required. I hope some kind person might have a look at this for us? Thank you.

nyanpasu64 commented 1 year ago

It would take someone with an Atari ST for testing (I don't have one), and an interest in making it work. If you want it fixed, you could try debugging the code (though I'm not sure I can help as I don't understand the sync code all that well either).

krupkaj commented 1 year ago

I can help with testing. But I am afraid about the debuging the code as I do not understand it either.Jan25. 5. 2023 v 6:20, kitten @.***>: It would take someone with an Atari ST for testing (I don't have one), and an interest in making it work. If you want it fixed, you could try debugging the code (though I'm not sure I can help as I don't understand the sync code all that well either).

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

mzryz commented 1 year ago

Is there not anyone here who understands sync code? Is @ramapcsx2 not here anymore? :(

ramapcsx2 commented 1 year ago

Hey, I'd just like to apologize, but I honestly don't have the time to try and riddle these GBSC problems with you guys. They are pretty difficult support questions, which I struggle with anyway, as a proper reply requires pulling up documents from somewhere, and then explaining in great detail what all the possible debug options are. Every person has a slightly different request, and different possibilities to address the problem.. basically, it would be amazing if others can step in and help. And they do! Please don't call for me right away, as chances are, I'm already busy on 3 others things here.. I hope you understand :)

mzryz commented 1 year ago

No problems I understand :)

ramapcsx2 commented 1 year ago

It would take someone with an Atari ST for testing (I don't have one), and an interest in making it work. If you want it fixed, you could try debugging the code (though I'm not sure I can help as I don't understand the sync code all that well either).

I agree here. It needs a coder (able to modify and debug the code, test the results) with this machine, so they can attempt any fixes on maybe the sync processor window parameters or so.

nyanpasu64 commented 1 year ago

One idea is a person with an Atari ST taking a trace of 1 or more signal frames, using a high-speed ADC card like the cheap (single-channel) https://github.com/happycube/cxadc-linux3, then sending the trace to someone who can study the signal trace, and/or feed it to a high-speed DAC (like https://osmocom.org/projects/osmo-fl2k/wiki) and send the signal into the GBS-C and try making it work. However I don't think it's practical to try making the ST work without the actual hardware, because that the CXADC probably cannot return absolute voltage levels to the PC, because the input is AC-coupled, and because I don't know the ADC's exact capture gain at various configuration levels. And perhaps the FL2000 can't output negative sync voltages through the VGA color pins, which are present in composite sync.

I actually have ordered a CXADC capture card, though it will take weeks to arrive. I have not ordered a FL2000 DAC since so far I haven't had a need to generate signals beyond what my GPUs and consoles can output, and I'm not sure how easy the DAC drivers/software are to setup.

beel1 commented 11 months ago

Hello, Based on @planeturban's work I've just released an arduino uno sketch to generate several Atari video signals here: https://github.com/beel1/15khzvgatester/tree/master/src/VGA_output_multi According to measures I made on my PAL STE, it can outputs timings similar to ST High, ST Low 60Hz and ST Low 50Hz (and VGA 60Hz as a test pattern). The software can be modified to add other video modes too. Hope this will help.

ramapcsx2 commented 11 months ago

Nice work @beel1! Video signals often have weird little details to them, which are hard to research for a project like yours. There can be oddly spaced CSync pulses in the VSync area, or short first/last lines like on the NES. These details are often what trips up the sync processor in the GBS. I suppose it's always best to have the original :p