4 ms·

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

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.
  - tenebrisalietum 4y ago
    So this would be like making Doom run entirely with SIMD instructions?
    - jandrese 4y ago
      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.
      - classichasclass 4y ago
        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.
        tadfisher 4y ago
        It's also not really Doom, but an entirely different 3D engine made to run Doom level data.
  - cptnapalm 4y ago
    I love John Carmack.
- ac29 4y ago
  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
- ncmncm 4y ago
  An SE/30 was not especially rare or exotic.

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.
- tenebrisalietum 4y ago
  So this would be like making Doom run entirely with SIMD instructions?
  - jandrese 4y ago
    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.
    - classichasclass 4y ago
      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.
      - tadfisher 4y ago
        It's also not really Doom, but an entirely different 3D engine made to run Doom level data.
- cptnapalm 4y ago
  I love John Carmack.
ac29 4y ago
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
ncmncm 4y ago
An SE/30 was not especially rare or exotic.