Category Archives: guest post

AXP64 2210 Installation Media Reconstruction

Posted on by
19
Yes, Neko is ALPHA64 Powered!

Introduction

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!

E:\Projects\LZNTTool>LZNTTool -d "E:\Whistler 2210 AXP64 Recovery\usetup_compressed_0.bin" "E:\Whistler 2210 AXP64 Recovery\usetup_0.bin"
Decompression successful.

E:\Projects\LZNTTool>wsl hexdump -C -v -s 0x600 -n 0x200 "../../Whistler 2210 AXP64 Recovery/usetup_0.bin"

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?

  1. Size: 4 bytes
  2. Location: Last 4 bytes of a 0x2000 section
  3. 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:

E:\Whistler 2210 AXP64 Recovery>wsl strings -t x SETUPLDR | wsl grep -i '.pal'
  91f68 A321064.PAL

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:

#if defined(_AXP64_)
        SlGetDisk("a121165.p64");
#else
        SlGetDisk("A321064.PAL");
#endif

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.

Download

ISO for Installation: https://mega.nz/file/q5AhhDJR#MsLYxxvmAdYDQ101fUHoGyzJ5Pk0EFsc2xdYH1p9qxQ
Whistler 2210 axp64 installable

Folder Dump for Preservation: https://mega.nz/file/r5gE3RxQ#4VfviMdQo44wJZT0df0cw8o4kE30lvSQKBZklma0mtg

Modified TXTSETUP.SIF For Other Machines: https://mega.nz/file/zsBVAJDD#5oQVM6U2AwseTJ54lOmN1E7BHTDFuwOuWdZOykmXP8E

Special Thanks

  • to the person who sent us the disk image
  • 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 ¯\_(ツ)_/¯.

Download: https://mega.nz/file/qoYyUbLB#oKArX_Qqh_kjnESnT6dQD8NGTg05_CMhKMxW4FKuhjEWindows 2000 build 2128 DEC Alpha

Windows 2000 64-bit for Alpha AXP

Posted on by
44

