Median filtering in 1D also did not work well. Well, I will let this rest for a while and instead solder a DB9 to SCART adapter so I can use the EGA with the OSSC and my old Profex CRT. 😉

the OSSC has a DE-15 input that supports RGBHV and RGBS - why use trash like SCART?

maxtherabbit wrote on 2020-07-18, 16:52:

the OSSC has a DE-15 input that supports RGBHV and RGBS - why use trash like SCART?

Oh, yeah, I forgot. Didn’t think I could use that. Well then I’ll just order a DB9-DB15 adapter. But still I will solder a cable for my Profex monitor. That one only has RGB SCART, not even composite. But should be nice for all 200 line modes.

Be careful - a passive adapter from TTL RGB on DE-9 (EGA) to VGA or SCART will destroy the sink device. You must built in a RGB DAC to convert the TTL 5Vpp RGB to 700mVpp analog RGB

The OSSC will be a paperweight if you plug EGA straight into any of its inputs with a direct adapter

maxtherabbit wrote on 2020-07-18, 18:32:

Be careful - a passive adapter from TTL RGB on DE-9 (EGA) to VGA or SCART will destroy the sink device. You must built in a RGB DAC to convert the TTL 5Vpp RGB to 700mVpp analog RGB

The OSSC will be a paperweight if you plug EGA straight into any of its inputs with a direct adapter

Aha. So it's not that easy after all. Well, then I'll continue with my SCART adapter. I have schematics for that, just waiting for a BS107 MOSFET for the composite sync. With that adapter I can use both the CRT and the OSSC. And since both are RGB, quality should be ok.

maxtherabbit wrote on 2020-07-18, 16:52:

the OSSC has a DE-15 input that supports RGBHV and RGBS - why use trash like SCART?

Because virtually every TV set built between the late 1980s and the early 2010s has it?
(from our European perspective)
It is by far the easiest way to feed a 15kHz RGB signal into a TV set.

root42 wrote on 2020-07-18, 19:08:

maxtherabbit wrote on 2020-07-18, 18:32:

Be careful - a passive adapter from TTL RGB on DE-9 (EGA) to VGA or SCART will destroy the sink device. You must built in a RGB DAC to convert the TTL 5Vpp RGB to 700mVpp analog RGB

The OSSC will be a paperweight if you plug EGA straight into any of its inputs with a direct adapter

Aha. So it's not that easy after all. Well, then I'll continue with my SCART adapter. I have schematics for that, just waiting for a BS107 MOSFET for the composite sync. With that adapter I can use both the CRT and the OSSC. And since both are RGB, quality should be ok.

But it is almost that easy. You need a couple of resistors, that's it. It is still a passive adapter.

Back to the original topic:
I believe that you can technically derive the phase offset for every line from the pattern of preceding "long" and "short" lines, where the difference between "long" and "short" is exactly one pixel.
This approach would rely on pre-computed data, but it would be much simpler (read: less complex) than repeated cross-correlation of a synthetic sync-frame with a sliding window of the input signal.

There plenty of solutions just google C128 DAC / RGBi

https://sites.google.com/site/h2obsession/CBM … 28/rgbi-s-video

Benedikt wrote on 2020-07-18, 19:28:

But it is almost that easy. You need a couple of resistors, that's it. It is still a passive adapter.

Ya passive was the wrong word, meant to go back and edit it out. Pin to pin is what I meant

The fantastic news is that the code from root42 (yesterdays revision...) is running real-time at 16 MHz sample frequency.!

Therefore this already works for MDA and Hercules which uses 16 MHz.

