Most home computers and videogame consoles of the 1980s were designed to output TV-compatible analog display signals. This allowed existing televisions to be used, rather than requiring the expense of dedicated monitors.

On an analog CRT (cathode ray tube) TV, an electron beam "paints" each line left to right, top to bottom. When the beam "jumps" from the end of a line to the beginning of a new line, or from the last line back to the first line, mechanisms called "horizontal blanking" or "vertical blanking" ensure that nothing is displayed. To a normal eye, phosphor persistence is enough to make the resulting images look like a smooth series of "still" frames, rather than a flickering set of lines or interlaced half-images.

Worldwide, the two main standards for analog TVs were NTSC (North America and parts of South America) and PAL (Europe and other regions). The two systems are also referred to as 525/60 and 625/50, with reference to the respective total number of scanlines (including hidden ones) and interlaced half-picture refresh rates (which originally matched the electrical power-line frequency).

Out of the total number of possible scanlines (i.e. 525 or 625), a small number was reserved to be hidden in order to allow the electron beam to return to the top of the screen without displaying a trail during the "vertical blanking interval". In the NTSC system, 39 lines out of 525 are reserved for the vertical blanking, leaving 486 lines for TV content. In PAL, 49 lines out of the total 625 are reserved, leaving 576 lines available. (Which is slightly simplified, as in practice the analog beam used to take a shorter path, from the middle of the last line to the middle of the first line, but for digital processing both are counted as full lines. )

Some of the (invisible) reserved lines were later used to broadcast teletext data and for other purposes. Additionally, digital systems (e.g. analog-to-digital conversion devices, computers, cameras, etc.) could modify the numbers slightly to fit different needs, e.g. rounding up to an even number, or to a multiple of 16.

To summarize the vertical blanking lines (all values are interlaced lines, i.e. twice the non-interlaced numbers):

• The NTSC standard reserves 39 lines for vertical blanking, which the Amiga rounds up to 42 (source: NTSC Agnus datasheet)
• The PAL standard reserves 49 lines for vertical blanking, which the Amiga rounds up to 52 (source: PAL Agnus datasheet)
• The Amiga Hardware Reference Manual states that "Vertically, the restrictions are simple. No data can be displayed in the vertical blanking area."

The visible lines are obtained subtracting the vertical blanking values from the maximum values set by the NTSC or PAL standard:

• NTSC (total of 525 lines): 486 lines are available in the visible portion by the standard; since the Amiga uses 42 rather than 39 lines for vertical blanking, this leaves 483 lines, which are rounded up to 484
• PAL (total of 625 lines): the standard sets a maximum of 576 visible lines; this is also the number of lines that the Amiga processes (625-52=573 which rounds up to 576)

Horizontally, it should be kept in mind that as long as the lines in a TV are processed as analog data, there can be infinite nuances within a line, i.e. in an analog system there are lines, but no "pixels". As video entered the digital era, it became necessary to agree on a "horizontal resolution". In practice, for most video-related needs, the horizontal resolution varies between 704 and 720 pixels depending on the requirement (DVD, VHS to digital conversion, etc.)

Considering that a CRT scanline has a total duration of 64 µs (i.e. 0.000064 seconds), of which 12 µs are needed for the horizontal blanking, and that in the PC industry a rate of 14.7692 MHz is used to obtain square pixels on a 4:3 monitor, a theoretical maximum of 768 horizontal pixels can be calculated from these values (52 µs * 14.7692 MHz).

On the Amiga computer, the timing of a pixel was defined as 140 ns for Lores modes, 70 ns for Hires, and 35 ns for Super Hires. Dividing the duration of the visible duration of a scanline (52 µs) by the duration of a single pixel thus results in 742 Hires pixels that may be visible on a standard-compliant NTSC or PAL TV. While some Amiga components can in theory process 768 (Hires) pixels per line, extensive practical tests (source: Toni Wilen) have led to the conclusion that no more than 752 pixels can be rendered horizontally in Hires modes. This also includes the maximum boundaries of sprites and copper effects.

To recap all of the above and apply it to Amiga emulation, using Hires interlaced units the maximum possible screen sizes are:

• NTSC: 752x484
• PAL: 752x576

In Amiga Lores modes the pixels were twice as wide (similar to a C64 computer) and in Super Hires mode they were half the width of Hires pixels.

Translated to Lores, non-interlaced units, i.e. a resolution commonly used for games, the above maximums are:

• NTSC: 376x242
• PAL: 376x288

Internally, within the RetroPlatform architecture (and in the RP9 data), the units used for offset and clipping values are always in the highest precision (to allow for any resolution), i.e. Super Hires, interlaced:

• NTSC: 1504x484
• PAL: 1504x576

When describing Amiga clipping offsets, these units are always relative to a starting position which starts on the first line from the top after the vertical blanking offset (42 interlaced lines for NTSC, 52 for PAL), and considering a left offset of (768-752)/2=8 Hires (16 Superhires) "unused" pixels. So, regardless of how "unusual" a screen mode may be (e.g. "72" modes), these top and left minimum offsets are considered constant.

For digital modes (e.g. VGA), including Amiga RTG modes, the RetroPlatform units are 1:1, i.e. there are no internal offsets and no multiplication factors. All values are always exact pixels. This is also the case for systems like the C64.

The Amiga further constitutes a good test case because it was designed with the ability to not only switch between non-interlaced and interlaced modes, but also to output multiple resolutions in the same view. For example, a Lores screen could be dragged down to partially expose a Hires screen. In such a scenario, for emulation and screen grabbing purposes, the higher resolution "prevails", i.e. the bitmap is saved in the higher of the various resolutions.

Additionally, since some low-level Amiga settings can be software-modified, and some features can be reprogrammed on the fly while the video beam is moving, the Amiga presents an additional variety of "non-standard" cases. For example, the game Dynablaster uses a CPU-controlled screen refresh (by writing to the VPOSW register), while the game BC Kid sets a 57 Hz refresh rate that is neither NTSC nor PAL.

Unlike on systems like the C64, which had a fixed addressable screen size, the fact that the Amiga allowed for such numerous variations in screen modes, sizes and visible content offsets, resulted in a potentially annoying diversity. It was not uncommon to have to adjust some monitor position or size settings between one game and another, in order to fully display and keep centered the intended content. This was also because larger bitmaps involved higher CPU loads for rendering, so many games had to reduce the resolution in order to achieve higher content update rates. Often, game title screens were displayed in Hires modes, and the actual game was in Lores mode.

Out of the maximum Hires resolution of 752x484 for NTSC and 752x576 for PAL, Commodore-Amiga gave recommendations for different practical overscan values:

• "Text" overscan was the minimum, and was defined as 80 columns by 25 (NTSC) or 32 (PAL) lines of text (using 8x8 pixels per character), i.e. (Hires, non-interlaced): 640x200 (NTSC) or 640x256 (PAL)
• "Standard" overscan was a custom setting that could be adjusted by the user, and was described as "just out of view"
• "Maximum" overscan was defined as the largest area that the Amiga graphics.library could handle "comfortably", i.e. with smooth scrolling and with a full range of supported operations on any region within this rectangle. This was (Hires, interlaced) 724x482 for NTSC and 724x566 for PAL.
• "Video" overscan was defined as the maximum that could be displayed by the graphics.library, comfortably or not. It was documented as "This region is typically out of sight on any monitor or TV, but provides our best shot at 'edge-to-edge' video generation." In Hires interlaced units it was 736x482 for NTSC and 736x566 for PAL.

So even the most extreme "Video" overscan defined by Commodore-Amiga fits comfortably within the maximum values we obtained from theoretical calculations and practical metrics, and which are used in the RetroPlatform framework for Amiga emulation.

RetroPlatform further introduced the ability to "clip" the display area in order to provide a more appealing visual experience (by reducing the frequently large surrounding blank area and keep the content centered) and also to not waste unnecessary computing resources on the rendering of invisible parts.

For example, the numbers and units outlined so far are exposed in the Screen Clip configuration options of Amiga Forever (right-click a title, select Edit, then the Configuration tab). In these settings, the leftmost offset always starts from 0, while the top offset also takes into account and exposes the different NTSC and PAL vertical blanking interval (if this were not the case, the numbers might "jump" inexplicably when switching between NTSC and PAL). Internally, in the RP9 file format and at runtime, the values are further adjusted to meet the need of different emulation engines. The "0" left offset is actually written as "112" in the RP9 <clip> values (i.e. there is abundant margin for future expansion), and becomes "368" to WinUAE. Both are Super Hires values, and are the result of a simple addition (+112 for RP9 and +112+256=368 for WinUAE). No corrections are applied to the top offset, and to the width and height values. WinFellow has an internal offset correction.