Windows 2000 64-bit for Alpha AXP

(this is a guest post by Antoni Sawicki aka tenox)

Recently, hinted by friends on Discord, Neozeed “discovered” a Win64 compiler for AXP64 / ALPHA64, that came in as part of Windows Platform SDK from 1999. This was released by Microsoft to allow developers test-compile their programs to see if they are “64bit ready”, ahead the 64bit hardware being available. However, this was just a cross-compiler and there was no actual way of running any of the binaries. Until Itanium finally came out, after infamously long delays. The Win64 project for AXP64 and IA64 was code name “Sundown”. Sadly, 64-bit Alpha AXP Windows was never released outside of Redmond.

Trying the compiler, just for fun, I compiled Alpha64 version of Aclock – with zero hopes of ever being able to run it. There are some surviving machines with AXP64 stored at Microsoft Archives. In fact I saw one with my own eyes, last time I visited there some 10 years ago:

DEC Alpha with AXP64 Windows at Microsoft Archives.
DEC Alpha with AXP64 Windows codename “Sundown”, at Microsoft Archives, 2014

The machine in picture above was featured in a blog post by Raymond Chen, which is a must read. It will give you background info on the whole Alpha 64bit situation. Unfortunately nothing ever leaves Microsoft Archives, unless you have a court order or SVP approval.

And that would be the end of the story… if not for one generous reader, who contacted Neozeed after his previous post, and shared a disk image… containing a 64bit build of Windows 2000 for Alpha AXP! The reader got it from a lot of random lot of hard disks bought from an e-waste, years ago, and completely forgot about it until they saw the blog post!

Having a PWS500 with ZuluSCSI handy, I was able to slap the image on an SD card and boot it up:

Windows 2000 Alpha64 Splash Screen

The system BSOD shortly after. Turns out, this is a checked (debug) build of Windows and requires a permanently attached kernel debugger to even boot up. Initially WinDbg and kd.exe refused to work, as the target CPU did not match the host (the exact error code is: KD Version has unknown processor architecture). After some deliberation and help from friends, I learned that alphakd.exe can be run on x86 machine to cross debug an Alpha target. Most importantly it works with AXP64!

Another problem was that the system came up with “Found New Hardware” wizard and there was no functioning keyboard and mouse to click through it. Yes I tried safe mode, VGA mode, etc., but nothing worked. The system was completely stuck on this dialog:

Fortunately, the network card worked. Neozeed and I built and hacked in to the registry an rlogin daemon. Finally solved the PNP fuckup by remotely executing a VBScript that clicked through 20+ “found new hardware” and “install unsigned driver” dialogs. Eventually, a PCI to ISA bridge was found and keyboard and mouse came up!

Aclock running on 64bit Windows on Alpha AXP

Unfortunately there are no identifying marks that would definitely prove that this is a 64bit Alpha AXP build. The only way to tell is because there is no WOW, even for AXP32. You can’t run any 32bit Alpha binaries. It will only run executables produced with the ALPHA64 compiler. This also means in practice, there is no native compiler for this. You have to cross compile on 32bit NT4 or 2KRC. However if you going to build anything for AXP64 I can run and test it for you 🙂

Update: Build Label from the Registry

For sake of search engines the build number is 2210, the full string 2210.main.000302-1934.

Update: So what else is in the image?

First of all, everyone is asking about Pinball… Yes, it’s there, but it won’t start:

In addition, I can’t open the event details. Maybe one day we can debug it with NTSD.

Other than that it has just basic stuff the every other Windows would have. Internet Explorer 5.5, agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0). Sadly msinfo32 doesn’t work unable to connect to a service. As mentioned before, SysWOW64 and Sys32x86 are empty directories, so you can’t run anything that isn’t compiled for Alpha64.

The image, similar to other private builds, comes with IDW which is Internal Developer Workstation. It’s a set of developer tools, that most of, but not all, were released in Platform SDK and/or Windows Resource Kit.

There are a bunch of unix like utilities, cp, mv, ls, kill, etc.:

build.exe version 4.03.2209

It can build for AXP32 and IA64:

There also are two famous text editors, Microsoft Editor aka MEP / Z and Stevie, VI clone:

