Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > CSDb Discussions > VIC and the odd/even fields
2007-06-07 15:00
Oswald

Registered: Apr 2002
Posts: 5086
VIC and the odd/even fields

okay this is getting confusing for me now. in another thread on lemon64 groepaz says that the vic does always display the same field, but it doesnt matter if its odd or even, and it lights up both the odd/even lines.

some1 can tell me:

- does vic use odd or even or dontcare lines?
- what does the term field mean from the tv electronics viewpoint?
- how does the vic only light up the odd (forex.) lines on the tv screen, and a little bit from the other ones?
- are there really 2 modes in the tv electronics for odd / even fields
- why does computer graphics flicker a hell more lot while "normal" tv screens looks as steady as my ass?
2007-06-07 15:27
chatGPZ

Registered: Dec 2001
Posts: 11360
Quote:
in another thread on lemon64 groepaz says that the vic does always display the same field, but it doesnt matter if its odd or even


"doesnt matter" as in "no idea which it is, but its irrelevant to explain what happens" yes :=)

Quote:
what does the term field mean from the tv electronics viewpoint?


field==halfframe. one field has all odd scanlines and the other has all even scanlines.

Quote:
how does the vic only light up the odd (forex.) lines on the tv screen, and a little bit from the other ones?


the chrominance part of the signal is reused for two scanlines.

Quote:
are there really 2 modes in the tv electronics for odd / even fields


modes? no, the length of a certain scanline at the start (or end, kind of matters how you define it) of each halfframe determines wether odd or even lines are used. (see how the "true" interlace on c128 works - it modifies the length of this scanline)

Quote:
why does computer graphics flicker a hell more lot while "normal" tv screens looks as steady as my ass?


pal/ntsc is optimized for "natural" pictures, and only works well with not-so-sharp images. (again, sideeffect of the reusing of chrominance due to limited bandwidth)

uh, its a bit more complicated than that actually :) ask your favourite tv technican :=P
2007-06-07 15:46
dahl
Account closed

Registered: Feb 2003
Posts: 2
- I believe the VIC doesn't support bobbing because of its low vertical resolution; e.g "dontcare".
- http://www.100fps.com covers fields etc.
- check answer 1
- don't understand the question
- your computer graphics flickers more on a computer monitor because the pixels lits down faster (going from say white to black). The pixels on an ordinary TV needs slightly more than a 50th of a second to shut down completely giving a more stable picture.
2007-06-07 15:51
chatGPZ

Registered: Dec 2001
Posts: 11360
let me try to draw a whacky chart, might be easier:

normal pal (tv) signal:

odd field: AAAAAAAAA
even field:BBBBBBBBB
odd field: AAAAAAAAA
even field:BBBBBBBBB 
odd field: AAAAAAAAA
even field:BBBBBBBBB


fields are displayed alternating (interlace). the chrominance is reused for ever other line in the _same_ field.

vic signal:


odd field even field

AAAAAAAAA BBBBBBBBBB
--------- ----------
AAAAAAAAA BBBBBBBBBB
--------- ----------
AAAAAAAAA BBBBBBBBBB
--------- ----------



*again* in each field the color signal is reused for every other line, but since the fields arent actually using different scanlines the "black" scanlines don't actually appear as black, but as dim (2/3rd) "copies" of the previous scanline.

mmmh, does that make sense? =)
2007-06-07 16:05
Oswald

Registered: Apr 2002
Posts: 5086
does the TV know anything about odd/even fields, or that is entirelly driven by the incoming signal? if so exactly HOW?

why does the electron beam light up half lines it shouldnt when it has old chrominance info ?

"the fields arent using different scanlines" huh???
2007-06-07 16:13
JackAsser

Registered: Jun 2002
Posts: 2014
"does the TV know anything about odd/even fields, or that is entirelly driven by the incoming signal?"

