The Harris HCX-9 aka TAHOE platform

A machine born in legend

This is a machine that is shroud in legend, and of course played an integral part of internet history but oddly enough almost all trace of it ever existing has vanished.

The release of BSD, aptly named the 4.3BSD TAHOE release was completed in June of 1988. However shortly after this release the makers of the CPU, Computer Consoles Incorporated abruptly exited the market killing off the platform.  What is interesting though is that while CCI was manufacturing the TAHOE processor, they also sold it to 3 other OEM’s, Sperry (which merged with Buroughs, and re-branded as Unisys), and ICL Ltd. and Harris is the only other one to have picked up the CPU for inclusion in it’s own machines.  Among them was the HCX-7, and the HCX-9.

The Harris HCX minicomputers were one of the possible machines that the CSRG team at Berkeley saw as a possible successor to the aging VAX line of minicomputers for their operating system.  While this may not have been the first port of UNIX or BSD for that matter, it was the first port of a 32bit BSD, that was included into the main VAX BSD source, and as such could be redistributed with the BSD license (which at the time required an AT&T 32V license).  The fundamental thing this did was to split out the VAX specific code as a mainstream port was to be rolled back into the main CSRG source, unlike any other 3rd party port at this point.

HCX-5

The HCX-5 ran an internal version of 4.2BSD, along with SYSV in a ‘dual universe’ config, while the HCX-9 was to be supported by the CSRG, as the file GENERIC.hcx9 indicates from 4.3BSD TAHOE.  As you can see the HCX-5’s starting price of $124,500 USD is if anything a continuing of the mindset that BSD only ran on super expensive minicomputers.

POWER 6/32 = HCX-9

Indeed from the config file in 4.3BSD TAHOE, we see this:

GENERIC POWER 6/32 (HCX9)

And for quite some time, I’ve always been searching for a CCI POWER 6/32, meanwhile it appears that was merely a reference platform that became the HCX-9 as indicated from the machine config file.  The evidence was hiding in plain sight, as always it was a typo that lead me here as I was searching for TAHOE processors, and came across people looking for GCC on the TAHOE, running BSD.  And following their threads I noticed that they were running Harris minis’ which then lead me to make the connection that the TAHOE was a processor, not just a machine, and that other vendors sold their own machines with the CPU.

Future cut short

Needless to say, once CCI exited the market these machines evaporated so quickly that they are only remembered in legend in BSD.  I’ve seen people debate if the machine actually existed, who put it out, or even what was it exactly? A workstation? Server?  As we can see from the Harris models, it was meant to be a minicomputer, to compete with the likes of the Digitial VAX.

Oracle Worker

As we can see from this ad, with Oracle support and the official porting target of the CSRG the HCX-9 was expected to have a bright future.  Instead it was cut so short there is barely any mention of it even existing.

Sadly this minicomputer target idea continued, as the CSRG sidestepped the commodity 32bit processors, namely the cheaper 68020 & 80386.

So a few things …

So after this comment, I decided to put a SIMH VAX running 4.3 BSD.  Back in the day, I used to keep a bunch of legacy systems online for the heck of it.  Although I don’t think it ever really took off.. But yeah I figured I should get something back online.

So this time I thought I’d make it somewhat.. different.. So anyways if you feel so inclined go ahead and telnet to

mud.superglobalmegacorp.com

And from there you can create a user account on the mud, and then it’ll create a user in the operating system.

 

I’ve loaded up a bunch of 3rd party stuff.. And since we are living in the past I managed to get the old news reader ‘rn’ to talk to olduse.net  The first time it runs it’ll complain a bunch but there isn’t much you can do except enjoy the ride.

Lynx is present but.. downloading stuff kind of stalls.

All I ask is you play nice.

I’ve added in the flash telnet app.

Some minor work on SIMH

So it’d been a while since I’ve booted it up, and I just went with the 3.8-2 rc2 release (I forget did that version ever get released..?) Anyways since I wanted to run my SIMH instance under a Linux VM..

Soooo I went through some fun to recompile it as a 32bit binary, as the slirp doesn’t work on 64bit machines..

I just built the 11/780 emulator as I wanted to run 4.3 UWisc on my VM (in a VM)..

You can download the build here.

