Yesterday I featured a QEMU branch capable of booting Windows NT PowerPC. I was asked in comments if this by any chance also supports OS/2 on this architecture. The answer is: YES!

Here is the result:

Here is a link to a ready to run image: https://tenox.pdp-11.net/os/os2/virtual/os2powerpc-qemu.tar.lz – it takes a little bit of time appearing stuck on PowerPC logo with a warning sign, but not too worry it will boot up.

The branch is https://github.com/tenox7/qemu/tree/powerpc

You can learn more about OS/2 PowerPC edition at OS/2 Museum.

Another day another NT QEMU post. This time we have stock Windows NT 4.0 PowerPC running on QEMU, with complete emulation of the BIOS / Firmware and everything. Networking and 1280×1024 resolution.

QEMU branch: https://github.com/tenox7/qemu/tree/powerpc

Ready to run image: https://tenox.pdp-11.net/os/winnt/VMs/qemu-ppc/nt40powerpc-qemu.tar.lz

The image includes recently acquired Microsoft Office, SDK Tools, Visual Studio and a bunch of ported tools and utilities.

You may also be interested in Windows NT on IBM RS/6000 – Definitive Guide

In the previous post I build at NT 3.1 MIPS based QEMU image based on Jazz architecture.

Today another NT 3.1 but on Jensen! An early Alpha XP NT DEC box – I have an entire blog post about it.

1280×1024 resolution, networking, SP3, Alpha SDK preinstalled!

Ready to run image: https://tenox.pdp-11.net/os/winnt/VMs/qemu-axp/nt31axp-qemu.tar.lz

QEMU Branch: https://github.com/tenox7/qemu/tree/jensen

More software apps etc in the previous post.

Have fun with virtualization!

Behold! QEMU Jazz emulator can now boot and run NT 3.1 MIPS

With high res and networking fully working!

Github: https://github.com/tenox7/qemu/tree/jazz

Ready to run image: https://tenox.pdp-11.net/os/winnt/VMs/qemu-mips/nt31mips-qemu.tar.lz

In my previous post I featured SINIX-N on MIPS based Siemens RM-200 emulated in QEMU.

Since I did some work on RM-200 QEMU and this system is also capable of running Windows NT MIPS in Lite Endian mode (the CPU can switch endianness) I decided to also get it working:

I have previously covered NT on MIPS QEMU Jazz emulated machine. This is not that much different and fundamentally very close. Just a different machine with different firmware and peripherals. Also much newer QEMU version.

https://github.com/tenox7/qemu/tree/rm200

Ready to run image: https://tenox.pdp-11.net/os/winnt/VMs/qemu-mips/NTRM200-QEMU.tar.lz

Previously I got SINIX-Z running on 86box! But I really really wanted to run SINIX-N the MIPS counterpart!

Behold! MIPS R4000 SINIX-N running on QEMU emulated SNI RM-200!

After some time and couple of reboots we get to this:

and this:

This latest version 5.45 also features CDE:

The emulated Cirrus Logic GD5434 does 1152×864 and AMD PCnet NIC works fine. Not bad.

The QEMU branch is here. If you fancy submitting it to upstream go ahead.

If you want to install from scratch, my collection of SINIX install images and various application software is here.

For the lazy, I have prepared a ready to run image with all dependencies and QEMU binaries for Mac, Linux and Windows. The root password is just password. I have included bash and a bunch of GNU tools from gnustuff package under /home/tools. You can get gcc and others from here. There are some commercial apps here.

Have Fun with Virtualization!

In the previous post I mentioned working on a large deployment of Citrix and NeoWare thin terminals. We were using Citrix ICA exclusively. But the NeoWare terminals also had this mysterious “NTRIGUE” protocol that I never had a chance to use:

Various brochures, press articles and ads about the HDS @workStation also mentioned that this thin client is for NTRIGUE with zero mention of Citrix or ICA!

Very strangely all NTRIGUE and no mention of ICA/Citrix! What is going on here?

And what exactly is this NTRIGUE?

In a nutshell: Isignia company was mainly known for SoftPC and SoftWindows – PC emulators for Mac and Unix.