It's driven by the signal. The half PAL line you sometimes see on the bottom of one of the fields actually makes the next field jump down half a raster line. C64 never outputs this line, thus the fields never jump up and down => progressive display.

About chrominance, that's simply that the color data has half y-resolution (per field). The chrominance data is not "re-used" between different fields.

One field consist of 720/(576/2) luminance pixels and 720/(576/2/2) chrominance pixels.

On the C64, the same field is output twice without any half PAL line on the bottom, thus u effectivly get 720/576/2 resolution, progressive with 720/576/2/2 chrominance resolution.

2007-06-07 16:20
chatGPZ

Registered: Dec 2001
Posts: 11360
Quote:
About chrominance, that's simply that the color data has half y-resolution (per field). The chrominance data is not "re-used" between different fields.


ah yes "re-used" is the wrong term. what happens (originally, in older, analog tv) is that the chrominance while beeing used for the current scanline it is also feed into a delay-line (in the simpliest case this is literally just a very long wire) and then in the next scanline (of the current field) the signal coming out of the delay line is used for chrominance.

confusion complete? =D
2007-06-07 16:24
Oswald

Registered: Apr 2002
Posts: 5086
groppie:I've checked wiki, and it says the chrominance averaging/delaying stuff is done to eliminate errors (transmission bugs?) originally it was NOT used in the early tvs.

edit: thus the chrom data is not truly half reso, rather avged with prev line.
2007-06-07 16:27
Oswald

Registered: Apr 2002
Posts: 5086
jack, how do I interpret all those magic numbers?:)
2007-06-07 16:30
chatGPZ

Registered: Dec 2001
Posts: 11360
the wiki is wrong :) the chroma signal is half resolution to save bandwidth. the averaging thing is true however, the current scanline chroma will always be a mix of 1 third of the previous scanline chroma and 2/3 of the current scanline chroma. (no, its not like this, its more complicated, but i forgot =D)
2007-06-07 16:32
MagerValp

Registered: Dec 2001
Posts: 1074
To understand how a CRT display works, stop thinking about pixels and lines. It's an analog display, and everything is driven by timing. Lines are not horizontal, but drawn in a zig-zag pattern. There are no pixels, but an electron cannon firing continuously at a phosphor layer that lights up for roughly 1/50th of a second. There are no dim 2/3rd lit up half scanlines inbetween, that's just how VICE approximates the effect of CRT dot pitch on high resolution PC displays.

Talking about odd or even fields on the VIC is also pointless, as you only have fields in interlaced video modes. The VIC outputs 50 frames per second, and no fields. Not odd, not even. The VIC does not output a spec conforming video signal, but it works because CRTs are not intelligent - they have no concept of odd and even fields. An interlacing video output device (Amiga's Denise, your TV receiver, whatever) "tricks" the CRT into moving every other field half a scanline down by delaying video signal 32 microseconds.

Please go read some articles on how CRTs, and especially interlaced video, works.
2007-06-07 16:38
MagerValp

Registered: Dec 2001
Posts: 1074
Quote: the wiki is wrong :) the chroma signal is half resolution to save bandwidth. the averaging thing is true however, the current scanline chroma will always be a mix of 1 third of the previous scanline chroma and 2/3 of the current scanline chroma. (no, its not like this, its more complicated, but i forgot =D)

Please don't bring chroma mixing into this already confused discussion :P

