Building MUD 86 from source

To build the 86 source you first need to get the MUD sources to your TOPS-10 host. I suggest that you use kermit to transfer it to a PPN of [2011,2776] as that is where we need to work. Alternatively create a tape of the sources using Linux Tops-10 tapeutils (untested) and then restore it to [2011,2776] on your TOPS-10 system. See the FAQ for how to restore.

The MUD.MIC that i may need to be altered to work with your BCPL installation. I used SOS to remove the references to DSKF:, raised the .HIGH. seg to 507200 for the larger MUD 86, and also changed the NSS and NSA commands to SSAVE and SAVE respectively, but all this is already done for you if you use the MUD sources linked to above.

Once this is done, you should simply need to DO MUD M and then DO MUD DM. This will compile and produce two EXEs: MUD.EXE and DBASE.EXE. If you don’t get this or you get an error during compilation or linking, it is likely that either your BCPL is missing libraries, your high-mem settings are wrong, or the linker broke somehow. The obvious symptom that you had linker errors is you end up with something called LINK.EXE in your directory and it should not be there. If you have BCPL compile errors then something bad has happened to the sources or your BCPL.

Assuming you have got DBASE.EXE and MUD.EXE (which is incomplete and will not run successfully), you now need to generate the MUD from the game sources and build the complete MUD.EXE.

Generating the game from MUD 86 sources

To build MUD, ensure you have all he text files in the [2011,2776] directory and type RUN DBASE. When complete, if all has gone well, you will see diagnostic output about the number of rooms and synonyms and stuff and at the end of the run it will say MUD Saved:

.ru dbase

initialisation used 1928
persona used 0
hours used 7
combat used 136
levels used 67
rooms 
420 = last room number
used 4755
maps 
8 = last map number
used 26
vocabulary ;vocabulary objects
vocabulary actions
;vocabulary action synonyms
;vocabulary demon actions
used 8376
demons 
71 = last demon number
used 288
objects 
482= last object number
used 4739
travel 
420 = last travel number
used 4062
text 
1114    = last text number
used 847
207 classes, 253 objects and 16 motion words defined
Total space used 25247
Loading database from MUD.DMP

.ssa

MUD saved

At this point you can now RUN MUD

.ru mud


 
ESSEX UNIVERSITY: Multi-User Dungeon.
                                      
This Mud created: 8th December 2018 at 13:23:32
Origin of version: 13:23:47.
Welcome! By what name shall I call you?
*

Once compiled and run, you can copy the MUD.EXE, *.DBA and MUD.??M files to any PPN and they will just run. I recommend a [2011,2011] PPN as this was the original PPN which held the MUD executable on Essex Uni.  The MUD guest account was [2653,2653].

About Quentin

Im just a normal bloke.
This entry was posted in Retro Computing and tagged , , , , , . Bookmark the permalink.

