14

I used played Spectrum games as a child.

According http://scanlines.hazard-city.de/ and http://www.zxdesign.info/vidresearch.shtml, the Spectrum 48K emitted 50Hz half-resolution full frames, instead of interlaced ones (also the 128K, though some reference hints it could do something sort-of-interlaced).

This suggests that the undrawn scanlines should have been visibly black or at least dimmer - but I don't remember that (blur and ghosting comes to mind rather).

Maybe it was due to the crappy Soviet black/white TV, which might had excessive luminance bleed? What is the truth, did you observe scanlines on the 48K / 128K? If not, why not (regarding the above given technical spec)?

  • I think nearly all computers of this era emitted 50Hz half-resolution full frames. You didn't see the scan lines on the TV, because OTOH the electron beam "smears" and lights up an area (with varying brightness, look at the "dot" an analog oscillopscope produces), and OTOH your visual system filles the gap between bright dots, so you don't notice them. That would apply even to video played back in this form. On a monitor with better resolution/more focused beam, you could see the scan lines. – dirkt Jun 23 '16 at 7:18
14

This may answer your question. This is my setup: a ZX Spectrum 48K and a 1084 CRT monitor. The Spectrum has been modded to output a composite signal instead of RF.

enter image description here

And this is a close-up on the picture the monitor shows:

enter image description here

So yes, the Spectrum generated scanlines, but this effect depends largely on the TV set used. My memories are also of a completely pure white screen, without scanlines or other artifacts, but I think that is just because we used to hook the Spectrum to the family TV, and the distance you normally used that TV with was far enough to have the impression of a scanless white screen.

Scanlines happen on CRT screens due to the electron beam actually tracing the scans, left to right, up to down. As the Spectrum had a (almost) progressive video signal, both fields were drawn on the same location and hence, black scans were shown between two lines. The 128K and +2A computers had an even worse (worse = out of norm) signal, which was almost progressive as well.

Curiously, I also have no memory of RF interference on the screen, when there was actually some of it, and that is just because we used to watch TV and that sort of interference was everywhere, so they passed unnoticed to us. It's many years later, with digital TV and noiseless Scart RGB connections when I have realised how crappy the original TV output was.

About TVs averaging odd and even scanlines... well, this monitor doesn't seem to do that. You can clearly see what they call "NTSC lines" followed by "PAL lines". That is: scans with correct phase (magenta), and below them, scans with opposite phase, which are shown as green (I believe).

enter image description here

Between each magenta scan and (green?) scan, you can barely see a small separation, which is the black scanline effect.

A modern (say LCD) screen doesn't do this anymore. It will show a pure magenta border (well, pure enough for a composite video signal)

  • 2
    It really strongly depends on the TV set. I remember that on a Czechoslovak black & white TV Tesla 4261A "Bajkal" we were using with ZX Spectrum there were clearly visible sharp scanlines. Later on different colour TVs the effect was much less visible. – pabouk Aug 9 '16 at 10:33
  • 2
    Black and white television sets have a smooth phosphor screen, so a solid white or gray area will appear as a bunch of horizontal stripes each of which is uniform from left to right. Color screens are subdivided into phosphor clusters which add their own "texture", generally making it hard to see the texture of the scan lines, but the uniform surface of black and white screens means the only texture visible is from the scan lines, making them very clearly visible. – supercat Nov 17 '16 at 21:56
  • 1
    Sorry, but it 100% depends on the screen, whether black and white or colour. It's a direct function of the width of your electron gun, nothing else. Given that a screen expects to paint a location once, then not paint anywhere near it again for another 1/50th of a second, the optimum is 1/312th of the height, not 1/625th. It's just that it's hard to hit that exactly. – Tommy May 25 '17 at 13:04
  • Alternating-colour lines due to hue decoding errors are known as Hanover Bars (en.wikipedia.org/wiki/Hanover_bars) and are typical of cheap TVs that want to avoid the expense of a delay line and/or patent licensing. These days, delay lines are cheap and the patents have expired. – pndc May 26 '17 at 20:19