Only very slight changes needed:
- vsync is reversed
- the "color" is on bit 3 of color1 (color1 = value & 0x20;). Then draw with another color (if(color1==32){color1=39;})
- vsyncc is not required (if( vsyncc > 1 ) { vsyncc = 0;)
- draw every pixel
- change frame size to see everything

Sample file shows a static picture to demonstrate the image quality (its like the screenshots I posted before) and the very slight jitter.

No lag at all, I can play Xenon 2 without problem.

Predator99 wrote on 2020-07-18, 21:01:

The fantastic news is that the code from root42 (yesterdays revision...) is running real-time at 16 MHz sample frequency.!

Therefore this already works for MDA and Hercules which uses 16 MHz.

That makes me confident that it will be fast enough for 24MHz with a few additional optimizations.
Since MDA and many Hercules clones use 16.257MHz, you'd technically need the full 24MHz for that, as well.

Thats the surprise. I tested 2 different HGC cards with a 16.00MHz OSC on it. But there are some jitters anyway. They are not static but appear on a different line on each frame. This shouldnt be.

Another idea for image correction at higher resolutions (dont know how it will look like): Combine the data of 2 frames. This will double the available data per pixel and reduce the refresh rate to 30 Hz which is still fluent. Dont think any program utilizes the full 60 Hz...

Predator99 wrote on 2020-07-18, 21:55:

Another idea for image correction at higher resolutions (dont know how it will look like): Combine the data of 2 frames. This will double the available data per pixel and reduce the refresh rate to 30 Hz which is still fluent. Dont think any program utilizes the full 60 Hz...

This will produce ghosting artifacts when screen transitions or animations happen. Even at lower FPS there will be some animations that fall on two frames that get averaged.
The question still is: are there all relevant samples in the source stream so we can reconstruct a whole line and/or is there a pattern to the jitter?

Predator99 wrote on 2020-07-18, 21:36:

Thats the surprise. I tested 2 different HGC cards with a 16.00MHz OSC on it. But there are some jitters anyway. They are not static but appear on a different line on each frame. This shouldnt be.

I wouldn't necessarily call that a surprise, but rather the expected behavior.
In the end of the day, we still don't have any phase information and might therefore be sampling in the middle of every pixel, at the edge of every pixel or even always right between pixels.
And since neither 16MHz clock source is going to be 100% accurate, the sampling position is likely going to drift between the aforementioned cases over time.
Sampling the signal at 24MHz should theoretically allow us to extract all the relevant information, as long as the pixel clock and the shape of the sync-frame are known, but it's not going to be easy.
You'd need at least 32MHz for a simple solution.

root42 wrote on 2020-07-19, 06:48:

This will produce ghosting artifacts when screen transitions or animations happen. Even at lower FPS there will be some animations that fall on two frames that get averaged.

Yes, thats true. But we are talking about 640x350 resolution? There are not many games using this. And the ones that dont have fast animations. For e.g. Sim City I dont think it will matter. We need it mostly for DOS or Windows, there it shouldnt matter at all.

root42 wrote on 2020-07-19, 06:48:

The question still is: are there all relevant samples in the source stream so we can reconstruct a whole line and/or is there a pattern to the jitter?

Yes I think for 640x350 all data is there. I can provide a capture with some test pictures later.
Yes, there is a pattern in the jitter. You can see it very well in above HGC screenshot and capture. But I didnt get a system behind it so far.

Anyway, the 1st priority should be to get 24 MHZ running at realtime. I this does not work we can forget all this. I may also be willing to get a faster CPU. But I do not prefer this. Didnt pay anything for my current system, everything inside is collected from cheap scrap lots 😁 Yes, you can find a i7-4790 including board in a scrap lot - crazy!

640x350 Test data. System bootup and dispaly of some test patterns, the last one shows lines 1 black, 1 white, 1 black, etc

And next part

Interesting results. I'll watch this thread. Good work.

I just had another idea, namely for a hardware-assisted solution.
If we add an oscillator matching the pixel clock, an edge-triggered flip-flop and an xor-gate, we could invert the polarity of the sampling clock depending on whether the oscillator output is high or low during the rising edge of the hsync pulse.
This should ensure that we always sample the pixels and not the transition between pixels.
The software part would become trivial.
You'd obviously need a logic analyzer of the kind that has an external clock input or add it as a modification.

Some more test files for 640x200 resolution which is used i.e. by Monkey Island 2. The 2nd file shows a test pattern blue-white-blue-...