32bits of disappointment, upgrading the IBM PS/2 model 60

So long..

While I had enjoyed this fully loaded 286, it was getting a bit annoying with all the 32bit limitations I was running into. Frontier Elite was a 32bit program, Obviously no WIndows/386 nor any DooM. It seems that most of the MS-DOS fun I had really was 32bit only. So with this PS/2 model 60, I did the only real thing I could do:

PS/2 80 motherboard

I swapped the motherboard with a PS/2 model 80 board. I had seen this on eBay for a bit of an excessive price, offered 40% of said price, and woke up to having shockingly won the bid. Of course it also means that I need special 32bit RAM to boot the board, because “IBM”.

a 1MB module

I picked up 2 of these 1MB modules, they are 3 chip much like the SIMMS I had used on the PS/2 model 60 motherboard. So these are no doubt parity 256k in each row, and 2 cards giving it 2MB of RAM right off the bat. I got lucky to find these 2 cards in country and at a really reasonable rate, when compared to all the others. They did make 4MB & 8MB cards, but naturally they are incredibly expensive.


Luckily for me the board & RAM worked (the board was listed as working), and running setup from the gotek was painless. However for the heck of it, I put in the Boca RAM/2 board to see if it works. It does. It also does the same thing where once the Boca RAM/2 board is configured the setup program only crashes on running it, meaning I need to disconnect the battery backed RAM.

I thought I could avoid setting up the RAM card, but oddly enough until I did so it would not initialize the SCSI card. Oh, sure it showed up in the setup program, saw all my disks and everything, but it would not boot or show up from a boot disk.

So now let’s re-visit the painful world of SCSI disks. I had bought one SCSI controller, and tore some pads off for being impatient, bought another and had it working fine with the approved cable, crashed the PS/2 MCA SCSI market, and then bought the caching faster controller card, to only reveal that it is in fact slower than the stupid card.

But it’s a 32bit card!

And now I have 32bit slots and a 32bit processor! Surely it’s going to ROCK!!!!….?

32bits of disappointment

It’s 0.3% faster.

What the actual FUCK. I mean ok BlueSCSI is great, and we’ve seen it perform faster with the ‘stupid’ card. I can’t imagine paying the $999 MSRP of this faster caching card to find out its slower. Nor the massive upgrade cost of going 32bit to find out its only slightly faster.


Just Wow.


That said, v86 mode is really cool!

My goto test for v86 is BattleTech the crescent hawk’s inception. I mean if Windows/386 can run this, everything else should be able to. And yeah, 16Mhz is almost enough to run this in a window. It screen tears like crazy and is just slow. But at least it runs!

Warning beeper music!

Although football was capable of doing this full screen in 1987, and Windows/386 could run it in a window in 1987 as well, it wasn’t until 1989/90 that OS/2 could with the much delayed 32bit version. Of course, the divorce happened after Windows 3.0 became such a massive seller, and OS/2 was delayed. again. While I had no issues under 86Box, I had plenty of weird issues on real hardware that seem to magically sort themselves out by running Infocom’s Planetfall first. I don’t know why either.

16Mhz Wing Commander

And luckily there is some difference in running at 16Mhz. Although I haven’t tried EMM386 on/off yet. The 286 had it’s excuse of copying pages in & out of protected mode, and the switch time being so horrific. But the 386 should be instant, only limited by it’s slow bus and I guess 4MB of slow RAM.

But what about DooM?

DooM v1.1 low resolution not quite postage stamp sized

Yes DooM v1.1 runs! I’ll have to try some Fast DooM later to see how much faster it can be! I’d like to think itll be faster but I am not holding out much hope.

Many of the bench stuff I had setup on the 286 to compare to the 386 sadly depend on a math processor. The problem of course is that 80287’s are very cheap for some reason. 80387’s however are not.

eBay special

And the majority of them look like this. I don’t know how on earth people have hundreds of 80287’s to sell at super cheap prices, but 80387’s all seem to have been trampled, or had their inner core’s turned into slag. I will keep a lookout, although knowing my luck it may be cheaper to find another motherboard with a 386/387 paring.

