Hacker News Reader

Comment by fredoralive | Hacker News Reader

It’s basically just an SD TV signal, the vertical height in lines doesn’t change, it largely just swaps if each line outputs 320 or 640 pixels during its assigned time period.

Having interlaced and non interlaced modes at once seems a bit funky though, but I assume it just forces everything into interlaced with the non interlaced mode sections having the same line sent on both fields?

View on HN

In TV land, there is no non-interlaced. It's all interlaced. You provide fields at 50Hz/60Hz* and the CRT displays one after the other, interleaved.

https://en.wikipedia.org/wiki/Interlaced_video

"Non-interlaced" is just sending the same line for both fields, "interlaced" is sending different lines for each field. You can update your "non-interlaced" screen at 50/60Hz and the viewer will see movement, because it's transmitted for both fields. If you were updating just one line of an interlaced screen at 50/60Hz, it would only be transmitted every second field, so the viewer would perceive 25/30Hz movement.

For high-resolution monitors, Commodore and 3rd parties offered a "flicker fixer", which took the raw output, buffered both fields in its own RAM, and re-emitted the combined image as a single frame.

https://en.wikipedia.org/wiki/Flicker_fixer

*: actually 59.94Hz

No, there is actually a difference between an interlaced and non-interlaced signal. A non-interlaced signal has an integral number of lines per field without the half-line that an interlaced signal would have. With a non-interlaced signal, a classic CRT will scan all of the fields with the same alignment instead of interleaving even/odd fields vertically. There was a definite visual difference between a non-interlaced mode and an interlaced mode repeating the same screen for both fields.

It’s worth noting that this is not actually explicit in the standard so much as it is just a natural consequence of not including the half-line. Since the raster is continually moving across and down, including during all retraces (until the actual blanking pulses reset them), the presence of the half-line means that the horizontal retrace doesn’t reset at the end of the half line, it just continues scanning horizontally while the vblank pulse resets the vertical deflection to the top of the screen. Similarly, all scan lines are actually very slightly tilted down on all CRTs unless there is compensation for it. The vertical deflection is consistently moving across the length of the horizontal trace.

Edit: if you have a set that is miscalibrated or worn out, you can end up actually seeing the retrace lines during what should be blanking

AmigaOS does indeed enable the extra half line when any visible viewports are interlaced. Fortunately that just works because the individual “non-interlaced” fields are still legible when shifted back and forth by a half line.

Forgot to add this earlier. Later versions of AmigaOS that support non-15kHz rates will promote all screens to the lowest screen mode that can suppprt all visible screen resolutions. So, if you drag a NTSC:High Res Interlaced (640x400@60i) screen down in front of a Multiscan:Productivity (640x400@70p) screen, then the front screen will also display in Prpductivity mode.

Reply on news.ycombinator.com