As a reminder the installation instructions for 4.3 BSD Uwisc can be found on gunkies, and all the files needed are on sourceforge.  Also the 4.x BSD if_de.c driver errors out on receiving packets, and I’ve found it easier to just remove the error checking from the driver, and recompile the kernel and just boot that up.

I’m thinking of rebuilding the login process on 4.3 BSD to bring back AberMud, and self service user creation.  Years ago I used to host all kinds of ancient UNIX, and I’d like to bring back at least one..

Some speedup with AberMUD & 4.3 UWISC.

So I found out why it’s now taking FOREVER to logon to the mud..

It turns out that there were nearly 4000 entries in the hosts file. Wow that’s a tad crazy eh? I guess this tape of BSD shows what the internet was like before DNS. I also bumped the CPU up to 4%.. it’s far more snappier.

Now to see if I can get added to abermud.info

Also as mentioned in the prior post, the AberMUD tape doesn’t just magically install, you have to run the install.sh & install2.sh which will recompile everything and set some paths, then install the DB in /usr/tmp as -iy7AM .. I guess it’s harder to forcefully delete it. Anyways logon as ‘debugger’ set yourself up a password, then run ‘reset’ to finalize the placement of everything….

And looking at the mud_syslog you can see fun stuff like this:

GAME ENTRY: Neozeed[root]
GAME ENTRY: Neozeed[root]
GAME ENTRY: Gatto[root]
GAME ENTRY: Geophoto[root]
Neozeed slain by The Yeti
GAME ENTRY: Neozeed[root]
GAME ENTRY: Erazmus[root]
GAME ENTRY: Neozeed[root]
GAME ENTRY: Jose[root]
GAME ENTRY: Neozeed[root]
GAME ENTRY: Nek[root]
Nek slain by The Yeti
GAME ENTRY: Lumpy[root]

So I don’t feel that bad being slain by the Yeti. Maybe one of us can kill the thing.

** UPDATE **

>
The Yeti attacks you
You hit The Yeti with the scimitar
Your last blow did the trick

>
The Yeti has just died

AberMud

I never was that much into MUD’s but after reading this and this, I decided to go for it. Looking here, I thought I’d go with David Kinder’s revamping of the version 2 source.

