If you grew up with a beige Atari ST on your desk and a faint feeling of being left out once Doom dropped in 1993, brace yourself — the ST strikes back. Thanks to [indyjonas]’s incredible hack, the world now has a working port of DOOM for the Atari STe, and yes — it runs. It’s called STDOOM, and even though it needs a bit of acceleration or emulation to perform, it’s still an astonishing feat of retro-software necromancy.
[indyjonas] did more than just recompile and run: he stripped out chunks of PC-centric code, bent GCC to his will (cheers to Thorsten Otto’s port), and shoehorned Doom into a machine never meant to handle it. That brings us a version that runs on a stock machine with 4MB RAM, in native ST graphics modes, including a dithered 16-colour mode that looks way cooler than it should. The emotional punch? This is a love letter to the 13-year-old Jonas who watched Doom from the sidelines while his ST chugged along faithfully. A lot of us were that kid.
Sound is still missing, and original 8MHz hardware won’t give you fluid gameplay just yet — but hey, it’s a start. Want to dive in deeper? Read [indyjonas]’ thread on X.
Great work. I do remember that DOOM was available on the STE (we only had an STFM, but did upgrade the RAM, but never realised that conversion had basically made it an STE so we would lament not being able to play DOOM due to our lack of understanding)
No doom no wolfenstein 3d no FPS games on Atari in the nineties.. Demo group released half finished Wolf 3D port in 2005 running at ~7 fps which is very impressive.
There was a basic FPS called Substation. It was STE only but it did exist back in 90s. There was a demo of it on ab ST Format cover disk.
Wolf has 15fps on basic ST… and we also had these first person shooters – Substation, Hellgate, Killthings, Midi Maze, Destruction Imminent. Possibly more but that’s off the top of my head:)
The closes you could get to an FPS on an Atari ST was probably the Mercenary series of games.
Resolution 101 was another.. in a ship, but still fps. Fantastic engine, and game of course
The hardware was really against it, eg. The screen RAM layout is the exact opposite of what DOOM needs.
Were they beige? My long-term memory says they were grey, and the Amiga was beige.
The Atari ST was definitely grey. Some of them even still are.
That’s the last I bthe line the Atari falcon which was on sale for less than 1 year
This is constantly being updated by Jonas. Newer video: https://youtu.be/7o7xcfmDZ_0?t=216
For a moment, I was surprised, thinking that it’s a GEM port.
Then I realized it’s just a TOS application.
Uh, why would you want to use the GEM APIs in Doom? The AES API is for UI elements and the VDI API is for vector graphics. Yes, you could use VDI to blit bitmaps, but with Doom you probably want to directly write to the framebuffer.
Because what we got here is similar (akin) to bragging about playing Doom on Windows, when it’s in reality just a DOS/mode13h version running on top of Windows.
(Or some pseudo Win16 app that bypasses Windows environment through dispdib.dll file.)
The direct-write to framebuffer strips the OS or hardware of any intelligence. It’s like bypassing the OS, altogether.
Could have been a booter game just as well.
In the Windows world, using GDI, WinG, Scitech’s WinDirect would have been a nice try, at least.
I’m writing it this way because GDI/VDI bear some resemblance.
There is no point in using a high level graphics API when the hardware is too slow even with direct hardware access. Native Windows games also (used to) directly access the framebuffer with DirectDraw.
The Atari ST’s Rainbow TOS had blitter support.
Later routines such as NVDI had better performance than stock VDI.
TOS/GEM could support ET-4000AX via drivers.. The list goes on.
The VDI calls to copy bitmaps (109 and 121) are useless for rendering textures. They can’t deform images during blitting. The blitter has the same limitation. And there is no benefit in copying the new screen contents from an off-screen buffer to the framebuffer if you can instead simply change the register with the start address of the framebuffer. There is even an XBIOS call to do that if you insist on using OS functions.
Are there any other VDI calls that you want to use to speed up Doom?
Isn’t the Amiga Doom better than the Atari ST? I always liked the Amiga more; but Commodore-Atari should have combined to survive the 90s. Quite Amazed that the ST could do it; I think only later ST models could if they have like a 68020-30 CPU.
Hi, the 68040 is fine for such things, I think. It’s roughly comparable to a 486SX.
Amiga 2000 had a CPU slot for such accelerator boards, I think.
The 68060 is a bit of a hot shot, but also an alternative.
On Atari ST side, a Mega STE is recommended in general.
It can run CPU at 16 MHz vs 8 MHz, if memory serves.
An 68010 is a simple upgrade path and can accelerate loops.
“I always liked the Amiga more”
Personally, I like the Amiga for DTP/color and the Atari ST for hi-res graphics/mono.
Bsck in the 80s, the Atari ST was like an alternative to the Macintosh, just quicker with higher fidelity.
Running MacOS (System) via Aladin/Magic Sac/Spectre128 gave access to first class software (on big screen).
It also allowed exchanging data with PC DOS platform.
I’m the guy porting DOOM to the Atari ST. I love the discussion here. Back in the day, we had a huge media discussion in Germany about the morals of video games in general and specifically first-person shooters like DOOM. I remember writing an essay at school, and actually taking the side of the moralists ;-)
Why didn’t I port to GEM (the Atari ST’s desktop)? Back in the day, the expectation for a game was to be bootable, so most of the operating system (all of GEM and most of TOS even) was avoided or disabled. Programmers accessed hardware as directly as they could, and this is something that is very appealing to me. Very different from what I do in my professional life, and very rewarding.
However, porting to GEM wouldn’t be too hard, and also kind of fun. It certainly wouldn’t help performance in any way, but why not! The cool thing with a fun project like this is that you don’t have to justify it. Just do it (TM).
Keyboard, mouse and graphics suppport would need to be changed, and the sound interrupt would need to be modified slightly in order to be compatible with TOS. Graphics is not too huge of a problem as DOOM keeps its graphics in RAM in its own format anyway.
If anyone would like to tackle this, they could branch off directly from STDOOM and I’d be glad to offer support.
In the meantime, I’ll be finishing music playback and trying to get the framerate up to playable numbers. I’m happy if STDOOM is actually playable on a 16MHz Atari ST.