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.