Insignia NTRIGUE product was a version of Citrix WinFrame that used Xwindow / X11 protocol for the transport. X11 appears beside ICA in the WinStation protocol list.

And that would be all… if I didn’t score a red box on eBay!

Behold! After 30 years of waiting, I present you NTrigue:

The CDROM is essentially Citrix WinFrame but everything is find / replace rebranded as NTRIGUE.

Even the NTOS kernel prints NTRIGUE…

And the login screen

The real deal comes from WinStation configuration. You can create one with X11 protocol instead of ICA:

But how do you use it? Very simply! In two ways:

XDMCP Query, either from a physical Xterminal or Xnest or Xephyr:

…yes so now any plain regular Xterminal like NCD, HP, Tek, IBM, DEC, etc can connect to a Windows host!

Second way – export NTRIGUE X11 client via remote display export. Like you would with xterm -display x.x.x.x:N or export DISPLAY=..... You RSH into NTRIGUE box and request a client:

rsh <target> <client_ip> <resolution> <colors>

In practice:

It seems that the NT box runs a rsh daemon and can send you an X11 exported client via x11.dll. It looks like they ported xlib to NT:

I find it curiously odd that the NTRIGUE client “app” runs on the host and exports display via X11 protocol. This is unlike ICA or RDP where the client runs on … the client.

Citrix ultimately acquired NTrigue from Insignia. Never to be heard from again and the tech essentially being buried. Is possible that this became their X11 ICA Client, but more likely they just bought it to kill competition to ICA protocol. After Microsoft released Terminal Server Edition with RDP, the ICA protocol and app management was all that Citrix had left to offer. NTrigue offered a “client-less” alternative. That couldn’t be good for business.

Finally a gallery of various UNIX systems talking to NTRIGUE:

You can download NTRIGUE from here: https://tenox.pdp-11.net/os/winnt/MultiWin/ntrigue/

PS
I do have the license disk but it’s unreadable because of 720k format trickery. I will read it with a flux reader in a few days.

Update: Rairii crafted a keygen for it.

Around 1998/99 or so I was involved in a large deployment of Windows NT TSE (Terminal Server Edition) with Citrix Metaframe, for a Forbes top-100 listed corporation. The general population were using plain boring Neoware thin terminals with ICA client for their daily tasks.

Managers and higher ups were using “high end” Neoware “workstations”. Actually named “@workStation Prima”. They had options for TV and AV capture cards, teleconferencing, streaming and multi screen. However no one really used these advanced features and the expensive workstations didn’t provide any extra functionality or value in practice. Just bigger, fancier and made you look more important in the corporate rat race.

For the more perceptive observer however they did have some interesting curiosities hiding inside the pizza box. Firstly they were rocking Intel i960 !

Secondly if you pressed the odd “Don’t login” button at the ICA screen, you would land at a full blown desktop with some apps, games and a terminal with local shell. The OS (named netOS) was some proprietary i960 UNIX. Because it did feature mostly GNU apps I assumed it simply must have been an embedded Linux distro and didn’t make much of it.

Fast forward almost 30 years, Rico scored a copy of Neoware netOS install media and some people even got it installed. Out of nostalgia, I also wanted to do some archeology here and play with i960 iron. Bought one of these Neoware @workstation terminals at eBay and got the OS copied to my tftp/nfs server and booted it up.

Good memories and fun with ICA and XDMCP terminal. But I wanted to see what else can be done with the weird i960 system. I started looking at the kernel and tools. Upon closer inspection of the binaries, turns out these are not Linux at all (also i960 doesn’t have MMU so it could not run it anyhow), instead it seem to be 4.4-BSD based.

AFAIK an official SDK was never publicly available. But applications like NEdit, XScreensaver and even Netscape Navigator shipped with the OS so they must have been ported to netOS internally. Fortunately with help of LLM I was able to do some reverse engineering and map out the binary format and syscall interface. GCC 2.95 did support i960 ISA and Binutils 2.11 was able to produce somewhat compatible binary format. i960-intel-nindy is the closest triplet (nindy is the i960 ROM monitor). The rest was history. An unofficial netOS SDK was born in an evening.

For now it can compile just the simplest C apps, but I will expand it more. I want to port SimCity!

