VOGONS


Reply 140 of 211, by root42

User metadata
Rank l33t
Rank
l33t

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. 😉

YouTube and Bonus
80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, SnarkBarker & GUSar Lite, PC MIDI Card+X2+SC55+MT32, OSSC

Reply 142 of 211, by root42

User metadata
Rank l33t
Rank
l33t
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.

YouTube and Bonus
80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, SnarkBarker & GUSar Lite, PC MIDI Card+X2+SC55+MT32, OSSC

Reply 143 of 211, by maxtherabbit

User metadata
Rank l33t
Rank
l33t

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

Reply 144 of 211, by root42

User metadata
Rank l33t
Rank
l33t
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.

YouTube and Bonus
80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, SnarkBarker & GUSar Lite, PC MIDI Card+X2+SC55+MT32, OSSC

Reply 145 of 211, by Benedikt

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 146 of 211, by matze79

User metadata
Rank l33t
Rank
l33t

There plenty of solutions just google C128 DAC / RGBi

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

https://dosreloaded.de - The German Retro DOS PC Community
https://www.retroianer.de - under constructing since ever

Co2 - for a endless Summer

Reply 147 of 211, by maxtherabbit

User metadata
Rank l33t
Rank
l33t
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

Reply 148 of 211, by Predator99

User metadata
Rank Oldbie
Rank
Oldbie

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.

hgc-edit.jpg
Filename
hgc-edit.jpg
File size
58.13 KiB
Views
662 views
File license
Fair use/fair dealing exception
Filename
HGC-edit-60s-16MHz.part001.rar
File size
4.5 MiB
Downloads
27 downloads
File license
Fair use/fair dealing exception
Filename
HGC-edit-60s-16MHz.part002.rar
File size
1.57 MiB
Downloads
26 downloads
File license
Fair use/fair dealing exception

Reply 149 of 211, by Benedikt

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 150 of 211, by Predator99

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 151 of 211, by Predator99

User metadata
Rank Oldbie
Rank
Oldbie

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...

Reply 152 of 211, by root42

User metadata
Rank l33t
Rank
l33t
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?

YouTube and Bonus
80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, SnarkBarker & GUSar Lite, PC MIDI Card+X2+SC55+MT32, OSSC

Reply 153 of 211, by Benedikt

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 154 of 211, by Predator99

User metadata
Rank Oldbie
Rank
Oldbie
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!

Reply 155 of 211, by Predator99

User metadata
Rank Oldbie
Rank
Oldbie

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

6401.jpg
Filename
6401.jpg
File size
57.31 KiB
Views
595 views
File license
Fair use/fair dealing exception
6402.jpg
Filename
6402.jpg
File size
240.62 KiB
Views
595 views
File license
Fair use/fair dealing exception
Filename
EGA640x350.part001.rar
File size
4.5 MiB
Downloads
25 downloads
File license
Fair use/fair dealing exception
Filename
EGA640x350.part002.rar
File size
4.5 MiB
Downloads
30 downloads
File license
Fair use/fair dealing exception
Filename
EGA640x350.part003.rar
File size
4.5 MiB
Downloads
25 downloads
File license
Fair use/fair dealing exception

Reply 156 of 211, by Predator99

User metadata
Rank Oldbie
Rank
Oldbie

And next part

Filename
EGA640x350.part004.rar
File size
4.5 MiB
Downloads
26 downloads
File license
Fair use/fair dealing exception
Filename
EGA640x350.part005.rar
File size
4.5 MiB
Downloads
25 downloads
File license
Fair use/fair dealing exception
Filename
EGA640x350.part006.rar
File size
4.5 MiB
Downloads
27 downloads
File license
Fair use/fair dealing exception
Filename
EGA640x350.part007.rar
File size
271.87 KiB
Downloads
26 downloads
File license
Fair use/fair dealing exception

Reply 157 of 211, by dogchainx

User metadata
Rank Member
Rank
Member

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

386DX-40MHz-8MB-540MB+428MB+Speedstar64@2MB+SoundBlaster Pro+MT-32/MKII
486DX2-66Mhz-16MB-4.3GB+SpeedStar64 VLB DRAM 2MB+AWE32/SB16+SCB-55
MY BLOG RETRO PC BLOG: https://bitbyted.wordpress.com/

Reply 158 of 211, by Benedikt

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 159 of 211, by Predator99

User metadata
Rank Oldbie
Rank
Oldbie

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-...

Attachments

  • Filename
    640x200.part003.rar
    File size
    4.83 MiB
    Downloads
    24 downloads
    File license
    Fair use/fair dealing exception
  • Filename
    640x200.part001.rar
    File size
    4.83 MiB
    Downloads
    24 downloads
    File license
    Fair use/fair dealing exception
  • Filename
    640x200.part002.rar
    File size
    4.83 MiB
    Downloads
    27 downloads
    File license
    Fair use/fair dealing exception
  • Filename
    640x200.part004.rar
    File size
    232.45 KiB
    Downloads
    23 downloads
    File license
    Fair use/fair dealing exception