Speaking of OS/2 and weird crashes, I got this fun one from OS/2 trying to run sysinfo:

trap 000e on 038600b1

While I’d seen plenty of trapcodes in my time, but I know less than nothing about reading them. Maybe it’s burred in there somewhere. The one odd thing was the 038600b1 part… Since the 386 is a 16Mhz part, maybe it’s a crazy old version? While it does have the ΣΣ mark, maybe there is other troublesome 386’s? I really don’t know. Or maybe OS/2 is just really more sensitive to having 2MB 32bit RAM + 4MB 16bit RAM.

Way back in the old times, I had upgraded from a 12Mhz 286 to a 16Mhz 286, and life was great, although I left out of all the 32bit personal computer revolution. After a lot of hard work, I managed to secure a 386sx 16Mhz board with 4MB of RAM. It was awesome although yeah SLOW. Clock for clock, task for task the 386sx was at best the same speed. Sometimes I’d swear the 286 was faster. A few months later though I made the insane trade of some complete in box Infocom games, along with cash and was able to score a 386DX 16Mhz, along with 4MB of 32bit RAM on some massive board. Surely this was going to be great right? I found pretty much the same thing there was no perceivable difference at all. At least back then it was 1992? and the capacitor plague was still decades away, and you could just call the BBS of the motherboard vendor and download the disks if needed (I didn’t need to). It was, frankly, a big letdown after so much ’32/32 is far superior to 32/16′ and here we are again in the future and the SCSI card bears it out, that id basically didn’t matter.

I guess it really comes as no surprise that the 386 does everything the 286 can just better.

So, what have we learned? The PS/2 model 60/80 chassis is the exact same thing. The low clocked 386 chips are super unimpressive, no doubt the magic in the intel family really didn’t hit until the DX2/66 and beyond. Beta versions of software act weird, oh, and that the backup program from MS-DOS 5.00 can actually backup a dual booted OS/2 install & restore it just fine. That was a bigger surprise for me, as the great thing about the BlueSCSI i that I can have so many drives, so I made a backup of the C: OS drive and trashed it quite a bit. Not expecting anything, but yes, a restore actually worked.


I’m not sure why I never heard of this format back in the day when it was relevant. On the surface it sure sounds great, 4.7GB capacity, widespread vendor support, and there is no ‘sessions’ to close, or the entire disc needing to be erased to re-use the disc.

Enter DVD-RAM, it’s not a MO (magnetic optical drive), it works by cooking the disc to flip the bits. But still it’s a read/write optical disc, that uses lasers, what isn’t to love?

Groovy disc

Well sadly the answer is pretty much eveything.

I think I found the format from the video “DVD-RAM: The Disc that Behaved like a Flash Drive” from Technology Connections.

Curiosity got the best of me, I paused the video, and bought 2 used discs for a whopping 3.99, and a 4.99 drive. Sure, it’s all cheap but how bad could it be? The discs were used in some DVD video production, and formatted UDF. I used XP to format them as FAT32. First thing is format from the CLI so you can clearly see what is going on.

bad sectors

I did this after the fact, and yeah bad sectors. This is the hint of why everything I tried on this blasted disc at best ‘kinda worked’ but for the most part didn’t. It’s not a little damaged, its totally worthless.

Windows – Delayed Write Failed

Battle Tech is so small it’ll fit with a copy of Windows/386 on a 1.44mb floppy disc, and yet the DVD-RAM struggled with this level of data.

I was going to do some kind of SQL bench thing of how terrible it was, but I couldn’t even create a database.

Everything I tried was non-stop failure.

I then tried the other disc for the hell of it.

Format complete.
    4,471,152 KB total disk space.
    4,471,136 KB are available.

       16,384 bytes in each allocation unit.
      279,446 allocation units available on disk.

           32 bits in each FAT entry.

Volume Serial Number is 941A-7AA7

And yeah, it worked. All my “simple” tests just worked, and they completed in a fraction of the time the other disc struggled and failed with. Using MS-DOS level file sized stuff it seemed to work great with, however remembering the optical drive they do love to spin up and down, and if the disc is spun down, reading files can take SECONDS… So that kind of sucked.

