News Doom slithers and dithers its way with a 16-color Atari ST port

But ... which CPU would you need to upgrade it to make it run at a near-acceptable frame rate?
A 8 MHz 68000 that the ST came with stock is relatively slow.

There has been a port to the Atari Falcon 030 back in 030. It took advantage of chunky video modes.
Otherwise, the classic 16-colour Atari ST (and STe) suffers from the same limitation as the Amiga: bitplane graphics, which makes drawing a single pixel column at a time very slow.

The common approach is to draw into a "chunky" pixel buffer and then do a chunky-to-planar pass. That pass could take half the CPU time. On the Amiga, there are techniques for using the Blitter to speed that up a little, but the stock ST does not have one, and I'm not sure that the STe's blitter could be used for that.
 
Last edited:
Hah, nope. Pixels were elongated. 4:3 screens.
*Wrong. Both low (320x200) and High (640x400) resolutions used square pixels; the resulting output was a letterboxed display.

Medium resolution (640x200) was the oddball.

(Source: I own a 1040 STe)
....

EDIT: I clicked on the X link and read the comments. Doom is NOT running on a stock ST - it is running on an emulated ST with 14 megabytes of RAM at an unspecified accelerated speed. Sure, you could by '030 accelerator boards for the ST with their own RAM, but they were far from commonplace, so until Eschenburg gets Doom running on an 8 MHz 68000 with 4 megs or RAM or less, I'm calling BS on this.

Tom's should amend the headline to reflect that Eschenburg is running Doom on a phantom Atari ST.
 
Last edited:
  • Like
Reactions: blppt
*Wrong. Both low (320x200) and High (640x400) resolutions used square pixels; the resulting output was a letterboxed display.
On most 8- and 16-bit computers and video games -- which output to analogue TV signals, pixels were never perfectly square like they are on VGA monitors.
Hardware was often made with the pixel clock in sync with the clock of the chroma signal in a composite signal so as to avoid colour artifacts on TV.s This was used to clock the video chip, and was often multiplied all the way up to the CPU's clock: thus making the CPU run at slightly different speeds in NTSC and PAL territories.

I think each NTSC pixel is slightly higher than it is wide, and the other way around for PAL (which has higher vertical resolution).

Computer monitor for these signals however, often had knobs that you could turn to stretch the image as well, and people did turn them to make the image fill the screen.
 
Last edited:
On most 8- and 16-bit computers and video games -- which output to analogue TV signals, pixels were never perfectly square like they are on VGA monitors.
Hardware was often made with the pixel clock in sync with the clock of the chroma signal in a composite signal so as to avoid colour artifacts on TV.s This was used to clock the video chip, and was often multiplied all the way up to the CPU's clock: thus making the CPU run at slightly different speeds in NTSC and PAL territories.

I think each NTSC pixel is slightly higher than it is wide, and the other way around for PAL (which has higher vertical resolution).

Computer monitor for these signals however, often had knobs that you could turn to stretch the image as well, and people did turn them to make the image fill the screen.
That may be the case for systems that used composite output exclusively, but I always used the computer using the component RGB output, and the pixels were not noticeably rectangular, medium resolution excepted.

To the best of my knowledge, an unmodified ST ran at 8 MHz wherever it was sourced, PAL or NTSC. It could, coupled to the right display, do PAL 60.

You are right you are right that you could stretch the display - in fact, PAL 60 did just that and you had to adjust the display to compensate. BUT... it did not elongate the pixels; PAL 60 increased the gap between scanlines (until you corrected for this).