(and it's 50:50 mixing btw, though technically it varies from CRT to CRT, and it has half the *horizontal* resolution)
2007-06-07 16:44
Oswald

Registered: Apr 2002
Posts: 5086
alrighty its nor odd nor even scanlines still there must be in some (to me unknown) form every 2nd line skipped. isnt it? on some TV's you can stretch/shrink the screen horizontally / vertically. but neither of that messes up the display. so when adjusting the vertical size the half lines must be still there in some timed form. also the outside signal can tell the tv wether its an odd or even field how does that happen ?
2007-06-07 16:49
chatGPZ

Registered: Dec 2001
Posts: 11360
Quote:
also the outside signal can tell the tv wether its an odd or even field how does that happen ?


jackasser already said how that works, wether the next field is odd or even is determined by the length of the last scanline. (and again, this is why/how the "true" interlace on the c128 works - it manipulates the length of that very scanline)
2007-06-07 16:54
Oswald

Registered: Apr 2002
Posts: 5086
why can then magervalp say that the vic's output is nor odd nor even ? it must be either this or that!!
2007-06-07 16:57
chatGPZ

Registered: Dec 2001
Posts: 11360
Quote:
why can then magervalp say that the vic's output is nor odd nor even ? it must be either this or that!!


no, since both fields are the *same*, there is no "odd" or "even" field technically :=)
2007-06-07 17:06
Oswald

Registered: Apr 2002
Posts: 5086
sdglékjasflékgjsdfkljglasfjkglsdfkglsdfg

*pulls all hair out*



but its either all odd or all even no matter what. the last scanline clearly determines that.
2007-06-07 17:18
chatGPZ

Registered: Dec 2001
Posts: 11360
Quote:
but its either all odd or all even no matter what. the last scanline clearly determines that.


yes :=)
2007-06-07 17:23
Oswald

Registered: Apr 2002
Posts: 5086
SIGH

then why do ppl always say it neither odd neither even when its clearly one of them.
2007-06-07 17:24
chatGPZ

Registered: Dec 2001
Posts: 11360
its just terminology.... technicans only refer to odd and even fields when there is actually interlace taking place.
2007-06-07 17:32
Oswald

Registered: Apr 2002
Posts: 5086
.. making something incredibly simple concept incredibly hard to understand.
2007-06-07 18:40
JackAsser

Registered: Jun 2002
Posts: 2014
oswald. listen. the CRT is all about timing as magervalp says. Since one of the fields is delayed due to the last line is longer on the previous field, that effectivly moves down the display half a line.

Also, CRTs doesn't "skip" every 2nd line. see it like:

OE
DV
DE
_N
1
1
12
12
32
32
34
34
_4
_4

The CRT it self doesn't know about fields, it simply displays frames, a new one on each vertical sync. In PAL 50 per second and by altering the length of the last rasterline every 2nd frame you effectivly wiggle the display up and down half a pixel, thus get a preceived higher resolution to the cost of 25hz motion instead (u don't want the two fields to be separated in time because that leads to weaving artefacts when moving).
2007-06-08 04:38
Oswald

Registered: Apr 2002
Posts: 5086
jack, now that is starting to make sense, but brings up new questions: why is every "2nd" line darker when the vic drives the CRT if the CRT effectively scans every line ?

2ndly according to wikipedia the fields are indeed seperated in time.
2007-06-08 06:21
JackAsser

Registered: Jun 2002
Posts: 2014
@oswald, simply because the raster beam moves in a zig-zag pattern. During a horizontal sync the signal is ultra-black and when that happens the TV starts moving the beam back to the left + moves it down a bit. Hence, if your beam is narrow enough and your screen has a dense enough fosfor-thingie then you'll see the individual scanlines quite easy.
2007-06-08 06:26
JackAsser

Registered: Jun 2002
Posts: 2014
Quote: jack, now that is starting to make sense, but brings up new questions: why is every "2nd" line darker when the vic drives the CRT if the CRT effectively scans every line ?

2ndly according to wikipedia the fields are indeed seperated in time.


@oswald, the fields are NOT separated in time. Either u misunderstand the wiki OR the wiki is wrong. The fields CAN be separated in time, but TV-signals generally are NOT. Badly re-interlaced movies by lame-ass converter-kiddies usually have the fields separated though. ;D

Of course every other field is shown 20ms after the other one, but the content it displays belongs to the same time frame when the camera snapped them.

