scandoubling - theory

[whitebird]

Tearing is a consequence of the 50Hz to 60Hz frame rate conversion like the telecine method where additional frames are created to match the input 50Hz rate to the output 60Hz. Perhaps simply duplicating frames may avoid the tearing but don't know which visual consequences it would have.

There may be good reasons why it was not implemented in the Indivision AGA...

The problem of solution 1 is that it requires 2 times the memory of solution 2.

Additionally, Solution 1 will delay video from sound of 1/25 s in laced mode. Don't know if it can be noticed by humans.

I will try to implement solution 1 to see how it performs...

[robinsonb5]

Originally Posted by whitebird

I will try to implement solution 1 to see how it performs...

Solution 1 will still create combing. Even if it takes 1/25 of a second to output a full interlaced frame, the display is not guaranteed to be static for that 1/25th of a second - objects such as the mouse pointer can move between the two fields, so any solution which mixes lines from alternate fields to make a single progressive VGA field will produce combing.

[whitebird]

the display is not guaranteed to be static for that 1/25th of a second - objects such as the mouse pointer can move between the two fields

Even if the two fields belong to the same full interlaced frame?

So why don't we see combing on the original amiga laced picture?

Mixing alternate fields is exactly what interlaced video does. So combing would be seen also on the RGB or PAL ourput.

And that would mean Amiga updates objects at 50fps regardless of the laced/non-laced mode...

[robinsonb5]

Originally Posted by whitebird

Even if the two fields belong to the same full interlaced frame?

Yes, indeed. The mouse pointer is updated with the VBLANK which (for PAL) is 50Hz regardless of the interlace setting.

So why don't we see combing on the original amiga laced picture?

Because the two fields are displayed 1/50th of a second apart, whereas a flicker fixer shows them simultaneously.

And that would mean Amiga updates objects at 50fps regardless of the laced/non-laced mode...

It does, at least in the case of the mouse pointer. There are 50 fields per second, and there's *very* little difference, as far as the Amiga hardware's concerned, between laced and non-laced modes. All the interlaced modes do differently is alternate between two different sync patterns to let the TV/Monitor know whether the current field is even or odd, whereas non-laced modes always emit even (or maybe it's odd?) fields. Software-wise nothing changes with regard to how often the screen can be updated.

[demolition]

The only way to get 50 fps without combing effects is to apply some smoothing around the area where things are moving fast (like the mouse cursor). This is how many deinterlacing algorithms work. It is not a very good solution (also it needs some DSP), but there is no perfect solution when it comes to deinterlacing a signal like this. Either you will lose fps (mix fields), lose resolution (show fields on top of each other, so 1/2 as many lines), get flicker (show every 2nd line as black, alternating) or get combing effects if you show two fields at the same time.

[whitebird]

Yes, indeed. The mouse pointer is updated with the VBLANK which (for PAL) is 50Hz regardless of the interlace setting.

OK, OK...

Because the two fields are displayed 1/50th of a second apart, whereas a flicker fixer shows them simultaneously.

Yes it is same as with TV broadcasting we never see combing on TV because the time difference between two adjacent lines is /50th of a second and phosphore has time to decay, when on progressive display, time between lines is only 32µs...

According to your answer, solution 1 has no advantages over solution 2.

[demolition]

Originally Posted by whitebird

Yes it is same as with TV broadcasting we never see combing on TV because the time difference between two adjacent lines is /50th of a second and phosphore has time to decay, when on progressive display, time between lines is only 32µs...

You could still eliminate combing when showing the screen on a progressive display at full fps, but you need to show the fields at the correct times. This would generate flickering, but perhaps some artificial afterglow could be a decent compromise between flickering and deinterlacing artifacts. This afterglow could be 50% intensity on the next output frame.

Like this:
0 sec: Frame 1, even field 100%
0.02 sec: Frame 1, even field 50%, Frame 1, odd field 100%
0.04 sec: Frame 2, even field 100%, Frame 1, odd field 50%
0.06 sec: Frame 2, even field 50%, Frame 2, odd field 100%
0.08 sec: Frame 3, even field 100%, Frame 2, odd field 50%
0.10 sec: Frame 3, even field 50%, Frame 3, odd field 100%
etc..

[whitebird]

Your solution is interesting and may be easily implemented on analog VGA output where intensity can be adjusted with R, G, B gain for example. But when outputing digitally like DVI, it's more difficult because the color code have to be alterated in realtime to half them when intensity has to be made 50%.

[demolition]

If you have the digital video data on a parallel connection somewhere, you can simply use a mux to switch the bits between two positions, so bit 1->0, bit 2->1 etc. every second frame. On a serial connection, you need to introduce one sample delay (and discard LSB).

[whitebird]

This seems to be good solution to me and easy to implement. Thanks.

[Marmes]

I know this is a bit old, but I have one question.
How is detected the interlaced mode from the non interlaced mode on A2320 scandoubler?
I am trying to reproduce the Multivision, and from what I see, there is detection from 2 modes.
Here is the link for sch. http://eab.abime.net/showthread.php?t=79278
Thanks!

[Jope]

Amiga progressive modes always output only even frames.. If the flifi never sees an odd frame, then it is safe to assume we're not in an interlaced mode.

[Toni Wilen]

Both odd or even only non-interlaced mode is possible. (It is simply state of LOF bit in VPOSW)

[Marmes]

Then what about making an open code for the multivision first, and then evolve to a more sofisticated hardware?
I can start making in wincupl, but my knowledge in image processing is not that good.
From What I see on sch there are 10bits on the input of the 2 gals from 74f163.
Making a freq divider up to 1024 times. It's dividing the 14mhz clock.
we have hsync and vsync inputs also.
We know that hsync needs to be doubled at some point and also needed to clock some of the memory .
If I make code, does anyone is willing to contribute?
I will after make a simpler design and also share as I did with this one.
I would like to keep this one, so I can make tests, since I already have a multivision with me.

[Jope]

Originally Posted by Toni Wilen

Both odd or even only non-interlaced mode is possible. (It is simply state of LOF bit in VPOSW)

Ah, good to know. Have you checked what happens to scandoublers when you output only odd fields?

[Marmes]

So if there is even & odd we need to deinterlace?

[pandy71]

Luckily most of Amiga interlace application are not interlace at all - this is progressive video displayed in two passes. I can imagine video applications (subtitlers etc) where real interlace signal is produced but once again this is not problems as they are not designed for progressive display anyway and comb artifacts from interlace on progressive can be accepted (IMHO).
There are good application notes about various approaches for interlace to progressive conversion but this is usually not required for Amiga.
http://www.nxp.com/documents/applica.../AN10233_1.pdf
or Micronas VSP9407b datasheet

[whitebird]

I am wondering how the indivision flicker fixers retrieve sync information as they don't get HSYNC and VSYNC from Alice... There is also a CSYNC signal but not available on Lisa.

[Toni Wilen]

Originally Posted by whitebird

I am wondering how the indivision flicker fixers retrieve sync information as they don't get HSYNC and VSYNC from Alice... There is also a CSYNC signal but not available on Lisa.

It snoops sync strobe custom "registers", available via RGA bus.

[whitebird]

Thanks. I guess they are the STREQU/STRVBL/STRHOR/STRLONG addresses?