Formatting the disc takes 30-45 minutes. It is not fast by any stretch of the imagination. During the format you can hear the drive constantly spinning up and down. Clearly you can see why hard disks rock, as they can keep the media spinning at the same rate. I’m not sure if it’s seeking around a lot or what is going on. I have to wonder if it was possible for any drives to maintain a constant speed? Would it have mattered?

I’ve seen outrageous claims on how long the media should last, far too long for it to be viable. When I hear about all the early SEGA CD drives all dying, turns out those lasers don’t last for centuries, there is no way this media is going to be viable at all.

I have to wonder if there really is any validity to this medium. I mean I have 2 discs that were recorded on in 2008, and in 15 years I have a 50% failure rate. Not good.

It’d be really terrible to recommend this stuff for pretty much of anything. The spinup/spindown basically kill any hope of using it for random access.

It’s no surprise that the ever increasing capacity of flash drives, and the economies of scale driving prices of flash down killed any hope for optical media.

The real question is will any 8/16MB flash sticks work in 2024 and beyond?

It’s all so depressing. If you have anything even remotely important on any optical disks, get them over to NVME or hell anything else.

Building OS/2 apps from QuickC for Windows

Hello from QuickC for Windows

Back in the olden days of when Microsoft had pivoted out of OS/2 in a hurry, I’ve always felt that the common ‘OMF’ objects ought to link for OS/2. But for some reason I never tried. But for some reason I thought I’d try it today.

I first installed Microsoft C 6.0, and set it up for a native OS/2 to OS/2 1.2 setup. This way I get a pure OS/2 include/library directory set. In retrospect, I don’t know why I didn’t just use 2 include / library directory sets to far easier target stuff, without dealing with changing the default names, and making linking an all around living hell.

So the first thing to do is to tell QuickC for Windows to default to the OS/2 include directory (turns out it wont link anyways). Compiling is nothing special. When setting up the project you’ll need a DEF file, I use this simple one:


Nothing to it!

I tried to fight the Windows linker, but it figures out what you are doing and won’t do it. But can you manually link? Well QuickC for Windows does include a DOS linker, and it’s oddly enough newer than the one for Microsoft C 6.0!

C:\proj\o2>msdos \WIN16APP\QCWIN\bin\link hi.obj

Microsoft (R) Segmented-Executable Linker  Version 5.15
Copyright (C) Microsoft Corp 1984-1991.  All rights reserved.

Run File [hi.exe]:
List File [NUL.MAP]:
Libraries [.LIB]: doscalls SLIBCE
Definitions File [NUL.DEF]: qco2.def

C:\proj\o2>msdos hi.exe
This program cannot be run in DOS mode.

Manually invoking the linker wasn’t all too hard, just answer the 30 questions. I did set the LIB environment variable so it picked up the libraries just fine. And yes, it created my OS/2 binary no problem!

And as you saw from above, yes it does run!

I do suppose the graphical editors would have been nice some 30 years ago, but in today’s era, sadly it doesn’t matter. QuickC for Windows won’t run under WLO, so this prevents it being a backdoor GUI/Protected mode compiler for OS/2. It’s a shame too as at least running under Windows 3.0, QuickC for Windows is WAY faster than using Microsoft C 6.00 in either read mode, protected mode with smartdrive.. I’m not sure what the deal is. Even with the advanced caching SCSI controller.

Not sure if anyone cares, but I think it’s cool.

Since there had been some confusion on how to install MacOS 9 on OS X

I thought with this iMac G5, the least I could do is make a quick video of how to do it.

Low effort video

I’ve done the hard work of converting the eMac 9.2 install CD to read-writeable, updating the system folder, then converting that back to a read-only image so the MacOS install can happen.

I’ve uploaded the file over on archive.org: ro-macos9updated.dmg.

The steps are somewhat simple basically download & mount the disk image.

Open up the prefrences, go into classic and select the

Then hit start to boot the image.

Then go and run the installer

Uncheck everything from the options

Customize the install and ONLY select Mac OS 9.2.2 & Internet Access.

The install took less than a minute on my G5

Go back to preferences, and stop Classic

Unmount the disk image, and open classic again & select the System Folder on the Hard Disk.

