Hacker News Reader

Comment by weinzierl | Hacker News Reader

How do different resolutions (pixel sizes) work? I get that everything memory related (including color mode and depth) could be switched on a raster line.

In theory it should be possible to change the frequency of the video signal mid screen as well, but I have a hard time to imagine switching repeatedly every frame wouldn't have driven the monitors of the time crazy. Even multi-sync monitors needed probably a couple of frames to sync, right?

View on HN

In the context of the Amiga you didn’t need to change the signal frequency, the underlying video signal stayed the same.

For wider pixels, the hardware just drew each pixel for longer, and for taller pixels each pixel spanned more lines.

Pixels weren’t real in the CRT days :)

In a sense pixels arent even real today right? It's an abstraction

Kinda, but a CRT literally doesn’t have precise pixel targeting in the way an LCD does. Instead, you’re telling the electron gun to draw red for a little while, and it paints what it paints.

LCD and OLED panels consist of a fixed, unchangeable matrix of native pixels. (Same for the discontinued Plasma TVs.) CRTs don’t have that.

> Pixels weren’t real in the CRT days :)

True, but it gets more purely true if we add the word analog in front of CRT. While no CRT had pixels native to the display in the way LCD & LED monitors do, it's worth clarifying whether we're talking about the video signal's native traits or the display's.

Most techies today were raised in a digital video world, so they learned to think of display output as being natively digital. Many struggle to fully wrap their heads around how a natively 'non-pixel' analog video signal is even a coherent concept. Often, they'll start by conceding "Sure, I get that in the 'old days', video output was converted into analog somewhere downstream before it 'hit glass', but raster image data in a digital computer was still 'born' as discrete pixels in a frame buffer. Even if it's converted to analog for display output, somewhere there's a natively 'pixel' form of that raster, right?"

While that was true on virtually all early 8-bit computers like the Apple II, Atari 400/800, C64, etc, it wasn't always the case before that. Some early digital computers displayed raster imagery on analog televisions which never existed anywhere as discrete pixels. Instead, they synthesized each horizontal scanline as an analog waveform. While these scanlines did technically have a resolution, that resolution was expressed as frequency and bandwidth of the waveform, not pixels. The raster image never at any point existed as discrete pixels, in much the same way that early audio recordings on vinyl discs or cylinders were never discrete "audio samples."

Thus, analog video imagery from some early digital computers wasn't just a display conversion of a 'ground truth' pixel raster, no pixels ever existed. For many digital natives it can be challenging to conceptualize media that isn't fundamentally quantized into discrete digital values.

Analog monitors don't care about the dot clock. They draw lines, but you can put whatever signal you want in the lines so long as the dot clock doesn't exceed the available bandwidth. So horizontal resolution is effectively a range you can change at any time and the monitor won't even notice.

Vertical resolution is very much part of the spec, but even then CRTs will sync to hilariously out-of-spec signals that gain or lose lines per frame. Sanely-designed graphics hardware like the Amiga wouldn't do this, but the Atari 2600 wasn't sanely designed and had plenty of games that played fast and loose with NTSC. Atari graphics hardware only generated a single line of graphics and relied on H-Blank effects for literally everything else. Even the vertical retrace signal was controlled by the game. So it was very common to see badly programmed games send too many lines, and a different wrong number of lines each frame, which nobody noticed until people started writing 2600 emulators.

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?

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