6 Responses to Building MUD 86 from source

  1. Drew says:

    Hi Quentin. This is great stuff, thank you for your hard work!

    I have followed your guides and have managed to get everything working up to MUD84. However, I can’t get MUD86 up and running.

    I noticed a lot of files had NULL bytes at the end of them, possibly introduced by KERMIT. These files caused ‘.ru dbase’ to fail early.

    I fixed these by simply loading every file in SOS, forcing a change and then re-saving them.

    However I am now facing problems not caused by minor EOF corruption.

    Looking at your .ru dbase log there is seems to be a different MUD.TXT in use to that provided on GitHub. e.g. @txthrs response appears earlier than it would.

    There also appears to be a different number of rooms. When I tried with default *rooms 420 I got a fail:

    ————
    .ru dbase

    initialisation used 1928
    persona used 0
    combat used 136
    levels used 67
    hours used 7
    rooms
    420 = last room number
    used 4755
    Unknown database section dead43
    .
    ————

    I tried again with *rooms 435 (like MUD84) and got a message that there are only 421 rooms. Ok. so I changed MUD.TXT to *rooms 421:

    ————
    .ru dbase

    initialisation used 1928
    persona used 0
    combat used 136
    levels used 67
    hours used 7
    rooms
    421 = last room number
    used 4766
    maps
    8 = last map number
    used 26
    vocabulary ;vocabulary objects
    vocabulary actions

    Unknown vocabulary type [rape]
    .
    ————

    So 421 rooms instead of 420 and it fails on [rape] of all things! I compared MUD84 with MUD86 and the jokey ‘rape’ scenarios are in both, with only a few more introduced in MUD86.

    I’m scratching my head here?… any help appreciated!

    PS. Is there any way of getting files in quicker with K10MIT? I only get around 50cps which is like the DEC-10 is emulating a 110 baud modem with line noise! lol! I’m using Linux ckermit.

    • Quentin says:

      Hi Drew

      Ok there are a few things to unpack here.

      The mud86 version has less rooms because I think death is handled differently. *rooms 420 is the correct value for MUD86.

      As a bit of sense check that your TOPS-10 BCPL install is all fine, have you tried the compiled MUD.EXE from the MUD84 tape? Have you unpacked MUD84 sources from the tape and successfully compiled them? Have you built MUD84 MUD.TXT using DBASE from the MUD84 tape? Does that work?

      Are you using the source DBASE and MUD.EXE that are with MUD86? MUD84 DBASE can’t compile MUD86.

      It sounds like you have already dealt with the text file issues, but just in case when you are uploading using Kermit there are a number of issues. Firstly k10mit doesn’t necessarily handle textiles well when transmitted from c-Kermit. If you have uploaded the source files with Kermit and they display as text when you TYPE them or SOS them, then the files are still possibly not quite right. Check both .TXT and .GET files. Each time you get an error when you run DBASE, edit the file with the error and save it; eg:

      ..sos mud.txt
      Editing MUD.TXT
      *ecb
      [DSKB:MUD.TXT]

      Do this for every .TXT and .GET file that causes an error. This will likely fix up the ASCII translation issues that seem to occur with k10mit where I think some characters seem to have the high bit set which breaks DBASE.

      If all is going well, you should get the following output from DBASE assuming that you have a compiled MUD.EXE and DBASE.EXE:

      .ru dbase

      initialisation used 1928
      persona used 0
      hours used 7
      combat used 136
      levels used 67
      rooms
      420 = last room number
      used 4755
      maps
      8 = last map number
      used 26
      vocabulary ;vocabulary objects
      vocabulary actions
      ;vocabulary action synonyms
      ;vocabulary demon actions
      used 8376
      demons
      71 = last demon number
      used 288
      objects
      482= last object number
      used 4739
      travel
      420 = last travel number
      used 4062
      text
      1114 = last text number
      used 847
      207 classes, 253 objects and 16 motion words defined
      Total space used 25247
      Loading database from MUD.DMP

      .ssa

      MUD saved

      If this is not working for you, let me know andI will write my currently working version (which has some mods to make it more like the later BL version) to tape with the source and upload the tape file somewhere so you don’t need to bother about the kermit nonsense.

      In regard to K10mit speed, my first question would be are you using linux screen to access the the host system? If you are, don’t, it massively slows down the data transfer. Make sure you launch C-Kermit on your host and connect directly to the TOPS-10 with a telnet connection and login and then run k10mit. Data rates are much improved (but not quick by modern standards, it still takes about 5-10 mins to transfer all the files including MUD.TXT, but I recall 100s of cps rather than 50cps). If you aren’t using linux screen or similar then it might be something else in the setup but difficult to know without understanding that.

  2. Drew says:

    Quentin,

    Thank you for your comprehensive reply.

    I had actually went through every *.DBA, *.GET and *.TXT file with SOS loading and saving them. I forced an edit just to make sure the files got saved. My convoluted procedure was:

    .SOS filename
    *i1
    00001 1
    *d1
    *es

    I have now re-tried SOS on the above files simply using *ecb as you suggest and MUD86 now works! I don’t know what *ecb does because the SOS H,E command just returns File not found but you mention high bit ascii so I guess that was the problem!

    Now I need a VALLEY.MIC to complete the Essex ’86 experience! (There was also ROCK too)

    As for the KERMIT speeds, I am not using screen. I’m using the newfangled Microsoft Win 10 Linux subsystem with Ubuntu 18.04 loaded. Runs natively, much nicer than Cygwin and I don’t need a VM or dual boot. I couldn’t get the abandoned Windows 95 Kermit trial software to work in Win 10.

    From C-Kermit I telnet localhost 2020 then login to TOPS-10, run K10MIT and use the SERVER command. Ctrl-\ C to get back to Linux kermit and then SEND *.*

    It takes over 4 hours to send the files! It’s quicker the other way, only 350cps though.

    I know in the setup of the TOPS-10 system I set the terminals baud rate to 9600 I’m guessing I could go higher here. Did those old terminals have a split baud rate, like the 1200/75 standard that was the top speed of my modem at the time?

    • Quentin says:

      I don’t think I can help with the Kermit issue, but I suggest that it could be the way you have the linux piece set up on Win10. I use a real debian linux server to host simh, and it works adequately for me.

      I had to fix the SOS help file, IIRC it is on one of the tapes but just hasn’t been copied into HLP: when they are copied to make the system. If you can find SOS.HLP, just copy it to HLP:. The SOS on these TOPS-10 tapes is much more recent than the manual on Bitsavers so it does help with using it, especially with large files.

      MUDTXT.MAS should have the VALLEY.TXT in it, you don’t need a VALLEY.MIC. To build Valley, you need a compiled MUD.EXE and DBASE.EXE, then you just need to RU DBASE-VALLEY.TXT, this should produce a VALLEY.EXE which when run will load valley.

      Here is my TTY.INI[1,4] which gives the fastest speeds possible:

      type tty.ini[1,4]
      ALL KSYS TEXT TYPE:VT240 FILL:0 LC WIDTH:80
      TTY0-37: SPEED:9600 IDLEDISCONN 120
      CTY: GALOPR NO REMOTE ACCOUNT “SYSTEM”
      STOMP ACCOUNT “SYSTEM”

      If you want to simulate that old dial up modem speed experience, just change the 9600 to 1200 or 300 and you will experience the slow old world.

  3. Drew says:

    The slow TTY / KERMIT speed issue seems to be with the newer version of simh.

    I had the precompiled V4.0-0 installed on my desktop Win 10 and only got ~50 cps

    I apt installed the Ubuntu 18.10 simh package on a Linux machine. That is V3.8-1 and I get ~960 cps, what I would expect from 9600 baud.

    I built the latest V4.0-0 from GitHub and ran it on the same Linux box and it’s back down to 50cps again. So it’s not just Windows.

    As for 300 baud, I remember the dial-in UCL JANET PAD X.25 gateway. That ran on a PDP8 iirc. Oh no, something else to build in simh 😉

    • Quentin says:

      I use an older v4 binary that I compiled myself. PDP-10 simulator V4.0-0 Beta git commit id: ba447399. This seems to work fine, but I haven’t tried the v39-0 binary with Kermit to see if it is any better. I would always build from source with simh as the distribution binaries in the repositories do make also sorts of assumptions and I like o have the ability to tailor some of the source which I do for some other simh projects I use (notably HP2100). I have noticed some issues with the pdp10 4.0.0 binary with the mux sometimes hanging, so there could be an issue but it hasn’t caused me enough hassle to do anything about it.

Leave a Reply

Your e-mail address will not be published. Required fields are marked *