Start up Classic from the hard disk, and OS X will want to update the System folder

MacOS will want to run the setup wizard but since the ‘Bluebox’ isn’t a real Mac, I just cancel it

And then you are good to go!

Knights of the Old Republic PowerPC

I just scored a G5 iMac for £20 with a damaged panel. It doesn’t bother me at all as I’m not going to use it for anything serious, I’m just wanting something mainstream.

I did want one thing which was KOTOR.

So I looked up eBay, and yeah turns out it’s a collectors thing?

£147!! No way!

I saw this for far less, the Star Wars Mac Pack!

vBut at the flip side had this ominous warning….

Intel only

I thought I’d just try the disc anyway.. nothing to lose?


and yeah, not only is KOTOR is PPC, but yes it does run on OS X 10.4!


granted it’s on steam, gog and of course available for pretty much anything modern. And sure yeah, it was originally PC/Xbox, but for some odd reason I’m feeling nostalgic for that last gen PPC.

Re-visiting Red Ribbon Linux on the PS3

£24 kit!

So after basically facing defeat, I thought I’d give Linux on the PS3 another shot. Last time things just didn’t work for some reason, and although I could boot Linux from the USB, I couldn’t get it to partition the hard drive. And running from USB 2.0 is just insanely slow.. Especially when it’s trying to run X11.

I followed the instructions here: psx-place.com.

Having already installed CFW 4.90 Evilnat Cobra 8.4 [CEX] on my PS3, I downgraded to the suggested REBUG_4.81.2_REX_EMER_INIT_PS3UPDAT.PUP version of the firmware.

Loading is a bit weird requiring you to load, then entering safe mode, re-installing, then recovering again.

One silly thing to note, is that although a USB keyboard got me through the majority of this, you ABSOLUTELY NEED a PS3 controller to his the PS button to continue in safe/recovery mode. I ended up buying a new controller for £12 on eBay. Used ones were selling for the comparable price, so why buy something with ick on it? Sadly, this did double my budget to £24.

But rest assured just keep pushing through.

Although my FLASH was clearly re-partitioned, with it not changing as I had expected the recovery boot didn’t work, so I had to jump the instructions, and install REBUG_TOOLBOX_02.03.02.MULTI_.16.pkg and select boot into safe mode from there, and re-apply the firmware.

over and over….

But eventually success!

You ABSOLUTELY need a PS3 controller to hit the PS button here!

Finally on enough reboots, I got to the setup screen for a clean system!

Re-installing the toolboox took me to repartitioning the flash (again), powering off, then loading petitboot for NOR flash (well mine is NOR), powering off, then prepping the USB, and this time booting with the ‘use current’ option.

While I had busybox & running from initrd/USB before so far so good, nothing looks different.


This time the create_hdd_region.sh actually did what it should do! Excited I rebooted back to ‘gameos’ and checked the system status

finally a partitioned PS3!

I’m not sure why it kept failing before, but this time it did what it should have done. Obviously, I screwed up something before, and I’m not sure what.

Booting back to the USB drive, Red Ribbon booted up in X11, allowing me to run run the installer.

The volumes by default are fine.

It does give the ability to set locale, region, and machine name. I don’t know why but I tried it twice and it failed every time.

So I just hit defaults, just setting input & language to EN-us for American English in Alaska. I mean why not. I gave up on just fighting and just let it go with defaults.

And with that I had the PS3 up and booting!

Sadly it wasn’t all sunshine and rainbows, I was noticing some important software like m4, unzip, gdb, autoconf/automake/libtool file, htop/ncurses to say a few!

Compiling however lead me to kernel crashes & panics.

Stackframe panics!

Eventually it’ll hard lock.

I speculate its probably my PS3. The optical drive doesn’t work so I’ve never played a game on it, or done anything intensive until compiling software. I did find that disabling the swap space to video ram stopped it from crashing. As a matter of fact I disabled a bunch of things to get back some performance.

In the /etc/rc2.d just rename the S*** to K*** for the following to disable all of this stuff..

K01nmbd K01ps3-eyetoy K01ps3-rsx-swapon K01samba-ad-dc K01xrdp K02smbd K03bluetooth

