8 ms·

Porting Doom to a/UX

81 points by soopurman 4y ago

Comevius 4y ago
There is a port called FastDoom that could serve as inspiration for achieving better performance. https://github.com/viti95/FastDoom 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 https://github.com/RandalLinden/DOOM-FX
- classichasclass 4y ago
  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.
- rzzzt 4y ago
  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 https://github.com/ozkl/doomgeneric
- andrewf 4y ago
  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.gas 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/phase1.c https://github.com/Olde-Skuul/doom3do/blob/master/source/pha...
  - flatiron 4y ago
    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.
tpmx 4y ago
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.
- hedgehog 4y ago
  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.
  - jandrese 4y ago
    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.
    - tpmx 4y ago
      Also: https://twitter.com/id_aa_carmack/status/1340794861050605568 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.
      - 4y ago
pinewurst 4y ago
I want to see Doom for Multics.
- kinghajj 4y ago
  Why stop there? Doom on the Analytical Engine!
- hulitu 4y ago
  I would like a DOOM for Xterm's Tektronics graphical terminals.
asveikau 4y ago
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.
avidphantasm 4y ago
In retrospect, it’s kind of mystifying that Apple didn’t merge A/UX and System 7 into a next-gen OS.
- duskwuff 4y ago
  They tried. There were multiple death-march projects to modernize classic Mac OS, like Taligent and Copland; all of them failed.
  - KerrAvon 4y ago
    Most of them weren't Unix, though. They all had unique kernels and APIs.
  - ncmncm 4y ago
    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.
- wsh 4y ago
  See this previous thread: https://news.ycombinator.com/item?id=18585922 https://news.ycombinator.com/item?id=18585922 (Briefly: licensing costs for UNIX System V.)
KerrAvon 4y ago
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.
- ncmncm 4y ago
  I used A/UX for years. I did not run COBOL.

81 points by soopurman 4y ago

There is a port called FastDoom that could serve as inspiration for achieving better performance. https://github.com/viti95/FastDoom 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 https://github.com/RandalLinden/DOOM-FX

classichasclass 4y ago
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.
rzzzt 4y ago
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 https://github.com/ozkl/doomgeneric
andrewf 4y ago
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.gas 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/phase1.c https://github.com/Olde-Skuul/doom3do/blob/master/source/pha...
- flatiron 4y ago
  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.

tpmx 4y ago

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.

hedgehog 4y ago
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.
- jandrese 4y ago
  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.
  - tpmx 4y ago
    Also: https://twitter.com/id_aa_carmack/status/1340794861050605568 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.
    - 4y ago

pinewurst 4y ago

I want to see Doom for Multics.

kinghajj 4y ago
Why stop there? Doom on the Analytical Engine!
hulitu 4y ago
I would like a DOOM for Xterm's Tektronics graphical terminals.

asveikau 4y ago

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.

avidphantasm 4y ago

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

duskwuff 4y ago
They tried. There were multiple death-march projects to modernize classic Mac OS, like Taligent and Copland; all of them failed.
- KerrAvon 4y ago
  Most of them weren't Unix, though. They all had unique kernels and APIs.
- ncmncm 4y ago
  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.
wsh 4y ago
See this previous thread: https://news.ycombinator.com/item?id=18585922 https://news.ycombinator.com/item?id=18585922 (Briefly: licensing costs for UNIX System V.)

KerrAvon 4y ago

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.

ncmncm 4y ago
I used A/UX for years. I did not run COBOL.