Retrocomputing Stack Exchange is a question and answer site for vintage-computer hobbyists interested in restoring, preserving, and using the classic computer and gaming systems of yesteryear. It only takes a minute to sign up.
Sign up to join this community
Were there any games/software that used a resolution or resolution-mode higher than what was advertised available on the machine ?
There may be an example for the Bally Astrocade, although I don't know any details / games / software
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:
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.
On ZX Spectrum there where these approaches I know of:
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 ...
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 ...
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...
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.
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:
get_into_phase_with_counter();
set_frequency(72);
wait(3);
/* Just passed counter value 2; display is enabled 12 slots early! */
set_frequency(60);
wait_until(counter == 13);
set_frequency(50);
/* 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.
