This seems implausible at first: A 34 year old Unix-based platform with no previous Doom port. I spent a few minutes furiously googling this, pulling out all of my tricks. Nope. I couldn't find a previous port. Please someone else try it. There must be one, right? I want to live in universe that makes sense.
It makes a little more sense knowing that A/UX install media was hard to find for a long time, until recently (2021?) there were no compatible emulators, and a lot of the real hardware is probably too slow to run Doom or has too little memory to do the build.
Also, the real hardware was both rare and fairly expensive so the community is further restricted. I wouldn't be surprised to learn that Doom was never ported to stuff like TANDEM mainframes either.
> AFAIK, nobody ever ported Doom to run on a Cray 1. The scalar CPU should be fast enough (in 1976!) to draw 320x200, but memory would be an issue because it wasn't byte addressable -- you could only load and store aligned 64 bit values, and a max of 1M elements would be a pinch.
> You could burn instructions to shift and mask on the low order address bits, but a faster path would be to interleave 8 independent textures at different bit positions in the words, and have specialized texture mapping routines with a constant shift and mask. I don't recall ever considering that arrangement, but there may have been relevant consumer systems where doing it for 2 or 4 bit textures packed in bytes would have been helpful.
> Figuring out how to best exploit chained vector instructions for texture mapping on the Cray would be phase two.
Not entirely, but it sounds like you might need to rewrite parts of it in a SIMD manner to make it performant.
The memory thing might be an issue, but I remember Doom was ported to the SNES which only had 128kB of RAM and a 3.5Mhz CPU. While that was a heroic hack, it leaves a lot of possible overhead for a Crey-1 port with 1 million words addressable and an 80Mhz clock.
The article mentions this as a reason why this has post has likely not been done before - while 68K Mac Doom requires 7.1 and A/UX supplies 7.0.1, Mac Doom can be modified to run anyway
The only place I ever heard of A/UX was when I was the device drivers editor for TUGboat and there were some TeX DVI drivers that were available on that platform.
I wonder why the Mac port of Doom, November 4, 1994, doesn't run on A/UX in the compatibility layer, Macintosh Application Environment (MAE). If it does, then that is why.
I don't think porting DOOM is about actually wanting to play it. It's extremely doubtful that someone who wants to play DOOM is only able to do so on their A/UX machine.
A third renderer that exists is the assembly for the official Jaguar port. I think Carmack wrote it? It's staged, like a really old C compiler, because the Jaguar's faster processors could only execute programs from a tiny scratchpad memory. https://github.com/Arc0re/jaguardoom/blob/master/r_phase1.ga...
When porting to SerenityOS, Andreas used a Doom flavor that required very few platform-specific changes to make it run: https://github.com/ozkl/doomgeneric
The SFX Doom is a lot of assembly. I think the official Lion port of Doom to the Mac uses a lot of assembly too. (Heck, plenty of it in the original.) 68K isn't hard to write in, and I think any fast implementation on hardware of this spec won't be able to avoid it.
Unless you are talking about running Mac programs as separate processes directly on Unix, protected from one another.
They certainly could have worked, but would have been as different from regular Mac programs as what they did end up with. Ultimately, they had to "fail" a bunch of times before they admitted that what worked was what should ship, and shipped one of them.
total pedantry: COBOL on a Unix at that time sounds anachronistic. I'm sure it existed somewhere, but I'm pretty sure COBOL wasn't why you were running A/UX.
