(This is a guest post by Antoni Sawicki aka Tenox)
Preparing for my Windows NT RISC Exhibition for VCFW 2023, I wanted to have NT running on an IBM RS/6000. This was previously covered in this excellent article by Shoutmon as well in this excellent video by NCommander. However both are missing some crucial information that I had to go through and learn myself the hard way. I hope it will help someone in the future.
Windows NT PowerPC was designed to run on PReP machines, however that by itself is not very useful. Which of the RS/6000 models are REeP and which are not? This is coincidentally answered by NetBSD/prep supported system models.
Firstly there are IBM PC Power Series. Yes IBM PC but with PowerPC CPU, and not to be confused with RS/6000 which is a different IBM product. However the IBM Power Series have equivalent RS/6000 “counterpart” models. WTF IBM.
IBM PC Power Series 440 6015 == IBM RS/6000 Model 7020 40P IBM PC Power Series 830 6050 == IBM RS/6000 Model 7248 43P IBM PC Power Series 850 6070 == IBM RS/6000 Model 7248 43P
There are also other models mentioned by Windows NT 4.0 HCL, namely E20, E30 and F30, and PowerPC ThinkPads. To summarize here is a more definitive list of IBM RS/6000 models supported by Windows NT 4.0:
Model 7020 40P Model 7248 43P, 100 and 133 MHz Model 7248 43P-140 (with a big asterisk) Model 7024 E20 and E30 Model 7025 F30 ThinkPad 820, 850 ThinkPad 860 (with a big asterisk)
If you could pick any RS/6000 machine, the 40P would probably be the most recommended. 40P can also run OS/2 PowerPC if you are in to this thing.
Unfortunately all I had on hand was 43P-140, which is PReP, but it’s not Power Series based and not supported by NT out of the box. WTF IBM. Chances are that you will run in to this as well. 43P-140 are way more popular and easier to acquire than any other hardware listed above.
The main trouble with 43P-140 is that the onboard GPU and NIC will not work with ARC and NT. Yes, you can hack in some generic S3 card. It will work in ARC/NT but not PROM and AIX. I wasn’t happy. Upon some collaboration with Shoutmon and NCcommander and my own research, I was able to find the one and only graphics card that will work in both the RS/6000 PROM as well as ARC BIOS, AIX and Windows NT. The lucky winner is:
IBM FRU 40H5838 aka GTX110P
It’s entirely possible that other adapters will work as well, however from all different cards that I tried this was the only one that worked in all combination.
As for NIC, there are way more options as it’s not used by PROM, ARC or AIX, just NT. In my case I opted for a standard Etherlink III card.
Once you have the correct hardware bits, NT installation is pretty straightforward. This is well covered elsewhere. In a nutshell you boot the ARC 1.51 floppy disk, setup partitions and install the OS. Note that the ARC BIOS will be installed in to a partition on your HDD and the floppy disk is not required beyond installation.
Billed as “NT RISC: Windows NT on RISC machines. Alpha, MIPS, PowerPC, Itanium.”, the exhibit demonstrates a lot of work in sourcing & repairing the machines along with some great rare example like
(This is a guest post by Antoni Sawicki aka Tenox)
I’m preparing a Windows NT RISC exhibition for VCF West 2023. While the CHM building is air conditioned, it’s far far from ideal and we have a rather hot summer. Most of the vintage machines lack CPU power management. Some, such as Alphas, are notorious for overheating. Despite installing modern fans and heatsinks, this still makes me uneasy. I wanted to come up with some thermal monitoring system to see whats going on in real time. Maybe alert or shut down if things go out of hand.
For a while now I been thinking about using Arduino with a thermistor. It would read the temperature sensor and send the data via serial port to the host. This should universally work for most old computers, as they commonly have serial ports. However, upon some prototyping I realized that between custom pcb/wiring, power requirements and TTL to RS232 converter, the whole thing was becoming a little too complicated for what I really wanted. Fortunately I came across a rather ingenious solution – someone sells this item on eBay:
It’s basically a thermal probe with RS232 interface, emitting a plain text ASCII string output. No drivers or software required. They are a little bit pricey. Perhaps readers can find a cheaper version. However it’s absolutely a perfect solution for what I really wanted. Note that the seller can make shorter cables on request. The default 3m is insanely long for this purpose.
With help of some thermal glue, installed the probe in to the CPU heat sink and routed the cable to a COM port in the back.
Above pictures are from Multia and PWS.
You can simply read the temperature as an ASCII string from the COM port:
However since this is a prestigious event I wanted something fancier. Also a simple terminal can’t really tell when was the data received and therefore is current. I banged out a simple Win32 app to have something nice on the screen:
If there is no update from serial port in last 10 seconds, “no data” will be shown. The text label changes color if the temperature goes over a threshold to warn if things are getting too hot.
I even added a thermal shutdown, if it goes over a critical value. However this only works on Windows 2000 and above. Earlier Windows NT versions lacked ACPI HAL support to invoke power down. Fortunately this will work nicely for 2210 build on PWS 500 and Windows XP on Itanium!
After VCF I’ll make something for Unix and VMS as well. Perhaps also a service / daemon version that can run in the background and doesn’t require GUI.
Unfortunately, during this amazing period, the Dec Alpha I had acquired specifically for this research had died. However, I was able to find an amazing group of people to not only go through with this research but take it upon themselves to provide an amazing working ISO image release! Needless to say, this is beyond my knowledge, and this is obviously a guest post
Background
In ~1997, Microsoft started work on a project dedicated to porting Windows NT to use 64-bit addressing on 64-bit machines. Before this, Windows NT used the 32-bit mode or ABI of 64-bit machines. This effort was internally referred to as “Sundown”, otherwise referred to as “Win64”. The ports consisted of not only to the Itanium/IA-64 architecture (which later shipped as Windows XP 64-Bit Edition) but also to the 64-bit DEC Alpha architecture.
Compaq dropped support for Windows on Alpha in mid-1999, and Microsoft stopped the development of 32-bit Windows NT for Alpha soon afterwards, with Windows 2000 build 2128 (RC2) being the last build. Due to a lack of physical IA-64 hardware and the slowness of the simulator, Microsoft continued to work on the AXP64 port of Windows till mid-2000, to help fix general issues related to 64-bit addressing. You can read more about this project here.
In May 2023, a disk image containing an installation of an AXP64 build of Windows XP (Whistler) build 2210 was discovered by a guest reader of this site, and a team (amarioguy, neozeed, pivotman319, starfrost and Tenox) was later assembled to help make this release possible.
Why Repack To ISO
When I saw the news about this build, I asked my friends why didn’t neozeed or Tenox share the full disk image, they told me that the disk image contained PII (Personally Identifiable Data) and neeozeed would like to have them removed first. I have some experience with cleaning up Windows builds, so I joined their Discord server and offered to help, then I got sent a full sector dump of that disk. I scanned the build 2210 partition with a file recovery tool that I stole from a data recovery shop when I worked there, and to my amazement, quite a few files in the deleted \$WIN_NT.~LS directory (a place for holding temporary setup files) survived (more importantly, setupdd.sys, txtsetup.sif, setupldr and the hiv*.inf files). Since all the files required for a clean install from ISO/CD are there, this build can be repacked into an ISO which is guaranteed to contain no personal information!
Recovery
The first thing I did was I recovered all of the files in the deleted \$WIN_NT.~LS directory, but since the integrity of files recovered from NTFS and FAT partitions cannot be guaranteed, I checked every single one of them. Most of those files were Microsoft Cabinet (CAB) archives, so I wrote a tool called CabChk to verify that 1) they are valid CAB archives, 2) there is only one file per archive, 3) the name of the compressed file is the same as the name of the archive and 4) the compressed file extracts fine. This helped me to verify most of those 4600 files, but I had to verify the remaining 300 or so files by hand because they’re not CAB archives and that task alone took days to complete. After verifying all the recovered files, it turned out that 85% of them survived while the remaining 15% didn’t.
Repacking
A lot of those overwritten files are actually in the Windows directory (NT64) of that 2210 install, so I copied them out and recompressed the appropriate ones. I set my computer to the time zone Microsoft used and compressed them with the Cabinet Tool (CABARC) parameters Microsoft used. Microsoft used UTC-8 and the following CABARC parameters:
CABARC -m LZX:21 N [output_cab] [input_file]
After repacking and copying over the files, the number of missing files went from about 650 all the way down to roughly 30 :).
Missing User Mode Setup Stub
Unfortunately, usetup.exe was one of those 30 or so files. It doesn’t do much as it’s a stub, but nonetheless without it, text mode setup won’t start. My original idea was to decompile I386 build 2211’s usetup.exe (as it has only about 20 functions) and recompile it for AXP64 with the toolchain discovered earlier on, but I had to wait for someone to cross compile it on an Alpha for me. While I was waiting, I searched that partition for substrings in the I386 usetup.exe and I got a match!
It’s compressed, but since LZNT1 is a simple and weak-ish compression algorithm, you can sort of recognise the original data. I cobbled together an LZNT1 decompressor and decompressed that 32 KiB chunk, and indeed it’s the AXP64 usetup.exe!
I then searched for strings expected to be in the second 32 KiB chunk and then the third chunk and so on, until I got all of them recovered. After decompressing all of the 5 chunks, I concatenated them together into one single executable and yay, we now have the original AXP64 usetup.exe!
E:\Projects\PEChkSum>PEChkSum "E:\Whistler 2210 AXP64 Recovery\usetup.exe"
Expected checksum is: 0x00035E4E
Actual checksum is: 0x00035E4E
"E:\Whistler 2210 AXP64 Recovery\usetup.exe" is valid.
Broken Driver Cabinet
pivotman319 pointed out to me that some files in driver.cab were dead, and indeed, Setup did not work with that broken cabinet:
Crash to the NT firmware Monitor
There were 2 copies of driver.cab on that disk, sadly the deleted one in $WIN_NT.~LS got overwritten and the one in \NT64\Driver Cache\axp64… well, 68 errors 😢:
Looking at the broken files, I noticed a pattern – all of them came from 3 blocks – 5, 36 and 37. What on Earth are “blocks”? Well, let’s talk about how CAB archives work first.
Files in CAB archives are stored in blocks, where each block stores 1 or more files. When files are added to a CAB archive, they are all concatenated together into one big file. The concatenated big file is then split into multiple sub-blocks (with default size of 0x8000 bytes) and each of them gets compressed and then concatenated together to form the compressed block. So, for small corruptions (bit-rots and etc.), theoretically only 0x8000 bytes are lost and the rest should still be recoverable, but tools like 7-Zip will refuse to extract anything beyond the point of corruption.
Now looking at the corruption in driver.cab, 2 of the 3 blocks can be fully recovered because we have all of those files in uncompressed form. Block 5 contains mostly printer-related files that are arch- and build-independent, so they can all be borrowed from build 2211 i386. Block 37 has only 1 broken file (win32k.sys) which exists on the hard drive (in system32). To fix these blocks, I simply took the uncompressed files, compressed them and replaced the broken blocks with the newly created ones.
And after fixing block 37:
I then ran my CabScan tool on the fixed CAB and as expected, there is only one bad sub-block left:
E:\Projects\CabScan>CabScan "E:\Whistler 2210 AXP64 Recovery\driver (fix).cab"
Offset 0x0253FD75:
Expected checksum is 0x568C0AC3
Checksum is 0x1CEBB9DE
Original size is 0x00008000
Compressed size is 0x00003862
Detected 1 bad sub-block(s) in 1 bad block(s).
So, what can we say about the corruption?
Size: 4 bytes
Location: Last 4 bytes of a 0x2000 section
Pattern: Starts with 00 F0 (possibly the result of a buggy NTFS driver)
Knowing these, I immediately located the 4 corrupted bytes in block 36:
So how did I recover those 4 bytes, did I brute force them? Nope, I used the checksum to calculate them! Here is the checksum algorithm Microsoft used for CAB archives:
CAB checksum algorithm
And as you can see, it’s very simple, so it took me almost no time to work out the 4 missing bytes (4A ED 16 71) from the checksum 0x568C0AC3! With block 36 fixed, as expected, all files are now good!
Buggy Setup Loader
I thought I got everything necessary recovered and fixed, so I packaged up the files and sent them to G-Nug85 to test… and it didn’t work:
It failed to find A321064.PAL in the [SourceDisksFiles] section of txtsetup.sif. Well, this is an AXP64 build and A321064.PAL is a 32-bit PALcode image… why would it be there? Needless to say, copying that file to the disc image didn’t help. I have literally spent days on this stupid issue and who would have expected this:
The culprit of the problem was they hard coded the name “A321064.PAL”… in the setup loader executable… how stupid!
We can tell from this that Microsoft has never made ISOs or discs for AXP64 builds, otherwise they would’ve found and fixed this bug. Well, maybe they did eventually try installing AXP64 builds from disc, because it’s fixed by the time of Windows XP SP1, but that’s long after this build:
Oh well, I replaced the hard coded “A321064.PAL” with “a121165.p64” and what do you know, it’s working!
Finishing Touches
That install went smoothly, but one error did pop up during second stage setup:
A missing driver – big deal, hey? We actually have the build 2209 AXP64 version of this driver, so I injected it to the ISO and Setup happily accepted it.
I’ve also copied the Arc Installation Program (ARCINST) from Windows 2000 build 2128 AXP32 to the AXP64 directory of the ISO, because it is required for disk partitioning if you don’t have AlphaBIOS (and yes, it works because it’s not a Windows executable).
Supported Machines
Microsoft compiled several HALs for this build, but not all of them are listed in txtsetup.sif, the following machines are supported by default:
Digital Personal Workstation A-Series
Digital AlphaServer 4×00 5/xxx Family
Digital AlphaServer/AlphaStation 1200 5/xxx Family
Digital Alpha 21264/Tsunami Uniprocessor
Digital Alpha 21264/Tsunami Multiprocessor
The following machines may be supported if you replace textsetup.sif with a modified version:
Digital Alpha EB164
Digital Alpha PC164SX
Digital Alpha XL 300/366 Family
Digital AlphaPC 164LX
Digital AlphaServer 1000 5/xxx Family
Digital AlphaServer 1000a 5/xxx Family
AlphaServer 800 5/xxx (Corelle)
AlphaStation 600A 5/500 (Alcor Primo)
We have only tested this build on the Digital Personal Workstation A-Series, AlphaServer DS10 and the AlphaServer 800, so there is no guarantee that the other HALs work (though they should).
Also, since this is a checked build, it does run slower than a retail build, and by default it will expect you to have a kernel debugger attached. Be sure to add the /NODEBUG flag to the bootloader to improve performance. I had noticed the SDL spite test demo going from 60fps to 70fps on my Alpha Personal Workstation 500a before it had died.
For Preservation
As I have said earlier on, Microsoft has never made ISOs/discs for AXP64 builds, so please don’t preserve the ISO file (eg: don’t upload it to BetaArchive). I know BA prefer ISOs over folder dumps, so let me tell you this mrpijey, the ISO is a franken-build with a patched Setup Loader and files from 2128, 2209 and 2211. We have a folder dump of the original files from the \NTDev network share with original high-precision timestamps just for preservation, so please for the sake of preservation, use this. Also don’t even think about creating an ISO out of the folder dump, you’ll end up with a non-existent thing that doesn’t work.
to Microsoft for not wiping that disk before throwing it away
to pivotman319 for verifying recovered files and finding missing files
to Tenox for testing
to G-Nug85 for testing and providing photos used in this post
to Furball for testing
to lbdm for testing
to myself… I guess?
Special Offer – Windows 2000 RC2 AXP32 Full ISO
The ISO on BetaArchive is the same as the ISO on WinWorld, which was originally named usa_2128_axpfre_win2000.pro_beta3_cairo.iso… hmm, that doesn’t sound very ‘Microsoft’!
Yep, definitely not original. Even worse, SETUP.EXE is broken/truncated:
The fact that the AXP32 2128 ISO we’ve had for over a decade is both unoriginal and incomplete is truly shocking! Well, I have something to offer – an at least complete Windows 2000 build 2128 AXP32 ISO from my private collection:
The SETUP.EXE in this ISO is good and complete! The CDIMAGE parameters used to build this image matches what was used to build ISOs of AXP32 builds from the same era and the disc label (W2PAS_EN) is much more sensible than “Cairo_2128”. The only thing that doesn’t make sense is the timestamp – 1999-09-23 12:00:00. Microsoft used 1999-09-10 as the timestamp for all other copies of build 2128, so I’m not sure why this one is different. It’s worth noting that all files from the incomplete ISO also have the strange 1999-09-23 timestamp, so I guess it’s not a coincidence ¯\_(ツ)_/¯.
(this is a guest post by Antoni Sawicki aka tenox)
Hinted by friends on Discord, Neozeed recently “discovered” a Win64 compiler for AXP64 / ALPHA64. It came as part of Windows Platform SDK from 1999. Microsoft wanted developers to test-compile their code to see if it’s “64bit ready”, well ahead of the 64bit hardware even being available. However, this was just a cross-compiler and there was no way of running any of the binaries. That is until Itanium eventually came out, after infamously long delays. The Win64 project for AXP64 and IA64 was code name “Sundown”.
Trying the compiler, just for fun, I built Alpha64 version of Aclock – with zero hopes of ever being able to run it. There are some known 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 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. Sadly, 64-bit Alpha AXP Windows was never released outside of Redmond.
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 non other but a 64bit build of Windows 2000 for Alpha AXP! The reader got it from a lot of random hard disks, bought from an e-waste, years ago and completely forgot about it until they saw the blog post!
The image was previously installed on Digital Personal Workstation. 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 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 32bit Alpha binaries. It will only run executables produced with the ALPHA64 compiler. This also means in practice there is no self hosted, native compiler. You have to cross compile on 32bit NT4 or 2KRC.
For sake of search engines the build number is 2210, the full string: 2210.main.000302-1934.
Update I have copied and ran a x86 `winmsd.exe` from Windows NT 4.0 and this came out:
How is it possible to run x86 binary? Because of Fx!32.
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 some 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.
The image, similar to other private builds, comes with Internal Developer Workstation (IDW). 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.:
Lastly, lets explore 64bit Alpha AXP gaming scene! While Pinball doesn’t work, IDW comes with an impressive amount of games. Microsoft engineers must have been busy 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!
(This is a guest post by Antoni Sawicki aka Tenox)
After years of waiting, VMS Software finally released OpenVMS x86 for hobbyist use. Luckily I was able to download the install media and a hobbyist license pack from the Service Platform portal. So lets have some fun with virtualization!
OpenVMS x86 has pretty strict hardware requirements. It only works as a VM (no physical hardware support). It wants a recent CPU. The VM must have EFI BIOS and E1000 NIC. As for storage controller – both HDD and CDROM must be on the same SATA controller.
The ISO image boots to a fancy new loader screen:
However as cute as it looks, don’t have your hopes up for a real GUI. That’s as far as it goes:
Once the OS boots up, it switches to a serial console for the rest of installation and operation. Being a VM and having no access to physical serial port, I hooked it up via named pipe to another VM’s serial port.
The installation is pretty straightforward. I picked all the defaults and off you go.
The system installs under couple of minutes. A boot takes just couple of seconds and it’s extremely fast end responsive. This is somewhat expected as the VMS dates back to 1977 and hasn’t grown in bloat much like more “modern” OSes.
One of first things to do after installation, is to register the license packs and configure TCP/IP.
For license pack I added the “BOE” pak by hand and transferred the rest as a `.com` file after TCP/IP was setup.
To configure IP you simply run @sys$manager:tcpip$config and go through the steps. Networking doesn’t start by default, so you need to edit sys$startup:systartup_vms.com file and uncomment line saying @sys$startup:tcpip$startup.com. After that you should be able to telnet to the VM at every boot. Also note that OpenVMS comes with some unix commands for the tcpip subsystem, you can find them in help under TCPIP_Services -> UNIX_Commands
You can setup auto boot in the graphical console by typing “auto boot”, this way you never have to open the graphical console to type boot.
Browsing through software packages on the VMS service portal you can find a C compiler, Fortran, as well as some typical OSS packages like OpenSSH, SSL, Samba, Git and many more.
(This is a guest post by Antoni Sawicki aka Tenox)
In early 90s DUX Software ported SimCity classic UNIX. They provided downloadable demo versions for SunOS, Solaris,HP-UX, SGI IRIX, OSF/1, Digital Unix,OpenDesktop, UnixWare, Linux and BSD.
SimCity SGI IRIX screenshot from DUX website
In the winter break wave of nostalgia I wanted to play SimCity on my vintage HPUX workstation. Unfortunately the 5 minute demo just wouldn’t cut it. Back in 1993 you could simply purchase a license key and unlock the demo to a full version. However even if I could find an old license code, these keys were “Host ID” locked, so you could not easily use it on a different machine anyway.
In 2008 SimCity Classic has been open sourced under a new name Micropolis for the OLPC project. This was truly epic endeavor, many thanks to everyone involved. Unfortunately for vintage computer enthusiasts, the source code been updated to compile on a modern Linux, before it was released to the public. It will no longer build on any old Unix system. Typically, when a developer decides to free up their obsolete version, they just toss out some licenses codes. Sadly this time no one ever bothered.
The only option left was to bypass the license checking code. Fortunately, modern binary analysis tools make patching old apps relatively straightforward. In just minutes I was able to get the game started in a full multiplayer mode. A few hours later I got it patched on all the vintage Unix platforms!
SimCity on Solaris 7 (also works on 8 and 9)SimCity on HP-UX 9 (doesn’t work on 10 or 11 due to TCL/TK issues)SimCity on OSF/1 aka Digital Unix aka Tru64SimCity on IRIX 5.3 on MAME (doesn’t work on never IRIX due to COFF binary)SimCity on SunOS 4.1.4 on QEMU SimCity on SCO OpenServer / OpenDesktop (ODT)
UPDATE: patched IRIX as well! Special thanks to Mr^Burns for providing a preinstalled IRIX 5.3 MAME image!
UPDATE: patched SunOS version as well. Special thanks to Daghdha for preinstalled SunOS 4.1.4 QEMU image!
UPDATE: patched SCO Unix/ODT version as well.
You can download the demo versions and patches here. Happy gaming on your vintage Unix Workstation!
If you just want to try the game without bothering with an ancient unix, you can simply sudo apt install micropolis && micropolis on a modern Linux – it’s identical except for multiplayer
(This is a guest post by Antoni Sawicki aka Tenox)
Project Monterey was an attempt to unify the fragmented Unix market of the 90s in to a single, cross vendor Unix OS that would run on the upcoming Intel Itanium (and others) CPU. The main collaborators were: IBM, who brought its AIX, SCO brought UnixWare, HP was supposed to bring parts of HP-UX and SequentDYNIX/ptx. Ironically the project shared fate of the Itanium CPU—it totally failed. In the end Linux took spot of the “single Unix OSâ€. IBM donated AIX pieces to Linux instead and the main legacy of Project Monterey was the famous SCO vs IBM lawsuit.
IBM did however produce AIX version for the Itanium architecture! According to Wikipedia, some 30+ licenses were sold in 2001-2002. For years a dedicated group of individuals was trying to locate a copy of the legendary OS. It seemed that the OS was lost forever…
…until some 21 years later friends of NCommander checked in with a set of AIX5L IA64 CDROMS! The CDs have now been dumped and you can download them here. Unfortunately downloading will not get you much closer to actually running this. As of today no publicly available virtualization or emulation platform can boot this. Yes we tried Simics, looked at QEMU IA64 and XEN/KVM for IA64, etc. The OS will not boot on modern Itanium 2 (McKinley) CPUs, only the early “pre-release†Itanium 1 aka Merced. The only emulator allegedly capable of doing so was the super elusive unobtanium called Intel SoftSDV.
It’s currently speculated that AIX5L IA64 will work on and only on so called “Intel Software Development Vehicle (SDV)†sometimes referred to as “Intel Engineering Sampleâ€. It was an Intel made machine, later sold in several OEM branded version: IBM IntelliStation Z Pro 6894, HP i2000 Workstation, SGI 750, Dell Precision Workstation 730 and Fujitsu-Siemens Celsius 880.
Intel Itanium Software Development Vehicle Lineup
…yes, they all look alike because all of them were in fact produced by Intel with custom case badges and paints.
Luckily I was able to score a working HP i2000. AIX booted up and installed on a first try:
AIX 5L IA64 on HP i2000 Workstation – boot loaderAIX 5L IA64 on HP i2000 Workstation – logged in
Initially I was not able to get the onboard NIC working. Upon short investigation AIX5L IA64 supports only two network cards:
The AIX Itanium Early Adopters Release Notes mentions a few other cards but I do not see drivers for these in the OS. The doc mentions “Extended Hardware Drivers CD†which we don’t have.
Luckily again I was able to find a working NIC on eBay!
The system comes with X11 and CDE but so far I was not able to get any GPU working beyond basic text mode. I tried many different video cards from that era but there simply doesn’t appear to be any driver in the OS except for basic VGA / LFT. I think the key to getting video working is the previously mentioned extended hardware drivers cd.
Finally, if you want to read more I have found some interesting pieces on ibmfiles and various mirrors here and here.
Update: Thanks to efforts of TRN we now have a working GCC and ports of lots of apps!
Update 2: After going through a pile of video cards I now have local X11 and CDE!
(This is a guest post by Antoni Sawicki aka Tenox)
I often make copies of large data archives, typically many TB in size. I found that rsync transfer speed slows down over time, typically after a few GB, especially when copying large files. Eventually reaching crawl speeds of just few KB/s. The internet is littered with people asking the same question or why rsync is slow in general. There really isn’t a good answer out there, so I hope this may help.
After doing some quick profiling I found out that the main culprit was rsync's advanced delta transfer algorithm. The algorithm is super awesome for incremental updates as it will only transfer changed parts of a file instead of the whole thing. However when performing initial copy it’s not only unnecessary but gets in the way and the CPU is spinning calculating CRC on chunks that never could have changed. As such…
Initial rsync copies should be performed with -W option, for example:
$ rsync -avPW <src> <dst>
The -W or --whole-file option instructs rsync to perform full file copies and do not use delta transfer algorithm. In result there is no CRC calculation involved and maximum transfer speeds can be easily achieved.
Long term, rsync could be patched to do a full file transfer if the file doesn’t exist in destination.
Also while copying jumbo archives of many TB I don’t want to see every individual file being copied. Instead I want a percentage of the total archive size and current transfer speed in MB/s. After some experiments I arrived at this weird combo:
(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.
