Were there any games/software that used a resolution or resolution-mode higher than what was advertised available on the machine ?

  • On home / personal computers between anytime - 1984 .
  • Without needing to plug in any additional hardware .

There may be an example for the Bally Astrocade, although I don't know any details / games / software

  • 5
    Pretty much any computer where the video controller was flexible enough to allow other resolutions was sooner or later used for such things. Even today people invent new modes, like in the 8088 MPH demo for the 1981 IBM PC + CGA (awesome youtube video, go watch it). – dirkt Nov 17 at 17:57
  • 2
    The "vapor lock" techniques on the Apple II allow mixing text / lo-res / hi-res graphics in odd ways. The Apple IIgs had a colored border that some clever demo people put text in. Not sure these are strictly in the scope of your question though. – fadden Nov 18 at 19:44

Since I know that little machine quite OK I think I'll throw my 2 cents.

When the ZX81 came out it was advertised with a character based screen of 24 lines by 32 characters, each 8x8 pixels in black and white. Of these 24 lines only 22 lines are available for user programs per default. The system variable to change this setting was documented, though.

Its character set had some special characters dividing the 8x8 pixels in 4 quadrants. This enabled some kind of "high resolution graphics" that could be generated by PLOT and UNPLOT commands giving 64 (horizontally) by 44 (vertically) "dots."

Some clever guys found out that the video signal was controlled by and in software so they wrote smart screen "drivers" that produced graphics with pixel resolution. However, due to the restrictions of the hardware it was not possible to set or reset each pixel individually.

For this a really simple modification was invented that "merged" the RFSH signal into the RD of its Z80 CPU. Now they got a high resolution graphic with 256 by 192 pixel.

Well, I had a self-built clone back in 1982 or so. But because my interests changed fast I never touched it again until the late 90s. That time I invented a graphic mode that added one level of grey to the standard black and white. Yes, that computer had no other colours!

Not only that, I also wrote a driver that extended the resolution to 320 x 240 pixel. This could be expanded still a bit more, but you need to maintain the video parameters for vertical and horizontal frequency.

Games were and are written for this machine, affectionally called "little black door-stopper," which use these screen modes. Since I never did "serious" work on it I don't know of any non-game software.

Two issues may render this story as not compatible to your requirements:

  1. For the "real" HRG (high resolution graphic) you need the mentioned little patch. However, it is built from a single logic gate. Those who know where the hot end of a soldering iron is can build it.
  2. You need more memory than the built-in 1KB (or 2KB if you use the US version by Timex) but the 16KB extension was a standard module. Almost everyone had the original or one of the countless clones.

Footnote: This cute little machine is so special that until today more than a few "oldtimers" still use it and write new software. Just search the web.

  • Aside: your username is what prompted me to write an Atari ST answer. – Tommy Nov 20 at 19:19
  • @Tommy :-) You're right, it's the ST's busy cursor. I used my beloved 1040STFM for about 15 years but never hacked the video hardware. – the busybee Nov 21 at 9:10

On ZX Spectrum there where these approaches I know of:

  1. using Border area

    the border has single color but by fast alternating it (in respect to CRT electron beam position) it can be used for rendering. Demos and even some games used it for printing some text or stuff. IIRC there was one flight simulator that used it to show the horizon cant remember its name and I think one of the first games using Border technique was Aquaplane but that is not the flight simulator mentioned before.

    The resolution increase depended on how much CPU cycles you where able to use but in theory you could use whole CRT resolution in y. In x its more rough as the CPU based memory to IO transfer bandwith was not so good so maybe every 4-8 pixels. So you would render small horizontal lines instead of pixels. Some custom tape loaders for games used that to show noise like lines instead of the common stripes ...

  2. double the scanlines

    by switching the video content every frame you could double the number of y lines due to fact that CRTs show even and odd lines in separate frames (interlacing). I do not know if any games used that (as it required quite a lot of CPU time without bank switching available) but demos certainly did that trick. Even I did code an image viewer using this technique. so going from 256x192 to 256x384 ...

  3. MultiTech

    using DMA is fast enough to apply the Border technique on the main screen area too but instead of enhancing pixel resolution it enhances attribute resolution so instead of 1 attr per 8x8 pixels you got 1 per 8 pixels instead enhancing colors. For more info see

    but this required additional HW plugged in your computer ...