You CAN separate the fields in time so that each field effectivly has a strickly forward time-pointer, but that will yeild weiving artefacts (plz see my twister in LCP Memories). The upside is that motion gets 50hz, downside is that effective resolution is halved, conclusion bandwidth is the same.

2007-06-08 09:18
MagerValp

Registered: Dec 2001
Posts: 1074
There are no "every 2nd line". The gap between scanlines depends on the CRT's dot pitch:



JA: please don't bring up digital effects and bandwidth, he's confused enough as it is :)
2007-06-08 09:43
Graham
Account closed

Registered: Dec 2002
Posts: 990
@JackAsser:

"Of course every other field is shown 20ms after the other one, but the content it displays belongs to the same time frame when the camera snapped them."

This depends on the camera and effect machines. Some cameras do 50 fps where each field is taken in 20 ms steps, but most cameras do it in 25 fps ofcourse. Same for genloc stuff put ontop. I have seen 50 fps scrollers put on top of 25 movies on TV.
2007-06-08 09:48
JackAsser

Registered: Jun 2002
Posts: 2014
@Graham: yeps of course, but in general...
2007-06-08 10:36
ptoing

Registered: Sep 2005
Posts: 271
Now one question remains. Is this technical stuff really relevant for us with what the demoscene does. I for one part would say no. The C64 works like it works, TVs work like they work. Unless you do hardware hacking stuff stays like it is. Done.
2007-06-08 10:40
chatGPZ

Registered: Dec 2001
Posts: 11360
never wrong to understand WHY thinks work as they work :)
2007-06-08 11:12
ptoing

Registered: Sep 2005
Posts: 271
Well I agree with that, tho people are explaining the same stuff over and over again here.
2007-06-08 17:25
Oswald

Registered: Apr 2002
Posts: 5086
Quote: Now one question remains. Is this technical stuff really relevant for us with what the demoscene does. I for one part would say no. The C64 works like it works, TVs work like they work. Unless you do hardware hacking stuff stays like it is. Done.

fully understanding the display we use to, be able to use it to maximum effect is kinda important isn't it?
2007-06-08 17:27
Oswald

Registered: Apr 2002
Posts: 5086
okay, I think I understand it now.

other questions:

how comes that eventho there is an iron rastermask (= defined pixels?) on color tvs, you can still resize the picture in a fashion which loooks like fully analog?
2007-06-08 17:52
chatGPZ

Registered: Dec 2001
Posts: 11360
Quote: okay, I think I understand it now.

other questions:

how comes that eventho there is an iron rastermask (= defined pixels?) on color tvs, you can still resize the picture in a fashion which loooks like fully analog?


read your question again, you already know the answer :=)
2007-06-08 18:16
Oswald

Registered: Apr 2002
Posts: 5086
you mean the "looks like" part?
2007-06-08 19:42
ptoing

Registered: Sep 2005
Posts: 271
meh
2007-06-08 19:47
chatGPZ

Registered: Dec 2001
Posts: 11360
Quote: you mean the "looks like" part?

yes what else? the mask obviously limits the "analogness" (uhh) to some degree
2007-06-08 20:03
MagerValp

Registered: Dec 2001
Posts: 1074
Understanding how displays work is of course useful, and is a prerequisite for developing some effects. For example, our beloved 0.5 pixel scrolling that, regardless of what Oswald believes, generates a genuine resolution increase.
2007-06-08 20:15
Oswald

Registered: Apr 2002
Posts: 5086
mager, regardless of what you believe I am right. (just to copy your argue style:)
2007-06-08 21:03
MagerValp

Registered: Dec 2001
Posts: 1074
You could take a hint from the fact that the people sitting here explaining how CRTs work, are the same people that say that 0.5 pixel scrolling works.
2007-06-08 21:09
chatGPZ

Registered: Dec 2001
Posts: 11360
Quote: You could take a hint from the fact that the people sitting here explaining how CRTs work, are the same people that say that 0.5 pixel scrolling works.


