Amiga multitasking - different resolution for each program on screen dragging

Question

I'm wondering about screen resolution while having two or more multitasking programs - concurrently on screen using dragging such as:

Dpaint is on a 320x256 screen, 32 colours
Workbench is on a 640x256, 4 colours (at least 4 used, 16 is the max on this mode I think)

Dpaint on 320x256 screen, Workbench on 640x512 interlaced

Yet they are both presented.
How this works? Is there some kind of upscaling happening for the lower res program, or each one retains it own res? The former is each to comprehend, but for the latter I cannot understand how would be possible to send such a mix of resolutions to a monitor.

Answer 1

Is there some kind of upscaling happening for the lower res program,

No.

or each one retains it own res?

Yes.

I cannot understand how would be possible to send such a mix of resolutions to a monitor.

It works, as for the monitor both are the same resolution frame structure (resolution): 256 lines within a 50 (Europe) or 60 (US/Japan) Hz Frame.

TL;DR: For the Monitor 320x256x32 is the very same as 640x256x4

How about a 640x512 interlaced screen and a 320x256 [non interlaced] one?

(from comment)

To the screen that's still the very same resolution. Interlaced resolution is generated by sending out two pictures in succession, one with all even lines, one with all odd lines. The sluggishness of human perception composes both into one.

---

Analogue video signal does not know such thing as 'pixel'. It's structures as frames containing a (fixed) number of lines, all structured by timing.

Within a line the signal is not quantified into discrete objects (pixel) with discrete values (intensity, colour) but analog. That is a continuous signal of intensity and colour which may change at any rate (or not at all). The fact that a logic generating this signal is using distinct values (pixel) with certain limitations ('width' and 'number of possible colours') is neither transmitted nor of interest to the Monitor.

As long as the total number of lines within a frame is the same, the monitor doesn't care if the horizontal resolution is four pixel per line or 4k pixel. Ok, given, with 4k per line the picture may get blurry (*1) as the electronics may not follow fast enough, but that's a different story.

---

On the generator side it's similar.
(Caveat, description extreme simplified)

The Amiga's video circuit does, while generating a video line, continuously read video memory. It reads 40 bytes (=320 bit) per line for a two colour (1 bitplane) 320 pixel wide picture. For more colours more bytes (80 for 4, 120 for 8, 160 for 16 or 200 for 32) need to be read per line. In theory this is unlimited.

In reality it's limited by memory speed. This means there is an upper limit of bytes that can be read during the time available for a line. A resource shared between pixel and colour per pixel. And this is where a lower resolution comes in handy. For 160 pixel per line it needs only to read half the number of bytes (20) per line and bitplane, freeing up time to read more bitplanes, thus producing more colours.

When it comes to sending out that 'pixel' to the analogue monitor, the difference between 320 and 160 is simply that for 160 the same value is kept unchanged twice as long.

The Amiga's video generation can switch between different horizontal resolutions (and colour depths) within the duration of one line, enabling to stack areas with different resolutions on a single screen (*2). In Amiga Lingo these are called ViewPort.

Combining a 'non-interlaced' ViewPort and an interlaced one simply results in the non-interlaced lines being send out to the screen with each frame, while the interlaced one will have its even and odd lines send to alternating frames.

---

Now, if you are really interested on the Amiga side of all of this, the Amiga OS Documentation Wiki offers a quite good writeup of all details.

---

*1 - It simply smoothes out all transitions - one may think of it as analogue anti-aliasing :))

*2- Always with a blank line in-between as the first picture nicely shows, where this blanked line goes right thru the mouse pointer.

Answer 2

The Amiga uses a coprocessor called "Copper", which runs synchronous with the video output. It can be setup to write data to the custom chip registers at a specific place on the screen.

In your screenshot the hardware is set up to output the 32-colour lores screen and at the point where the Workbench screen starts the Copper is used to change the hardware to switch to hires. When you drag the screen up/down, the videoline where the Copper makes the change is simply changed.

