Vintage computing for fun and [no] profit

[MartinHowe]

Thanks, I'll look into that. The reason for 2.7 was simply to get a reasonably modern one without going too far ahead; I'll check into what libuv needs.

[Blzut3]

I think you're getting your version numbers backwards (both in that post and your previous one). 2.7 is what Lenny shipped with isn't it. I assume you mean you installed 2.27? Not that it matters why you chose 2.27 but since you said "not going too far ahead," I'm somehow more curious as to how the arbitrary stopping point of 2.27 is not "too far ahead." I'm guessing you got that number from Linux Mint/Ubuntu 18.04?

Anyway, I do think you'll have better luck going to something like 2.12 which CentOS 6 uses. Just looked it up and apparently that's the minimum as well. Probably not a coincidence. Looking at what versions RHEL/CentOS uses is usually a pretty good place to start since RHEL is well supported and has a 10 year support cycle vs the usual 5 for LTS distros.

[MartinHowe]

What is confusing me is the version numbering; thanks for pointing this out.

I think I was confused by the lack of a strict n.nn.nn with leading zeros in all fields; having sorted the ftp listing by date, it makes sense now. I must remember that the middle field is not fractional but an integer where single digits have no leading zeros.

[MartinHowe]

In light of my experiments with getting Doom on an AlphaServer 5303, it was freaky to find there was actually a laptop using AXP - the Tadpole AlphaBook.

It was a ruggedised laptop used by salespeople and field engineers, kinda like a Panasonic ToughBook, but with a minicomputer-class CPU, a 520MB HDD and 128MB of RAM, which was an insane amount for 1994 when PCs used for Doom usually had only 4 or 8. Needless to say, it was expensive, at launch it cost around $14,000! There's even a docking station for one on eBay at time of writing It has OpenVMS and X, so probably *would* run Doom, as PrBoom was been ported to OpenVMS

Video on Vimeo: https://vimeo.com/29546476

Vaxbarn video:

[MartinHowe]

Time for another progress report. After a lot of trial and error, I have reinstalled everything, and used my experience to know what to build from source, what can be trusted (at least for now) from the system's packages and tamed the network.

TL;DR: I have now got a reasonable working system, with critical apps and subsystems up to date, on top of a recent kernel (5.11.1) and all built with a recent GCC (10.2.0).

Firstly, the fsck vs clock issue

The system clock battery is wearing and fsck (equivalent of chkdsk) is very fussy about the write time, mount time, last check time being in the future or past, and forces a full filesystem check on boot, even if the filesystem is not tagged dirty. I bought a genuine modern(ish) Dallas type chip, but it's not as compatible a replacement as they claimed; the original is a genuine Dallas (not Maxim) DS1287A and while they are available in the UK, at around £45 including VAT ('sales tax' to you yanks ), think I'll pass. I have toyed with cutting open the case and hot-wiring the battery as it seems easy enough to do; I do run an electrical workshop for a living and the woodwork shop downstairs are only to happy to let me borrow their tools.

But in the end, I don't really need a real-time clock and the rest of the system settings are in an NVROM on the motherboard anyway. The config file option in fsck to ignore the time when deciding to do a full check has been ignored for years, a bug only fixed in a recent release of the filesystem tools; so I built e2fsprogs from source and it now works fine. It only needs to work until ntpd starts, after which the system clock (Linux clock, not the RTC clock) is updated from the internet. This also involved building a few other things, including coreutils, which for some reason totally escaped me in my list of critical things to update

Secondly, the Gnome Network Manager
On the new kernel, this continually causes alignment traps (wonder what special sauce the EV4 kernel in Debian 5 for AXP was spreading on Network Manager ); after spending a day getting it and its crapton of dependencies either installed or built from source, despite I might add the several bugs in the autogen script, it no longer has an issue, but still has trouble getting a DHCP lease. Since the system dhcp client and it's CLI app have no such trouble and I don't expect to be carrying the server into a Starbucks to poseur with it on WiFi, I've reverted to the system package of network manager ... then disabled the bastard! Thank ${DEMON} the self-build Makefile for GNM includes an uninstall target or I'd be really pissed off!

