Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Let's compile Quake like it's 1997

fabiensanglard.net

Post reply on HN
Print view View original

11–20 of 91 posts

Re: Let's compile Quake like it's 1997

#11

Post by Sesse__ »

kelnos wrote: post #6
clarity_hacker wrote: post #3

[flagged]

> The detail about needing to reinstall Windows NT just to add a second CPU shows how tightly coupled OS and hardware were — there was no abstraction layer pretending otherwise. In this case there was: the reason you need to reinstall to go from uniprocessor to SMP was because NT shipped with two HALs (Hardware Abstarction Layer): one supporting just a single processor, and one supporting more than one. The SMP one h…

> If they'd packed everything into one HAL, single-processor systems would have to take the performance hit of all the synchronization code even though it wasn't necessary. Memory usage would be higher too.

Linux also used to be like this, but these days has unified MP/UP kernels; on single-CPU systems (or if you give nosmp), the extra code is patched away at boot time. It wouldn't have been an unheard of technique at the time.

Re: Let's compile Quake like it's 1997

#13

Post by boznz »

On one particular project from 1995 where the hardware was very cost optimised, the C program compiled to 1800 bytes which meant we could save nearly a dollar by buying micro-controllers with 2KB flash rather than 4KB flash. We manufactured 20,000 units with this cheaper chip. 2 years down the line we needed a simple code change to increase the UART baud rate to the host, a change that should have resulted in the same sized binary, but instead increased it to 2300 bytes due to a newer C compiler. We ended up tweaking the assembly file and running an assembler, then praying there would be no more changes!

I have always over specified the micro-controllers a little from that point, and kept a copy of the original dev environment, luckily all my projects are now EOL as I am retired.

Re: Let's compile Quake like it's 1997

#14

Post by qingcharles »

knorker wrote: post #5

> The first batches of Quake executables, quake.exe and vquake.exe were programmed on HP 712-60 running NeXT and cross-compiled with DJGPP running on a DEC Alpha server 2100A. Is that accurate? I thought DJGPP only ran on and for PC compatible x86. ID had Alpha for things like running qbps and light and vis (these took for--ever to run, so the alpha SMP was really useful), but for building the actual DOS binaries, su…

I thought the same thing. There wouldn't be a huge advantage to cross-compiling in this instance since the target platform can happily run the compiler?

Re: Let's compile Quake like it's 1997

#15

Post by travoc »

boznz wrote: post #13

On one particular project from 1995 where the hardware was very cost optimised, the C program compiled to 1800 bytes which meant we could save nearly a dollar by buying micro-controllers with 2KB flash rather than 4KB flash. We manufactured 20,000 units with this cheaper chip. 2 years down the line we needed a simple code change to increase the UART baud rate to the host, a change that should have resulted in the sam…

"luckily all my projects are now EOL as I am retired."

I doubt that everything you ever worked on is end-of-life. Some of it is still out there...

Re: Let's compile Quake like it's 1997

#16

Post by direwolf20 »

Visual C++ 6 was the first C(++) compiler I used. I'm fairly certain it had auto completion (Intellisense).

Casey Muratori would point out the debugger ran faster on hardware from the era than modern versions run on today's hardware, though I don't have a link to the side–by–side video comparison.

Edit: Casey Muratori showing off the speed of visual studio 6 on a Pentium something after ranting about it: Jump to 36:08 in https://youtu.be/GC-0tCy4P1U — earlier section of the video is how it is today (or when the video was made)

Re: Let's compile Quake like it's 1997

#17

Post by 7thpower »

travoc wrote: post #15
boznz wrote: post #13

On one particular project from 1995 where the hardware was very cost optimised, the C program compiled to 1800 bytes which meant we could save nearly a dollar by buying micro-controllers with 2KB flash rather than 4KB flash. We manufactured 20,000 units with this cheaper chip. 2 years down the line we needed a simple code change to increase the UART baud rate to the host, a change that should have resulted in the sam…

"luckily all my projects are now EOL as I am retired." I doubt that everything you ever worked on is end-of-life. Some of it is still out there...

Better have kept those environments.

Re: Let's compile Quake like it's 1997

#18

Post by boznz »

travoc wrote: post #15
boznz wrote: post #13

On one particular project from 1995 where the hardware was very cost optimised, the C program compiled to 1800 bytes which meant we could save nearly a dollar by buying micro-controllers with 2KB flash rather than 4KB flash. We manufactured 20,000 units with this cheaper chip. 2 years down the line we needed a simple code change to increase the UART baud rate to the host, a change that should have resulted in the sam…

"luckily all my projects are now EOL as I am retired." I doubt that everything you ever worked on is end-of-life. Some of it is still out there...

Correct, I have thousands of tank temperature controllers still out there, still working fine where the End Of Life was 3 years ago. EOL just means support for spares and software updates cannot be guaranteed past that point, and is mainly tied to the EOL of the specific micro-controller used.
Post reply on HN