Porting Doom to a/UX | Hacker News Reader

Porting Doom to a/UX

katelibc.medium.com

81 pointssoopurman34 comments

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.

Also:

https://twitter.com/id_aa_carmack/status/1340794861050605568

> 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.

So this would be like making Doom run entirely with SIMD instructions?

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.

Well ... not quite. SNES Doom had a co-processor (SuperFX) doing the work. Even with that it had a lot of compromises to work on the hardware.

It's also not really Doom, but an entirely different 3D engine made to run Doom level data.

I love John Carmack.

The supported hardware list contains machines that werent particularly rare:

    A/UX 1.0 ~ A/UX 2.0

[ 68020 w/PMMU, 68030 ]

    Macintosh II, Rev B, with a 68851 PMMU
    Macintosh SE/30
    Macintosh IIx, IIcx, IIsi, IIci, IIfx

A/UX 3.0 ~ A/UX 3.1.1 [ 68040 ]

    Centris 610, Centris 650
    Quadra 605, 610, 650, 700, 800, 900, 950.
    AWG 60, 80, 95

An SE/30 was not especially rare or exotic.

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.

You could probably run the 68k mac port unmodified on a/ux. A/ux ran contemporaneous Mac binaries unmodified.

(Source: I have a quadra with a/ux i haven't touched in about 10 years)

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

I must have skimmed over that.

I seem to recall seeing doom on a Mac in the system 7 era, but i guess it was 7.1 or later.

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.

unix v6 - go for it!

There is a port called FastDoom that could serve as inspiration for achieving better performance.

https://github.com/viti95/FastDoom

There is also the official SNES port for the faster Super FX GSU-2 chip running at 21 Mhz.

https://github.com/RandalLinden/DOOM-FX

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.

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

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...

I think Rebecca Heineman ported this back to C for the official 3DO port. https://github.com/Olde-Skuul/doom3do/blob/master/source/pha...

And she did it in a few months! No time to get music working so someone at Panasonic got a band together and recorded a garage band redbook version.

In retrospect, it’s kind of mystifying that Apple didn’t merge A/UX and System 7 into a next-gen OS.

They tried. There were multiple death-march projects to modernize classic Mac OS, like Taligent and Copland; all of them failed.

Most of them weren't Unix, though. They all had unique kernels and APIs.

A/UX was that OS.

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.

See this previous thread: https://news.ycombinator.com/item?id=18585922

(Briefly: licensing costs for UNIX System V.)

I want to see Doom for Multics.

Why stop there? Doom on the Analytical Engine!

I would like a DOOM for Xterm's Tektronics graphical terminals.

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.

I used A/UX for years. I did not run COBOL.

I was disappointed to see the git history. A single giant commit.

She should have imported the source code unmodified as a first commit and tracked her work.

Reply on news.ycombinator.com