keep me out of that kthxbye :)
2007-06-08 21:09
Nightlord
Account closed

Registered: Jan 2003
Posts: 131
ok I have a question. I see a contradiction between what Groepaz says and what Magervalp says about Chrominance being half resolution.

So there are 576/2= 288 scan lines in one frame (between 2 v-syncs). For each 288 scanlines, The corresponding part of the signal starts with h-sync, then color burst, then video_info. My understanding was that the low freq amplitude of video_info is luminance and the color gets modulated and added to the signal in a higher freq smaller amplitude sinusoidal whose amplitude determinas "saturation" and whose phase determines "hue".

From what I understand, Groepaz is saying there are 288/2=144 lines in each frame that has this modulated color info and 2 consecutive scanlines in same frame use the same crominance.

Where as Magervalp refers to "horizontal resolution being half". thus two "pixels" (thinking of pixel as a part of crt tube where the beam covers in 1/50/288/720 seconds) next to each other share the same chrominance but can have different luminances. This way all 288 scan lines in a frame has different color info modulated in them.

Do I understand you guys correctly? If yes which is true? I was thinking Magervalp's statement is true, but I am not 100% sure
2007-06-08 21:15
chatGPZ

Registered: Dec 2001
Posts: 11360
chromincance has lower resolution in both dimensions :) in X its valid for more than one pixel, in Y it "drains" down the display due to the delay line.
2007-06-08 21:23
Nightlord
Account closed

Registered: Jan 2003
Posts: 131
ok so all 288 lines between 2 v-syncs have different chrominance, right?

The "draining" you refer to confuses me though... Isn't that true for Y as well?
2007-06-08 21:47
chatGPZ

Registered: Dec 2001
Posts: 11360
Quote:
ok so all 288 lines between 2 v-syncs have different chrominance, right?


yes

Quote:
The "draining" you refer to confuses me though... Isn't that true for Y as well?


no, thats only done for chrominance (and only on PAL *afaik* - ntsc works a bit different).
2007-06-08 23:22
White Flame

Registered: Sep 2002
Posts: 136
The vertical color blending on PAL is actually due to hardware on the display deliberately performing the blend, not due to the signal itself, right?

And this might help or hinder the discussion: http://www.white-flame.com/interlace.gif

and the whole "half horizontal color resolution" thing is more about bandwidth than digital resolution. The signal can only change so sharply due to frequency limitation. So you can _start_ a color change anywhere on the analog line, but it's limited to how fast it can change. The luminance signal can change much more rapidly, thus has a finer resolution.
2007-06-08 23:38
chatGPZ

Registered: Dec 2001
Posts: 11360
Quote:
The vertical color blending on PAL is actually due to hardware on the display deliberately performing the blend, not due to the signal itself, right?


yep

Quote:
And this might help or hinder the discussion: http://www.white-flame.com/interlace.gif


makes sense to me :)
2007-06-09 05:41
Oswald

Registered: Apr 2002
Posts: 5086
whiteflames illustration makes sense even for me, but is again source of confusion.

according to jackesser this happens:

_e
ov
de
dn
10
12
32
34
54
56
76
78

now is there an "empty" scanline between consecutive odd / even scanlines or not ?!

or: is one scanline "doubled" in height according to the above ascii art, and the vertical resolution only "doubles" by having an "half" scanline shift between odd/even frames?!
2007-06-09 09:06
JackAsser

Registered: Jun 2002
Posts: 2014
Quote: whiteflames illustration makes sense even for me, but is again source of confusion.

according to jackesser this happens:

_e
ov
de
dn
10
12
32
34
54
56
76
78

now is there an "empty" scanline between consecutive odd / even scanlines or not ?!

or: is one scanline "doubled" in height according to the above ascii art, and the vertical resolution only "doubles" by having an "half" scanline shift between odd/even frames?!