The other thing was to just plain disable X11. I’m going to ssh across the network, so I don’t need the PS3 hogging my TV:

(live)neozeed@redribbon:~$ cat /etc/X11/default-display-manager

So yeah, not sure why I had goofed this up so bad, but in the end I got what I wanted, a big endian machine on a budget. What is interesting about this Red Ribbon thing, is that the kernel looks 64bit, but it’s all a 32bit userland. I don’t know if it matters so much. The place to get deb’s is long gone, so I guess Id have to find something with source this was based off of to build the missing stuff, or just keep going on, and building from source. I’m find with either, but I don’t need it as a desktop so my motivation is already waning. I can’t imagine even trying to use a 256MB PS3 as a desktop. It’s just pain.

Dumping nice ‘desktop’ services conserves a great deal of RAM

Again I’m not sure why the swap to video ram thing kills the PS3, but I can live with avoiding it.

Thanks to dazzaXx, for the instructions.

Inside Windows 2000

part 1

A talk from Dave Probert on the design of the NTOS kernel. Shame Microsoft didn’t put this anywhere people could have found this 20+ years ago, just as a shame they never opened up NTOS like they did that even tepid Windows Research Kernel. It goes without saying this is the ‘Linux is a cancer’ generation, with the crazed idea that looking at Linux would contaminate Windows.

PART 2: https://www.youtube.com/watch?v=OrohgqgzhgM

PART 3: https://www.youtube.com/watch?v=SUK_OfEMQos

PART 4: https://www.youtube.com/watch?v=JqnvmedwkYc

Too little, too late I guess. It would have been an interesting foundation a long time ago.

And of course the ongoing work behind the scenes making Windows fully 64bit compatible on the Alpha at the time.

Stadia controllers can be re-flashed to generic PC controllers

Stadia controller

So I saw this controller for sale for 20. I figured that there ought to be a way to hack it to do something useful so it may be fun. Turns out all it needs is a re-flash of new firmware and it’ll become a generic controller.

All you need to do is peer it to your computer, go to https://stadia.google.com/controller and follow the prompts.

You might be slightly scared that the browser can talk directly to bluetooth devices, including the unlock, and re-programming the controller.

And yeah after that it’s all unlocked and good to go!

Not sure if it matters all that much, but for anyone wanting either a controller on the cheap, or if you bought into Stadia when it was a thing (did anyone remember other than the announcement and the expected cancellation?).

I guess it’s nice that google is providing an unlock service but I’m sure that won’t be around forever, so yeah. yay.

Patching Touhou 6 (Embodiment of Scarlet Devil) to run on a 3dfx Voodoo 2

This is a guest post from spaztron64

One thing that’s been bugging me for years at this point is the ability to run Touhou 6 on my PC-9821 V166. For a good few years I’ve been stuck with nothing more than a Matrox Mystique graphics card in that thing, which can’t create a D3D6 HAL context for rendering the game’s 3D elements. In 2021 I snatched a 12MB 3dfx Voodoo 2, in hopes of being able to play more 3D games on that machine. There were two major problems….

1) The USBHID.SYS driver for PC-98 Windows 9x conflicts haaaard with Voodoo drivers. Moving the cursor around corrupts memory and makes the system unstable or kills the driver in mere seconds of use

2) None of the Touhou games support secondary Direct3D devices

For those not in the know in regards to the second issue, DirectX allows you to use multiple DDraw and D3D capable GPUs on one system. By default it’ll set the video card outputting a signal on the primary monitor as the primary DirectX device, the secondary output as secondary, and so on. Most people only used one monitor on their Win9x PC back in the day, hooked up to their 2D capable card. The Voodoo 1 and 2 aren’t meant to act as 2D video cards, yet they had to support D3D initialization somehow, so they presented themselves as non-primary DirectX devices, usually secondary, in hopes that game developers would allow the end user to select their 3D accelerator of choice.

