Trying to make OSSC work with MDA-ish video — won’t sync?

[david.given]

I have an exotic machine (a Brother WP-1 word processor) which I’m trying to make work with OSSC.

It’s got a built-in monitor with its own internal three-wire video feed. This seems to be TTL-level video, hsync and vsync, all active high. Horizontal frequency is ~16kHz and vertical frequency is ~62.5Hz. The electrical interface seems to be MDA-ish, so I have it plumbed through a CGA2RGB gglabs adapter. I’ve verified that this is producing plausible-looking VGA output. The CRT is weirdly letterbox, at nearly 2:1 ratio, so it only shows 80×15 text, but I think there’s ~200ish scanlines (I haven’t counted).

However, when I plug this into the OSSC, the OSSC behaves rather oddly. For about a second after switching to the AV3-RGBHV mode I see frequency information; this is wrong, showing 16kHz 68Hz. Then it goes away, just displaying NO SYNC, and the HDMI output turns off. The only way to make it show the frequencies again is to power cycle the OSSC.

The fact that it’s getting the refresh rate wrong makes me think that it’s not detecting the vertical sync pulses correctly. But why? I can’t find any information about whether it’s expecting positive or negative sync — does it care? I’ve tried using a NOT gate to flip them both, to no avail. The voltages look right (0V and 5V). Does it care particularly about the length of the pulses? I’m seeing 940us for vsync and 8us for hsync. Is it expecting any particular front porch / back porch pulses in the data itself? That seems unlikely…

Can anyone suggest anything?

I’m using firmware 0.90a, and I’m reasonably confident that my OSSC works, as I also use it with an Amiga using the same AV3 port.

**Edit:** for entertainment value, here’s a picture of the machine in question: https://photos.app.goo.gl/956SJ8th4jB8jvhHA

[BuckoA51]

Have you tried increasing Hsync tolerance slightly? Also H-PLL Pre-Coast set those higher first then gradually increase it see if that helps?

[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

[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?

[BuckoA51]

OSSC can support 62.5Hz input just fine, as you rightly say it’s down to the target display to then support the resulting digitized signal. Actually since older DOS modes went to 70hz I would have thought DVI displays could handle this, though it will vary of course.

Regards interpreting your scope results that’s beyond my technical ability so if someone else more experienced doesn’t weigh in then I’ll give Markus a nudge ask him to take a look at this.

[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]

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]

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…

[Zacabeb]

A quick estimation of how many cycles are missing given how the undersampling affects the ampersands in the clip makes me think that H.samplerate needs to be somewhere around 900. I could be wrong though.

Edit: Doing another pixel count it seems there are 3 samples for every 4 pixels, which would put the correct H.samplerate at 984, which given the horizontal frequency of ≈16.26 kHz results in a neat pixel clock of 16 MHz. Give it a try!

Given the above assumption, the duration of a line is 61.5 μs. With a sync pulse 8 μs long and 984 samples per line, H.synclen should be set to 128. H.backporch and H.active can then be adjusted to hopefully center the image and give it as much underscan as desired.

Since there are 91 columns, I guess an active picture of 91 plus 2 columns for underscan would work well, so try setting H.active to 744 after adjusting H.samplerate.

[Zacabeb]

Any success in getting the video from the WP-1 working? I’m curious if the timings I suggested work. 🙂

[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]

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

[Author]

Posts