Lastly, lets explore 64bit Alpha AXP gaming situation! While Pinball doesn’t work, IDW comes with an impressive amount of games. Microsoft engineers must have been playing these while waiting for builds to complete…

64-bit gaming on Alpha AXP

We have 4 different card games, FreeCell, Solitaire, Gold and Cruel. Also Taipei game, TicTactics, Reversi, Minesweeper and Snake.

AXP64 NT also has fully working OpenGL Screensavers:

If you want to see this live in action. We going to be exhibiting on VCF West 2023 in August, alongside other NT RISC machines. Come and see us!

OpenBSD 7.3 on the es40 Dec Alpha emulator!

Yes OpenBSD 7.3 Alpha boots, and installs! And it’s incredibly slow. But it’s running!

For those impatient just download it here: OpenBSD73_Alpha_es40.7z

The root password is: password

I had es40 built this from gdwnldsKSC but I amputated the pcap based networking code. I just wanted a smooth compile. The install took over an hour, as there is ssh keys to generate, and re-ordering and re-linking involved. All of which I disabled in the above image. The root password is password.

Since people never read this, the password for root is password.

One weird thing is that OpenBSD will crash on an assert if you are using the VGA console, so a serial console is a must. After it boots, as you can see the VGA console works fine.

The games work just fine as well. I didn’t bother installing the compilers as it took forever to decompress the base file, and I figured if you wanted it, you could install it. Also since I amputated the networking, there is no X11.

For those of you who want to play with virtual Dec Alpha stuff this one is pretty simple enough.

At the P00>>> prompt type in

boot dka0

And in no time it’ll boot up (takes about 2-3 minutes)

And for those of you who are into these things:

OpenVMS PALcode V1.98-104, Tru64 UNIX PALcode V1.92-105

starting console on CPU 0
initialized idle PCB
initializing semaphores
initializing heap
initial heap 240c0
memory low limit = 1b0000 heap = 240c0, 17fc0
initializing driver structures
initializing idle process PID
initializing file system
initializing hardware
initializing timer data structures
lowering IPL
CPU 0 speed is 1000 MHz
create dead_eater
create poll
create timer
create powerup
access NVRAM
Memory size 512 MB
testing memory
probe I/O subsystem
probing hose 1, PCI
probing hose 0, PCI
probing PCI-to-ISA bridge, bus 1
bus 0, slot 1 -- pka -- NCR 53C810
bus 0, slot 2 -- vga -- Cirrus CL-GD5434
bus 0, slot 4 -- ewa -- DE500-BA Network Controller
starting drivers
entering idle loop
initializing keyboard
*** system serial number not set. use set sys_serial_num command.
Partition 0, Memory base: 000000000, size: 020000000
initializing GCT/FRU at 1c8000
Initializing pka ewa
Memory Testing and Configuration Status
  Array       Size       Base Address    Intlv Mode
---------  ----------  ----------------  ----------
    0        512Mb     0000000000000000    4-Way

     512 MB of System Memory
Testing the System
Testing the Disks (read only)
Testing the Network
AlphaServer ES40 Console V7.2-1, built on Jun  9 2006 at 15:36:48
P00>>>boot dka0
(boot dka0. -flags 0)
block 0 of dka0. is a valid boot block
reading 15 blocks from dka0.
bootstrap code read in
base = 200000, image_start = 0, image_bytes = 1e00(7680)
initializing HWRPB at 2000
initializing page table at 1ff56000
initializing machine state
setting affinity to the primary CPU
jumping to bootstrap code