This was standard practice at the tail end of the 1990s, but it was falling out of use at the turn of the millenium with the demise of 3dfx and the general lack of need for multiple graphics cards in one system for 3D gaming. This presented a problem, as games that technically could be played on a Voodoo 2… didn’t, as they could never be told to use it through normal means. Hacky solutions existed, like 3dfx’s unfinished, buggy attempt at a Voodoo 2 driver for Windows 2000 that allowed it to behave like a primary display adapter for general 2D and 3D use, but it’s notoriously unstable and isn’t possible to use on 9x. I’ve used this method before to play Touhou 6, Max Payne 1, GZDoom, GTA 3 and Vice City on the Voodoo 2 through Windows XP with mixed results.

Once I got an NEC bus mouse for use on my PC-98, I could finally use the Voodoo 2 on it without constant crashing. This got me interested in trying to get Touhou 6 to work on it, which lead me to a path of pure pain.

For starters, Touhou 6 is one of those games that only use primary DirectX devices, like the unsupported Mystique, so I had to somehow coax it into initializing the secondary device instead. My first approach to handling this was through direct binary patching. I didn’t know where to look for the init routines, so I asked 32th System for some heads up, and he pointed me to a rough location in process memory where the appropriate CreateDevice calls reside:

I then searched for the appropriate opcodes in the game binary, and patched all 6A 00 (push 0, A.K.A D3DADAPTER_DEFAULT) opcodes to be 6A 01 (push 1), forcing the game to init the secondary D3D device.

While this initially did in fact work, the approach ultimately sucked for two reasons.

1) Static binary patching only works for that specific binary, and doesn’t carry across different versions.

2) This requires manually patching every CreateDevice call, of which there are many in Touhou 6

It is at this point that I started sharing my progress with friends. jbit was quick to hop in and say “Why the fuck are you doing it this way? Just make a d3d8.dll wrapper DLL”. This was absolutely the smarter approach, I just didn’t know how to do it since I don’t know jack about DirectX programming. Fortunately, he handed me a little VS project he worked on called d3dcutter that, among other things, wrapped the CreateDevice function, which I promptly modified to always push 1 instead of 0 to the stack for the device selection parameter.

This solved the two patching problems, and I had something to show for starters:

Now, I’m sure you can tell that the performance is absolutely atrocious. This came as no surprise to me, as while the Voodoo can absolutely render the game at a full 60FPS most of the time, the dinky little Pentium MMX 166 struggles hard at doing triangle setup for the backgrounds every 16 milliseconds. Remember, 3dfx cards had no Hardware T&L, so the game has to fall back to Software T&L. I think the following wireframe screenshot will help illustrate the amount of work the CPU has to do every frame:

“Well, I’m in luck!”, one might think as they remember that older Touhou games support framerate division by 1/2 (30FPS) and 1/3 (20FPS) as options in custom.exe… There’s just one problem.

The game just… fails to initialize the D3D HAL on the Voodoo 2 in the frame divided modes. Why? Beats me, I still haven’t figured it out and likely never will. Just more ZUNcode bullshit I suppose.

I then figured out that framerate division is handled by a variable (that can be set even lower than 1/3, by the way) which could be set at runtime, even when the normal 60FPS mode is used. I suspected that the game uses a different initialization path for the two modes, so I once again tracked down opcodes that expect the variable to be set to 0 in process memory, this time with Cheat Engine, and patched them in the binary. Well guess fucking what, the game fails to initialize even when the regular init routines are modified to expect 30FPS or 20FPS frame division to be set.

This approach simply wasn’t going to work. so I went with trying to set the variable at runtime. Unfortunately, I had to go back to version specific patching once more for this, since there’s no way to wrap this functionality through DLL means. Additionally, while this wasn’t hard to do with the game running in windowed mode with Cheat Engine on the side on a modern system, it was basically impossible on a Voodoo 2 equipped machine, as the game ran in fullscreen and it wasn’t possible to restore the window after an Alt+Tab.

My final solution was to generate a trainer in Cheat Engine for version 1.02d of the game, as it’s the last one with a working logic speed limiter, that would forcibly set the frame divider variable at runtime with a hotkey:

This finally allowed me to play the game in 1/3 framerate mode on the Voodoo 2.
This allows the game to run at full logic speed most of the time, as the CPU now has 40 miliseconds per frame for triangle setup, however there’s something wrong with how the card handles buffer swaps in this mode of operation, leading to a very back-and-forth stuttery image that’s very unpleasant to look at.