This is a simplification of course – the Copper will do more than just change the resolution as it also changes the colours used as well as the location of the bitplane data used to make the image on the screen.

Answer 3

On most computer and video game systems from the Amiga's era and before which were capable of supporting multiple display modes, changing display modes or parameters that were made while the beam was in the middle of the frame would start taking effect at the beam's present location. If one e.g. set the background color to white every time the beam got 1/3 of the way down the frame, and set it to black every time the beam was 2/3 of the way down the frame, then the background color would be white in the middle third of the frame and black elsewhere. Such techniques have been by at least one program or game on each of the following systems. The systems marked with an asterisk were designed to facilitate such techniques; on those not marked, the technique may not have been part of the machine's design intention, but was used by at least some programs back in the day. I don't know whether the NES was intended to facilitate such techniques, but many games do in fact use it.

• Atari 2600(*)
• Apple II family
• Atari 400/800 family(*)
• Magnavox Odyssey 2
• Commodore VIC-20
• Commodore 64(*)
• IBM PC Color Graphics Adapter
• Apple //gs (*)
• Nintendo Family Computer (Famicom)/Nintendo Entertainment System (NES) (*?)
• IBM PC Enhanced Graphics Adapter(*)
• Commodore Amiga(*)

What makes the Amiga unique compared with other machines on that list is that not only does it provide hardware assistance for mid-screen mode switches without CPU intervention (a feature otherwise unique to the Atari 400/800 and Apple //gs) but its operating system understands the concepts involved and can automatically merge the screen mode-change lists ("Copper lists") among programs that are simultaneously using different parts of the screen. This was a very cool feature, hampered unfortunately by the fact that while it could handle programs that used multiple screen modes, the algorithms it used were not designed to efficiently work with large numbers of mode changes and--from what I was told in the 1980s, it lacked any concept of a "full screen" mode where a program could have exclusive control of the Copper list. Many Amiga games exploited the ability to have hundreds of parameter changes per frame with a continuously modified list (e.g. changing one of the palette entries in a downward scrolling blue pattern) but the OS couldn't change individual entries within a list without re-merging all programs' lists into a single master list--an action which would take multiple frames to perform. The only workaround was to effectively disable the OS entirely while taking control of the screen hardware.

Answer 4

When you see the Amiga displaying multiple video modes simultaneously, they’re separate “graphics modes” from the perspective of the graphics chip but still just a single video mode from the perspective of the (CRT) monitor or TV (which only cares about the timings of the video signal and not its content).

The Denise graphics chip, aided by the Copper co-processor, juggles between different framebuffers and color and pixel clock modes (140 ns for Lo-Res pixels, 70 ns for Hi-Res pixels), switching such parametrization on the fly, mid-refresh, so that you see different content and differently-shaped representations of pixels with different color palettes on different spans of scanlines.

Timing-wise, however, the video raster remains stable: regardless of the pixel clock and color mode that is active in an individual Intuition “screen”, all scanlines are still of the same total length (in microseconds), and each vertical refresh contains the same number of scanlines, and the horizontal and vertical sync pulses appear at constant intervals, meaning that the horizontal and vertical refresh rates remain constant. The monitor does not see any difference between a view that displays a single full-screen graphics mode and a view that contains multiple overlapping Intuition screens with different pixel clocks and color modes.

Traditionally, the Amiga could only generate two types of a video raster: a broadcast TV-compatible, 15 kHz interlaced mode and a non-interlaced (progressive) variant of the same. The latter would omit the so-called “half lines” and give a stable (non-jittery) picture, but with only half the apparent vertical resolution.

If one of the simultaneously displayed Intuition “screens” is in an interlaced graphics mode, the entire generated video raster for all the visible content will be switched into interlaced scanning mode — that is, half lines will be enabled in the signal generated by the video chip. Everything else remaining constant, this is such a minor change to the timings it will not cause any visible re-syncing effect; you’ll just notice the horizontal details will start jittering due to the half-line positional (and timing) difference between each vertical refresh.