9

Interlacing works basically by adjusting the start time of a new field (half-frame) forward or back by half a scanline in relation to the previous one. Thus either the first line is complete and the last one finishes early (after starting normally), or the first one starts late (but ends at the normal time) and the last one is complete. Literally, when it's stated as "312.5 lines per field", that's the honest truth, not an averaging of a 312 and a 313 whole-line pair. You could see it as a single extra-tall frame of 625 lines where an extra Vsync pulse is issued EXACTLY halfway down the screen.

As the main horizontal AND vertical scan circuitry is continually running, at a steady pace, and each one always resets to the same distance up or across the screen regardless of what the other does (hence the 2D rolling effects with a desynched signal), there's nothing to say a Vsync can't happen at any arbitrary point along a horizontal line... and each line is actually very slightly diagonal - its position up/down the screen at its start point is essentially the same as the end of the previous one, plus a tiny displacement caused by the flyback time (ditto the vertical, if you could make the very last and very first lines visible between an "odd" and "even" field, the last line of the odd field wouldn't be quite 1/2 length when it finished, and the first line of the even field would start a little after halfway, with a very steep, dim (as it's more spread out) line connecting those two points across the entire height of the display, with the signal structure and circuitry designed to make it all even out. And, at least for computer monitors, a minuscule little twist engineered into the orientation of the electron gun (and, for colour, dot/aperture mask) assembly, and a slowly shifting bias to the horizontal deflection, to make the lines actually horizontal but with a much steeper descent on each flyback... (without the shifting bias they would have obvious trapezoidal edges because the Vscan centreline is no longer fully vertical)

