15

The issue doesn't arise on today's LCD screens, but on a CRT screen, because the edges are slightly curved, and you might not be able to be sure exactly how the individual screen is tweaked, it's not possible for the displayed data to exactly match the visible area; you will inevitably get some overscan or underscan, i.e. you will inevitably either be unable to see some of your data, or leave some of the screen area unused.

For business, you want (a little bit of) underscan, because you want to make sure you can see all the data; any of it might be important.

For games, on the other hand, you often actually want overscan; it looks better that way, and objects far from the player are probably not critical.

Accordingly, e.g. the NES normally overscans; if you play Super Mario Brothers, you can see landscape and enemies coming at you out of the right edge of the screen itself, with no intervening border.

The Atari 800, being designed as both a general-purpose computer and games machine, made overscan optional; a program could set the pixel width per scan line.

Both of those machines typically output to TV. I don't remember overscan being an option on anything designed to output to a non-TV monitor. They all underscanned.

To be sure, it was less of an issue on monitors, because they were more consistently calibrated, so the required underscan - amount of unused screen area - was smaller than on a TV. Still, many Amiga and PC games would've looked better with a little bit of overscan.

Did any computer allow overscan on a non-TV monitor?

Improve this question
5
  • 7
    Pretty much any non-TV monitor allowed it by just adjusting the screen accordingly, but few if any PC gamers did this intentionally to try to make their games look better. Most PC games not designed for consoles assume the entire display is visible.This was especially true in the retrocomputing era as most PC games were designed for PCs or other personal computers, and low resolutions had designers trying to cram as much information as they could on screen. Doom for example, would not look better with overscan. But even for console ports, most PC gamers would begrudge any loss of pixels.
    – user722
    Dec 22, 2019 at 20:32
  • 1
    I'm pretty sure the BBC micro did on its analogue / composite monitor output, as all that was was a TV signal prior to UHF modulation.
    – abligh
    Dec 23, 2019 at 9:01
  • @RossRidge Doom had the variable screen-size option - probably more for performance than overscan-compensation (because it didn't scale the all-important HUD bar at the bottom of the screen), though the game's menu-system was all well-within the Title-safe area - and they ported it to games consoles that definitely did have to accomodate TVs with overscan - so I dunno.
    – Dai
    Dec 24, 2019 at 1:25
  • My 2010 LCD TV (LG) defaults to overscan its HDMI inputs, producing ugly resizing artifacts. I had to disable it in the TV's settings (called 1:1 display or original ratio)
    – Jonathan
    Dec 24, 2019 at 8:26
  • Overscan is be something that would be discouraged at the time when memory was very expensive and any lost pixels off the edge of the screen would be lost money. Overscan allowed TVs to have cheap horizontal deflection that heavily distorted depending on the image intensity. VGA computer monitors have extra electronics to keep the edges of the screen nearly perfectly straight regardless of what is displayed on the screen. TV out adapters let you adjust to compensate for TV overscan but then it would look distorted seeing wavy edges on a TV screen.
    – Alex Cannon
    May 20, 2020 at 4:12

6 Answers 6

Reset to default
19

The Commodore Amiga (all models) had hardware support for overscan on CRTs. This was accessible to the user through the Preferences settings, as shown in the dialog panel below. enter image description here

The Preferences setting allows for quite a bit more screen real estate on the Workbench screen, and is quite useful for productivity apps.

For games, software control of overscan is common. For demo scene productions, it is even more common.

Additionally, the Commodore 64 supports overscan, just like the Atari 8-bit machines did. It is more commonly seen in demos than games, but games can use it if they are willing to pay strict attention to the costs incurred in terms of memory cycles available to the CPU.

Improve this answer
6
  • The majority of amiga games and demos overscan on TV. Where there any that overscan on non-TV monitor, as asked?
    – lvd
    Dec 22, 2019 at 16:14
  • 5
    Amiga overscan is present on all types of displays.
    – Brian H
    Dec 22, 2019 at 16:35
  • 1
    @lvd The question asked about computers that allowed for it, not computers where it was regularly used by games. The Amiga absolutely allows for it (regardless of TV or monitor), its just up to the programmer if they want to use it or not.
    – mnem
    Dec 22, 2019 at 22:13
  • 2
    @lvd The Amiga has no idea if the output goes to what you call a "TV" or if the output goes to what you call a "non-TV monitor", so I can't see how it would make any difference
    – pipe
    Dec 23, 2019 at 13:15
  • 1
    The C64 didn't really support overscan. Border graphics were realized by exploiting the VIC II's border mode bug and then placing sprites there. Amiga games probably rarely used overscan because chipram bandwidth was precious.
    – Zac67
    Dec 23, 2019 at 18:34
11

TL;DR;

Did any computer allow overscan on a non-TV monitor?

Every computer that allowed overscan did the same on TV and non-TV.

Computer-to-TV transmission only differs from computer-to-CRT by having the frame signal modulated onto a carrier during transmission. Modulation doesn't change any part of the payload (*1) regarding timing, which, relevant for all things cumulated under 'overscan'.

Background

Keep in mind 'overscan' is not a feature about the signal or a source, but the way it is displayed. From a display side, there is no such thing as an 'overscan'. A display only features a way of defining how much of a visible line content is really visible. Usually this setup is done external to the signal and handled manually when the display is setup.

There is as well not overscan in signal generation, as before, a line got always the same timing and thus the same amount of visible content. There is no general issue to not use all of this - except for the usual effort vs usefulness. Especially with early computer systems it is about the memory spent for image data.

It's easy to generate a full NTSC (alike) image with all content of all lines being software accessible. That's all lines and all visible part thereof. But if on average screens there are only like 80% of this signal visible (due the way it is manually set up), then why waste so much memory (and thus money) on parts not everyone will enjoy? Better fill some of the less likely displayed parts with default values and save up 20% of effort.

This even gets more important when looking at early systems whose memory wasn't enough to generate even full resolution NTSC content. Here filling a portion of the visible signal with default values not only saved memory but allowed to cramp a higher resolution with the same amount of memory.

As usual there are many ways to tackle this. And as more capable in sense of line generation a video circuit is, as more can be realized.

The Numbers

To generate a full spec NTSC (half) frame from a digital source and under full software control, a video circuit must provide some 262 lines with 660 pixel each, that's about 172,920 pixel, or 21,615 bytes in B&W (*2,3). Quite a lot in 8 bit times.

If we generate 22 of the lines (~9,5%) with default values (black) we save accordingly display RAM, cutting it down to 19,800 Bytes. Cutting of 20 pixels per line saves another 600 bytes - down to 19,200 and a total of ~11% less memory without loosing much visible on an average screen.

[Insert

And by switching to a text storage and generate this by hardware usign lookup tables, aka character generators, we get this down to at or below a manageable 2 KiB.]

Still a lot - but it worked great so far, so why not going further by reducing lines to 200 and halving doubling the pixel, resulting in 320 per line? It gets us a high resolution picture with just 8 KiB of storage needed for display data. Cool.

Except now the number of lines lines filled with default value make it look like a letterbox screen. Not cool. By making the pixels a bit smaller and increasing the default fill left and right of the generated picture we get a nice 4:3 size again.

Now, since we already fill in some parts of the frame with default values (*4), we can as well make them configurable. Looks quite like a C64 screen, doesn't it?

*1 - Living in an analogue word, it does of course reduce the payload quality.

*2 - For simplicity this is just about B&W, considering colour would lead to a way more complex consideration without changing the basic issue.

*3 - Interestingly that's roughly what the original Mac did - a bit less pixels per line (512) but a few more lines - and blacked out corners per software to allow maximum display.

*4 - It's important to recognize this filling as default value, as it's really arbitrary and doesn't have to be black - like the ZX80 already perfectly shows :))

Improve this answer
2
  • But nonetheless, the Atari 800, despite being released in 1979 when memory was a very scarce resource, did provide optional overscan, because it really was significantly beneficial for many games. So it would certainly have been feasible for the Amiga and the various PC graphics standards, having much more memory available, to do it.
    – rwallace
    Dec 22, 2019 at 13:48
  • @rwallace True, there is no technical reason to do it either way - and Atari came from (almost) total line control used with the 2600s TIA. So it's up to design requirements going the additional mile - and what they think is worth it. But discussing that would be speculation, something not really fitting RC.SE - also the question was about difference between TV and CRT (there is none), not various ways a video generation design can or should be made. Right?
    – Raffzahn
    Dec 22, 2019 at 14:15
4

From my experience using a Vectrex: it does allow "overscan" by letting the ray get out of the phosphorous area of the CRT. Sometimes that results in electrons scattering and part of the scattered electrons bumping back to the phosphorous area, making some vague spots. An example of what I'm saying is this: youtube. Note the spots at the right of the screen.

Improve this answer
6
  • 2
    A vector screen hasn't any overscan, as there are no scan lines or fixed frames at all. Also that isn't really 'scatter' but simply the beam being clipped by the deflection circuit, while the program was holding it there without cutting it off. More of using a side effect the was display is controlled to save on programming. The same intense blur is seen whenever the beam is held longer/too long at a position.
    – Raffzahn
    Dec 22, 2019 at 14:18
  • What is the way the deflection circuit clips the beam? What means are there in magnetic deflection coil that clips the beam as soon as it moves out of the phosphorous area of the CRT?
    – lvd
    Dec 22, 2019 at 16:13
  • By reaching maximum deflection voltage.
    – Raffzahn
    Dec 22, 2019 at 19:19
  • 1
    And current is controlled by the voltage applied. Isn't it? And that's what is regulated.
    – Raffzahn
    Dec 23, 2019 at 13:31
  • 1
    The deflection coils are essential inductance, so by applying a small constant voltage one can ramp up the current and magnetize the coil core up to the saturation and extreme deflection angles. Which is actually hard to achieve -- since the magnetic lines travel mostly in the space inside the coil (as to have an effect to the electrons flying inside).
    – lvd
    Dec 23, 2019 at 13:39
4

The Amstrad CPC machines came with a CRT monitor. Some games included use of the overscan area (border). For example, Arkanoid drew into the top and bottom borders to create a taller play area. enter image description here

Improve this answer
3
  • 2
    I think the CPC is a fantastic example: it uses a 6845 CRTC, so the programmer gets to set line length, how much of that has graphics, how many rows there are and row size. Furthermore the monitor uses regular PAL timings, likely being calibrated similarly. So you could paint well outside of the visible area on the RGB monitor.
    – Tommy
    Dec 23, 2019 at 20:52
  • 1
    If I can find any other games that did so, I will add them to my answer.
    – Mark Williams
    Dec 24, 2019 at 8:18
  • 2
    Donkey Kong sets up a 256-line display that is very likely to, but that’s all I can think of. Which reminds me that the BBC Micro, also a 6845 CRTC, defaulted to 256 lines at boot and the manual gave an explicit *TV command you could use to move everything down a line if the top one was outside your screen.
    – Tommy
    Dec 24, 2019 at 12:03
1

Radio 86 RK did not have any circuitry for forming the borders. These were created by writing the whitespace code (20H) inside the areas around edges that are often poorly displayed, or not at all. Only 64 characters per line were "official", while there 80 characters per line in video RAM.

Hence the "overscan" was kind of always on, and was used by some games. Supporting libraries in ROM ("monitor") had the output functions that took care of respecting the margins.

This computer used KR580VG75 (Intel 8275 clone) video controller that only provides text output, no graphics.

Improve this answer
0

The Atari 8 bit computers provided for both over and under scan.

The DMACTL register provided options for 32, 40 and 48 byte DMA. The 48 byte DMA allowed pixels in nearly all of the active display region of an NTSC scanline.

DMACTL $D400 Write SHADOW: SDMCTL $022F

Direct Memory Access (DMA) Control

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 - - Display List DMA Player Missile Resolution Player DMA Missile DMA Playfield Width Playfield Width

The 48 byte DMA mode was not entirely visible on pretty much all home televisions of the era. Flat screen type TV's did show more of the display, and PVM type displays offering an "underscan" option would display everything.

Back in the day, I manually realigned a Zenith color television to display a full frame, with the corners of the raster aligned with the midpoint of the CRT radii at the corners to see the entire raster and make use of the extra pixels. One could get a 384x220 pixel display (more possible in the Y direction, depending on how many lines one wanted to have active) on those computers using a custom screen display list and the wide DMA setting.

Doing this would slow the machine CPU down another 15 to 20 percent.

The 40 byte DMA was roughly aligned with the NTSC "Safe Area", a region defined as one nearly all TV sets would display. The need for this region came about due to the many varied CRT designs.

Finally, most composite, monochrome monitors featured width and height controls and would display overscan easily.

This was just for the "playfield". The "Player Missile" sprite objects were positioned according to "color clocks", which were one period of the colorburst. These objects could exist in the overscan by default. 40 byte DMA = 160 color clocks. There were 160 sprite "x" positions possible, aligned with the 160 color pixels possible, for reference.

Improve this answer

You must log in to answer this question.

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