[david.given]

No luck, I’m afraid. https://i.imgur.com/7JnQtj5.jpeg I’d expect to see the aliasing artifacts in the ampersands get further apart as the pixel clock approaches the correct value, but they look about the same. The good news is that the video does seem more stable and centered, but I also inverted the sync signals so that may have helped too.

I looked at the PCB and found the crystal next to the video controller. It claims to be 15.33 MX. Does that help? https://i.imgur.com/VYLqtji.jpg

[david.given]

Ah, didn’t see your edit. I did try the low 900s but testing ranges of numbers is very slow (due to a combination of winding the value up and down — the remote control has a number pad on it, wouldn’t it be great if we could use it for entering numbers — and waiting for my monitor to decide to resync). I did find a clock input to the 6544 video controller but I forget the right number, and was down in the single-digit MHz anyway, so it’s obviously being used to generate the pixel clock internally. 16MHz does sound plausible.

Regarding the vsync length issue: I found this in the source code:

define VSYNC_LEADING_EDGE ((VSYNC_in_L ==HI) & (VSYNC_in ==`LO))

This suggests that the OSSC only supports negative sync polarity as it’s looking for trailing edges. That surprises me. I’m aware that what I’m doing is a bit weird, but surely there are other positive sync devices out there? (It’s also possible that if OSSC is trying to lock onto the trailing edge of hsync pulses it’s making it unhappy about detecting pixels. I’ll try inverting both syncs and seeing what happens.)

[david.given]

Yes. Yes it does. Syncing the hsync with the vsync produces a much more stable output. Again, it’s not right. The best I came up with was this: https://imgur.com/a/Asfinbp But my monitor is still very unhappy, showing an image offset a long way to one side, and the pixels aren’t being sampled properly.

I don’t know the pixel clock for this thing but each scanline is 91×8 = 728 pixels. So… about 740 samples per line, adding padding for front porch and back porch? I’ve tried it, and it’s no better.

Also, and this is a minor issue because I can easily fix it in post, but is there a way to change the aspect ratio? This thing has a 25:10 monitor…

[david.given]

Yes, that is indeed the case. Shortening the vsync pulses cause the OSSC to lock on (16.26kHz, 62.55Hz). However my monitor won’t display it, not even producing a bad-mode error, just failing to detect anything at all. My HDMI capture device is more tolerant, but it’s still very much not right: https://imgur.com/a/xvIb9an

Is hsync required to be aligned with vsync at all? I notice on the scope that hsync is drifting with respect to vsync.

[david.given]

I finally got around to pulling out an old Toshiba laptop with CGA output to test against. It works fine, at 15.69kHz and 69.91Hz. Looking at the output signal through the scope produces this: https://imgur.com/a/LFWUP7o

Comparing with the WP-1’s output, the vsync pulse is much shorter, only four scanlines (191us) in contrast to the WP-1’s 15 (921us). Everything else looks pretty much the same. I think I have the equipment (a PSoC dev board) to reduce the pulse width, so I’ll give it a try, but surely the OSSC only really cares about leading/trailing edges, depending on the sync polarity?

…although I haven’t found any sync polarity setting in the OSSC menus, so maybe it’s trying to autodetect and the very long pulse means it can’t decide whether it’s positive or negative polarity?

[david.given]

I’ve just found a reference that the OSSC does not change the refresh rate, which is obvious in hindsight given the way the OSSC works; as my device uses a refresh rate of 62.5Hz, this most likely will prevent my modern LCD from displaying the resulting DVI output. Could this also be causing the OSSC to fail to sync? Does it have a set of supported refresh rates, and if so, what are they?

[david.given]

I try that, but no luck. In fact, I’ve tried fiddling with all the numbers and nothing ever seems to happen. Silly question: the settings update live as I adjust them, right? There isn’t a commit button hidden somewhere where I haven’t found it?

Is there any way to get any diagnostics as to what the OSSC is actually doing? I have a decent set of test equipment, including a scope.

Speaking of which, here’s a snapshot of the sync pulses as produced by the cga2rgb. There doesn’t seem to be a lot of jitter. Is there anything here that the OSSC might be unhappy about? https://imgur.com/a/RIPcMeU

[Author]

Posts