General stuff
I have built openssl, curl and wget and installed the latest ca-certificates from the sid repository (which they 'nicked' from Mozilla Firefox, LOL); so now I have working SSL & TLS. Most of the system apps were build against the ancient versions that came with the system, so I need to build each as required. The only thing I really want now for networking is a GUI web browser, but it is a nightmare finding one that's functional enough to be useful but doesn't have a ton of dependencies or a custom build system that was designed when sky-high on crack The most promising one so far is NetSurf but even that has trouble building. It's not essential, so I've stopped for now, but may try again later.

Next steps

I need to build CMake, as most current Doom source ports depend on it. Perhaps git too, the one in the Lenny repo is as old as Moses and has issues. If I can avoid updating glibc I will, as that's always fraught with danger. After that, or maybe before, I really must try and port Nouveau to AXP. With an EV56 CPU, i.e. one that can do efficient BYTE/WORD/DWORD memory access, there's no theoretical reason why this couldn't be done, indeed for any architecture. I really would like at least Dr Frag's *ZDoom stuff running in accelerated mode on the GF 8400 GS, if not full-fat GZDoom itself.

But now, I need a break!

[MartinHowe]

Speaking of power, do you know how much wattage your Alpha uses?

You know, I never measured it; however it uses around £1 worth of electricity if left on for a typical weekend day's effort (around 12 hours) so it's not too expensive to run. It does keep the big main room warm at night; the building I live in was refurbished a few years ago, in fact just before I moved in, and so the thermal insulation is very good - if I leave the AlphaServer on overnight for a long build job, I don't need to put the central heating on in the morning

[MartinHowe]

Interim progress report. Have now got Woof! 6.0.0 and chocolate-doom 3.0.1 up and running. Both of these and the entire SDL2 library set, including their dependencies, built for EV56 using gcc 10.2.0. They are still slow as mud to begin with, but when exporting the SDL software renderer thing before running, run a lot faster than they did before; they are actually playable

They are about as fast as a Pentium on an old DOS system, and that with the Gnome/GLX overhead; if I could build an old-school Linux Doom for direct FB access from single-user mode, they should be faster than original DOS Doom. How much faster, I don't know, as much of the Pentium's speed was due to IP ripped off from Alpha before Intel bought it (for which Intel got sued by Digital LOL).

[Blzut3]

Interim progress report. Have now got Woof! 6.0.0 and chocolate-doom 3.0.1 up and running. Both of these and the entire SDL2 library set, including their dependencies, built for EV56 using gcc 10.2.0. They are still slow as mud to begin with, but when exporting the SDL software renderer thing before running, run a lot faster than they did before; they are actually playable

Nice. Any chance you could post -timedemo results for the curious?

[MartinHowe]

Sure. Windowed, 640 x 480, Gnome is 1280 x 1024, doom.wad, demo 1:

Woof does 15.1 FPS. So playable, but still slow. If music is disabled, which is how I normally play games anyway*, it improves to 22.1. Chocolate Doom is about the same. These figures improve to around 36 fps when run with music at 320x240 like in the good ol' days

*Music in FPS games is really a hangover from the earlier games; let's face it, I don't think Bobby Prince was sat on top of a tower overlooking the UAC base with a synth and a boombox while Doomguy was fighting demons

I think I'll have to spend some time on getting a single-user framebuffer-only variant to work. lxDoom looked promising, but the library it needs is full of the usual early-version alpha-isms (can't find <asm/whatever.h> etc) and doesn't directly support the Permedia card specifically anyway (though it does the generic fbdev driver). The biggest problem with just about everything alpha at low-level is handling page mapping and virtual memory assignments; all the alpha systems seem to do it differently, which is why each needs a specific memory driver when using milo (basically LILO for AlphaBios). I'd have to learn all this to get any chance of making Nouveau work on alpha, anyway.

I suppose learning Alpha assembly language and getting my hands dirty that way might help. Maybe port some of the FastDoom stuff for 486s.

Or recompiling everything with -O3 and praying to ${DEMON} that it doesn't crash and burn

EDIT: I just realised that RelWithDebInfo for Woof! uses -O2 Surely all DebInfo is supposed to do is keep symbols? Then again, given what -O3 does to a program, maybe it doesn't So I'll build release Woof! and do whatever's needed to build the chocolate family with -O3, then see what happens. SDL2 itself is -O3, so that won't make much difference. I'll leave the other libraries (mostly -O2) alone for now. Let's see what happens.