The net effect being that the second line of an even field is displaced upwards by half a field-line height compared to the second line of an odd field, because it starts half a line-time earlier compared to the start of the vertical sweep. And so is every other "even" line vs its matching "odd" line. (The first, half-length one starts at the same height as its counterpart, but it's already halfway along, so the odd line has already descended by half its full sweep height).

Naturally, with a non-interlaced scan, connected to a simplistic old school single-frequency CRT that ALWAYS deflects its beams at the same rate (ALWAYS!), and whose only sop to a not-quite-correct input scan rate is to reset the deflection to the "zero" (minus preset calibration bias) position in time with the appropriate H or Vsync pulses (so long as they're not so fast that the flyback circuitry hasn't fully charged, nor so slow that the beam has deflected way off the screen and the circuits are overcharged... by which point a safety trap circuit should've kicked in and issued an automatic unsynched flyback anyway), each field will exactly overlay its predecessor, at twice the normal rate, but with nothing at all displaying on the lines that would be taken by the other field. Hence, scanlines. The basic TV / 15khz monitor is a pretty unintelligent beast, it just looks for those particular pulses and resets when they come in, not holding a great deal of information in state re: scanrate, line count, what the current field is, etc. Most of the cleverness, including the 4-field colour sync cycle for broadcast images, is inherent to the signal instead and dealt with by what were originally very complicated room-filling machinery at the studios.

But, there are differences between the existing standards, and here I think is the root of why NTSC computer/console displays at 240p have obvious scanlining, whereas PAL ones generally do not. Or did not, should I say?

1/ Higher inherent resolution, and often smaller screens. The lines are crammed closer together by about 20%, and may themselves be smaller, which leads to a bit of physical "Kell" smearing (which for broadcast material lowers the apparent resolution by anything upto 30%) that's worse for smaller sets than large ones because the actual overshine radius stays about the same... thus is proportionally wider. If you're sitting a few feet away, a small 12 or 14 inch screen with a not particularly fine-grained mask (especially if it's a dot/cluster shadowmask rather than aperture type) simply isn't able to render each line with enough clarity at your eye for you to easily pick up on any discontinuity.

2/ PAL colour encoding, vs NTSC. This isn't relevant to RGB connections, true, but some of the cheaper ways to implement the decoding may still have been permanently active regardless of input method (certainly, when our ST's CM8833 was run in 60hz by a game that could do the switch, it seemed a lot more "liney" than might have been expected, and far moreso than at 50hz - the vertical height was increased automatically too, meaning it had at least enough intelligence to detect between the two modes, and therefore potentially change other display circuitry settings, because a truly "dumb" monitor would have shown a 320x200 image at the same size just with smaller vertical borders, and probably displaced upwards somewhat). The main method I'm thinking of here is the rock-bottom "PAL-S" mode, which relied on simple visual smearing and interpolation to produce the final colour from the two opposite-phase components that would otherwise both be the wrong colour... essentially dealing with the line-by-line colour dithering by blurring them together, partly physically at the screen, partly in the eye, and partly in a temporal (alternate flash) fashion. This is what's behind the faint "green and purple" and "red and blue" stripes seen in the closeups. Obviously, the way this works is by making each line excessively tall (either just defocussing the gun a little and accepting the blurring effect this would also have on the horizontal resolution, or increasing the amplitude of any installed "spot wobble" circuit which oscillates the vertical deflection voltage very slightly at extra-high speed (10+mhz), increasing the apparent height (and edge-softness), and slightly reducing the brightness, of each line as the gun aim jitters up and down a bit several times within one spot width's worth of sweep. Normally this would make the otherwise quite starkly different and contrasting interlaced scanlines overlap just enough to reduce the stripes to more of a faint wavering gradient pattern instead ("hanover bars"), mainly only really discernible with artificially strongly-saturated colours, and greyshades on signals with a lot of phase error, disappearing into homogeneity with a cleaner or less saturated signal. For a non-interlaced computer, it smears each actually-scanned line far enough into the unscanned region that adjoining field lines should overlap slightly (thus reinforcing each other in the very middle of the unscanned area)... and as they're double-scanned, therefore being made twice as bright as they otherwise might have been, those more dimly lit overlap areas are also considerably above black, and there's the effects of stronger phosphor overshine to consider as well.

(that said, I am a little confused at seeing those vertically-displaced hanover bars - what SHOULD happen is that each opposite-colour line is directly overlaid on top of the previous one, and so you'd instead see a very rapid shimmer effect, alternating temporally but fairly stable in the spatial dimension... and in fact if it's a baseband or a reasonably clean RF signal with no skew or other phase issues, and the monitor picks up the colourburst properly, the phase reversal should happen the same on both sides, and it would then scan the same colour for each line anyway. Colour mixing isn't an essential part of getting an accurate colour image out of a PAL set - it's merely one of its robust error-rejection features where an image tends more towards monochrome as its colour components are symmetrically displaced (NTSC lines in one direction, PAL in the other) by phase errors picked up along the transmission path, but the hue remains relatively stable. Hence no hue control on most PAL sets. So here it's maybe more likely that one or more of the colour guns isn't aimed entirely straight compared to the others? EG there might be a slight vertical mismatch between red and blue, but a bigger one between both of them and green, almost as much as a half line in fact; so in the not-quite-white background image (paper 7, bright 0), the magenta/green contrast is most obvious, as the "dark" lines are being lit mainly by the green gun, and the "light" ones by a reasonable overlap of the red and blue, with their own displacement masked by the overall brightness, and the further interference with each to produce cyan and dim yellow. On the magenta border, where the green gun doesn't fire at all, the displacement of the red and blue guns becomes more obvious, as now each not only overlap each other to make a magenta combination for the "lit" lines, but also claim a portion of the "unlit" line for themselves, forming a red and a blue stripe outline alongside; one suspects yellow would then give an impression more like white, and cyan more like magenta, with each of the three primaries having a more clearly scanlined appearance, much like the pixels on an overly coarse LCD.)

For NTSC, no such scheme is applied, as the only smoothing-out technique applied to the colour is to shift the clock a little each line and each field, which counters some of the dot-pattern effects but doesn't do anything for phase errors as it's always in the same direction and orientation. So every line is an NTSC line, there's no need to smear the colours between them, and there's fewer lines anyway so the spot wobble / gun focus is made as tight as can be got away with whilst still producing a smooth, uniform picture in full interlace. Thus when you switch into progressive, the most help you get is overshine from the inherently brighter scanlines.

A different PAL scheme is that of the acoustic (later, digital) delay line where the colour info from one field is stored directly into the start of the line, whilst simultaneously being summed with what comes out the end of it after exactly one field time's, plus or minus half a line (IE either 312.0 or 313.0 lines, because it has to be reused with a slight displacement... maybe alternating with two very slightly different lines, even), and that used as the actual colour information for the current line. Aka PAL-D. (obviously, this gives you some lines, especially halflines, where the delay doesn't work right, and you get an output line with wildly incorrect chroma... this shouldn't matter though, given that the halfline is DEEP in the blanking area, and any artefacting output would be well into overscan and not seen.)

Thing is, that doesn't store the luminance information in any way. ONLY the colour. And it still doesn't do anything for further filling in the black areas anyway, as the beam still scans over the same half-frame / single-field positions, just with more accurate, less changeable/shimmery colour now.

So, erm ...

My money is on either the sets somehow automatically switching field start position anyway in the absence of a fully accurate sync signal (counting lines and ignoring the vsync after the first few fields have got it locked in), Sinclair telling a pack of lies and the composite/RF output actually being interlaced even if the RGB isn't (it might even just be an unavoidable feature of the composite encoder / RF modulator that it adds interlaced-spec timing/sync to the incoming image data even if that means actually outputting an alternating string of 311.5/312.5 or 312.5/313.5 line frames in response to a 312 or 313 progressive input), or it simply being a misfeature of badly aligned electron guns, defocussed spots, overenthusiastic spot wobble and phosphors with leaky photon wells.

What you really need to do is either get an oscilloscope on there, or use a really high framerate slowmo camera (like, at least 100fps...) with good enough resolution that when you single-step the recording with decent zoom on the screen, it shows you clearly whether the image scans over the same place on every single field and it's down to a combination of other factors, or whether it really does interlace despite claiming not to. And do that with a variety of screens, and a couple of rival machines.

  • Welcome to Retrocomputing Stack Exchange! This is a spectacular answer, explaining the factors involved in great detail. I hope you continue to contribute to this site. – wizzwizz4 May 25 '17 at 15:55
  • No need to get a scope to see the PAL signal generated. The internals of the ULA, including the kind of TV signal it outputs, is fully documented. It outputs a progressive PAL signal of 312 scans per field, and with a non standard vertical sync signal (just a low pulse, not serrated). – mcleod_ideafix May 25 '17 at 17:27
  • Could consumer-grade acoustic delay lines delay an image by an entire frame without excess timing drift? – supercat Sep 14 '18 at 21:25
0

Scanlines seen in the topic starter's setup actually do not depend on the type of home computer he used to connect to his TV, but just on two factors:

  1. Whether his home computer was emitting true interlaced raster or 'static' non-interlaced one. For example, not only ZX but also C64 emits 'static' non-interlaced raster, but Commodore Amiga is able to work both ways -- with and without an interlace.

  2. Whether his TV or monitor has enough sharpness to see less brightened space between the light traces of focused electron ray. For example, I own NEC multisync CRT monitor for the Amiga (which is able to show both TV and VGA rasters) and when I use non-interlaced TV mode on my Amiga (like 640x256 50Hz), the scanlines are seen there very sharply. If I use some conventional home TV instead, no scanlines are visible.

  • 1
    One interesting thing with the Amiga was there was a software hack you could use to eliminate the scan lines. I used to use a program that would force it to output non-interlaced workbench screens in interlace mode, only at the same resolution (640x200 or x256) with each line of the image repeated twice. This would get rid of the scan lines without adding any flicker since every two lines were the same, so there was no contrast change between them. – mnem May 25 '17 at 17:49
0

Looks like a ground loop issue on the video line, happens a lot in audio you get that annoying hum. How to get rid of it requires a bit of trial and error. One thing to try is to plug the monitor and the spectrum on separated power points in the house. Another is to put either the monitor or the spectrum on a isolation transformer see if that works.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.