(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 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. 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.:

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 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!

OpenVMS x86 hobbyist finally here!

Posted on by
Reply

(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:

OpenVMS x86 on VMware ESXi

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.

Just for fun let’s use a recent build of C-Kermit by David Goodwin!

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.

Apparently there also is a WebUI for VMS?

I’m hoping that in future OpenVMS will be available on some public clouds like AWS, Azure and GCP. This would open some interesting possibilities.

I’m going to go and port some apps to x86 VMS!

SimCity for Unix Liberated

Posted on by
9

(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 Tru64
SimCity 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

IBM AIX for IA64 (Itanium) aka Project Monterey runs again!

Posted on by
6

(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 Sequent DYNIX/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 loader
AIX 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:

adapter 23100020 IBM 10/100 Mbps Ethernet PCI Adapter (23100020)
adapter ae120200 10/100/1000 Base-T Ethernet PCI Adapter (ae120200)

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!

AIX IA64 local X11 with CDE

This was the lucky winner:

How to fix rsync slowing down over time (SOLVED)

Posted on by
5

(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:

$ rsync -aW --no-i-r --info=progress2 --info=name0 <src> <dst>

Ready to run OpenVMS VM – Student Kit from VSI

Posted on by
1

(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!

https://training.vmssoftware.com/student-license/

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.

Undocumented Madness – 2.9BSD on XHomer

Posted on by
4

This is a guest post by Seal331

Since I’ve been dealing with XHomer a lot lately in order to get the two dumped VENIX/PRO versions to work, I noticed that the XHomer documentation mentions a thing called “maintenance mode” and the DEC Pro port of 2.9BSD, so I was interested.

After doing a bit of searching around I found some install notes on www.frijid.net from real hardware, so I decided to adapt these notes for XHomer and install it. TL;DR – I did it, here I’m explaining all this stuff.

Step 1 – Acquiring XHomer

XHomer is a DEC Pro 350 emulator that can run P/OS, Venix, 2.9BSD and possibly RT-11, but I didn’t get to installing the last one yet. There is a statically linked binary but, since I’m a Gentoo Linux person (but I didn’t use Gentoo for this particular install)and prefer compiling everything I can, I grabbed the source code (https://xhomer.isani.org/xhomer/xhomer-9-16-06.tgz) and quickly compiled it on my Linux box. It was pretty simple, just install a development toolchain (build-essential on Debian based systems), the libX11 development package (libx11-dev on Debian based systems) and the XShm extension which is included in libxext-dev on Debian based systems. During make it spit out a bunch of warnings but I got a working xhomer binary. Also it kind of messes the xterm settings a bit after being closed, so I’d recommend running it in a separate xterm window. Since there’s no install target in the Makefile I just copied the xhomer binary to /usr/bin, and that was it. From here on, I will assume that the XHomer binary is called xhomer and is somewhere in your PATH, if not just modify the way I run XHomer.

Step 2 – Acquiring the distribution

Thanks to the people at the same www.frijid.net site I mentioned earlier, I was able to easily piece together a distribution set. Since we don’t really rely on how many physical floppies we have with an emulator, I grabbed the recommended root disk set and the 15 disk usr set with the source code, although we won’t be compiling the kernel in this post. Maybe next one? We’ll see.

The site with the floppies is http://www.frijid.net/download/pro350/bsd/raw/ and here’s what I used for my install:

box#0/maintenance0.img
box#1/usr+k00.img
box#1/usr+k01.img
box#1/usr+k02.img
box#1/usr+k03.img
box#1/usr+k04.img
box#1/usr+k05.img
box#1/usr+k06.img
box#1/usr+k07.img
box#1/usr+k08.img
box#1/usr+k09.img
box#1/usr+k10.img
box#2/usr+k11.img
box#2/usr+k12.img
box#2/usr+k13.img
box#2/usr+k14.img
box#2/usr+k15.img
box#2/root1.img
box#2/root2.img
box#2/root3.img
box#2/root4.img
box#2/root5.img

The 3 disk usr set in box#2/ doesn’t include the source, so I didn’t grab it.
The maintenance disks are all the same, so I just grabbed the one in box#0/.
The 6 disk root set in box#0/ does include some extra dev files and something that appear to be leftovers from the development DEC Pro, but it’s missing /bin/ed and /bin/passwd, so I suggest using the 5 disk set instead.

There is also box#2/procomm.img which was labeled as containing “PRO/COMM terminal emulation” but when I mounted it to install, there was only an empty lost+found directory. Perhaps the original disk had gone bad over the years or someone accidentally reformatted it? We may never know.

Step 3 – XHomer configuration & serial port preparation

Since the maintenance (install) floppy uses a serial terminal interface over the printer port and XHomer only allows us to send its output over serial, I had to do some searching again since most PCs nowadays don’t have a serial port to use. Thanks to cantoni over at StackOverflow I managed to find instructions for using socat in order to generate a pty, which actually worked for me. At first you need to install socat (bruh) and then run “socat -d -d pty,raw,echo=0 pty,raw,echo=0”. Something like this will be printed out on the terminal:

Then we do a quick test. I use putty to connect to the pty’s output, in my case it’s /dev/pts/3. Just use the default settings for serial connection with speed 9600 and the device as /dev/pts/3. If everything goes well, you will get a blank putty terminal window. Don’t panic, the fact it’s blank is normal.

Let’s test if our serial port works. Echo something in the pty’s input, in my case it’s /dev/pts/4. For example, “echo “Test” > /dev/pts/4″. If the word “Test” appears on the screen, congratulations, you have successfully set up the pty to a point where BSD will happily talk to it when we set up the connection later. !! DO NOT CLOSE THE PUTTY WINDOW AT ANY POINT DURING THE INSTALL UNTIL WE NO LONGER NEED IT (at the initial hd boot) !!

Now we configure XHomer. At first, let’s make a disk image. BSD only supports RD51 or RD50, we’ll use RD51 as it’s slightly bigger. If you get the hard disk wrong, BSD will silently hang at boot. Here’s the command to make a 10MB RD51 disk image for use with XHomer:

dd if=/dev/zero of=29bsd.rd bs=10027008 count=1

Let’s make the XHomer config file. Note that everything after the symbol | including the symbol itself does not need to be inputed, it’s just my notes.

screen = window | make the emulator window mode
window_position = 0, 0
window_scale = 2
full_scale = 3
screen_gamma = 10
pcm = on
framebuffers = 0
serial0 = /dev/pts/4 | change to your needs, pty input
la50 = null
la50_dpi = 300
kb = lk201
ptr = serial0 | DO NOT CHANGE, we'll replace it later when we no longer need serial
com = null
rd_dir = ./
rx_dir = ./
rd0 = 29bsd.rd, 4, 306, 16 | change if not using suggested disk
force_year = 99 | fix y2k bugs by forcing year to 1999
maint_mode = on | DO NOT CHANGE, bsd install uses maintenance mode for terminal
int_throttle = off | random workarounds for clocks or older linux systems, we don't need this on new stuff
nine_workaround = off
libc_workaround = off
lp_workaround = off

Save the file as xhomer.cfg.

Now run the xhomer binary. If everything goes right, you should have something like this on your screen:

If you didn’t run the test documented above or changed the string, the “Test” string will not be in the terminal or will be some other text, this is all okay.

Step 4 – BSD install

In order to feed floppies to XHomer, you have to use the XHomer control menu. In order to get to it, press Ctrl+F1 when the emulator window has focus. The two floppy drives we need are rx0: and rx1:, these are equivalents of A: and B: in DOS. Insert the maintenance0.img disk in rx0. If all goes okay, the floppy disk picture should disappear from the display window, leaving just the DIGITAL logo. The putty window should then display something like this:

40Boot
:

(all following input is in the terminal unless otherwise stated)

If all is okay, congratulations, you have booted from the installation diskette. Now type the following in the putty window after the : symbol:

r5(0,0)rdfmt

Then, if you inserted an RD51 10MB disk in the emulator as suggested, type 0 when asked for drive type. If you inserted the 5MB RD50 instead, type 1. If you don’t know the exact disk sizes and types, refer to the XHomer documentation, specifically the Emulated Hard Disk part. The formatting shouldn’t take long, then it will dump you back in the 40Boot prompt. Now you need to boot the UNIX kernel, type this in the putty window:

r5(0,0)unix

If everything goes okay, you should have something like this now:

If you get a boot hang instead (like me), restart both XHomer and putty, connect putty back to the pty, then in XHome insert the maintenance0 floppy back and boot the UNIX kernel again. DO NOT FORMAT THE DRIVE AGAIN!!

Install time!

At first, create the root filesystem by running:

/etc/mkfs /dev/rrd0a 2240

Then insert the root1 disk in the 2nd floppy drive (rx1) and restore the root filesystem dump from the 5 root set floppies:

restor rf /dev/rr51 /dev/rrd0a

When it says “Last chance before scribbling on /dev/rrd0a.” just press Enter.
When it says “Mount volume N”, just insert the right floppy and press Enter. Volume number == floppy number in this case.

After the “end of tape” message, verify the rootfs:

/etc/fsck /dev/rrd0a

If it succeeds, create the usr filesystem by running:

/etc/mkfs /dev/rrd0c 6528

Then insert the usr+k00 disk in the 2nd floppy drive (rx1) and restore the usr filesystem dump from the 16 usr set floppies:

restor rf /dev/rr51 /dev/rrd0c

When it says “Last chance before scribbling on /dev/rrd0c.” just press Enter.
When it says “Mount volume N”, just insert the right floppy and press Enter. Floppy number == volume number – 1 in this case.

After the “end of tape” message, verify the usr fs:

/etc/fsck /dev/rrd0c

(all following input is in on the Pro display unless otherwise stated)

If everything is okay, run sync two times and shut down the emulator. Restart it with only the maintenance floppy in rx0, then type this in the terminal (NOT the Pro display):

rd(0,64)unix

This should boot up Berkeley UNIX (BSD). We’re not done yet, but it’s close.

Type the following to install the hard disk bootblock:

dd if=/rdboot of=/dev/rrd0h count=17

If everything goes okay, set the root password:

passwd root

Congratulations, you have successfully installed 2.9BSD. Here are the cleanup and hdboot prep stuff:

Bring the OS to single user mode:

shutdown +1

(you can close putty now)

Then run sync two times and shut down the emulator.

Step 5 – Booting the OS

In order to boot the OS, you need to do the following:

Open the xhomer.cfg file;

Remove the serial0 = line;

Change the ptr = serial0 line to ptr = null;

Change the maint_mode = on to maint_mode = off.

Then save, after running XHomer you should be able to just log in.

Congratulations, you have successfully installed 2.9BSD for the DEC Pro 350! Sadly it’s pretty unstable, and due to emulation issues in XHomer vi completely crashes BSD, but there’s always ed 😉

Appendix A – Transferring Files

In order to transfer the files (up to 400KB per file) you will need some additional utilities. Here’s a guide on how to install them:

(the following steps are done on the Linux host side)

  1. Grab the following files:

https://xhomer.isani.org/xhomer/BSD/f2rx
https://xhomer.isani.org/xhomer/BSD/rx2f.c
https://xhomer.isani.org/xhomer/BSD/lbn2xhomer.c

  1. Apply the following patch to lbn2xhomer.c:
--- lbn2xhomer.c   2015-07-05 07:51:19.000000000 +0300
+++ lbn2xhomer.c        2021-12-30 17:13:28.539768500 +0300
@@ -25,6 +25,7 @@

 #include <string.h>
 #include <stdio.h>
+#include <stdlib.h>

 #define SECSIZE                512
 #define SECTORS                10
@@ -66,7 +67,7 @@
   if (fptr_v == NULL)
   {
     printf("Unable to open %s\n", argv[1]);
-    exit();
+    exit(1);
   }

   fptr_x = fopen(argv[2], "w");
  1. Compile lbn2xhomer:
cc -o lbn2xhomer lbn2xhomer.c
  1. Set up f2rx for operation:
chmod +x f2rx
  1. Make a floppy image with the BSD side utility:
./f2rx rx2f.c
  1. Run XHomer and attach the generated rx2f.c.dsk to rx0

(the following steps are done on the BSD side)

  1. Grab the file from the floppy:
dd if=/dev/r50 of=rx2f.c skip=18 bs=1 count=891
  1. Compile the utility:
cc -o rx2f rx2f.c

You’re now ready to transfer files.

Short file transfer handbook:

  1. Run f2rx FILE on the host box, FILE being the file to use;
  2. Insert FILE.dsk into rx0 on XHomer;
  3. Run rx2f on the BSD side.

Appendix B – Init: no more children issue workaround

On some hosts, programs from the install floppy may randomly die with the “no more children” message. A workaround is to disable RTC mode and enable IOTRACE mode in the XHomer Makefile and recompile, leading to a much more slower (due to accurate timing) and working XHomer. After the installation, you can revert to normal settings and it should work, as the programs installed on the hard drive to not appear to suffer from the same issue.

Appendix C – Sequels

Possibly coming soon to VirtuallyFun:

Undocumented Madness 2 – Big hard drives on 2.9BSD XHomer
Undocumented Madness 3 – Custom Kernel on 2.9BSD XHomer

Revisiting Windows NT 4.0 MIPS on QEMU

Posted on by
9

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

This was previously well covered by Gunkies and Neozeed, however as almost a decade passed, some improvements could be made and annoyances fixed.

Firstly NT MIPS now works in 1280×1024 resolution under QEMU. It previously had issues with mouse tracking, but this is now fixed. So the new image has a higher resolution.

Secondly the old images were made with FAT filesystem which I didn’t like too much. The reason for that is the infamous RISC NT osloader needs to be placed on a FAT partition. Then, if NT is installed on a second NTFS partition the default drive will be D:\, C:\ being the just the osloader drive. This was super annoying in practice. So a common procedure was to just have one FAT partition for both osloader and winnt. I have fixed it by supplying a pre-partitioned disk and specified the second partition for osloader and the first for NT.

Also I only had just a bare/vanilla image with no additional software installed. The new image includes most of the available apps, including IE3, some editors, Reskit and Visual Studio.

Lastly I wanted to figure out all the right settings and flags for qemu as they were discrepancies between different sources and nothing seem to work smoothly. The correct flags seem to be:

qemu-system-mips64el -hda nt4.qcow2 -M magnum -global ds1225y.filename=nvram -L . -rtc "base=1995-07-08T11:12:13,clock=vm" -nic user,model=dp83932

The -rtc flag is not really needed if you are ok with having the current date in the guest.

Thanks to Neozeed for figuring out the network settings! Unfortunately the old/legacy -net nic -net user is no longer working while the new -device doesn’t like dp83932. The documentation was quite helpful.

Thanks to reader Mark for pointing out the correct NVRAM settings! See comments below.

The new image with all the apps preinstalled is here and a plain “vanilla” here.

Curiously this now works right out of the box on QEMU 6.1 and is pretty smooth and stable compared to what it was before. Good job QEMU team and thank you! Just in case I still keep the old binaries for Windows made by Neozeed here.

Update: I built Yori for NT MIPS! You can download here!

Fun with Nano Server

Posted on by
10

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

While everybody is busy buzzing about Windows 11, I wanted to commemorate the finest operating system ever made by Microsoft – Nano Server.

For most of people Nano Server was esoteric, distant and unapproachable. It had a rather high entry barrier, requiring you to build it on a Windows Server 2016 host using PowerShell magic spells. You couldn’t just simply download and run it. Even if you managed to get it running, there wasn’t anything you could actually do with it for fun. People didn’t bother to even check it out. My goal is to demystify this a bit, lower the entry bar and made it easy for people to hack it.

Background info (you can skip it)

Nano Server was an interesting attempt at creating a datacenter grade OS that’s not managed via local GUI, keyboard and mouse, but rather full automation, remote tooling and code. It went one step further than Server Core or Windows PE by completely removing GUI components and local shell. Hence it’s not actually called “Windows” or “Windows Nano” but rather simply “Nano Server”. Rumor has it, it started as MinWin. The OS has a rudimentary text mode console with functionality similar of VMware ESXi console. However Nano was much more than a bare metal hypervisor. It was a fully fledged operating system. Unlike ESXi you can develop and install services/apps for it and hypervisor wasn’t even it’s default role.

Ever since I first saw a demo on Microsoft Ignite (previously known as TechEd) I wanted to run aclock on the text console. Much like the WinNT BSOD edition. This article started around my efforts to run (or port if needed) aclock to this platform. At the time of writing, the technology has been dead for several years now. However all the artifacts and documentation are still available on Microsoft’s website. Probably not for long, so a good moment to do it now, before everything gets deleted in to oblivion.

How to quickly deploy Nano Server and run command line apps on the console

The hard way: you need to download Windows 2016 Server (eval) and run a PowerShell command to produce a bootable VHD file.

Microsoft provides (soon to be deleted) Nano Server Quick Start. However the steps are trivial so you can totally skip that and just do this:

  • Launch PowerShell terminal window on the WS2016 host.
  • Run: Import-Module D:\NanoServer\NanoServerImageGenerator -Verbose
    (D:\ drive being where Windows Server CDROM is mounted)
  • Run: New-NanoServerImage -DeploymentType Guest -Edition Standard -MediaPath d:\ -BasePath c:\nano -TargetPath c:\nano.vhdx -ComputerName nano -Development
    (c:\nano folder and c:\nano.vhdx image will be created for you)

Done! This will build a .vhdx image that can be run under Hyper-V as “Gen-2” VM. For Gen-1 or to run it on any other hypervisor change .vhdx to .vhd in -TargetPath while running the PowerShell command.

The easy way: you can just download a pre-built VM image from here. There are VHD for Hyper-v Gen-1 and VHDX for Hyper-v Gen-2 and OVA for everything else.

First Boot

Once you boot it up you will be greeted with a PowerShell prompt. Just like that! You can type cmd to launch the good old cmd.exe shell. MS-DOS 2016?

Keep in mind, this is a developer mode (see -Development flag). Normally you would be greeted with a login prompt and a boring menu that allows to change some networking settings and not much beyond that. In production mode you need to resort to hacks (or this) to get stuff running, fortunately nothing like that needed here.

So what can you run on it?

Firstly in order to get some external utilities going, you can mount a SMB share using net use in cmd or New-SMBMapping in PS world. Nano being a server and all, you can also share out a folder via net share or use C$ (you may need to create a user by using either net user /add in cmd or New-LocalUser in PS). Alternatively you can install Posh-SSH and use SCP to transfer files. If you don’t have working network you can just shut it down, mount the vhd image on the host and copy stuff in to the image then detach the VHD.

Aclock worked on the first run, no issues, using standard win64 exe:

aclock running on Nano Server Console

Wow! So looks like Nano console does have basic terminal controls. That opens quite a lot of possibilities. But can you run more complex apps? Text editors? Web browsers? GAMES?

Well, yes…, but likely not, but it really depends – on dependencies (read: DLLs).

From all the editors I tried XVI is probably the best:

XVI Editor Running on Nano Server Console

Everything else has a variety of issues:

  • The font is lacking line drawing characters. Some editors like YEdit allow to use ASCII drawing characters fortunately.
  • There is no reverse video. This manifests mostly in menus, etc. however it also applies to the cursor.
  • There is no cursor, or rather the cursor is an underscore and not transparent cell. Moving arrow left in the CLI doesn’t actually move the cursor it erases characters. There is no line editing.
  • Also related to reverse video, it appears Nano console has some weird issues with colors.
  • Missing DLLs. Nano Server not being a “Windows” OS is missing a lot of Windows DLLs and it has its own nano DLL hell. This has actually been acknowledged in MinWin. As such a lot of apps will not launch due to dependencies.

For example YEdit works remarkably well except for the menus, which use reverse video:

YEdit running on Nano Server Console

Update: Malcolm has fixed it in latest version of YEdit! Thank you!

Update: thanks to Ron Yorston you can also run BusyBox on Nano! All you need to do is get the 64bit version and before you run it set an environmental variable to disable ANSI emulation. In CMD set BB_SKIP_ANSI_EMULATION=0 in PS $env:BB_SKIP_ANSI_EMULATION=0. Done!

BusyBox on Nano Server

You even get ls colors and vi editor works flawlessly! Unix shell on Nano, thats awesome!

So what about games?

Initially nothing worked as expected. Either due to line drawing, colors or previously mentioned DLL hell. There was one game that actually worked – PowerShell adaptation of snake:

PowerShell Snake running on Nano Server Console

But I wanted something better. I had high hopes for ascii-patrol, which is pure text mode and they build it for win64. Unfortunately the game requires a bunch of multimedia / sound DLLs from Windows which are not present in Nano.

Thankfully Neozeed has stepped in, took the source code, amputated all the multimedia stuff, borrowed the Unix clock code and gettimeofday, and used an older Visual Studio to build it. But he managed to produce a fully working and playable version!!!! Truly amazing stuff!

ASCII Patrol Running on Nano Server Console

The binary is available here. To play the game scroll down one screen to start a mission. If you enter profile customization simply press ESC to get out. Thanks again Neozeed!

I’m hoping readers can find more text mode/ascii apps and games that will work on the console. Please comment and send links!

In another dimension, having a working text editor, Yori shell, smb/scp, maybe with help of mingw64, sdk tools or borrowed compilers from Visual Studio, one could have a self hosted developer workstation with this.

For now please just download the pre-build image, or make one yourself and run it in your favorite hypervisor and have some fun with it!

With this, goodbye Nano Server! You will be always remembered. I know folks at Redmond tried really hard to make it such beautiful gem.