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 is included 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].
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.
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:
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:
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.
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?
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:
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.
Thanks to Drew’s instructions I managed to hit 80cps transferring the updated compil.mac from Github using SimH V4 – although it seems to have added another set of line numbers meaning it won’t compile successfully. I’d love to see what changes you made to Mud86 to appear more like BL Quentin!
Have you found what is, apparently, the first computer Easter Egg? If not, at the command prompt in Tops10, type “make love” ðŸ˜
I have now added a SIMH TOPS-10 tape image containing the BCPL COMPIL.EXE. You can download from GitHub https://github.com/PDP-10/essex-bcpl/blob/tape/bcplcompil.tap and restore to SYS: [1,4]. Don’t forget to copy the original COMPIL.EXE somewhere just in case!
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 😉
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.
You need to use eub command in sos to enable Valley to produce an .exe file via dbase.
Compiled succesfully the tapeutils on debian, then using “tapewrite toto.tap *” produced a tape file.
But restoring it from TOPS-10 fails with:
/files
/restore dsk:=*.*
!
%BKPNBF Not BACKUP format reading non-file data
%BKPNBF Not BACKUP format reading non-file data
Shouldn’t files be encoded somehow so that TOPS10 recognize them?
OK, it looks like you tape image is broken. If you have correctly downloaded the mud86.tap from GitHub https://github.com/PDP-10/MUD1/blob/zip/mud86.tap then you do not need to do anything with it prior to attaching it to simh. Follow the the tape mounting instructions in the FAQ. You will need to press ctrl-E to get to the sim> prompt when on the console.
Hi, can we talk
Drforbin
Yes, we can.
It has been a few years and I only recently got back into playing MUD86 with cool-retro-term for amber nostalgia.
What I remember is the OPR’s managed the amount of people who could login and kept it at the night time only for DZ when nobody at the Uni was using the pdp10.
There was a GUEST [2653,2653] account and then the [2011,2776] PPNs. IIRC there was another account [2011,2011]
How was the 2653 account given a script on login to KJOB any external user if over some limit (20 or 30?)
(which I managed to defeat by quick ^C’s) but also nobody could delete or edit the MUD files from the other accounts? I guess they could but it would be to arcane.
You are right. [2653,2653] was the MUD guest account. The player limit was set as 32 in MUD itself as it could not cope with more than 32 players online due to the word length that contained a status bit for each active player. There may have been a INIT.MIC that did the login count check on login to [2653,2653] but I don’t have that, either way the game EXE won’t support more than 32 concurrent users. The opening times check was also built into the game and the times were stored in the game database.
The executable and private files were in [2011,2011] and Richard Bartle’s account was [2011,2776] which had the source and database generation programs in it.