I figured I’d try to run AberMUD on 2.11BSD / PDP-11 which didn’t go so well.. I know there is issues with the word size (it tries to switch on longs which it doesn’t like, I changed them to int’s and.. well sigbus. Not to mention I had to link with overlays and well.. I get the feeling you actually have to do something not just trust the linker.

32v is just too crusty, along with 3.0 BSD. 4.2 BSD was lacking a few functions (memcpy/strchr) so I grabbed some replacements and it just crashed. Looking back AberMUD dates from the late 1980’s so I figured 4.3 BSD would be a far better match. And I figured 4.3 from Wisconsin would certainly work the best for my needs. This time, only a minimal amount of hacking on the source was required, and more importantly it worked!

So here is a tape file with the source & binary.

The next thing I figured I’d do is put it online. Now my VPS runs a 64bit version of Linux, and seeing this is a VAX exe/OS I’ll need to run it on SIMH. Since I’m going to allow people to telnet it (I guess I could go thru some hell with the serial line mux) I’ll need my SLiRP build of SIMH, which only runs clean as a 32bit exe. So to get things started, first install 32bit support on x86_64 debian like this:

apt-get install ia32-libs

Then using Slackware 13.37, I made my exe, and uploaded it… And it worked fine! I also set the cpu to throttle at 3% so I don’t get into trouble for running 100% of the time, and it’ll be about as slow as a real VAX 11/730… It’s a simple line in SIMH, but I tend to misplace things so here it is.

set throttle 3%

Simple, right?

Well I thought I’d make one more change. I hate those systems that make you login to run the designated program that you went there for in the first place. At the same time, this VM is born to MUD, why not let it MUD all the time? Simply replacing /bin/login with mud.1 let me do just that. And of course I could just add an option in mud.1 to allow me to have a normal OS login. Simple, right? Not to mention it works on the console just fine.

So, let’s connect!

telnet vpsland.superglobalmegacorp.com

I suppose I could hook up flashterm to it later, but for now, telnet on in. I’ve never run a MUD before so I guess we’ll see. Worst case it’ll suck and crash and the only evidence will be the tape image, and this post.

Old Unix tree’s

Well I was looking for a good way to see what changed between Net/2, 386BSD 0.0 and 386BSD 0.1 and it appears that nobody has a cvsweb of these early versions….

What is strange, is that cvsweb package for debian is lacking the actual cgi file.. So after going insane with cvsweb, I set one up.

http://unix.superglobalmegacorp.com/cgi-bin/cvsweb.cgi/#dirlist

I’ve never really setup a CVS repository before so this was my first shot…

rm -rf /var/lib/cvs
mkdir -p /var/lib/cvs
cvs -d /var/lib/cvs init
cd /var/www/unix.superglobalmegacorp.com/source/Net2
cvs -d /var/lib/cvs import -m “Net/2” Net2 CSRG Net2
cd /var/www/unix.superglobalmegacorp.com/source/386BSD-0.0
cvs -d /var/lib/cvs import -m “386BSD 0.0” Net2 BJolitz Jolix00
cd /var/www/unix.superglobalmegacorp.com/source/386BSD-0.1
cvs -d /var/lib/cvs import -m “386BSD 0.1” Net2 BJolitz Jolix01
cd /var/www/unix.superglobalmegacorp.com/source/NetBSD-0.8
cvs -d /var/lib/cvs import -m “NetBSD 0.8” Net2 NetBSD NetBSD08
cd /var/www/unix.superglobalmegacorp.com/source/NetBSD-0.9
cvs -d /var/lib/cvs import -m “NetBSD 0.9” Net2 NetBSD NetBSD09 

From what I saw the more the directories align, the better, so I moved all the i386 and other platform stuff into arch directories to better match NetBSD 0.9 …

I also setup src2html to browse various levels, it’s great for quickly finding things that may have moved… It’s here.

Now I just have to see about doing ‘forks’ in CVS and adding in the 4.4 lite stuff.

Downloads of my BSD on Windows..

bsd42 downloads

I just noticed that sourceforge is making changes to their downloads, so it’ll probably break a tonne of my stuff on this blog (and other places)… but look at the nice picture!

1. United States 913
2. China 321
3. Hungary 152
4. United Kingdom 111
5. Germany 73
6. Canada 36
7. Russia 36
8. Argentina 26
9. Japan 22
10. Greece 16

Which is interesting… well to me anyways. I wonder if it’s more representative of internet penetration, or language barrier?

Net Hack wiki moved

I just received notice that the NetHack wiki has now moved and the new site is nethackwiki.com.

It’s great when old software just doesn’t revive for a little while then fade back to obscurity, so update your links, or just browse the site and be blown away by all their information on such a great (and difficult) game.

And of course, I have NetHack for the Windows NT 4.0 MIPS, and various 4.X BSD on sourceforge under the package tapes….

The 2038 ‘problem’.

Eventually you will start to hear about the 2038 problem regarding UNIX, and the C language. Looking at the 4.3 BSD source, the problem is pretty simple.

The time_t value holds the number of ‘ticks’ since new years, 1970. It’s a signed long, that can hold a maximum value of 2147483648. This will set you into the year 2038. There is some great detail on the site 2038bug.com . Naturally the easiest option here, is to simply change it from a signed long to an unsigned long. This will let us use a maximum value of 4294967296, which translates to the date Sun Feb 6 06:28:15 2106.

While this is not a “perfect” solution for some people, this works great on platforms that are not built with compilers that can understand 64bit “long longs”. Not to mention that constantly updating a pseudo long long could have negative implications in the kernel….

The bottom line is that eventually we need to move away from 32bit platforms, and with some programs that try to look 30+ years into the future, the time is NOW. But just because you are on a 64bit UNIX doesn’t mean the date isn’t being kept in a 32bit signed value for ‘compatibility’…

To test the idea, I’ve taken the 4.3 UWisc BSD from my project here, and gone about making some changes.

Starting with the file /usr/sys/h/types.h

myname# diff -r types.h x
47c47
< typedef long time_t;

> typedef unsigned long time_t;

Very simple, right? The kernel has it’s own version of this file, /usr/sys/h/types.h , and will require the same fix.

myname# diff -r types.h x
47c47
< typedef long time_t;

> typedef unsigned long time_t;

Now with that out of the way, the next thing to do is patch some of the functions in libc.

/usr/src/lib/libc/gen/time.c

myname# diff time.c /time.c
25c25
< long

> unsigned long

/usr/src/lib/libc/gen/ctime.c

myname# diff ctime.c /ctime.c
248c248
< long hms, day;

> unsigned long hms, day;

Ok, that’s the bulk of the changes. Really.

Rebuild the kernel & libc, and install them.

cd /usr/sys/GENERIC
make clean
make
cp vmunix /

cd /usr/src/lib/libc
make
cp libc.a /lib
cp libc_p.a /usr/lib
ranlib /lib/libc.a
ranlib /usr/lib/libc_p.a

Now with that out of the way, reboot the VM.

So far everything should behave normally. But it’s time for some fun!

First, let’s make sure we can use dates beyond the 2038 bug date. This program comes from the aforementioned 2038bug.com site. I’ve just added one header needed by 4.3 BSD to get the time_t structure called in correctly.

#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <time.h>
#include <sys/types.h>

int main (int argc, char **argv)
{
time_t t;
t = (time_t) 1000000000;
printf (“%d, %s”, (int) t, asctime (gmtime (&t)));
t = (time_t) (0x7FFFFFFF);
printf (“%d, %s”, (int) t, asctime (gmtime (&t)));
t++;
printf (“%u, %s”, (unsigned int) t, asctime (gmtime (&t)));
return 0;
}

Now when I run it I get this:

myname# gcc 2038.c;./2038
1000000000, Sun Sep 9 01:46:40 2001
2147483647, Tue Jan 19 03:14:07 2038
2147483648, Tue Jan 19 03:14:08 2038

Notice that it works!

Unfortunately the date command in BSD (well just any 32v derived UNIX) is set to handle two digit years. So what I’ve done is to ‘fix’ date to handle four digit years. So here is the diff:

myname# diff date.c date4year.c
94c94
< long time();

> unsigned long time();
160c160
< tv.tv_sec += (long)tz.tz_minuteswest*60;

> tv.tv_sec += (unsigned long)tz.tz_minuteswest*60;
167c167
<

> /*printf(“setting time….”);*/
228c228,229
< year = gp(L->tm_year);

> year = gp2(L->tm_year);
> /*printf(“gtime year %d\n”,year);*/
243c244,246
< year += 1900;

> /*year += 1900;
> no more 2 year dates!
> */
270a274,292
> gp2(dfault)
> {
> int c, d,e,f;
>
> if (*sp == 0)
> return (dfault);
> c = (*sp++) – ‘0’;
> d = (*sp ? (*sp++) – ‘0’ : 0);
> e = (*sp ? (*sp++) – ‘0’ : 0);
> f = (*sp ? (*sp++) – ‘0’ : 0);
> /*printf(“c %d d %d e %d f %d\n”,c,d,e,f);*/
>
> if (c < 0 || c > 9 || d < 0 || d > 9)
> return (-1);
> if (e < 0 || e > 9 || f < 0 || f > 9)
> return (-1);
> return ((f*1000)+(e*100)+(d*10)+c);
> }
>
293c315
< long waittime;

> unsigned long waittime;

Now I can set the time like this:

myname# ./date 201001021208
Sat Jan 2 12:08:00 PST 2010
myname# ./date
Sat Jan 2 12:08:01 PST 2010

And all is well.

So let’s take it to 2040!

myname# ./date 204001011433
Sun Jan 1 14:33:00 PST 2040
myname# ./date
Sun Jan 1 14:33:02 PST 2040

And there we have it!

The old date command would return Thu Nov 26 08:04:46 PST 1903, which is slightly wrong!

Naturally EVERY program that calls time/date stuff will have to be checked to be fully 2038 vetted, but you get the idea. The major offender in the date command is the idea of adding 1900 to the date, which is not needed when you specify the full year.

While this 2038 solution is simple, it still requires people to start to take action. It seems the industry is not moving yet, but it’ll certainly require source code access to make it quick & easy… But I’m sure like the Y2k issue, people will wait until 2036, and by then there’ll be good money in programs that can decompile various UNIX binaries, and change that signed long value… The ‘issue’ is the other fallout like the slight change I had to make to the 2038 test program….

Always remember to keep your source SAFE!

Oh, and happy new years!