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

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.