Interlace problem.

[obiwanken]

Hi, Im playnig with interlace screen.

My code Works perfect in WinUAE:



But on my real A1200,A600 looks like this:




Even/Odd lines switching is in VBI.

Code:



When I change code :

BNE SETBITPLANESODD
to
BEQ SETBITPLANESODD

then works perfect on real A1200,A600 ofcourse. But not in WinUAE.

Is this any Even/odd lines sync problem ?
Or problem is me ?

[mark_k]

Does the WinUAE display look any different if you use the double, fields or double, fields+ interlaced line modes? (With the latter you'll want to have the WinUAE output vsynced to your monitor to avoid flashing/flickering.)

[Toni Wilen]

I think you are modifying copper list while copper is reading it, if CPU is fast enough, plane pointers are updated before copper reads them (and moves to bitplane pointers), if CPU is slow enough, copper wins and effectively odd and even fields get swapped.

This is not that rare bug, many A500 demos have similar bug and only work because CPU is slow enough.

[obiwanken]

to mark_k: I tried, but no effect. Thanks

to Toni:
Clever, when I use Cycle-exact option in Chipset menu , then WinUAE and real Amiga works with no difference.

Many thanks.

[pandy71]

probably wrong field order - change order and it should work better, remember that NTSC and PAL have different field order (but windows is US so it can ignore PAL field order) not sure also on Amiga behavior - it is US machine it can force NTSC field order even for PAL (so incorrectly from PAL point of view)

http://documentation.apple.com/en/mo...4%26tasks=true

btw it is safer to set one large bitplane than two separate fields (ie process only each second VBLANK i.e. trig on pictures not on fields)

[Toni Wilen]

Easiest fix is to add copper WAIT before bitplane pointer moves which waits for line 10-20 or so, leaving more than enough time for CPU to update everything needed in copper list.

Amiga surely has exact same PAL and NTSC field order or all PAL games would have bad interlace on NTSC and vice versa.

[mr.vince]

Originally Posted by pandy71

probably wrong field order - change order and it should work better, remember that NTSC and PAL have different field order (but windows is US so it can ignore PAL field order) not sure also on Amiga behavior - it is US machine it can force NTSC field order even for PAL (so incorrectly from PAL point of view)

This is absolutely wrong. Both standards start with the odd field.

Where is this supposed to come from?

EDIT: ok, will read Apple doc. But still wrong...

[pandy71]

Originally Posted by Toni Wilen

Amiga surely has exact same PAL and NTSC field order or all PAL games would have bad interlace on NTSC and vice versa.

So Amiga probably will use NTSC field order... for progressive data field order is not important, it is only important for animations.

Originally Posted by mr.vince

This is absolutely wrong. Both standards start with the odd field.

Where is this supposed to come from?

EDIT: ok, will read Apple doc. But still wrong...

nothing is wrong, NTSC have inverted field dominance, in this case i think fields are swapped (incorrect field order is not a problem for progressive video, swapped fields give distortion for progressive video).
Wrong field dominance i see quite frequently in Europe nowadays as lot of people without knowledge use various video processing tools (like FinalCut), usually those tools working in native(default) NTSC field order, after processing such video is sent to encoder but most of the encoders is fixed on PAL dominance and distortions is badly visible as strobe motion - also video materials from USA need to be fixed.

https://support.apple.com/kb/TA26010?viewlocale=en_US
http://documentation.apple.com/en/fi...6%26tasks=true
http://www.mir.com/DMG/interl.html
http://lurkertech.com/lg/fields/

WinUAE AFAIK not support interlace in a native way and interlace is simulated on progressive screen (AFAIK Windows support display on interlace but not provide control over field order).


But once again - this kind of distortion for static picture means swapped fields, i've made simple Avisynth script with original and swap fields corrected (swap swapped) and seems that it works. issue can be or display or capture device - this why i recommend to test interlace always on CRT.

Bellow Avisynth script and picture:

StackHorizontal (ImageSource("Interlace2.jpg"), ImageSource("Interlace2.jpg").SwapFields())

[mark_k]

I don't think the original PAL or NTSC analogue video standards specify a field order; there's not really any concept of that in interlaced video as broadcast. Likewise there is no "field order" for Amiga output video. If you want to output an interlaced animation where the image is only updated every two fields (i.e. ~25/30 fps frame rate), you choose the field order yourself. That is, does each frame consist of an odd field then even field, or does it consist of an even field then odd field. Either way, that wouldn't be ideal since motion would be jittery. (For what it's worth, WinUAE's "double, frames" method works like that. Meaning, if you chose the "opposite" field order for your program to that used by the "double, frames" method, the WinUAE display will look pretty bad. The recently-introduced "double, fields" is better, matching what a real Amiga with de-interlacer shows.)

Where defining a field order (and/or field dominance) does become relevant is editing video, or converting from interlaced video which is actually a representation of a progressive source. For example, a PAL DVD sourced from film. Each original film frame would be stored as two successive fields. To reconstruct the original progressive frame you need to know whether a frame is odd then even fields, or even then odd fields.

[mc6809e]

Setting LACE in BPLCON0 auto-toggles LOF in VPOSR, so there are two questions:

What is the initial state of LOF? Do you set/reset it by writing to VPOSW?

When you read LOF in your handler, does the read happen before or after the toggle of LOF -- i.e. is there a race condition? I'm not sure LOF is toggled immediately at the beginning of vblank. When does the toggle actually happen? If your int handler takes too long, you might read LOF after the toggle and get the LOF for the next frame. Or, you might read it quickly and get the LOF for the current frame. Which happens? Maybe you can find out by quickly polling both VHPOSR and VPOSR.

[pandy71]

Originally Posted by mark_k

Where defining a field order (and/or field dominance) does become relevant is editing video, or converting from interlaced video which is actually a representation of a progressive source. For example, a PAL DVD sourced from film. Each original film frame would be stored as two successive fields. To reconstruct the original progressive frame you need to know whether a frame is odd then even fields, or even then odd fields.

But Amiga can generate or progressive or interlace content and this is why field dominance is important - for example scrolling of text - can be performed or by progressive way (25/30fps) or interlace (50/60fps) way - all animation using interlace will be twice smoother- motion will be more smooth.

To display static picture, filed order can be ignored, for animated content there are two possibilities.

[Toni Wilen]

LOF toggles at the end of last line. (But I am 100% sure my explanation in 3rd post explains OPs problem 100% and LOF or whatever is not the problem at all)

Originally Posted by pandy71

But Amiga can generate or progressive or interlace content and this is why field dominance is important - for example scrolling of text - can be performed or by progressive way (25/30fps) or interlace (50/60fps) way - all animation using interlace will be twice smoother- motion will be more smooth.

To display static picture, filed order can be ignored, for animated content there are two possibilities.

Sorry but I'll have to ask: What? Really? (When did progressive become 25/30? It has always been 50/60, 1 field is 1 frame. Also static interlace image with wrong field order will look horrible)

[pandy71]

Originally Posted by Toni Wilen

Sorry but I'll have to ask: What? Really? (When did progressive become 25/30? It has always been 50/60, 1 field is 1 frame. Also static interlace image with wrong field order will look horrible)

You can have progressive video on interlaced display (situation where both fields have no temporal difference is progressive) - refresh rate is reduced by half.
In fact progressive (static video) with incorrect field dominance looks exactly the same as video with correct field dominance (field dominance == field order), swapped fields is horrible in both cases (i.e. for static and dynamic video). I can create 2 movies if You interested - one correct field order and second with incorrect field order (but no swapped fields) - they will look exactly the same on CRT, LCD or any other display, sometimes video equipment (mostly encoders) are equipped with feature to fix this problem (incorrect field dominance).

Btw
It is quite clear that TV video is designed to be interlace - i.e. two fields but with half vertical resolution (in fact less than half due Kell factor https://en.wikipedia.org/wiki/Kell_factor ), full vertical resolution (with respect to Kell factor) is achieved only with reduced refresh rate i.e. field rate /2 - this is why video can be interlace or progressive (temporal) on interlace display.

[Toni Wilen]

But I still don't see what this has to do with Amiga and its analog progressive/interlace output. There is no field order to detect or anything like that. It just works

Display device just follows sync signals, field ordering is "automatic". (sync starts at mid scan line vs sync starts at the end of scanline)

Amiga creates the field order and it is fully programmable, it does not need to be (and rarely) is what PAL or NTSC spec says, for example both field order and plane order may suddenly change, result is still correct image but if you try to capture it, you probably get a glitch(es).

Yes, PAL/NTSC is designed to be interlaced, "progressive" is just a hack and not in spec. (for example most LCDs try to deinterlace it resulting in ugly half-vertical resolution 25hz with every other field dropped)

[pandy71]

Of course you can distinguish between fields in display thus source need to provide correct information - serration/equalizing pulses combination is responsible for that - look at Agnus specification - how different are sync signals for "odd" and "even" fields" - based on this display (capture) device can distinguish between fields, field order is extremely important for interlace content - TFF (Top Field First) or BFF (Bottom Field First) - without this you will have very nasty stutter.

For Amiga it can be all fields are Odd OR all fields are Even (usual case for modes without ILACE bit active) but for ILACE active Odd/Even or Even/Odd sequence should be kept constantly especially when content displayed (produced) by Amiga is interlaced type (like smooth animations - like software to video titling supporting interlace fully in a smart way).

And most LCD's perform deinterlacing by BOB method (ie interpolate missing lines in field to form frame, usually kernel to shift lines vertically +-0.5 line is used - this is why progressive video modes from Amiga shaking vertically on many modern LCD's/PDP's)

[Toni Wilen]

I think we are talking from different view points. I only care what Amiga hardware does, it is not Amiga's or programmer's problem to care if display device (or whatever gets the input) understands it correctly. It just does it and if it does not, it is broken

You seem to look from input (display) device's point of view.

Also even emulation does not need to care about sync pulses because Agnus will latch LOF (unless I missed something when I tested it) state at the end of field and it will use this latched value to generate next field (including correct equalizer pulses etc..) , nothing happens even if you modify LOF immediately, at least not until following field starts.

[pandy71]

Originally Posted by Toni Wilen

I think we are talking from different view points. I only care what Amiga hardware does, it is not Amiga's or programmer's problem to care if display device (or whatever gets the input) understands it correctly. It just does it and if it does not, it is broken

You seem to look from input (display) device's point of view.

Yes, i agree as WinUAE is emulator - You see data in memory, interpreting them based on state in few register and produce based on this bitmap exposed to Windows.
Minimig trying to recreate hardware based on WinUAE however need to follow different way.

Originally Posted by Toni Wilen

Also even emulation does not need to care about sync pulses because Agnus will latch LOF (unless I missed something when I tested it) state at the end of field and it will use this latched value to generate next field (including correct equalizer pulses etc..) , nothing happens even if you modify LOF immediately, at least not until following field starts.

As mentioned previously this is main difference between software emulator and real hardware implementation.
For sure real sync signals need to behave in correct way to provide correct video (especially that one of unique features in Amiga video hardware was full TV video standard compatibility - AFAIR Agnus/Denise was designed to fully follow RS170A USA video signal standard).

[mark_k]

The most logical behaviour for a hardware/software Amiga emulator which needs to output a progressive video signal is (in my opinion) to work the same as an Amiga de-interlacer card (flickerFixer, A2320 etc.).

So for interlaced modes, in the case of an odd field, all odd lines of the output frame are the lines of that field. The even lines of the output frame are the lines from the previous (even) field. Similarly when the Amiga outputs an even field. WinUAE's "double, fields" method does that. If the field type is the same as the last one, assume output is non-interlaced and double the field lines in the output frame. [Some de-interlacers including the Microway flickerFixer didn't have logic to do that, so you get deinterlacing artifacts even when the Amiga output is non-interlaced.]

That avoids the extra-latency problem and artifacts of combining each pair of fields into two identical output frames. In certain cases, that combining can give "better-looking" results than a real Amiga. But in others it doesn't, and without a way to manually switch the fields→frame pairing (does one output frame = odd field + even field, or even + odd?) might not give consistent results even when running the same program on different occasions.