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.


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
< 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
< 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.


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

> unsigned long


myname# diff ctime.c /ctime.c
< 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
cp vmunix /

cd /usr/src/lib/libc
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)));
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
< long time();

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

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

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

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

> /*year += 1900;
> no more 2 year dates!
> */
> 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);
> }
< 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!

More packages for 4.3 BSD

As someone has requested I have started to do lots of package updates for 4.3 BSD (the original/Vanilla version)…  Sourceforge however is doing major updates again, and I cannot add anymore files to the download sections…

Again not to gripe but I do wish sourceforge would allow you to use the old UI while they are building this new one…

Anyways I’ve managed to upload binutils/bison/flex/gmake & a few versions of GCC.  I haven’t built the c++ compiler as of yet… I just built nethack but I can’t finalize the upload though..

PUPS mail archive….

I thought this was interesting as it’s from the start of the PUPS movement..


And I can say I got involved in the PUPS thing for sure on the 8th of May 1998..

It’s hard to think that it’s been 11 years now I’ve been lucky enough to stuble uppon Bob Supnik’s excellent emulator, and the work of the PUPs people to run version 6 research UNIX on MS-DOS….

Speaking of which, I’m kind of surpesed that there is nearly 50 downloads of the MS-DOS build of SIMH. I’m sure it has everythig to do with the small test OS’s and whatnot… But it’s still cool to me.

Also I’ve started work re-tweaking the RENO install package. I’m moving away from the 4 ra disks, to a single HP disk, that only consumes 160MB unlike the 2GB of the old setup. I hope to have that done sometime in the next week, along with fixes to the cursor keys & some more testing… I’m also going to try to track down the missing ‘adduser’ script/exe from RENO.. there is a few odds & ends missing from the TUHS RENO tape….

BSD RENO on SIMH’s microvax DZV11 vs DHQ11

I got this note over on gunkies.org from Lei Wu:

I use the following code to replace the original dz configration. set dz disable set vh enable set vh0 normal set vh0 modem set vh0 hangup att vh 2311

After this, when the vax emulator run up, you can see some messeges on the process of booting like this

dhu0 at uba0 csr 160440 vec 300, ipl 14
qe0 at uba0 csr 174440 vec 764, ipl 15
qe0: delqa, hardware address 08:00:2b:aa:bb:cc

this mean that the hardware is recognized by virtual machine.

next step, login as root, to make dh11 device node in /dev .

sh /dev/MAKEDEV dhu0

this command will make ttyS0 – ttyS15 device node.

now, you need to modify /etc/ttys to add those termial driver to autoload when system startup next time. the parameters is same with tty01-tty07 in the original ttys file.

At last you could reboot and telnet localhost on port 2311.

you will see the prompt, but there will emerge some flaw (some messed characters). but you can neglect this, and continue input your username and password. then you will get a shell.

Now, I don’t know the reason of those messed characters. Any one can continue to explore.

So that’s a ray of sunshine for the other UNIX/BSD’s that predate RENO that can boot on the MicroVAX II… Hopefully the drivers may work on the 11/780 to help some older OS’s whose support under the dz isn’t whole enough to work….

More updates on the 4.2BSD project thing

I updated the website after 2+ years of stagnation… lol


I know its sad, and mostly all licensing… Anyways I’m in the process of moving so no major updates in the next week to two… But once I’m settled up in New York, I’ll crank out another set of releases to include working cursor control for games, and a loaded version of Uwisc BSD with all the fun stuff ready to roll… I’m also going to do a “HP” install of Reno so it won’t be an 80Mb download anymore… I figure if people are actually using them, they can modify the configs, add more disks etc etc….

Which reminds me if there is a online 1st edition copy of the “Unix System Administration Handbook”.. That’d be cool, but otherwise, I’d recommend people to get a copy of the 1st edition as it covers the tail end of the VAX era BSD’s.

Packages so far on Uwisc 4.3BSD

I’ve been compiling quite a bit of stuff.. Looking back it was something I intended to do back in October of 2007… Well no time like the present then! I’ve done my best to include all the relevant bits for each of the following packages. It’s entirely possible I’ve missed stuff, so feel free to re-build the stuff as you wish. Some of the packages require you to build them with GCC as the default CC won’t work. However if you are going to build it yourself you won’t be able to jump to gcc as it requires gperf which in turn requires a working c++ compiler. So far here are the following packages:


All of these can be downloaded from here. I’m keeping all the source code (unaltered) in tap format for the SIMH emulator right here.

To get the C compilers going I had to build gcc 1.42 with the system compiler (cc/PCC) then use that version of GCC to build the next version. Once I had gcc 2.5.8 building, then I was able to build binutils 2.8.1 without issues, then rebuild gcc 2.5.8 to use binutils instead of the default system assembler so that I could build lynx and it wouldn’t barf because of the massive switch statement…

And no, -J didn’t help.

Speaking of lynx the search ability is broken because the function simply isn’t in 4.3 BSD (bsearch), and for pine, I had to make a fake tmpfile function that uses the /tmp/pinebox directory.

The gcc 2.5.8 package includes the C++ components, and I’m pretty sure I did with as well. I’m not sure if GCC 3.x kept the VAX cpu so I haven’t pushed forward, but seeing that the cc1 exe is over 1mb it doesn’t seem worth it to push ahead.

I’ll have to see about including more games. The selection in this 4.3 release is kind of weak,

aardvark* boggle* [email protected] monop* snake*adventure* ching* hangman* quiz* snscore*backgammon* cribbage* hunt* robots* teachgammon*battlestar* doctor* lib/ rogue* trek*bogdict* fortune* mille* sail* zork*

I’ll have to see what’s missing from where.. Also I notice that the arrow key bindings in terraterm are not working… I’ll have to dive into that as well. It may end up with a new re-relase of the emulator or a patch thing. I’ll have to see.

I should add a quick note on how to unpack these tap files. First you will need bzip2 on your native pc. You should be able to get one here.

Now just uncompress the file..

C:\Program Files (x86)\uwiscbsd>bzip2 -d lynx-2.8.2.binary.BSD-4.3.Uwisc.tap.bz2

Now you need to go to the SIMH console window. It will say something like this in it:

VAX780 simulator V3.8-1
Listening on port 42221 (socket 376)
Waiting for console Telnet connection

Hit Control+E and it’ll interrupt the simulator. Then we need to attach the tap file like so:

Simulation stopped, PC: 800018A3 (MTPR #0,#12)
sim> att ts0 lynx-2.8.2.binary.BSD-4.3.Uwisc.tap
sim> c

the att command will attach the tap file to the ts0 device. the c will tell the simulator to continue. Now just switch to a tty windows (or attach a pty), then it’s a simple matter of running the following commands:

myname# cd /
myname# mt rew
myname# tar -xvmf /dev/rmt12
x /usr/local/bin/gzip, 66560 bytes, 130 tape blocks
x /usr/local/bin/lynx, 949248 bytes, 1854 tape blocks
x /usr/local/lib/lynx.cfg, 97203 bytes, 190 tape blocks
myname# rehash

Thats about all it takes, now you can run lynx. If you so wish, you can run back to the SIMH console, and tell it to “det ts0” which will detach the tape image.