On PC with VGA there where the X-modes and also UNIVBE which could increase resolutions supported by gfx card and in some cases even bit depth (not sure how I suspect dithering but it was able to use my old trident with high and true color even if it does not have any HW support for it or my mind plays tricks on me again? and there where high color support and output was truncated to it, or it was just turned off in firmware as I remember I got even few similar tridents with high/true color at that time). IIRC UNIVBE was shipped with some games directly as part of them...

  • 1
    CRTs don't even show a whole field at once; at any point in time maybe at most a fifth is emitting any light at all. They also don't actually have a concept of even and odd lines, in conformant video you're just ensuring one frame is started half a line higher or lower than the other. Persistence of vision and psychology do the rest of the work. – Tommy Nov 20 at 20:36
  • 1
    @Tommy yes psychosomatic rendering is the way to enhance visual stuff without changing HW capabilities. The best implementation I ever saw and use is The Colors of the Stars here is example of mine swift sphere combine star data – Spektre Nov 20 at 21:22

On the VIC-20, you only had character mode (22x23) but you could redefine the character set, allowing 128x128 I think (may have been less) or what looked like more if you repeated characters around the screen.

The BBC Micro had a 6845 CRTC which allowed very flexible displays and you could display 640x512i (although as this used 40K of the available 32K, some was repeated. There were also games that had wider or taller modes.

  • Some games like Super Alien selected a screen dimension wider than the C64's default 22x23. – supercat Nov 19 at 16:46
  • I also think the BBC is unlike the Amstrad CPC in that it only ever shipped with versions of the CRTC that supported interlaced output, because the SAA5050 explicitly supports it so it's worth worrying about? On the CPC, which also has a 6845 CRTC, whether interlaced mode is supported or not depends on which manufacturer's 6845 is present in the system. Amstrad, being experts at production line cost optimisation, swapped suppliers quite a few times. – Tommy Nov 20 at 19:21

For standard displays the Atari ST purports to offer at most a 640x200 pixel resolution, with a classic '80s big old border around the display. In PAL world the border is about 36% of the vertical time, which is conservatively at least 20% of the visible area, and 37.5% (/~22%) of the horizontal.

Clever programming allowed Atari ST programmers to remove the borders, increasing the total resolution.

The user doesn't get to pick the size of the viewport, or its location.

But they do get to pick their output frequency and display type — 50Hz or 60Hz for colour monitors and televisions, or ~72Hz for monochrome monitors. Which Atari had implemented in a standard fashion, e.g. for each line having a horizontal counter and a bunch of attached tests:

if(counter == 2 && frequency == 72) enable_horizontal_output();
if(counter == 13 && frequency == 60) enable_horizontal_output();
if(counter == 14 && frequency == 50) enable_horizontal_output();

if(counter == 82 && frequency == 72) enable_horizontal_output();
if(counter == 93 && frequency == 60) disable_horizontal_output();
if(counter == 94 && frequency == 50) disable_horizontal_output();

... and similar tests on a line counter, with pixels being output only when both horizontal and vertical output enables are active. Those counter values are from memory, don't quote me on them.

So, you're probably already ahead of me here but once the state machine had been reverse engineered the demo scene first managed to beat the advertised resolution by raster racing and implementing code conceptually equivalent to:


/* Just passed counter value 2; display is enabled 12 slots early! */

wait_until(counter == 13);
/* Now none of the disable output conditions were ever satisfied, so output
continued right the way across the line! */

Doing that and the vertical equivalent does what ST programmers call opening the borders, i.e. it gets rid of them. You now have a framebuffer beyond the visible screen area.

Specifically, rather than the designed (non-monitor) maximum of 640x200 you can now expand to something like 864x285, at the cost of having to race the raster.

Late demos manage to deploy the system's timers to do most of the raster racing, leaving a comfortable majority of the processing time available for animation. See e.g. Interrupt Fullscreen (link to an in-browser emulation), which conveniently starts with a fake out version of the usual hardware borders to give you an idea of scale (though it's probably border extending the more normal 320x200 4bpp graphics mode rather than the highest advertised of 640x200 2bpp; timings are the same you just distribute the fetched bits amongst pixels differently).

For a fuller discussion of the state machine see the Atari-Forum Wiki. Measurements there are at a scale of 512 ticks/scanline, mine are at a scale of 128 ticks/scanline, map appropriately. I know of this stuff only thanks to that forum, so if any of my specifics deviate from what's documented there, prefer that documentation.

Footnote 1: I'm even less confident of the specifics, but I'm pretty sure the Commodore 64 was amenable to similar tricks based on similar constraints and objectives. A counter plus a bunch of exactly-equals tests is an efficient way to design video hardware, so the same probably also applies elsewhere.

Footnote 2: the same avenue of exploration has also led to other Atari ST scenesters being able to produce things like a hardware scroll that the hardware doesn't intend to provide, but that's not really relevant to your question.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.