Last but not least the “premium workstation” has an IDE port and allows installation of a hard disk for local boot. This makes it lot less of a network booted terminal and more of a proper workstation. I slapped on an industrial IDE DOM, fdisk/newfs and got the OS copied to it using provided script:

Now I have a full blown i960 UNIX graphical workstation with local OS and SDK. Hopefully one day it can self host its own toolchain!

netOS documentation is available from https://tenox.pdp-11.net/os/netos/Documentation/
netOS sdk https://github.com/tenox7/netos-sdk

Update: now we have rshd, telnetd and even busybox !!

studio:/Users/tenox> telnet 192.168.1.11
Trying 192.168.1.11...
Connected to 192.168.1.11.
Escape character is '^]'.
netOS telnetd - exit or ^D to quit
NETOS> busybox sh

BusyBox v1.00 (2026.09.27-09:42+0000) hush - the humble shell v0.01 (testing)
Enter 'help' for a list of built-in commands.

~ # version
Server Code Version: 3.2-D (Build 560)
PLCC Boot PROM Version: 3.1.1-E (Build 12)
netOS Version: 3.2 netOS for the Enterprise with ICA
~ # 

Update: Thanks to Ajfa netOS is now running on MAME!

This is exciting news, there is a fork of Qemu that has workable Itanium Merced emulation, and it’s good enough to run Windows XP/2003! Enter Malte Kuhlmann‘s Qemu fork of syunnPC‘s AI Itanium infused Qemu fork.

I’m sure at some point there will be some kind of merger. As always things move fast when they are interesting.

At any rate, I had nothing but incredible issues getting this to build. I should have written the steps down for the Qemu Alpha for that can run Alph64 Windows! … .however I didn’t so I kind of lost (hopefully temperarily) the recipies needed.

Instead, I’m jumping back to my mac mini, as of course macOS is just enough UNIX to be useful but mainstream enough to have real application. And part of the reason is that I wanted to build the firmware as I had a feeling that this was some important ‘lockstep’ thing I was missing.

Building cross compilers isn’t that new for me or this blog. As a matter of fact, I’ve got two at the moment from other various projects:

jsteve@Jasons-Mac-mini gcc % /usr/local/os2/bin/i386-pc-linux-gnuaout-gcc -v
Reading specs from /usr/local/os2/lib/gcc-lib/i386-pc-linux-gnuaout/2.8.1/specs
gcc version 2.8.1
jsteve@Jasons-Mac-mini gcc % /usr/local/i586-linux2/bin/i586-linux-gcc -v
Reading specs from /usr/local/i586-linux2/lib/gcc-lib/i586-linux/2.8.1/specs
gcc version 2.8.1

Since GCC 2.8.1 seems to run ‘okay’ as a macOS arm64 binary to cross compile to the i386… But that’s not for here. Since this is a ‘modern’ build, there was no need for any funny business. Things just worked. Surprisngly, I know. Obviously for people years later this won’t hold true.

Binutils

Nothing much to see or say, just used binutils 2.46.0, and it configured/built out of the box. Nice.

../binutils-2.46.0/configure --target=ia64-linux-gnu --prefix=/usr/local/ia64-linux-gnu

GCC

This is a bit weird as, the Itanium is not a dying platform, but a very dead one. Although thanks to a single user, René Rebe keeping the flame alive, I just chose to use the mentioned version, 15 to see if it still works. Spoiler, it did!

Building on macOS also means I do have homebrew installed, and that instead of building so many dependancies from hand, I could just brew the dependancies for GCC. That did make configuring it a little more involved.

../gcc-15.3.0/configure \
  --target=ia64-linux-gnu \
  --prefix=/usr/local/ia64-linux-gnu \
  --disable-bootstrap \
  --disable-multilib \
  --enable-languages=c \
  --with-gmp=/opt/homebrew \
  --with-mpfr=/opt/homebrew \
  --with-mpc=/opt/homebrew \
  CPPFLAGS="-I/opt/homebrew/include" \
  LDFLAGS="-L/opt/homebrew/lib"

There is some weird duplicate define of fdopen that throws off the build, thanks to zlib. I know wtf.