Can we do better? Well yes! The game uses so-called STD scripts for certain stage-specific data setup, but also handling camera movement and geometry generation. Using Touhou Toolkit, I was able to unpack the appropriate DAT file, decompile all the STD scripts, remove all geometry commands, and recompile them for in-game use. As there are no more backgrounds to draw, there’s a trail effect left behind every frame, but thankfully custom.exe has an option to forcibly clear the back buffer every frame.

The end result? A nearly tripled framerate in 60FPS mode, recovered just by not drawing any 3D backgrounds. The game still lags when lots of bullets are on screen, but this doesn’t really come as a surprise.

Windows NT 3.1 on DEC Alpha AXP

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

As I was preparing the Windows NT RISC exhibit for VCF west, I realized that I’m missing a rather important piece of the history. While I will be showing the potentially last DEC Alpha Windows build ever – AXP64 2210, I don’t have anything earlier than NT 3.51. It would be nice to showcase the very first RTM version – NT 3.1. From time perspective, NT did not get popular until the version 3.5 and later. Windows NT 3.1 would be considered rare even on a 386, let alone on a RISC CPU! So what RISC hardware does Windows NT 3.1 run on?


Not many! The HCL published on gunkies has a few more systems, but nothing that I have. The early MIPS based systems are all but unobtanium as of today. This is probably a good time to mention a little known port of Windows NT 3.1 to the DECstation 5000. However these builds are not found even on earliest NT betas. Not to mention lack of ARC firmware for this machine.

The Alphas were looking a little more reachable. The DEC 2000 Model 300 and DECpc AXP 150 are one and the same machine, packaged in a server and workstation cases. Code-named Jensen, DEC designed and marketed these specifically around Windows NT. Unlike prior Alphas, this model used a lot of “PC” components for increased compatibility and lower cost. Eventually paved way for the more well known DEC Multia. The Jensen has been seen floating here and there and many people have these.

I was able to get a loaner from Chris Satterfield aka Compgeke for the VCF. Having a working specimen at hand, I started looking at part numbers of various components. In an amazing streak of luck, in practically zero time I was able to find, buy and assemble a complete DECpc AXP 150 from spare parts on eBay! Without a case, but nevertheless. Also big thanks to Christopher Rivett for help with some fine details!

Franken Jensen built from spare parts off eBay.
Jensen running at VCF West 2023, with fans installed


  • Motherboard + CPU – DEC 70-29685-01
  • GPU – DEC/Compaq Qvision 1024/E (1024×768) – 126654-001
  • GPU – (Optional) Number 9 High Res (1280×1024) – 30-41800-01
  • HBA – Adaptec AHA-1742A EISA – 467806-00
  • NIC – DEC DE422-S EISA – 5021102-01
  • RAM – 4x 16MB, FPM, 60ns, 72-Pin, 12-Chip, True Parity SIMM
  • PSU – DEC/HP 30-37197-02, however a standard AT PSU may be OK

If you going to build one yourself, beware of overheating. Jensen runs rather hot and needs good cooling. Not only for the CPU. There is a section of the motherboard just under the EISA cards that runs incredibly hot. See the picture, where I have installed a large Noctua fan.

OS Install

There are many Windows NT 3.1 CDROMs floating around. I purchased a DEC branded, shrink-wrapped CD on eBay to use as a prop along with the machine. You can download the iso image here.

Installation of Windows NT 3.1 on DECpc AXP 150 is pretty straightforward and not that much different from the later versions. However as a prerequisite you will need the ECU floppy disk to configure the EISA slot assignments, card and jumper settings. After that you will have to go through various setup screens in ARC BIOS to configure system settings. Then you run arcinst to create a system partition and setupldr to install the OS. The rest of it is pretty uneventful. This is somewhat expected, as this was pretty much the only one and supported hardware combination, so must have been well tested. The only curious part is that the NT OS Kernel does not display any text during normal boot. Later versions of NT will display the build number and MP or UP kernel variant and dots indicating subsystem load progress. This is rather odd because I expected more text mode stuff from older NT version, but who knows.