"is one scanline "doubled" in height according to the above ascii art, and the vertical resolution only "doubles" by having an "half" scanline shift between odd/even frames?!"

BINGO!
2007-06-09 09:40
Oswald

Registered: Apr 2002
Posts: 5086
jack, wont work if I take into consideration that the "half scanline shift" happens due to having "half screen wide" scanlines. :P o_O
2007-06-09 10:13
MagerValp

Registered: Dec 2001
Posts: 1074
Quote: keep me out of that kthxbye :)

*sigh*

Here's another experiment for you:

Connect a C64 to a 1084 mounted on a table that has an adjustable height. Adjust the 1084 so that every VIC scanline is exactly 1 mm high. Now simultaneously display a 0.5 pixel upscroller, and move the table down at a constant speed of 25 mm per second. In what was does this display differ from that of an interlaced Amiga display (assuming a 1084 with infinite height, etc)?
2007-06-09 11:53
chatGPZ

Registered: Dec 2001
Posts: 11360
Quote:

Connect a C64 to a 1084 mounted on a table that has an adjustable height. Adjust the 1084 so that every VIC scanline is exactly 1 mm high. Now simultaneously display a 0.5 pixel upscroller, and move the table down at a constant speed of 25 mm per second. In what was does this display differ from that of an interlaced Amiga display (assuming a 1084 with infinite height, etc)?


next time when i am very very bored i am going to try this. or maybe make a wildcompo entry from it while at it :o)
2007-06-09 12:38
AmiDog

Registered: Mar 2003
Posts: 97
I found this site quite interesting when I was trying to understand PAL color encoding a while back:
http://www.techmind.org/vd/paldec.html

(I had some plans to try to get my hands on a high quality sampler which would allow me to sample and decode non-standard video signals, like from the C128 in Risen from Oblivion. Turns out they are very expensive and I'm not good enough at electronics to be able to build my own video digitizer...)
2007-06-09 12:53
JackAsser

Registered: Jun 2002
Posts: 2014
Quote: jack, wont work if I take into consideration that the "half scanline shift" happens due to having "half screen wide" scanlines. :P o_O

@oswald: How do you mean it doesn't work?, elaborate plz. Exactly what part did u misunderstand?
2007-06-09 15:19
Oswald

Registered: Apr 2002
Posts: 5086
1
12
32
3


^^^means the TV can shift scanlines "half" scanline down, but as someone said the TV knows nothing about interlace in itself so how can you tell it to shift one half scanline?
2007-06-11 07:39
JackAsser

Registered: Jun 2002
Posts: 2014
Quote: 1
12
32
3


^^^means the TV can shift scanlines "half" scanline down, but as someone said the TV knows nothing about interlace in itself so how can you tell it to shift one half scanline?


It's all rather simple actually.

When the TV hits the VSYNC at the middle of the last raster line it has to move up to line 0 immediately, however there is still half a raster line to go. So in effect the raster beam will continue it's journey for the remaining time (and also move down at the same pace as normal). So finally when it hits the HSYNC it will have moved down for 0.5 raster lines.

In numbers:

At line 313 on the even field it hits VSYNC in the middle.

even field:
1) x=middle y=313 VSYNC (jump to odd field)

odd field:
2) x=middle y=0
3) x=right y=0.5 HSYNC
4) x=left y=0.5

Remember the beam ALWAYS moved in this down-right slow slope, VSYNC and HSYNC simply resets either X, or Y. The slope remains.

Got it?
2007-06-11 08:57
Oswald

Registered: Apr 2002
Posts: 5086
ah another confusing info ! :D

so the scanlines are not totally horizontal ??! :)

leftmost Y=0, rightmost Y= 1 ? :)
2007-06-11 11:35
JackAsser

Registered: Jun 2002
Posts: 2014
@oswald: that's my impression of it yes. ;D
2007-06-11 11:50
chatGPZ