In file included from ../../gcc-15.3.0/zlib/zutil.c:10:
In file included from ../../gcc-15.3.0/zlib/gzguts.h:21:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdio.h:61:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:322:7: error:
expected ')'
322 | FILE *fdopen(int, const char *) __DARWIN_ALIAS_STARTING(__MAC_10_6, _...
|   ^
../../gcc-15.3.0/zlib/zutil.h:140:33: note: expanded from
macro 'fdopen'
140 | # define fdopen(fd,mode) NULL /* No fdopen() */

The fix, of course is to comment out line 140 of zutil.h

After that, it’ll mostly build, (remember to have the binutils binary in your path!
export PATH=/usr/local/ia64-linux-gnu/bin:$PATH )

It’ll complain about missing pthread as it want’s to build all the Linux stuff, but we don’t care.

In file included from ../../../gcc-15.3.0/libgcc/gthr.h:157,
from ../../../gcc-15.3.0/libgcc/libgcov-interface.c:27:
./gthr-default.h:35:10: fatal error: pthread.h: No such file or directory
35 | #include <pthread.h>
| ^~~~~~~~~~~
compilation terminated.

I did have to manually copy libgcc.a however.

cp ia64-linux-gnu/libgcc/libgcc.a /usr/local/ia64-linux-gnu/ia64-linux-gnu/lib/libgcc.a'.

Then just cd to the gcc directory and run a make install.

And with that, I’ve now got an Itanium cross compiler, to build the firmware!.

jsteve@Jasons-Mac-mini gcc % /usr/local/ia64-linux-gnu/bin/ia64-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/ia64-linux-gnu/bin/ia64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/local/ia64-linux-gnu/libexec/gcc/ia64-linux-gnu/15.3.0/lto-wrapper
Target: ia64-linux-gnu
Configured with: ../gcc-15.3.0/configure --target=ia64-linux-gnu --prefix=/usr/local/ia64-linux-gnu --disable-bootstrap --disable-multilib --enable-languages=c --with-gmp=/opt/homebrew --with-mpfr=/opt/homebrew --with-mpc=/opt/homebrew CPPFLAGS=-I/opt/homebrew/include LDFLAGS=-L/opt/homebrew/lib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.3.0 (GCC)

Neat!

Qemu

I’ve defiantly homebrewed some dependencies in the past, but I’ll be damned if I know what exactly.

First get the source (as of this moment, July 31st 2026)

git clone --branch merced --single-branch https://github.com/makuhlmann/qemu-system-ia64.git

Then make a build directory, as we don’t build in the source!

Configuring on macOS is of course…. weird.

../qemu-system-ia64/configure \
  --disable-qom-cast-debug \
  --disable-stack-protector \
  --extra-cflags='-O2 -fno-stack-protector -fzero-call-used-regs=skip -ftrivial-auto-var-init=uninitialized' \
--disable-guest-agent-msi --disable-werror --enable-slirp \
--target-list=ia64-softmmu --disable-sdl  --python=/usr/bin/python3

Since I’m on macOS, I wanted to use the coca backend, so I don’t care about GTK+ or SDL.

From there it was just a matter of running make… I did a -j6 to use six cores it tore through the source, stopped after a few minutes with some weird error, I just typed in ‘make’ again and it finished…. Not sure what it’s hangup was, and I really don’t care.

**EDIT

Newer builds now require iasl from ACPICA

For this installation I’m using this image:

5.1.2600.0.xpclient.010817-1148_ia64fre_client-professional_retail_en-us-WXPIFPP_EN.iso

It’s got a MD5 checksum of : 604ee3141ed6a34391a89a33c0019702

As there are many versions of XP Itanium, but it’s so easy to get the wrong one.

Installing

Now for the ‘hard’ part. Getting this to actually install.

First create a hard disk, say 20GB ?

./merced-build/qemu-img create -f vmdk ia64-xp64-merced.vmdk 20G
Formatting 'ia64-xp64-merced.vmdk', fmt=vmdk size=21474836480 compat6=off hwversion=undefined

This is what I use, thanks to Roy Tam!

merced-build/qemu-system-ia64-unsigned \
    -bios ./merced-build/roms/ia64-firmware/ia64-firmware.bin \
    -machine ia64-vpc,i8042=off,nvram=ia64fw-nvram-merced.bin \
    -cdrom "5.1.2600.0.xpclient.010817-1148_ia64fre_client-professional_retail_en-us-WXPIFPP_EN.iso" \
    -hda "ia64-xp64-merced.vmdk" \
    -accel tcg,thread=multi,tb-size=2048 -smp 1 -m 1536 \
    -vga ati -cpu merced \
    -display cocoa,zoom-to-fit=on \
    -nic user,model=i82557a,hostfwd=tcp::3386-:3389

And with that, it’ll launch into the EFI firmware

Being greeted by the firmware image, is again confirmation that we can indeed cross compile the Itanium firmware with our GCC cross compiler!

And then the CD-ROM will prompt to hit any key to boot from CD

At this point I should mention that Qemu doesn’t scale well with high resolution monitors. But since we enabled the zoom-to-fit option, we can resize the window so we can read it, or just maximize it.

From here it’s basically a normal XP install

Unlike the RISC of old, the creation of the system partition is now handled by the install program, like all the other EFI/UEFI platforms.

Which I have to say, is a nice change.

From there just select the remainder of the disk, I format mine as NTFS (quick) and from there it’ll start copying the files. For me this completed in under 5 minutes.

A quick reboot and you’ll now be in the graphical installer.

From here it could crash or lock hard. In that case, re-create the hard disk image, and re-try the installation. It took me 5 attempts. Although I should mention that I never could complete a single install using syunn’s fork.

And when asked, I just chose the default networking settings.

In prior builds this would fail and/or hard lock at various moments, with an overall success rate of 1/5. Not the best. Although I’ve only installed XP 2600 once today, and it was a 1:1 rate in 30-40 minutes, so I guess I can say that as always, things are in motion, and getting way better!

On my m4, it took about another 30 minutes, and then It’s done.

And there we go!

I’d highly suggest setting up RDP, and using a remote desktop application, as the arrow keys currently tend to repeat far too often making typing a chore. Plus it’ll fix any coca video scaling issues.

Future?

Well what about the 2003 version of Windows XP?

Namely: 5.2.3790.0.srv03_rtm.030324-2048_ia64fre_client-professional_retail_en-us-NRMPIFPP_EN.iso

Using the same config, different ISO, yeah it installed in about 40 minutes on my m4 Mac Mini.

Why, even the earliest Windows Server Itanium build that’s available, 5.1.2462 installs and runs! Of course, install it prior to August 2001.

What about other operating systems?

As of now I don’t think anything else works. Monterey didn’t do much, nor HPUX, VMS etc.

Where to go from here? Compilers! and whatnot. Needless to say, since this is 1st gen Itanium, all the stuff I’d built when I had an Itanium won’t run as it was Itanium2. Don’t you love broken binary compatiblity?

This is why 80386 is just as relevant in 2026 as it was in 1987.

Of course, Apple will break it, just because they can.

In the past I did some and some more work on SimCity/Micropolis to bring it to vintage computing. This old DUX SimCity / Micropolis works remarkably well, but because of the TCL/TK and X11 UI, platform availability is quite limited. I have previously also ported Micropolis to Windows NT (RISC) as WinTown.

But thats not enough! I wanted to run SimCity on a vintage Unix without dependency on X11 and TCL/TK. The game graphics (basically a map) is quite simplistic and structured. I was wondering if text mode rendering would work. Quite a while ago I winged up a quick ncurses based map/city viewer and it was quite promising! Fast forward to today… Behold TTY City!

The game is quite usable and playable. In a modern terminal it even supports mouse with panig and simple animations. Earthquakes look pretty cool!

The monochrome terminals are little more difficult, but I’d say is playable.

Here is a picture from an actual DEC VT420! Not bad!

When perfecting the letters and characters, I had this idea… what if modern terminal amenities could be used… like Unicode Emojis perhaps? After all you can have these and these in rendered in a terminal

Behold Unicode Emoji Terminal SimCIty!

Available from: https://github.com/tenox7/ttycity – there are no releases or packages yet, as it’s work in progress but expect it to be available for most modern and vintage operating systems!

PRs welcome!

Have fun with Virtualization!