EDIT2: For Woof! it doesn't make any difference! So I guess it has to be the framebuffer transfer that is the biggest overhead after music.

[Blzut3]

Or recompiling everything with -O3 and praying to ${DEMON} that it doesn't crash and burn

O3 is basically telling the compiler "assume that this program doesn't rely on undefined behavior." I know some C people think that O3 is super risky, but O3 is the default for Release on CMake and a lot of programs use CMake. I think we may have run into one misoptimization with ZDoom one upon a time, but for the most part if O3 exposed a bug I was able to trace it to a standards violation. Usually the culprit is auto-vectorization since the code it generates depends on the memory alignment guarantees the standard assigns to types. Yes, turns out that matters even on x86.

Of course by now the Alpha support in GCC is likely not very well tested so who knows if there are more bugs there.

EDIT: I just realised that RelWithDebInfo for Woof! uses -O2 Surely all DebInfo is supposed to do is keep symbols?

Well the shocking thing for most people is that for some reason CMake uses O2 for RelWithDebInfo and O3 for Release. Shouldn't RelWithDebInfo be Relase with debug info? Anyway you can turn on debugging symbols at any optimization level it's just a matter of how useful that debugging information is. Ultimately if you're debugging an issue that only happens with optimization some debug symbols is better than none.

SDL2 itself is -O3, so that won't make much difference. I'll leave the other libraries (mostly -O2) alone for now. Let's see what happens.

Usually the gains from O3 are anywhere from marginal to none. With significant improvements and negative improvements being outliers. Certainly doesn't hurt to try, but not expecting much.

[Graf Zahl]

Well the shocking thing for most people is that for some reason CMake uses O2 for RelWithDebInfo and O3 for Release. Shouldn't RelWithDebInfo be Relase with debug info?

Yes, it should. I have no idea what the CMake guys were smoking here, but if this doesn't allow debugging an actual release build the option is useless. In GZDoom I at least changed it for Windows to produce identical output - and this option has indeed helped a few times to track down bugs.

[Chris]

Well the shocking thing for most people is that for some reason CMake uses O2 for RelWithDebInfo and O3 for Release. Shouldn't RelWithDebInfo be Relase with debug info?

Depends if Release includes any optimizations that makes debugging effectively impossible. You can never truly get a build that's exactly like Release but with debug info; the whole observer paradox or heisenbugs do rear its ugly head, where adding any amount of tooling to better track the program's behavior can change the program's behavior. RelWithDebInfo is effective at what it does, it enables the vast majority of optimizations for a release build, but still ensuring debugging is possible. One could argue Release shouldn't use -O3 by default, since as you say, the gains over -O2 is marginal to non-existent in most cases, and in some cases can actually make performance worse. It may be wiser for a program to opt-in to -O3 optimizations when it knows they're helpful.

What annoys me about RelWithDebInfo is it uses NDEBUG, which disables asserts even though they're specifically for debugging, to ensure behavior that shouldn't happen didn't.

[Graf Zahl]

That reasoning makes no sense. Yes, release builds are hard to debug, but what's the point of a compromised build when having to debug a problem that only occurs in release builds?
The main reason why release builds need to be debugged is either uninitialized menory or optimization issues. For that you need a release build with as much debug info as possible, not some Frankensteinian mixture between debug and release that's actually neither.
The same goes for asserts. Since asserts affect code generation, they are generally unwanted when debugging release builds.

[Blzut3]

Have to agree with Graf, to me it would make sense for the default to just be Release with the -g flag added. Ultimately it doesn't matter that much to me since 1) I rarely have to use it, 2) when I do use it changing the tweaking the setting in ccmake if necessary is no pain at all. But I still consider it an unintuitive default. Furthermore if the default was set that way, it would be useful for generating dbg packages for Linux without having to manually add in support for that.

While I certainly see the argument for opt-in O3 and think it's a perfectly reasonable position, I think having developers compile with O3 by default is generally a good thing. If you write code with good development practices it shouldn't break your code with any regularity, so I feel like defaulting to O2 would simply proliferate the at least half-myth that O3 is particularly dangerous. I don't think the performance regression case is common enough that it really matters either way.

[MartinHowe]

Fascinating to read the comments here by developers far more experienced than I. Especially the half-myth; the impression I always had was that using -O3 would cause the Moon to explode while Cthulhu eats the Sun Am learning a lot from this, and not just from my own experimenting