While I had posted endlessly about this particular computer, as someone that I had long desired as a kid, overall, the PS/2 model 60 is an underwhelming machine, with an exceptionally high price tag. Many other fans of other 80s 16-bit computers, were able to augment their weak processors with faster 16bit CPUs, and even 32bit processors. As it turns out, the IBM PS/2 also had options:
Is another $425 worth the sunk cost of a $10,000 286?
On the one hand, I have to imagine that if you could afford a $10,000+ 286 in 1987 you probably would have upgraded to something else in the last 5 years. The Kingston upgrade heralds from 1993, and well that 10Mhz 286 is pretty much borderline useless for productivity. I’m not even going to talk about gaming! DooM is right around the corner being released at the end of the year, and how on earth can you justify this monster of a machine at your desk?
So let’s unpack this little doodad!
Installation
The old 80286 & 80287 processors removed.
The first step in the manual says you need to extract your main processor, and maths co-processor if you have one installed. The FPU’s are so cheap now, it seemed crazy to not get one. Although the only thing more bizarre is that considering the asking price of the PS/2 model 60, is that the FPU was even considered optional. This was a serious business machine afterall!
Pin 1 of the 80286 processor socket
With the processor extracted, the next big task is to identify pin 1. Looking from the top it’s impossible to see, but rotating the board around it’s easier to see the indentation that they left on the board to denote pin 1. Unfortunately, the socket they used has no visible indication, and Intel had not learned the importance of keying parts yet, making incorrect insertion impossible.
With pin 1 identified, it’s now time to gently insert the upgrade module.
Fully loaded module
I had also purchased the 80387sx 25Mhz math coprocessor. Combining this with the IBM IBM 486SLC2-50 (50G6950) should give a rather 486 like experience. And keeping with 80s tradition all the chips point in various directions making this look like a mess.
Physical installation is as simple as that, with the module socketed we are go for power on!
BOCARAM/2 strikes back
Since this is the model 60, that means I’m still using that BOCARAM/2 card that totally messes up with the BIOS settings, so I have to remove the card, and configure things one card at a time.
But it does work!
Brining up MSD it does indeed show that it is a 486, with built in math coprocessor. I didn’t try it without one, to see if it becomes a 486SX, but I guess it would?
Default performance however…
Default clock speed
For some reason it felt faster doing the initial memory test. But that was demonstrably false. By default, the upgrade module runs at the original speed, meaning you have 32bit instructions at the 286’s 10Mhz clock. There is an included driver for MS-DOS & OS/2 2.0 GA that will turn on all the fancy features, but that means that it won’t work for Windows NT, or Xenix. SAD.
Turbo CPU
However, with the driver enabled, we are talking 386DX/33 speeds! Making this 2x the speed of the PS/2 Model 80 @16mhz!
Yes it runs DooM!
And why yes, it runs DooM! Performance is terrible since the memory is all 16bit, and the VGA on the PS/2 model 60/80 motherboards is 8bit, well there is so much performance left behind.
The 32bit port of Sarien to Pharlap 386 v4 /Watcom7 is pretty fast as well!
DUMB SCSI is the best SCSI
And SCSI remains a winner with the 32bit dumb SCSI card in a 16bit MCA slot, I still get 2,318.9 Kilobytes/Second
The good
The upgrade when compared to a new system is a fantastic bit of value. People had been buying and selling 386sx machines, which are basically full feature 286 machines with the hobbled 16-bit external 386 processors. Into the early 90’s all the rage was faster clocks, internal clock doubling, and yet even more cache. The later PS/2 model 80, running at 25Mhz did include the 82385 cache controller, and soldered on the motherboard cache ram, making it the best of the 80’s.
The bad
There is literally only so much you can do with a 16bit machine, and it being 1993, the Pentium was already shipping it’s 5v 60/66Mhz variant, with the infamous FDIV bug. Over the next year the Pentium would see it’s voltage dropped to 3.3v, and clock speed increased. Good times. The Pentium would drive 64-bit memory access along with faster 33Mhz PCI bus making it an incredible machine. Even a hopped up 286 is vastly outclassed, with its ancient and laughably tiny MFM hard disks, and 16-bit memory/peripheral bus.
If you are hanging onto a computer from 1987 in 1993, odds are you have old software anyways, and this is such an incredibly compelling upgrade for such an old klunker. By default it preserves the 286 speeds on boot if you so need them, but it’s nice having some 32bit POWER.
Although I wouldn’t want to use GCC on a machine this starved of resources, not even in 1993.
So I had gotten this Boca Ram/2 card with 2MB of RAM, with space for an additional 6MB. Unfortunately trying to find matching memory has been a lost cause. Since the existing memory is 9 chip modules, I take that to mean it’s parity RAM, so I went shopping for much more available 3 chip modules.
2MB!
I picked up 2x 1MB modules for £10.
Slotting them carefully into the ram card, taking great care as the clips are plastic!
4MB of ram slotted, made in the USA!
Now from what I can remember being told is to never ever ever mix memory types like this. But logically I have to think that 9×1 = 4+4+1, right? RIGHT?!
I copied the @7A7A.ADF onto the reference disk image, slotted the card and booted up to the config, and toggled the card to 4M
4M (4 SIMM modules)
I didn’t trust the auto-config, plus I just wanted to see what was there. Also I’ve always wondered if the PS/2 model 60 (or 30? 50z?) can slot higher density than the 256kb SIMM’s that IBM had used. I guess one day I’ll give it a shot.
Anyways thinking that this is about done, I save the config and reboot and now It’s Bocaram/2 issues.
Immediately, on reboot I get error 164.
164 POST detected a base memory or extended memory size mismatch error.
1. Run F1 Setup. Check System Summary menu for memory size change. 2. Run the Extended Memory Diagnostic tests.
Booting from the reference disk just crashes the PC.
Fantastic.
Pressing F1 however does let you boot, ignoring the issue.
After a bunch of digging I found this zip file with some utils. And just guessing br2pmems ‘fixes’ the CMOS settings allowing the machine to boot normally.
So now it’ll recognize the 5MB of RAM, and just boot normally. GREAT. But booting the reference disk still hangs the machine.
Which then brings me to the next upgrade:
The IBM SCSI with Cache
The IBM SCSI with Cache aka the SPOCK. Since I ruined the one SCSI card, and ended up picking up a second card, but this time with the appropriate cable I’ve caused a massive market panic on Microchannel SCSI cards. Seriously check eBay, and you will see that the pricing has collapsed with many now selling in the £20-30 range. You’re welcome!
Not really wanting a 3rd SCSI card, but my eye saw this one with the cache RAM, and I figured if I wanted the ultimate PS/2 of course I’d want a caching controller. This looks to be the first rev of the PCB, but with the ‘hot fixes’ in place from the second rev. While the ROMs are stepping back to 1990, I don’t care much about the 1GB disk limit, as the BlueSCSI can emulate all the available devices in the chain, so I’m not losing anything in the way of capacity. This is a 286 after all.
Since the RAM card screws up the setup program, I have to remove it, and the old SCSI controller, re-configure the system with all the RAM and disks removed first. Then put in the new controller, and re-run setup.
I just accept the defaults, and reboot to check what happened. So far it looks good, slot 8 being near the middle of the PCB, and closer to the disk cage where the blue SCSI rests.
placehold all the drives!
Remembering that the IBM controllers inventory the disks backwards, the 380MB disk image on SCSI ID 6, is the primary boot disk. I didn’t set it to the full 1GB as I want to later see how older versions of DOS/OS2 work with this, and I know they have issues with disks bigger than 512MB, but I figured matching a disk that did exist in 1988 would be more realistic.
With the SCSI setup, I could put the troublesome Boca board back with the RAM, and get my system booting up with the new “faster” SCSI controller, and all that new RAM.
Old SCSI controller
Of course I did a few benchmarks on the old SCSI controller so I would know how much more awesome the new one is.
As you can see this is booted with my normal config.sys with a himem.sys and smartdrv from Windows 3.1 on a MS-DOS 5.1 install.
2,345.8 KB/sec With himem.sys & smartdrv
2,347.5 KB/sec with no himem.sys
2,316.6 KB/sec with runtime xmsmmgr & smartdrv
2,334.0 KB/sec with Windows 3.1 himem.sys no smartdrv
So, with these scores in hand, you can see that the penalty for various XMS memory access being turned on is there, but it’s nowhere near as massive as I’d have thought for performance. Even with it just being there, although again it’s so minimal.
Now for the real shocker:
2,079.2 KB/Sec
That’s right, the advanced card is slower. A good 11% slower. Well, that was disappointing. I’m still keeping it in the machine, as having a hardware caching controller was all the rage, just like Mach microkernels. Maybe it’d make more of a difference in a 32bit system, but it’s performance is very underwhelming. For anyone wondering, the WDC AC2340, is an EIDE 340MB hard disk, with a 64kb cache. Im sure it was considered very fancy, and fast for the era, and it’s nice to know that no matter the SCSI controller, the BlueSCSI blows it out of the water. Also keeping in mind that MFM data transfers are usually sub 400KB/sec, so this is much more faster.
Okay you have all this XMS what are you going to do with it?
Well, after I did manage to get this original copy of Word for Windows 1.0, I thought that it would be a good test. One fun thing is that it includes the ‘runtime’ version of Windows 2.11, which can also upgrade an existing install of Windows 2 if detected. Running Windows 2 on MS-DOS 5, does involve loading the setver command in the config.sys, and rebooting. Windows 2 cannot use XMS (more on that) but instead uses the older LIM EMS standard that allows a 64kb page to be viewed from a far larger card. Since the 8086/80286 still use 64kb segments it’s not all that crazy to use.
And that brings me to this great program EMM286!
It allocates a 64kb page in low ROM, and backfills it from XMS. So I give it 3MB, and now I have 1.3MB of XMS left, and 3MB of LIM EMS ready for Windows!
So now I have EMS & XMS! And didn’t have to get some pesky EMS board either. I am pretty sure you need device drivers to use EMS, so how do you use LIM EMS under OS/2 1.x? I have no idea. Probably not I guess?
Anyways I run word, everything is great, it sees extra ram. I exit windows, and unload EMM286, and ..
3.4MB of XMS available? Somehow I lost a megabyte of RAM from Windows 2?! I’m not sure what is going on, or why or how Windows even touched it. Needless to say if you want it back, you need to reboot.
DOS 10.21494KB free!
That’s right 494KB free! I thought MS-DOS under OS/2 just used some stubs in real mode, and called back to protected mode. No doubt this is totally wrong, there has to be some weird version of DOS+OS2 that actually runs in real mode going on here. I know that ‘bimodal drivers’ were a thing, but it sure seems like there really is a ‘real mode OS/2’ kernel with MS-DOS tacked onto the side.
Windows 3.0 standard mode, 286 + 5MB of RAM
It’s annoying OS/2 can’t tell you how much ram it sees and what is in use, but at least Windows 3.0 can. It’s more than enough to run Sim City, clearly making this one of the more expensive machines to run the game as intended. With the added RAM it doesn’t thrash as hard, but having emulated disks probably doesn’t matter as much as access time is always zero, and it’ll stream data as fast as it can. You can feel the difference moving between tasks, but things like the OS/2 file manager that loads a view into every directory is still incredibly slow. What were they thinking?!
Thouhts?
Back in the day this would have been an incredibly expensive upgrade. And is it worth it? The machine is still locked at 10Mhz. The FPU is also locked at 10Mhz, and you can feel it. The lightening fast disk access, despite it being some 11% slower is really hard to tell. Does the caching help at all? Applications don’t have to page in/out like crazy before as there is enough RAM to actually run them, but that is where the 10Mhz processor just isn’t there.
Just like the caching SCSI controller, I’m sure we’ve all heard how having that magical EMS memory would help out games like Wing Commander.
XMS/DOS High + EMM286 on the left, and just XMS + DOS High on the right
Well, I had to put them side by side, as I couldn’t believe it, but adding EMS made it noticeably slower. I was *NOT* expecting that. I should add that I used Vegas & this quick tutorial, on how to pan & resize one video to get them side by side. No doubt it’s not perfect but it’s enough to see that once the ship explodes, the performance on the EMS configuration is greatly throttled. It’s moments like this that makes me wonder is this something the caching SCSI card would do better implicitly? Or is it snake oil as well?
3MB is enough to load OS/2, and one application, just as Word v1 or Excel v2/v3 load just fine, but swapping between them is basically unloading one from memory, and loading the other back out to disk. It’s a shame RAM cost so much 1987-1992 as people really could have benefited from it. It’s just utterly bizarre that on such an outrageously expensive system that you even need RAM upgrade cards, it really should have been baked into the main logic board.
(This is a guest post by Antoni Sawicki aka Tenox)
I’m preparing a Windows NT RISC exhibition for VCF West 2023. While the CHM building is air conditioned, it’s far far from ideal and we have a rather hot summer. Most of the vintage machines lack CPU power management. Some, such as Alphas, are notorious for overheating. Despite installing modern fans and heatsinks, this still makes me uneasy. I wanted to come up with some thermal monitoring system to see whats going on in real time. Maybe alert or shut down if things go out of hand.
For a while now I been thinking about using Arduino with a thermistor. It would read the temperature sensor and send the data via serial port to the host. This should universally work for most old computers, as they commonly have serial ports. However, upon some prototyping I realized that between custom pcb/wiring, power requirements and TTL to RS232 converter, the whole thing was becoming a little too complicated for what I really wanted. Fortunately I came across a rather ingenious solution – someone sells this item on eBay:
It’s basically a thermal probe with RS232 interface, emitting a plain text ASCII string output. No drivers or software required. They are a little bit pricey. Perhaps readers can find a cheaper version. However it’s absolutely a perfect solution for what I really wanted. Note that the seller can make shorter cables on request. The default 3m is insanely long for this purpose.
With help of some thermal glue, installed the probe in to the CPU heat sink and routed the cable to a COM port in the back.
Above pictures are from Multia and PWS.
You can simply read the temperature as an ASCII string from the COM port:
However since this is a prestigious event I wanted something fancier. Also a simple terminal can’t really tell when was the data received and therefore is current. I banged out a simple Win32 app to have something nice on the screen:
If there is no update from serial port in last 10 seconds, “no data” will be shown. The text label changes color if the temperature goes over a threshold to warn if things are getting too hot.
I even added a thermal shutdown, if it goes over a critical value. However this only works on Windows 2000 and above. Earlier Windows NT versions lacked ACPI HAL support to invoke power down. Fortunately this will work nicely for 2210 build on PWS 500 and Windows XP on Itanium!
After VCF I’ll make something for Unix and VMS as well. Perhaps also a service / daemon version that can run in the background and doesn’t require GUI.
Since I was a kid growing up in Canada, everything was NTSC. And my first computer the Commodore 64 was of course NTSC based. My parents refused to get me a monitor, so I had to use the RF modulator to get it to work on a TV. In north America we had these RF modulators on the back of the TV’s to connect our systems up (Atari, Commodore, Nintendo, SEGA etc..)
And the picture looked terrible, it was an antenna so it was suspectable to all kinds of RF emission interference, grounding issues and all kind of all around problems. It’s no wonder I had 20/20 vision as a kid, but it was absolutely destroyed because I was even forbidden to buy a proper monitor.
So thanks to patreon and ebay, I found this amazing bundle for 49GBP, a Commodore 64, plus tape drive. The catch being it didn’t include any proper cables, so I went to Tesco and bought an RF lead. I have this weird LG TV, a LG 50PC1D 50in Plasma TV. The original list price was an eye watering £1800! I got it used a while back for a more reasonable £130.
Lots of Inputs!
While I was at Tesco, I didn’t see any kinds of RF boxes. I was hoping I could just plug the cable directly from the TV into the Commodore C64, and it turns out that is exactly how it works.
With the cable plugged in, I was able to eventually get an image. I found out that the LG is more than capable of locking the RF image from the Commodore 64, and it looks awesome!
One man and his Droid over the RF on the LG 50PC1D
It’s a lot better than I was expecting. Clearly RF on a ‘modern’ TV works great.
Of course getting this to work wasn’t all that intuitive, and again probably because I’ve only delt with NTSC TV’s where the channel would be locked to either 3 or 4. Not so in Europe.
Channel 4
So setting the TV to channel for, and the band to ‘cable’ you can see the distinct border of the basic screen. The image of course is useless but you can see it trying. And that is because after letting the TV scan and find the picture on it’s own it’s actually channel 36.
Messing with the image options I found that there is 3 systems to choose from:
System L
You can see the image trying to form under System L, but it’s obviously no good
System BG
While the image looks better, the speakers erupt with absolute static. And the image is a bit faint, but immediately recognizable. It does look better in person however.
System I
And finally we have System I, over V/UHF on Channel 36.
I don’t know if this will help anyone trying to get anything working. Maybe it’s only relevant for people new to PAL territories like me.
Shockingly no explosions, I was recapping stuff to notice that the PSU I’m using is sliced. Of course a 35 year old PSU runs better. I need some transistors, and maybe some diodes, but I don’t have good access to any at the moment. So weird how 80’s DRAM could need +12/+5/-5v to operate. Oh well.
So I wanted to capture some composite PAL signals, and well yeah I have a fancy capture card but it’s only HDMI of all things. NO VGA, EGA/CGA and sure no composite. So I headed down to Sun CHeong Computer Co. Ltd. 246 Apliu Street Shum Shai Po, and picked up one of these.
Although it’s not all that great, I have a webcam, and toggling between the display inputs can trigger a bluescreen.
So yeah it’s not so great.
I can’t really comment on the quality of the capture as it turns out I don’t have any RCA cables, so this is me running a jumper wire to the device directly. This is FAR from ideal but here we go:
So yeah…. It’s probably me, but there you go. at $99 HKD ($13 USD?) it’s not great. Actually its damned near temperamental. But its better than nothing.
While talking about home brew 8080 and 8086 systems on Discord an ebay search brought me to Elijah’s store page where this small little curiosity was up for sale. It’s literally just a NEC v30 on a Raspberry Pi hat, for a mere $15 USD! Interestingly enough the v30 can operate at 3.3v meaning no special hardware is required to interface to the GPIO bus on a Pi. This reminds me so much of the CP/M cartridge for the Commodore 64, and the price being so right I quickly ordered one and eagerly awaited to 2 weeks shipping to Asia.
While I have Pi 4’s that I run Windows 10 on to drive some displays & power point, I wanted to use the slightly faster Pi400 for this. The Pi400 has a compatible GPIO expansion port so just like a cartridge it’s a simple matter of slotting the card, powering up and building the software. While there is an included binary, it’s a 32bit one, and I’m running Manjaro on the Pi400 for a similar look/feel as the PineBook Pro. Anyways the dependences are SDL2, and an odly named ‘wiringPi’ library that allows C programs to interface to the GPIO.
You can download the emulator over on homebrew8088, specifically the Raspberry Pi Second Project. The last ‘ver 2’ download has the project configured for a v30 which is an 8086 analogue, unlike the v20 which is an 8088. When physically interfacing to the processor things like this really matter!
With the emulator built it was pretty simple to fire it up, and boot into MS-DOS:
first boot!
I have to admit I was a little startled at first as I really had no idea if this was going to work at all. I’d spoken to an engineer friend and he was saying plugging a CPU directly into the GPIO bus, and toggling connections to actually emulate the board was both crazy and that without any electrical buffers it’d most likely either fry the processor and maybe the Pi as well. I suspect this being low voltage may be sparing both, although I have no EE so I’m not going to pretend to know.
Loading up Norton SI confirms what Elijah had posted on Ebay is that it runs very slowly about 1/3rd the speed of an XT. Now I may not know anything about hardware but this seemed at least something a profiler could at least tell me what is going on, and if someone like me helicoptering in on the shoulder of giants could see something.
This will build a profiled version of the emulator that’ll let us know which functions are being called both the number of times, and how much time to do so. Not knowing anything but having profiled other emulators, the usual pattern is that you spend most time fetching and possibly translating memory; Both in feeding instructions and pushing/popping data from stack and pointers. Waiting is usually for initialisation and for IO.
Once you’ve run your profiled executable, it’ll dump a binary file gmon.out which you can then use gprof to format to a text file like this:
gprof pi gmon.out > report.txt
And then looking at the report you can see where the top time, along with top calls are. Some things just take a while to complete and other well they get called far too often.
As expected Start_System_Bus takes 1 second, followed by 1,100,374 calls to set the Data_Bus_Direction_8086_OUT (no doubt the Pi needs to alternate between reading and writing to the CPU), followed by 5,954,106 ticks of the CLK function. Of course the real culprit is Print_Char_9x16 which was called 286,883 times, and is responsible for nearly 40% of the tuntime!
Obviously for a simple MS-DOS boot the screen should not be calling any print char anywhere near this many times. Clearly something is amiss. Not knowing anything I added a simple counter to block at the top of the Print_Char_9x16 function to let it only execute 1:1000 times, and I got this:
Obviously it’s not right, which means that the culprit really isn’t Print_Char_9x16 but rather what is calling it. It was a simple change to each of the Mode functions to only render a fraction of the time, and I changed it to a define to let me fire it more often. This is a simple diff, assuming WordPress doesn’t screw it up. It’s not pretty but it gets the job done.
$ diff -ruN ver2/vga.cpp ver2-j/vga.cpp
--- ver2/vga.cpp 2020-07-29 10:36:51.000000000 +0800
+++ ver2-j/vga.cpp 2021-06-04 01:51:33.546124473 +0800
@@ -1,5 +1,9 @@
#include "vga.h"
+static int do9x16 = 0;
+#define VIDU 5000
+
+
void Print_Char_18x16(SDL_Renderer *Renderer, int x, int y, unsigned char Ascii_value)
{
for (int i = 0; i < 9; i++)
@@ -23,6 +27,12 @@
void Mode_0_40x25(SDL_Renderer *Renderer, char* Video_Memory, char* Cursor_Position)
{
+do9x16++;
+if(do9x16>VIDU)
+ {do9x16=0;}
+else
+ {return;}
+
int index = 0;
for (int j = 0; j < 25; j++)
{
@@ -36,6 +46,7 @@
Print_Char_18x16(Renderer, (Cursor_Position[0] * 18), (Cursor_Position[1] * 16), 0xDB);
SDL_RenderPresent(Renderer);
}
+
void Print_Char_9x16(SDL_Renderer *Renderer, int x, int y, unsigned char Ascii_value)
{
for (int i = 0; i < 9; i++)
@@ -57,6 +68,12 @@
}
void Mode_2_80x25(SDL_Renderer *Renderer, char* Video_Memory, char* Cursor_Position)
{
+do9x16++;
+if(do9x16>VIDU)
+ {do9x16=0;}
+else
+ {return;}
+
int index = 0;
for (int j = 0; j < 25; j++)
{
@@ -102,6 +119,12 @@
void Graphics_Mode_320_200_Palette_0(SDL_Renderer *Renderer, char* Video_Memory)
{
+do9x16++;
+if(do9x16>VIDU)
+ {do9x16=0;}
+else
+ {return;}
+
SDL_RenderClear(Renderer);
int index = 0;
for (int j = 0; j < 100; j++)
@@ -156,6 +179,12 @@
}
void Graphics_Mode_320_200_Palette_1(SDL_Renderer *Renderer, char* Video_Memory)
{
+do9x16++;
+if(do9x16>VIDU)
+ {do9x16=0;}
+else
+ {return;}
+
SDL_RenderClear(Renderer);
int index = 0;
for (int j = 0; j < 100; j++)
While it feels more responsive on the console, it’s still incredibly slow. SI was returning the same speed which means that although we aren’t hitting the screen anywhere near as often it’s still doing far too much. Is it really a GPIO bus limitation? Again I have no idea. But the next function of course is the clock.
First I tried dividing the usleep in half thinking that maybe it’s not getting called enough. And running SI revealed that I’d gone from a 0.3 to a 0.1! Obviously this is not the desired effect! So instead of a divide I multiplied it by four:
Now it’s scoring a 1.5! Obviously these are all ‘magic numbers’ and tied to the Pi400 and more importantly I haven’t studied the code at all, I’m not trying to disparage or anything, if anything it’s just a quick example why profiling your code can be so important! At the same time trying to run games is so incredibly slow I don’t even know if my changes had any actual impact to speed as emulation of benchmarks can be such a finickie thing.
My goto game, Battletech 3025 Crescent Hawks Inception loads to the first splash but then seems to hang. I could be impatient or there could be further issues but I’m just some impatient tourist with a C compiler…
With my changes and re-running the profiler I now see this:
Which is now what I expect with the bulk of the emulation now calling Read_Memory, with the Clock following that and of course our tamed screen renderer (although its still called far too much!) with the Data_Bus_Direction being further down the list. No doubt some double buffering and checking what changed in between calls would go a LONG way to optimise it, just as would actually studying the source code.
The one cool thing about this is that if I wanted to write a PC emulator this way gives me the confidence that the CPU is not only 100% cycle accurate, but it’s 100% bug for bug accurate since we are using a physical processor.
And again for $15 USD + Shipping I cannot recommend this enough!
The following is a guest post by PA8600/PA-RISC! Thanks for doing another great writeup on that PowerPC that was going to transform the industry!.. but didn’t.
The history of the PReP platform from IBM is quite interesting, not only because of its place in the history of Windows NT but also the history of the PowerPC architecture in general. When the PowerPC platform was new, IBM (just like a few other vendors, notably DEC) had grand plans to replace the x86 PC clone market (they helped create) with PowerPC. Of course thanks to various factors such as Apple’s refusal to play along, the launch of the Pentium Pro CPU (and the later Itanium disaster), and high cost, this plan never ended up panning out. Later IBM PReP machines were designed for AIX and Linux use only, and they were sold as regular old RS/6000 computers.
Still, Microsoft being Microsoft and willing to port their OS to literally anything hedged their bets and made MIPS, PowerPC, and Alpha ports of Windows NT (along with a PC98 release for Japan only). In the guest post about Solaris for PowerPC I made, I talked about the history of IBM’s PReP platform some more so you should go read that post if you want an initial rundown on PReP’s flaws and history. But I have learned a bit about the Windows NT port for PowerPC, and I discovered a rare version of it as well. By now everyone with a PReP machine (or PPC Thinkpad) has run Windows NT 4.0 on it, and if PReP machines are emulated it’s guaranteed this will be the second most run OS on it aside from AIX of course.
IBM also made a half-baked OS/2 port for PowerPC as well, and then there’s the previously mentioned Solaris port. All of these are rarities and it’s worth documenting. With how rare PReP machines are and their high prices on eBay when they do turn up for sale (or their tendency to be snapped up fast), I think it’s fitting to write perhaps the most in depth look at PReP hardware that anyone has seen.
Windows NT 3.51: “The PowerPC Release”
It’s commonly accepted that Windows NT 3.51 was the first release for PowerPC hardware and it was even called this within Microsoft. Featuring HALs for most of the early PReP machines including the Moto Powerstack, the rare FirePower machines built for NT (which used Open Firmware), the Power Series 6050/70 (and maybe 7248), and the unobtanium IBM 6030, it’s pretty much what you’d expect for a first release for PPC. It’s a polished, solid OS that’s arguably faster than NT4 on the same machine. Aside from the red boot screen (on my Weitek GPU), it’s pretty much Windows NT 3.51 but on the PowerPC. It’s like running NT 3.51 on MIPS or Alpha, it’s interesting but more software will likely run on 4 anyhow (especially on Alpha).
One interesting quirk of Windows NT for PowerPC is it does not report the CPU type of your machine. It simply reports “PowerPC” and what machine you’re running it on. It does not tell you that you’re running it on a 601, it tells you that it’s running on an IBM-6015.
Unsurprisingly Visual C++ 4 works on PowerPC Windows NT 3.51 as well. This is no shock, Visual C++ 4 was designed to work on 3.51 as well as NT 4.0. The same goes with many of the pre compiled programs. One advantage Windows NT 3.51 offers over 4.0 is that it is simply faster than 4.0 on the PowerPC 601.
There’s not much else about Windows NT 3.51 for PowerPC quirk wise that hasn’t been said elsewhere about NT 4. It runs in little-endian mode (one of the few PPC OSes to), it has 16 bit Windows emulation that’s slow, and it needs specific PReP machines to run. One interesting series of articles about the “behind the scenes” of the port worth reading is the Raymond Chen article series, and this discusses the quirks of programming a PowerPC 60x CPU in little-endian mode as well. It can be installed with the same ARC disks NT4 uses, and of course the same SMS and firmware disks will work. In fact QEMU at one time was capable of booting the IBM firmware image from these disks.
Here’s something I’ve found out from research however. There was actually a limited release of Windows NT 3.5, it’s been dumped, and it is a real operating system. It also requires a very specific model of RS/6000 to work, and one with a interesting history giving it a unique place among the PReP machines. While I was unable to make it work in the end, I did discover and document a lot of interesting features of PReP machines.
Enter Sandalfoot: The IBM 7020/6015 (and demystifying PReP machines)
To understand the HCL and weirdness of Windows NT for PowerPC (and why it won’t run on Macs), we need to take a look at one such machine it runs on. This is my RS/6000 40p, a machine that was given several brand names by IBM and used as a development platform for PReP software and operating system ports. This is also perhaps the most historically significant RS/6000 model from the era. While it wasn’t the first PowerPC RS/6000 (that honor goes to the 250), it was the first to use the PCI and ISA busses and it was a few months ahead of both the initial PCI PowerMacs and other PReP boxes. It’s also one of the few true bi-endian machines as just like other PReP machines, the MIPS Magnum, HP’s Integrity, and modern Power8+ machines it has OSes for both endians available.
In 1994 (presumably October 28, if the planned availability date is correct), IBM released the RS/6000 40p (announcement letter here, codenamed Sandalbow) and the Power Series 440 (codenamed Sandalfoot). Both are near-identical machines with different faceplates and boot screens. The RS/6000 ranged in price from around $4,000-6,000 and was designed to be an entry-level AIX workstation, bundling a copy of AIX with each machine. As an AIX machine it’s relatively slow and fits the entry-level badge quite well, but thanks to the 601’s POWER instructions it served as a transition machine over to the later 604 AIX machines. Unlike the later PowerPC 603 and 604 machines, it featured POWER instructions allowing it to run both legacy AIX POWER software and later PowerPC software. The Power Series was presumably sold to those wanting a PReP box for Windows instead.
Since IBM PReP hardware is so obscure and undocumented, I’m going to document this as best as I can being the owner of an IBM Model 6015/7020. The machine features a 66mhz PowerPC 601 (similar to that of the Power Mac 6100 and RS6K 250), PCI and ISA slots, and IBM’s “Dakota” PReP firmware (more on the boot process here). It uses an off the shelf NCR 53c810 SCSI controller, Crystal CS4321 sound chip, an Intel 82378 PCI bridge, and a NIC can be inserted into the ISA slots (mine has the famous 3com Etherlink III). The Super-IO chip is also off the shelf, and is a National PC87312VF. The clock IC is a Dallas DS1385S, a close relative of the Dallas DS1387 (with internal battery). At least some of the IBM custom ICs are the chipset ICs and those are also documented. A Linux 2.4 dmesg can be found here.
Mine is also maxed out at 192mb of RAM, however there are some solder pads for more and the chipset is limited at 256mb. This makes me wonder if the system was based on a reference design of some sort. There was an ultra-rare 604 upgrade as well, but considering how there are more 7248 and 7043 machines in the wild I can assume many customers just waited for that instead due to its superior AIX performance.
If the idea sounds familiar (off the shelf chips + RISC CPU) it’s because it was the very same idea used to create the two other non-x86 Windows NT platforms. The Microsoft Jazz MIPS platform most MIPS NT boxes were influenced by was infamously based on the same idea of a “PC with a MIPS CPU”. To a lesser extent, this was also seen on the DECpc AXP 150 and other EISA/ISA/PCI based Alpha machines designed to both run Windows NT and DEC’s own OSes. Crazy undocumented custom hardware and expansion busses were thrown out the window in favor of industry standards. In fact when I posted a photo of the motherboard to a chat full of PC nerds, they stated it looked remarkably like a normal PC motherboard. The whole industry would later adopt PCI and sometimes ISA on non-x86 machines to cut costs and reuse the same expansion cards.
The main difference between the RS/6000 40p and the Power Series variant is the boot ROM logo and chime. The RS/6000 and “OEM” systems used a boot ROM that featured the PowerPC logo and just a beep, while the Power Series machines featured a logo more closely resembling the PowerPC Thinkpads complete with the chime. One can boot firmware from a floppy as well by typing in the name of the ROM image in the prompt and pressing enter, and watching as it reboots once the firmware is loaded into RAM. Here’s a video I filmed demonstrating this, along with some other quirks including there being two SMS keys: F1 for a nice flashy GUI SMS and F4 for a text based SMS, along with F2 for netbooting (with the right NIC of course).
The Sandalfoot machines were LPX form factor machines, featuring a riser card and generic sheet-metal case popular with prebuilt machines from this era. The LPX form factor was wildly popular in the mid 90s due to its versatility, seeing use by both IBM and DEC for their RISC machines, various PC builders, and even Apple for the clone program and clone based Power Macintosh 4400. The Sandalfoot machines also drove home one of the core goals of the PReP project, which was to build a PowerPC platform using as many off the shelf and PC style components as possible instead of using lots of custom ICs like Apple did. I dug out one of my cameras to take a few high-res photos of the motherboard of this computer to illustrate this. Compare this to the motherboard of the Power Macintosh 6100 or even the 601 based 7200 and notice the bigger heatsink and use of fewer custom ICs (Apple loved those).
There were three main GPU options: the famous S3 Vision864, the Weitek Power 9100 (or P9100 for short) as a higher end option, and IBM’s own GXT150P. The S3 was the entry level GPU and the Weitek was a higher-end and faster GPU. The GXT150P is beyond the scope of this because it is unsupported on the other PReP OSes, only AIX. The other two video cards are essentially unmodified Diamond PC cards with the BIOS chips missing.
The Sandalfoot machines are perhaps the most important PReP machines due to their role in PReP OS development. Both OS/2 Beta 1 and Windows NT 3.5 were written for this machine in particular as it was one of the first PowerPC machines to support PReP and feature PCI/ISA slots, unlike the NuBus Macs released a few months earlier or the first PPC box: the MCA based RS/6000 Model 250. They also often shipped with the well documented and emulated S3 Vision 864 video card, a common GPU family in PCs of the time to the point where it was even included on some motherboards and emulated in too many PC emulators/virtualization programs to count (notably 86box/PCem). In fact it’s successor (the 7248) featured one soldered to the motherboard.
Windows NT 3.51 was dubbed the Power PC release, because it was designed around the Power PC version of NT, which was originally supposed to ship in version 3.5. But IBM constantly delayed the Power PC chips, necessitating a separate NT release. “NT 3.51 was a very unrewarding release,” Thompson said, contrasting it with Daytona. “After Daytona was completed, we basically sat around for 9 months fixing bugs while we waited for IBM to finish the Power PC hardware. But because of this, NT 3.51 was a solid release, and our customers loved it.” NT 3.51 eventually shipped in May 1995.
I think a more accurate thing to write is that there simply weren’t many PReP boxes out in late 1994. Windows NT 3.51 supported the Motorola PowerStack series, the IBM 6050/6070 (and maybe the 7248, which came out in July 1995), and rare FirePower machines. Windows NT only features HALs for the 6015 (Sandalfoot/Power 440/RS6K 40P), 6020 (Thinkpad 800), and the 6030 (a rare IBM machine that likely was only sent to a few developers). By 1995, there were more PReP machines on the market and this made the NT 3.51 release logical. NT4 even supported a few servers, mainly the RS6K E20, E30, and F30.
Windows NT 3.5 was most likely a limited release for testing purposes on the Sandalfoot machine as it’s HCL file declares it as “Build 807” with a date of October 18, 1994. The date seems to be around a week or two before the first 40p machines at least shipped. Some more files were modified later on and the folders were created on November 9th, 1994. Hardware support is very barren, and the readme file even has a section dedicated to quirks of the 40p along with a list of supported software for the x86 emulator. This might have been considered a beta as well, as an announcement letter for the Thinkpad 800 (6020) explicitly mentions Windows NT and that this version might be a beta for developers. It also talks about a Windows SDK for it and a Motorola compiler used to build 3.5 software.
However the real problem for me has to do with getting a video card. Windows NT 3.5 for PowerPC does not support the Weitek P9100 GPU that came with many RS/6000 branded machines, and neither does OS/2 for PowerPC. It only supports the S3 Vision 864 and 928 video cards. It’s listed in the setup options, but choosing it causes a txtsetup.sif error. I’m going to assume that the development units came with the S3 video card instead. My box contained a Weitek card which works for AIX, Solaris, and Windows NT 3.51/4. I bought a card from eBay to use with NT 3.5 and the OS/2 port.
The readme also features an ominous warning with the S3 video cards, that only revision B3 is supported and that 928 cards need 2MB of VRAM for anything above 256 colors. My revision of the card I ordered was B4, so I took the risk of seeing if it worked with my system. I also removed the ROM chip as the system initializes the video card itself and that having a ROM chip can cause the system to not complete the self-test or display video. As the IBM Weitek card lacks a BIOS, I did this.
Despite the scratches on the card from possibly coming out of an ewaste pile, the card worked fine in both a PC I inserted it in for testing purposes and the IBM system. I now had a 40p with a GPU much more well supported among non-AIX or Windows NT operating systems.
Anyhow, let’s talk about the install process in closer detail here. Windows NT for PowerPC installs in a similar manner to Solaris for PowerPC on the IBM PReP machines. First the floppy disk boots ARC, then when you choose to install it the machine copies the ARC bootloader/firmware to the hard disk so it can load it from there at each boot. The floppy disk can also be used to load ARC if the loader is damaged on the hard disk. Keep in mind, on IBM machines ARC is not stored in the ROM unlike on many other ARC capable machines so this has to be done. The Firepower machines do something very similar by using an Open Firmware shim, and unsuccessful attempts at emulating PPC NT have exploited VENEER.EXE to attempt booting instead of using the IBM firmware. It fails because they’re not emulating the hardware, just trying to find a quick way to just boot NT.
Once this is done, the installer loads up and installs just like every other NT install. It checks the HAL by reading the machine ID, what video hardware the machine has, and whatnot to prepare the installer. You need a IBM 6015, 6020, or 6030 according to the HALs it has and only the S3 video cards are on the HCL.
Or that’s what should happen. I first tried using ARC 1.51 as it worked for 3.51 and was greeted with a HAL error BSOD:
I first attempted to use older ARC boot floppies and I got somewhere, the BSOD changed to the classic 07b, and then I got nothing else. Using ARC 1.48 and 1.49 gave me this, I got some i/o error with ARC 1.46 (the first 3.51 ARC floppy), and any previous ARC floppy is most likely undumped. I’m assuming either the error is due to an ARC mismatch, a weird firmware mismatch/hardware revision mismatch, or some incorrect SCSI ID Solaris style. There might very well be some weird forgotten trick to making it work (maybe a Windows expert could dig through the files and find some weirdness), but I’m going to move onto another obscure PPC rarity:
OS/2 PowerPC Boot Attempts: Beta 1 and the Final
Recently the OS/2 Museum site dumped Beta 1 for PowerPC. It’s an earlier version of OS/2 for PowerPC that insists on a Sandalfoot machine with an S3 GPU. Unlike the other OS/2 PowerPC disc, it features a verbose boot featuring the kernel it uses. If you want to really see OS/2 for PPC working, try it on a 7248 or read this post about it.
This failed to boot, throwing up an error about mounting the disk or something. I did record it doing something at least however, an improvement over the Weitek which just does nothing at the PowerPC screen. I tried several things including removing the external SCSI CD drive and that didn’t fix much. It also declares 88c05333 an unknown PCI device.
So I decided to try the “final” build. The final build requires a 6050/70, and some people did get it working on the PPC Thinkpads. I decided to see what it’d do on my machine. Unsurprisingly it did absolutely nothing but give me a blank white screen and sometimes a 00016000 error (for a trashed CMOS). If anything the 6015 loves to trash it’s CMOS contents for absolutely no reason, especially when OS/2 is involved.
Anyhow this was very anti-climatic, as the OSes I threw at it found reasons to not work on it whatsoever. I weeded out the GPU being at fault by testing Windows NT 4.0 and finding out that it works just fine with the GPU, however I seem to have fewer resolutions available than what the Weitek card allows. It did change the boot screen font, making me wonder if the red boot screen is a GPU driver quirk.
However changing the device IDs with OS/2 PowerPC Beta 1 got me somewhere, as I now got a screen about the HDD failing to write. I formatted the HDD to FAT using the ARC diskette, then I nuked all the partitions, but not much else changed. I’m not sure what the error means, but it was a letdown.
Unless these OSes require some long lost firmware, I’m wondering if there’s else that’s causing issues with installation. Either way, it was a letdown. Nothing I tried worked and I spent hours messing with everything from SCSI IDs to using different drives.
Enter the Pi1541! What makes this different from the SD2IEC is that this emulates both the 6502 processor of the 1541 drive, it also emulates the two 6522 chips as well giving far stronger emulation. Is this enough to satisfy CP/M? Or is my issue something deeper?
Cleaned up a little
So in my continuing adventure of stuff arriving for my Commodore 64 project, I took the opportunity to pull the keyboard apart and clean it. I didn’t do any weird retrobrite thing, as I don’t care that this looks 30+ years old. And I haven’t swapped out any further caps just yet, although I did also get a big box of random caps ranging from 0.1 to 220uF, so I can probably do all the small stuff on the board when I feel like it next.
It took a bit extra effort to get this far.
The IEC cables had finally arrived, and that means I could connect up the Pi1541 hat I bought and get this project going.
Although it’s the latest ‘rev 4’ board, it doesn’t support the Pi4 (does anything support the Pi4? What an evolutionary dead end!), auction did include the LCD display, but no software, and no serial cable. The cooler looking one I wanted was all assembled in Poland and they are unable to ship.
Bummer.
Anyways, turns out the software is written by one Stephen White, who doesn’t get any cut of the board sales, but in turn I guess they aren’t bundling the software either… I’d have imagined it’d be some kind of 1+1 thing, but it’s not to be. I guess it’s also why so many people keep on thinking you can buy a PiZero for $5 or so, when they are much closer to $25.
Anways, getting the initial part of the board working was just a matter of reading Steve’s site, and following which files to be download, and where to be placed onto a FAT32 formatted SD card. This is one of those ‘bare metal’ type projects, so this also doesn’t run Linux.
Unfortunately for me the Pi1541 didn’t do ANYTHING on powering on, that is until I connected the HDMI cable. And yeah what a let down. And even worse when trying to load anything it’d just hang. So frustraiting!
But thanks to this post by jerrykurtz over on lemon64, I was able to put together this fragment to get it working (for me!)
Now this of course works for my v4 hat, and the way I like it. Also keep in mind that if the C64 isn’t detected it will appear to hang after loading the chargen ROM. It took a while to figure that out, until I just turned on the c64 to see what would happen. I also hate having it change disks when I power cycle, so IgnoreReset was a great feature, well for me anyways.
I fired up CP/M, and yeah it’s doing the same thing. So it turns out that it’s not the SD2IEC adapter that I have. I’m kind of mixed about this, on the one hand that’s great as the SD2IEC’s are significantly cheaper and easier to come by, at the same time I had hoped a little that the bigger investment of the Pi1541 would make the difference. At least it’ll be the difference for stuff like Ghosts’N’Goblins Arcade.
CP/M Planetfall
One interesting thing is that SOFT80 is now faster, getting somewhere between 1-3cps. It’s still totally unplayable, but I guess that’s progress?
Still waiting for the dead test cart to see if it tells me anything useful.
So since CP/M is acting all wrong, there is clearly something up with the C64. I hadn’t opened it yet, and I almost regret doing so as despite it ‘working’ it was a MESS!
After separating the case halves, and unplugging the top LED, I saw that capacitor C66 had exploded. There was some faint hint of staining from the top, but I didn’t expect it to be something like this.
The board was disgusting, like the cap had something spilt onto it? Then it ruptured? or did it rupture? it still powered on and ‘worked’ despite this gunk.
Isopropyl is in short supply still, so I did something probably dumb, I took a 50% baiju a brush and gave it a quick rinse.
Cleaned up board
with all the fuzz removed it’s a 250469 REV.B… which I understand is a pretty late model. It’s one of the short boards, which not a lot of chips, which I’d hope means fewer things to fault, although at the same time, some of these chips are going to be impossible to source.
Also, I should add that I found various C64 schematics online, and none had a 470uF cap for C66. Maybe I’m going crazy? I found an E-bay auction for replacement caps, and yep, they also have a 470uF in there. Am I crazy?
TONEREX 50v 470uF(M)
Now I was hoping that being in Hong Kong, that means I could actually find some retail shop actually selling capacitors. So I went around the audiophile places and scored this higher voltage cap for a whopping $5 USD! The store owner was insistent that this was for ‘high end audio gear’ and not my toy 80’s computer. That this thing was somehow some magical ‘audio only’ capacitor. Has anyone heard such a thing? Is this like audiophile grade SATA cables?!
Massive cap installed!
So I replaced the cap, and NOTHING. The power led turns green and that’s about it. I had to dig up a simple volt meter and yeah power is going places. I gave up and went home for the night. Turned it on this morning expecting a POP or further disappointment, and it fired up.
A bit of digging around I found HeadAlign v1.1, which I transferred to the SD2IEC, and much to my amazement the stupid tape drive started working, although it was a full screw turn out of alignment, and it looked normal (no picture). I rewinded the tape, and loaded up Hans Kloss, and it worked!
Sadly CP/M still is printing far too many things to the screen. I guess I need to replace more caps, and keep on waiting for that dead test cart to get a bit of a further hint. Although my soldering skills are terrible.