Registered: Dec 2001
Posts: 11360
ehrm, the scanlines are horizontal for their visible part (beam moving left to right) but they are not for their invisible retrace part (beam moving right to left).

-- scanline
 / retrace
/
-- scanline
 / retrace
/
--
2007-06-11 12:01
Oswald

Registered: Apr 2002
Posts: 5086
jack, according to groppie you have to come up with a new explanation :)
2007-06-11 12:23
JackAsser

Registered: Jun 2002
Posts: 2014
Quote: jack, according to groppie you have to come up with a new explanation :)

Well then, let's all join the club of major confusion. ;D Without having a constant slope I can't explain how interlace would have worked. I mean that slope could be counter acted by rotating the cannon a bit... But I'm not the TV-technician really.
2007-06-11 13:11
Radiant

Registered: Sep 2004
Posts: 639
JackAsser: Since it only retraces one half scanline, the beam only moves down 0.5 scanlines. Quite simple, no? :-)
2007-06-11 13:14
JackAsser

Registered: Jun 2002
Posts: 2014
Quote: JackAsser: Since it only retraces one half scanline, the beam only moves down 0.5 scanlines. Quite simple, no? :-)

@radiantx: put in that way it all feels rather logical then. ;D
2007-06-11 20:25
White Flame

Registered: Sep 2002
Posts: 136
As the raster beam moves down the screen, it's moving in the vertical direction at a constant rate. It doesn't scan purely horizontally, then jump down vertically, etc. So by default the scanlines would actually appear diagonally, in more of a sawtooth configuration, with the diagonal saw edges being a raster line and the quick snaps back being the horizontal refresh. The actual scanning guts are slightly rotated inside CRTs so that the raster lines are horizontal on the final display, afaik.

This should help explain how a vertical refresh in the middle of a scanline offsets the entire picture by half a scanline, interlacing 2 fields. It's 2 sawtooth patterns with a 50% phase shift.
2007-06-11 20:54
JackAsser

Registered: Jun 2002
Posts: 2014
Quote: As the raster beam moves down the screen, it's moving in the vertical direction at a constant rate. It doesn't scan purely horizontally, then jump down vertically, etc. So by default the scanlines would actually appear diagonally, in more of a sawtooth configuration, with the diagonal saw edges being a raster line and the quick snaps back being the horizontal refresh. The actual scanning guts are slightly rotated inside CRTs so that the raster lines are horizontal on the final display, afaik.

This should help explain how a vertical refresh in the middle of a scanline offsets the entire picture by half a scanline, interlacing 2 fields. It's 2 sawtooth patterns with a 50% phase shift.


@whiteflame: that was exacly how I thought it worked too until gropaz and radiantx "corrected" me. Dunno who's right though... ;D
2007-06-12 00:56
ChristopherJam

Registered: Aug 2004
Posts: 1408
I suspect the only reason the visible scanlines are horizontal is from the horizontal circuit operating on a slight diagonal, so it drags the beam back up a bit as it goes to the right, compensating for the vertical circuit providing a constant downward motion.

If you assume for the sake of argument the lines are on a slight angle when a CRT is first constructed, it will probably be a lot simpler to understand the interlace. Making them horizontal later is just an adjustment that can be done by rotating some coils or feeding some current from one circuit to another.

(Oh, and to answer an earlier question, the iron mask on a CRT doesn't line up with the pixels at all - it just ensures each beam can only reach the right colour phosphors. Have a look at a reversed space with a magnifying glass, and count the green dots. There almost certainly won't be eight of them!)
2007-06-12 06:56
AmiDog