OpenBSD/Alpha Primary Boot
VMS PAL rev: 0x4006800010162
OSF PAL rev: 0x400690002015c
Switch to OSF PAL code succeeded.
>> OpenBSD/alpha BOOT 2.0
booting disk:/bsd: 8562592+683208 [326169+106+499752+320686]=0x9e9790
Unrecognized boot flag '0'.
[ using 1147688 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
        The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2023 OpenBSD. All rights reserved.

OpenBSD 7.3-current (GENERIC) #133: Wed May  3 12:45:27 MDT 2023
    [email protected]:/usr/src/sys/arch/alpha/compile/GENERIC
AlphaServer ES40, 1000MHz
8192 byte page size, 1 processor.
real mem = 536870912 (512MB)
rsvd mem = 2801664 (2MB)
avail mem = 514916352 (491MB)
random: good seed from bootblocks
mainbus0 at root
cpu0 at mainbus0: ID 0 (primary), 21264C-6 (pass 4.0)
cpu0: architecture extensions: 305<PAT,MVI,CIX,BWX>
tsc0 at mainbus0: 21272 Chipset, Cchip rev 0
tsc0: 8 Dchips, 2 memory buses of 16 bytes
tsc0: arrays present: 512MB, 0MB, 0MB, 0MB, Dchip 0 rev 1
tsp0 at tsc0 hose 0
pci0 at tsp0 bus 0
siop0 at pci0 dev 1 function 0 "Symbios Logic 53c810" rev 0x01: dec 6600 irq 8
scsibus0 at siop0: 8 targets, initiator 7
sd0 at scsibus0 targ 0 lun 0: <DEC, RZ58 (C) DEC, 2000> serial.DEC_RZ58_(C)_DECSRL0000
sd0: 2048MB, 512 bytes/sector, 4194304 sectors
vga0 at pci0 dev 2 function 0 "Cirrus Logic CL-GD5434-8" rev 0x02
wsdisplay0 at vga0 mux 1
wsdisplay0: screen 0-5 added (80x25, vt100 emulation)
dc0 at pci0 dev 4 function 0 "DEC 21142/3" rev 0x30: dec 6600 irq 20, address 08:00:2b:e5:40:00
ukphy0 at dc0 phy 0: Generic IEEE 802.3u media interface, rev. 0: OUI 0x000000, model 0x0000
sio0 at pci0 dev 7 function 0 "Acer Labs M1533 ISA" rev 0xc3
isa0 at sio0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16450, no fifo
com0: console
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0 mux 1
wskbd0: connecting to wsdisplay0
pms0 at pckbc0 (aux slot)
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
lpt0 at isa0 port 0x3bc/4 irq 7
mcclock0 at isa0 port 0x70/2: mc146818 or compatible
tsp1 at tsc0 hose 1
pci1 at tsp1 bus 0
tsciic0 at tsc0
iic0 at tsciic0
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
siop0: target 0 now using 8 bit async xfers
root on sd0a (d4f7f3ff7ccee1b1.a) swap on sd0b dump on sd0b
WARNING: / was not properly unmounted
Automatic boot in progress: starting file system checks.
/dev/sd0a (d4f7f3ff7ccee1b1.a): 11877 files, 188223 used, 792736 free (232 frags, 99063 blocks, 0.0% fragmentation)
/dev/sd0a (d4f7f3ff7ccee1b1.a): MARKING FILE SYSTEM CLEAN
pf enabled
starting network
/etc/rc[498]: read: -p: no coprocess

starting early daemons: syslogd pflogd ntpd.
starting RPC daemons:.
savecore: no core dump
checking quotas: done.
clearing /tmp
kern.securelevel: 0 -> 1
creating runtime link editor directory cache.
preserving editor files.
starting network daemons: smtpd sndiod.
starting local daemons: cron.
Wed May 10 04:54:32 MDT 2023
reorder_kernel: failed -- see /usr/share/relink/kernel/GENERIC/relink.log

OpenBSD/alpha ( (tty00)


And there we go!

OpenBSD/alpha ( (tty00)

login: root
Last login: Tue May  9 12:00:11 on tty00
OpenBSD 7.3-current (GENERIC) #133: Wed May  3 12:45:27 MDT 2023

Welcome to OpenBSD: The proactively secure Unix-like operating system.

Please use the sendbug(1) utility to report bugs in the system.
Before reporting a bug, please try to reproduce it with the latest
version of the code.  With bug reports, please try to ensure that
enough information to reproduce the problem is enclosed, and if a
known fix for it exists, include that as well.

You have new mail.

Did I mention that the root password is password?

Hiding in plain sight: The 64bit Dec Alpha C compiler

Of all the Microsoft Windows NT versions, the few of the rare ones include:

  • The i860 version, the original N-Ten that put the NT in NT.
  • The DEC 5000/MIPS version
  • The Clipper version
  • The SPARC/LE version
  • The HP9000/HPPA version
  • The AXP64/ALPHA64 port, the first 64bit version of 2000

Sadly, I don’t have any leads on any of the above. But while I was looking for the first public Win64 compiler that I could remember, it was just the frontend to the Itanium compiler, not letting you actually compile anything. Anyways I was able to find these two downloads:

And both of them have the same Win64 SDK, which includes this quick note in the readme:

Platform SDK support for Win64(tm)

This release of the Platform SDK will allow you to test-compile your
code for Win64. It supports the new 64-bit data types and pre-beta
releases of an IA64 compiler and an ALPHA64 compiler and linker.

1999 Platform SDK

It’s the same thing on both discs from what I remember.

Installing the SDK is certainly a product of it’s time, with a seemingly incredible amount of products to support.

I haven’t tested yet, but I have to wonder how integrated all the tools are into Visual C++. Stay tuned?!

Also there was still POSIX support. Windows 2000 was the last to support all the subsystems.

And of course, the star of the attraction, the 64 bit Test Compiler. There is an incredible amount of products and options to select, It must have been absolute chaos at Microsoft in the late 90s!

If you are on an intel based system, the 64bit compiler will be the top half of the Itanium compiler. It lacks the C2.DLL so it will not emit any assembly or object files. There is no linker libraries either, so for all intents and purposes it’s useless.

However, if you were to install this super preliminary SDK on a Dec Alpha you would instead discover a version 13 build of Microsoft C/C++

Microsoft (R) & Digital (TM) Alpha C/C++ Optimizing Compiler Version 13.00.8499
Copyright (C) Microsoft Corp 1984-1999.
Copyright (C) Digital Equipment Corporation 1992-1999.
Copyright (C) Compaq Computer Corporation 1998-1999.
All rights reserved.

The Visual C++ 6.0 on the Dec Alpha however is a version 12 compiler. So this is a big surprise for AlphaNT users!

And added to version 13 are these flags:

  /Ap32 enable P32 model
  /Ap64 enable P64 model (default)

That’s right! It turns out that the AXP64 compiler set has been hiding in plain sight for DECADES. I know that it’s so unlikely that we’d ever see any public release of a 64bit version of Windows for the Alpha, but oddly enough the compiler, headers and libraries are all there. YES You can make full EXE’s for AXP64/Alpha64. Of course with no OS, so it’s not like you can run them.

The compilers have been tested on NT 4.0 Terminal Server & 2000 RC2.

For anyone wondering here is how I ran it to compile then link a 64bit exe:

C:\proj>cl /c /Ap64 mt.c /Fomt64.obj
Microsoft (R) & Digital (TM) Alpha C/C++ Optimizing Compiler Version 13.00.8499
Copyright (C) Microsoft Corp 1984-1999.
Copyright (C) Digital Equipment Corporation 1992-1999.
Copyright (C) Compaq Computer Corporation 1998-1999.
All rights reserved.


C:\proj>link mt64.obj /MACHINE:ALPHA64
Microsoft (R) Incremental Linker Version 6.20.8528
Copyright (C) Microsoft Corp 1992-1999. All rights reserved

There is no point sharing the EXE as I mentioned above, there is nothing to run it on. But for the heck of it, here is uuencode compiled into assembly in both 32bit & 64bit mode.

I can’t imagine why, but for people who want to take them apart you can download the tools here.

Sadly as of today, there is no way to test. There is one surviving machine with Windows 2003 AXP64, outlined in an article by Raymond Chen. Its a great read about how Alpha64 NT port came to be. The machine is still sitting in Microsoft Archives. Hopefully one day someone can dig it out.

That said there is also version 13 compilers for both Itanium & AMD64. Although we can do stuff with the AMD64 port which I will try to write into something a bit more.. sane.

I found this a few weeks ago, and thanks to @tenox for giving me Alpha access to play a little with this hidden gem. It’s still crazy we’ve all had Alpha64 tool access the entire time.

When 0 is greater than 1.0

I came across this fun thing debugging a QuakeWorld client on a RISC machine. I think something is failing as I’m using terminal server. For some reason width is being passed as 0. Not sure why I didn’t debug it enough to care, so I setup a quick block to only evaluate the Fov if the calculated x was greater than 1.0

And Microsoft C did not disappoint.

I think it may have been some incremental linking issue? I’m not sure I purged the build directory and re-ran make and didn’t experience the crash again. I had to get the screenshot or even I wouldn’t believe it.

In the end I got it running:

Of course among the eagle eyed you may notice this is version 13.00.8499 of the compiler. But the last compiler for the Dec Alpha / Windows NT was version 12…

More on that later!

Ready to run OpenVMS VM – Student Kit from VSI

(This is a guest post by Antoni Sawicki aka Tenox)

I was recently registering a new OpenVMS Community License. In the process I learned that there is a ready to run, pre-installed and pre-configured VM with OpenVMS 8.4. Completely free for non-commercial purposes. You don’t even need to register or leave your details (WOW). Just download and run! Thank you VSI!

The student kit runs only on Windows as contains FreeAXP emulator. However it’s super easy to download, install and run.

VSI OpenVMS Student Kit

I’m hoping that in near future once x86 OpenVMS port is ready there will be images for x64 hypervisors like VMware, VirtualBox, Hyper-v and QEMU/KVM hopefully.

Installing Debian Linux 5.0 on the Qemu Dec Alpha

Years ago I’d written this terribly vague, and generic quickie post that Debian 5 will in fact boot inside of Qemu. I didn’t really want to get into it as it’s a little complicated and a lot painful. People have cried out over the years, but I figured I’d help people.

Linux for the Dec Alpha

For operating system tourists, I’ll save you the story, just go here, and download qemu-2.2.50-DecAlphaDebian.7z. You’ll quickly find out it’s borderline useless, and go onto your next thing. You’re welcome.

First thing this was running in 2014, and newer Qemu’s seem to behave… strange. So I stuck with a late 2014 build of Qemu. If you deviate from here , you are on your own. I did dig up quite a few other Dec Alpha AXP emulators and put them on -But that’s totally up to you, again I’m sticking with 2014’s Qemu.

The BIOS/Pal on Qemu’s Alpha is far from complete and cannot read disks, so no boot sectors, boot loaders, no on disk kernels. All is not lost, you can inject a kernel and initrd, however this is where the fun is. Obviously to install you need to extract both from the ISO file. Also make sure the kernel is decompressed, add a .gz extension and de-compress it, as it should be around 6MB.

qemu-system-alpha.exe -net nic -net user -drive file=alpha.vmdk,if=ide,media=disk -drive file=debian-5010-alpha-netinst.iso,if=ide,media=cdrom -initrd initrd.gz -kernel vmlinux

This is vaguely how to boot up the installer. Partition, make sure hda1 hda2 hda3 etc are created and all is fine.

Now the next amount of fun is that you need to extract the created initrd as the installer initrd always launches the installer. The busybox cannot create tar files, there is no ftp or scp, also I couldn’t get it to even try to mount NFS images.

However on Windows 10 with WSLv2 or a Linux machine you can mount the disk image (keep it raw? or convert it?)

losetup /dev/loop0 myimage.disk 
partprobe /dev/loop0
mount /dev/loop0p1 /mnt/myimage

These three steps will let you mount the disk in this case /dev/loop0p2 which is the root filesystem. Debian didn’t have partprobe installed so I had to apt-get install parted

Now that you can mount it, you can copy the boot/initrd.img-2.6.26-2-alpha-generic file.

We do need to tell Linux where the root filesystem is so to finally run Qemu it’s like this:

qemu-system-alpha.exe -net nic -net user -drive file=alpha.vmdk,if=ide,media=disk -initrd initrd.img-2.6.26-2-alpha-generic -kernel vmlinuz-2.6.26-2-alpha-generic -append "root=/dev/hda2"

Obviously this was a lot more time consuming than it should be, but now I can do useful things.

Also sometimes Qemu just sits there with a black screen. the UI is waiting for something ,not sure what. It’ll either come to life on it’s own or you got to bang it.

Multia under Thermal Camera

(This is a guest post by Antoni Sawicki aka Tenox)

DEC Multias are known for notoriously overheating. Someone even coined a term “Multia Heat Death”. The typical folklore recommendation of the time was to only run it vertically and replace the built-in fan with a more powerful one.

In modern times one can inexpensively acquire a thermal camera that attaches to a mobile phone. So why not take a peak inside the inferno.

Multia with 166 MHz CPU Under FLIR

This is how Multia looks like in a thermal camera. PS is on top right. CPU on the left. FDD/HDD bottom left.

The CPU, Alpha AXP, runs at around 60C, not great, not terrible.

Scanning up close through individual chips I found this curiosity:

Wedged between the memory chips and the power supply is a little chip that generates almost 100C. That’s a boiling temperature of water. Note the thermal image is shifted in regards to the visual part due to close range.

What does this chip do? I have no clue. Perhaps someone can help here. What I however did to it is this:

Slapped on this really nice radiator. In fact I added little radiators you can buy for Raspberry PI to all the chips generating tons of heat.

This is how the motherboard looks like right now:

I also added a tiny fan on top of the CPU. Drilled some holes in the case and of course replaced the main fan with a highest air flow I could find.

Time will tell if this resolves the heat death, but my Multia now runs much cooler with help of all the radiators and extra fans.

UPDATE in 2022:

Readers frequently asked “what about the heat death chip?“. Multia indeed has one specific chip that is a source of most of Multia casualties. According to NetBSD Multia Page the chip is 74F623 and is located on the bottom (flip) side of the motherboard.

You can tell it’s little charred. I so I went to take a peek with a thermal camera:

Can you locate it? FLIR found it immediately… Up close the chip goes above 100C:

I have added a small heat sink to it and now looks a little better!

Time will tell if it helps or not.

GXemul for Win32

Luna m88k booted off RAM disk

Don’t get all to excited, it’s a terrible port, but it’s to the point where it can barely run stuff. Although I don’t know how much is me, and how much is GXemul. I probably should have tested on Linux first.

Anyways it’s enough to boot the Luna m88k OpenBSD ram disk up to the single user mode, and poke around. The hard disk doesn’t pick up, and I haven’t even tried the NIC, although the address is looking pretty bogus.

I wanted to try the PMAX version of Mach, but then it hit me, that there is no server to load. And porting the system level from Mach 3.0 to 2.5 looks way more involved than Mach 3.0 being ‘something minor’.

Back on the 88k front, the Luna shipped with something called UniOS-Mach, but good luck finding that in this day & age. I guess I’ll have to go back to Japan.

For the crazy among us, go ahead and try The name says just how stable it is.

In the meantime here is a super low resolution capture of the screensaver from a Luna via

As an update, I added in the timer code from PCemu, and now that the timers appear to be firing some stuff like OS/F 1.0 get’s further!

OS/F 1.0 in single user mode

I need to go through the setup stuff a lot better as this is just untar’d and not setup at all. Not that it’s useful, but here, osf1-barely.7z .

So if anyone downloaded gxemul prior to this update, re-download it again! I put the m88k ramdisk kernel in there too so you can quickly test the Luna 88k emulation.

Confessions of a paranoid DEC Engineer: Robert Supnik talks about the great Dungeon heist!

What an incredible adventure!

Apparently this was all recorded in 2017, and just now released.

It’s very long, but I would still highly recommend watching the full thing.

Bob goes into detail about the rise of the integrated circuit versions of the PDP-11 & VAX processors, the challenges of how Digital was spiraling out of control, and how he was the one that not only championed the Alpha, but had to make the difficult decisions that if the Alpha succeeded that many people were now out of a job, and many directions had to be closed off.

He goes into great detail how the Alpha was basically out maneuvered politically and how the PC business had not only dragged them down by management not embracing the Alpha but how trying to pull a quick one on Intel led to their demise.

Also of interest was his time in research witnessing the untapped possibilities of AltaVista, and how Compaq had bogged it down, and ceded the market to the upstart Google, the inability to launch a portable MP3 player (Although to be fair the iPod wasn’t first to market by a long shot, it was the best user experience by far).

What was also interesting was his last job, working at Unisys and getting them out of the legacy mainframe hardware business and into emulation on x86, along with the lesson that if you can run your engine in primary CPU cache it’s insanely fast (in GCC land -Os is better than -O9).

The most significant part towards the end of course is where he ‘rewinds’ his story to go into his interest in simulations, and of course how he started SIMH when he had some idle time in the early 90’s. SIMH of course has done an incredible amount of work to preserve computing history of many early computers. He also touches on working with the Warren’s TUHS to get Unix v0 up and running on a simulated PDP-7 and what would have been a challenge in the day using an obscure Burroughs disk & controller modified from the PDP-9.

Yes it’s 6 hours long! But really it’s great!