SIMH on the DEC Alpha…

I released a partial binary build of SIMH on the DEC Alpha using Visual C++ 6.0 … I didn’t think much of it, but it’s been downloaded 400% more then I had thought…. (I didn’t think anyone would!)…

I can either conclude that:

  • There are some DEC Alpha NT users still out there…
  • Some people download things for the sake of downloading…

If you are one of the four remaining users, let me know… I have Visual C++ 6 I can try to build other stuff….

In the meantime, here is VMS on WNT…

VAX./VMS running on a Dec Alpha / NT machine

 

Qemu 12.2

Well while I was busy playing with my DEC Alpha (lol) there has been a few updates on the Qemu front…. There is some super basic Dec alpha support going in, but no system support yet….

One can only hope that one day it’ll run NT!!!

Anyways, I’ve built up the latest version here for win32, Windows users.

As much as it kills me, the MIPS version still CANNOT boot NT 4.0… the ARC Bios runs great, but now the program crashes on the loader….

I did however do some basic tests with the i386 version and it seems ok.

Updates for NT 4.0 on the DEC Alpha

It seems that the ‘official’ updates for NT 4.0/Alpha on the Microsoft website are long gone… I know that Internet explorer 5.0 will be a part of that SUN vs Microsoft lawsuit which barred Microsoft from distributing any product containing the MS JVM… (like Office 97, IE5, J++ etc…)

However I found a stack of CD’s containing among other things the last updates that were provided for the DEC Alpha platform running NT 4.0.

For Windows NT 4.0 workstation & server users you’ll want Service pack 6a.

Terminal Server users will no doubt want Service pack 5. As far as I can tell, this was the last update to Terminal Server for Alpha users. Also there are MANY WTSALPHA.EXE’s out there, that are ALL corrupt… I was very lucky to have found this on a CD, and I can safely say that it runs perfectly fine on my Alpha.

Finally, on the Service pack 6a CD, there is a copy of Internet Explorer 5.0, and I’m pretty sure this was the last Alpha version of IE released. I’m sure its possible to run Firefox 1.5 or maybe even IE6 via !FX32, but native exe’s are so much the better. Internet Explorer 5.0 contains the standard accessories, namely outlook express, netmeeting, comic chat, and the media player…

I’ve been lucky enough to have a MSDN CD set from 1998, that included the MS Word, and Excel for the DEC Alpha… Back in 1997 when I used a DEC Multia, as a primary machine, I remember how ‘cool’ it was to run Office 97 through FX32, along with lotus notes to do work stuff… But I have to tell you, sure it’s 2010, but having a native version is way more cooler.

Also I have to say the C++ compiler for the DEC Alpha is the buggiest thing I’ve ever seen. The ‘hint’ should have been from the NT 3.5 SDK that builds all the Alpha stuff with the /Od flag turning off all optimizations. I had such a hard time with unzip it’s not even funny.

Luckily Visual C++ 6.0 for the Alpha is way more stable, even unzip will build with the /O2 flags. I can only wonder how much Microsoft went crazy fighting this compiler.. They seemed all to willing to give up on public releases of NT for the Alpha, but rumor is that the Itanium was so delayed for physical units, the 64bit version of Windows 2000 was started on the DEC Alphas… Then finally ‘tested’ with the Windows 2000 Data Center limited availability release…

For what it’s worth, here is the version strings of the compiler….

Microsoft (R) & Digital (TM) Alpha C/C++ Optimizing Compiler Version 12.00.8217
Copyright (C) Microsoft Corp 1984-1998.
Copyright (C) Digital Equipment Corporation 1992-1998
Copyright (C) Compaq Computer Corporation 1998.
All rights reserved.

And the compiler that is on the NT 3.5 SDK…

Microsoft (R) & Digital (TM) AXP C/C++ Optimizing Compiler Version 8.03.JFa
Copyright (C) Microsoft Corp 1984-1994.
Copyright (C) Digital Equipment Corporation 1992-1994
All rights reserved.

It’s funny that there is almost *NO* mention of this 8.03.JFa version… But then I’m sure most people at the time, didn’t realize that the i386/MIPS compilers were on the 3.1 SDK, the Alpha on the 3.5 & the PowerPC on the 3.51… I never did figure out why they didn’t keep on providing these compilers…. But then MS works in mysterious ways at times.

Oh, and I finally benched quake on the console with a 32k video card.. It was just shy of 60FPS! Which for a 600Mhz machine circa 1996 is pretty dammed fast! The fastest intel cpu at the time would have been the 200Mhz Pentium PRO… I actually have one, and I’ll have to install NT 4.0 on that and do a comparison..

Dungeon on the DEC Alpha

I forgot to mention this, but f2c built, although there is probably some error with the floating point… I’ve had issues building f2c on OSF/1 on Alphas a while ago….

Anyways it can be found here.

One day I’ll have to try to debug the floatlib on the Alpha to see why f2c freaks out….

 

But then again, who still uses DEC Alpha’s?

Well today I got my new Dec Alpha running!

Ok, my friends say I’m insane to have bought this… but I couldn’t resist.

It’s a DEC Alpha 221164 machine, with 64MB of ram, and a 4GB disk!

It’s the best technology of 1996-1997!

So I’ve gone ahead and installed Windows NT 4.0 on the beast… at 600Mhz it’s pretty dammed fast… considering how old it is. Although I suspect a Pentium III I found in the garbage with a 1Ghz cpu is 2x faster…..

But at any rate, this is a DEC Alpha, the long time geek cpu of dreams etc…
What makes this slightly useful for me, is that I do have Visual C++ 4.0 & 6.0 for the Alpha. So at least I can build *SOME* stuff to run on the thing….

So I’ve been fighting the compiler, and it seems it’s default blended optimizations do *NOT* work on my machine.. I’m sure this will be fun down the road. However it seems setting the target cpu to the 21064 produces ok code.. I’ve got to bench the stuff, but at least my exe’s are not crashing.

So what have I manage to produce today so far?

Well…

unzip is a major one.. It’s hard to use a machine today without it.

The other thing I’ve manage to get running, is Quake! I’ve included my source & project trees as it was a feisty little thing to build..

I’m currently building & testing over terminal services so I don’t know what the speed is on the console… Also, this build does not include networking… I’m sure the winsock code will work just fine, I’m just not in a good position physically to test it, as Quake1 will *NOT NAT* correctly.. Also the SDL sound doesn’t actually output anything, so I’ve built it with the null sound driver..

I’d love to get that m68k->C build of frontier elite to go on the Alpha but I’m afraid my 64mb of ram will be a major constraint..

I know this isn’t much of an emulation thing, as the only emulator that possibly can run Windows NT for the Alpha costs upwards of $16,000 USD… It’s cheaper to score an alpha on ebay for $100 USD.

Well here is the screen shot…

Quake on the Dec Alpha

 

I know it’s not much to ‘look’ at, but the pallet is correct, because it’s a real Alpha!.. Unlike the MIPS thing.

Proxmox 1.4 is out

I’ve been rooting for proxmox for a while now, and I’ve just installed it on a DL385 with a 1.7 TB FC NAS…. This version is SO MUCH BETTER then the prior ones with regards to storage….

I’m installing a Windows 2003 server right now for some basic tests, but I’ll have to post back later with far more testing…

So far, so good though.

Also if you are going to install with a SAN of some kind, make sure to have it disconnected on install.

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!