Registered: Mar 2003
Posts: 97
And how can all this be applied to modern CRTs with digital filters, 100Hz, etc? (Not to mention all video equipment which I assume will have to know if the current frame is an odd or even field. Doesn't even a simple genlock need to know that to be able to sync the two video sources properly?)

At some point one had to start detecting the horizontal position of the V-Sync and act upon it. So, how old (or cheap?) would a TV need to be to still rely on that half scanline shifting the display down half a pixel for free?
2007-06-12 09:56
MagerValp

Registered: Dec 2001
Posts: 1074
Quote: And how can all this be applied to modern CRTs with digital filters, 100Hz, etc? (Not to mention all video equipment which I assume will have to know if the current frame is an odd or even field. Doesn't even a simple genlock need to know that to be able to sync the two video sources properly?)

At some point one had to start detecting the horizontal position of the V-Sync and act upon it. So, how old (or cheap?) would a TV need to be to still rely on that half scanline shifting the display down half a pixel for free?


100 Hz CRTs with digital filters are way beyond what we're discussing here. Just think of them as digital displays, like LCDs.

And yes, the beam moves down in a zig-zag pattern, with constant vertical velocity. However, the zig-zag is rotated and skewed:



On each hsync it goes a little more to the left, adjusting the slope of the zig-zag pattern.
2007-06-12 10:08
Graham
Account closed

Registered: Dec 2002
Posts: 990
100 Hz CRTs are the biggest marketting joke ever. Despite the fact that they have a field rate of 100 Hz, they still are bound to display 25 Hz interlace :D
2007-06-12 11:04
JackAsser

Registered: Jun 2002
Posts: 2014
@oswald: any more loose ends?
2007-06-12 11:11
MagerValp

Registered: Dec 2001
Posts: 1074
Quote: 100 Hz CRTs are the biggest marketting joke ever. Despite the fact that they have a field rate of 100 Hz, they still are bound to display 25 Hz interlace :D

A good 100 Hz CRT, just like a good LCD or DLP, displays a progressive image, using the usual deinterlacing techniques. Cheap 100 Hz CRTs are a joke though.
2007-06-12 11:22
Oswald

Registered: Apr 2002
Posts: 5086
Quote: @oswald: any more loose ends?

all my ends are on loose, I simply gave up.
2007-06-12 16:11
Graham
Account closed

Registered: Dec 2002
Posts: 990
@Magervalp:

The problem is that the deinterlacing does not work. Some movies are 25 fps, some are 50 fps, and sometimes it's even 25 and 50 fps mixed. So even IF you have a deinterlacer, the better movies and animations (50 fps) will look jerky.
2007-06-13 03:47
ChristopherJam

Registered: Aug 2004
Posts: 1408
Well, unless it's got some kind of motion prediction, a 50Hz scroll will ghost as badly on a 100Hz display as a 25Hz scroll does on a 50.

I saw someone trying to play some Amiga games on a 100Hz TV once. It wasn't pretty.
2007-06-13 06:27
MagerValp

Registered: Dec 2001
Posts: 1074
Of course, deinterlacing is a complicated process, and only ever works most of the time, never always. High end displays do a good job with natural images. They are completely unsuited for displaying computer images though.
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Jetboy/Elysium
Holy Moses/Role
MCM/ONSLAUGHT
Didi/Laxity
psych
bexxx
rexbeng
kbs/Pht/Lxt
instant
d'Arc/Topaz Beerline
Guests online: 85
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Mojo  (9.6)
6 The Demo Coder  (9.6)
7 What Is The Matrix 2  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 Layers  (9.6)
2 Party Elk 2  (9.6)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.6)
5 Libertongo  (9.5)
6 Rainbow Connection  (9.5)
7 Onscreen 5k  (9.5)
8 Morph  (9.5)
9 Dawnfall V1.1  (9.5)
10 It's More Fun to Com..  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Nostalgia  (9.3)
5 Triad  (9.2)
Top Diskmag Editors
1 Magic  (9.8)
2 hedning  (9.6)
3 Jazzcat  (9.5)
4 Elwix  (9.1)
5 Remix  (9.1)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.182 sec.