Jensen NT 3.1 Boot Menu
Windows NT 3.1 on DEC Alpha AXP, DECpc 150 aka Jensen

Service Pack Saga

If you are even vaguely familiar with installing Windows NT at all, you will know that the very first thing you have to perform after installation, is to apply a service pack. NT 3.1 did have service packs, up to SP3. The problem is that, as you may very well expect, non-x86 editions were nowhere to be found in 2023. The only thing I could come up with was http://www.win31.de/ent31.htm, which had a German AXP and MIPS SP3, but no English! [It since has been updated…]. I had to do some real detective work to track down an US-English AXP SP3 version. I spent a few days going through various random CDs and ftp site mirrors of that era, with little luck. Eventually I stumbled on this README file, stating:

Due to space constraints on the Windows NT Service Packs for
International Versions CD, the USA Service Pack version 3 is located on
the Additional Windows NT Service Packs, Windows 3.11 versions, SDKs,
and DDKs CD in the NTSRVPC3\USA directory.

Bingo! After a few hits and missed I spotted this particular CDROM here: https://archive.org/details/microsoft-developer-network-january-1995-disc-4-of-15 – Now the OS is finally “servicepacked” 🙂


My general impression of NT 3.1 on DEC Alpha is pretty awesome. If you can overlook the age and some obvious shortcomings, the OS is pretty stable, solid and even snappy for such old hardware. An OS itself without apps is not much. While overall Alpha NT application outlook is pretty scanty I was able to find a several very interesting gems!

Most importantly, thanks to Chris, a DEC Windows NT Developers CD-ROM!

The disk has an incredible amount of demo, freeware, public domain and shareware applications as well as DEC marketing material.

Windows NT Developers CD for DEC Alpha NT 3.1

You can get a lot of DEC proprietary software like C++, Fortran, PATHWORKS, DECtalk, as well as X servers, etc.

However I was particularly interested in some 3rd party commercial apps.

For example there is an early version of DMC Calamus Desktop Publishing.

DMC Calamus desktop publishing on Windows NT 3.1 DEC Alpha AXP

Also a demo version of a vintage, text-mode SlickEdit, way before it was replaced by the Visual SlickEdit known today.

SlickEdit 2.3 on Windows NT 3.1 DEC Alpha AXP

There also is WinDev editior, which is quite superior to Notepad and has some code editing goodies and shortcuts to SDK tools, making it something of a simple IDE.

WinDev 1.56 on Windows NT 3.1 DEC Alpha AXP

Another big source is Windows NT Application Sampler CDROM, (also from Smithsonian).

One of the coolest thing found there is a graphical text editor called WinEdit. It has a ton of features and even syntax highlighting! It has since became my default to go editor / IDE on this system!

WinEdit 3.0E on Windows NT 3.1 DEC Alpha AXP

There of course is a Windows NT SDK with the M (MEP) editor.

Windows NT 3.1 SDK with M / MEP Editor on DEC Alpha AXP

There also are quite few public domain apps and games, ports of GNU software, Micro Emacs, Kermit, etc.

Update: CICA NT Shareware Collection has some interesting apps under the /alpha directory.

High Resolution GPU

One of things that was troubling me for some time was rather low resolution of the default QVision graphics card. The maximum being only 1024×768 is just not acceptable. Talking to several Jensen’s owners, no one even heard about anything better. However looking at the Windows setup options, I curiously noticed that the system does support one 1280×1024 video card – Number 9 GXE.

I simply assumed that such card would simply be unobtanium in 2023. However, digging through some old catalogs and spare part listings, I managed to find a DEC part number, which is 30-41800-01. Armed with this, I was able to find it via DEC spare part reseller that I often use. They had it in stock listed as “HIGH RES EISA 1280 x 1024 GRAPHICS”. The price wasn’t too bad either, at least compared to the whole endeavor. A few days later I received this:

After installation of the S3 driver (must be the Service Pack 3 version!) I was finally able to get 1280×1024 from the poor thing!

With this I should have a more cozy environment to compile and port even more apps 🙂

In future I want to try the Advanced Server edition as well as some early Betas with Alpha support.