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

Amiga Workbench with Deluxe Paint 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)

Amiga 640x512 and 320x256 screens 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.

  • 4
    Try the DPaint screen fully visible and then drag that down to show the interlace workbench. The DPaint screen will also start flickering as soon as you do (assuming an actual setup, not an emulator that hides it)
    – pipe
    Commented Jul 12, 2022 at 14:11

4 Answers 4


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


or each one retains it own res?


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.

  • 1
    @Krackout yes, it's still the same, as by-512 resolutions use interlaced output. That is two pictures of 256 lines in succession. Nomaly the same picture (by-256) is send out twice, but in by-512 mode two different are sent, one holding all even lines the other all odd lines. For the human eye this melts into one picture. Much like with TV.
    – Raffzahn
    Commented Jul 12, 2022 at 12:08
  • 3
    Interlacing requires using an odd number of scan lines for each pair of fields, while normal video would send out an integer number of scan lines for each pair of fields. It's not possible to mix interlaced and non-interlaced video on a single frame, but the Amiga will display what would be normal windows as line-doubled interlaced video if any windows are interlaced.
    – supercat
    Commented Jul 12, 2022 at 14:43
  • 4
    To just add a little more "how" with the non/interlaced mixing, the idea is that if one of the screens on the display is interlaced, the Denise chip will switch to an interlaced mode and just double the non-interlaced screen. In other words, if you're looking at a non-interlaced workbench and you drag it down to reveal an interlaced screen, you'll start to see flicker as soon as the interlaced one is revealed. Drag it back up and the flicker disappears. Regardless, the non-interlaced workbench retains its resolution despite there being flicker.
    – bjb
    Commented Jul 12, 2022 at 14:59
  • 2
    @bjb as said, it's simplified to keep the question this side of a multi page booklet. . After all, these video tricks are what makes an Amiga the machine it is.
    – Raffzahn
    Commented Jul 12, 2022 at 18:04
  • 2
    @Raffzahn: From the monitor's point of view, there are two video scanning patterns: interlaced, and non-interlaced. While the circuitry in an analog monitor that processes horizontal and vertical deflection independently may be agnostic to the difference between the two scanning patterns, I think a good answer should recognize that interlaced and non-interlaced scanning patterns cannot be mixed within a frame.
    – supercat
    Commented Jul 13, 2022 at 14:35

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.

  • 3
    I remember futzing around writing copper lists on my A3000 back in the day, and it was great fun. It was amazing what you could tell the copper to do for you, then sit back and forget about it while the main thread used the MC680x0.
    – Geo...
    Commented Jul 14, 2022 at 14:35
  • 1
    The Copper is basically a development of the ANTIC used in the Atari machines, and the Amiga is the successor to the 400/800. Copper lists are basically identical to ANTIC Displays Lists. Same people, same concepts, five years of Moore's Law, but less money. Did you know Apple had a chance to buy them, but passed? Commented Jul 24, 2022 at 17:07

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.

  • "it lacked any concept of a "full screen" mode where a program could have exclusive control of the Copper list." - Sure it does. Just call LoadView(NULL) and then you have exclusive control of the entire video display. Of course then some OS functions (those that need do to do screen output) won't work, but you probably didn't want them anyway. Commented Jul 14, 2022 at 1:31
  • @BruceAbbott: My friend who wrote games with the Amiga in the late 1980s said that performing efficient copper updates required effectively disabling the OS, which is why games almost universally did it. Was he mistaken?
    – supercat
    Commented Jul 14, 2022 at 5:29
  • From KS2 on the OS doesn't even open a screen until Workbench loads. So yes, he was wrong. But many coders back then were used to taking over the entire machine like they did on the Spectrum and C64 etc. and didn't want to be bothered with multitasking. Kicking out the OS gives you exclusive access to all the hardware, which many coders did to get the best possible performance. Of course that meant losing all the nice goodies the OS had, but when your target is a stock A500 (that's just being used as a gaming console) who cares? Commented Jul 15, 2022 at 0:07
  • 1
    The phrase “otherwise unique to the Atari 400/800” is significant: Amiga’s graphics hardware is a spiritual descendant of the Atari 400/800’s and, ultimately, the Atari 2600’s - all three were designed by Jay Miner. Using the CPU to build a display line-by-line originated with the 2600, which had the CPU change a “playfield background” buffer on the fly. The 400 improved this with an interrupt (the Display List Interrupt) raised after N scanlines, so that the CPU could change screen-mode, re-use sprites, etc. On Amiga, you got a processor just to manage those per-line updates, freeing the CPU
    – KrisW
    Commented Jul 22, 2022 at 14:12
  • If the asterisk marks systems which “were designed to facilitate such techniques”, why does the Amiga not have the asterisk, as the entire Q&A is about the Amiga’s design to facilitate such techniques? And are you sure about C64 or EGA to be “designed to facilitate such techniques”?
    – Holger
    Commented Sep 14, 2022 at 13:58

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .