Retrochallenge 2009
      Summer Challenge
      Mark Wickens


      How hard could it be? Having posed a question (that I thought I already knew the
      answer to) on the comp.os.dec newsgroup I was armed with the knowledge that (in
      theory) the cable running out of the attic, down three stories, into the
      basement and up through the louge floor had enough conductors to form a
      communications path between the DECserver 90TL and a bona-fida terminal.

      The cable was installed by me a couple of years ago. I have no idea why I
      installed it. Oh hang on, no I do. It was installed for a CCTV system I was
      setting up. I had bought SVHS cable, which I assumed was four core screened,
      only to find that it was five core unscreened. Having blown up a couple of
      cameras bought from China via ebay (by plugging them all into a 12v transformer
      instead of the 8v they required) the cable lay unused. Then it was used as a
      telephone extension when the router was in the attic serving the network and a
      laser printer. Then, when the printer got a network card and the router was
      better placed in the lounge (wifi signal coverage) the cable remained unused.

      The challenge then was to create a signal path between an RJ45 connector plugged
      into the DECserver and an MMJ connector plugged into a VT320. First step was to
      create an RJ45 to SVHS connector. Spare SVHS cable rotting slowly in the
      basement, snip one end off, work out that roughly the colours of the cores match
      that in the cable I'd normally use, five minutes of gently waggling the
      conductors into the right slots in the CAT-6 connector and CRIMP. At the other
      end, I had a MMJ to DB9 male cable (the classic cable used to connect a VAX to a
      PC). By putting a DB9 female on the bare end of the wire poking up into the
      lounge I should be sorted. This cable used the same six core flat cable that I
      had judged colours from with the other end, so it was a case of soldering the
      same colour on the DB9 female connector whilst it was plugged into the DB9 male
      connector. Piece of cake. Normally a cable like this involves three levels of
      colour coding context shifting.

      Alas, no joy. I buzzed the attic end with a multimeter. This end I could see was
      connected ok, no joy. At 22:45 I gave up. I have a backup plan, involving a
      10base2/10baseT network hub and another DECserver. That way I utilise existing
      CAT-6 cable from the lounge to the attic, at the cost of having yet more network
      equipment plugged in. Shame that I can't get a three-wire cable to work, but
      I've been here so many times before. Serial cables have always been a nightmare
      for me - the only way I get consistency is to take a cable I already have made
      (and been through the pain with) and copy it exactly.

      Might be worth mentioning that the DECserver 90TL in the attic is dumb. It can
      have either 1MB or 4MB of RAM, and a little flash memory. The flash memory
      stores 'where do I go to find my software'. So you have to provide a server that
      accepts a MOP request from the DECserver and pump down the wire the appropriate
      file. If you have a server that is switched on all the time this is not a
      problem. My DECserver is home-wired into a 5V supply, instead of using either
      the DEC external power supply or plugged into a backplane. The home-wiring has
      never been right - there is a dodgy part in the power cable somewhere - which
      means that this particular DECserver suffers from an accute case of amnesia.

      Any road up, because I now run the Retrochallenge BBS [1] on an old Dell
      Inspiron 7500 laptop, which requires NetBSD, I have the perfect platform to
      service the DECserver's nostalgic requests. So, as I look to be going down the
      two DECserver route, I'll need to alter the MOP configuration. Currently, on the
      NetBSD box, I have:
      $ pwd
      $ ls -l
      total 2942
      lrwxr-xr-x  1 root  wheel      16 Apr 29 09:07 08002b344d6f.SYS ->
      -rw-r--r--  1 root  wheel  592896 Nov 18  2007 MNENG1
      lrwxr-xr-x  1 root  wheel       6 May  5 15:31 MNENG1.SYS -> MNENG1
      -rw-r--r--  1 root  wheel  825344 Nov 21  2007 MNENG2
      lrwxr-xr-x  1 root  wheel       6 May 13 14:01 MNENG2.SYS -> MNENG2
      lrwxr-xr-x  1 root  wheel      16 Apr 28 20:52 MOPBOOT.SYS -> ./boot.mopformat
      -rw-r--r--  1 msw   users   63852 Apr 28 20:47 boot.mopformat

      The interesting entries here relate to the MNENG1 and MNENG2 files. These
      contain the software used by the DECserver. The model I have can contain either
      1MB or 4MB of RAM. If it has only 1MB of RAM, it has to be configured to request
      the MNENG1 file, which contains reduced functionality. If it has 4MB of RAM, it
      can be configured to request MNENG2 which has much improved functionality. The
      RAM is quite specific - my 4MB stick came from a fellow DEChead who had it spare
      for a VAXstation VLC (DEC X-terminal).

      The other entries provide a way for another VAXstation 4000/90 to MOP boot
      NetBSD. The top entry maps the VAXstation's MAC address to a boot file. All good
      stuff. However, the bit I was missing for several attempts at booting NetBSD on
      a VAX was the fact that DHCP has to get involved. So, I had to turn DHCP off on
      the router (that acts as my default gateway) and invoke it on the NetBSD dell.
      My dhcp configuration file on it contains:

              # Setting DHCPD global parameters
              allow unknown-clients;

              ddns-update-style ad-hoc;

              # Set parameters for the subnet.
              subnet netmask {
                      default-lease-time 604800;
                      option subnet-mask;
                      option domain-name-servers,;
                      option domain-name "";
                      option routers;

                      host aleph {
                              hardware ethernet 08:00:2b:34:4d:6f;
                              option root-path "/export/aleph/root";

                      host mirrorbow {
                              hardware ethernet 00:04:a3:00:00:00;

                      host netfs1020d {
                              hardware ethernet 00:c0:ee:d5:6c:ae;

                      host xpsgen2 {
                              hardware ethernet 00:12:3F:D1:CA:46;

      The host entry aleph is the VAX. The name aleph comes from a VAX connected to
      a cluster I worked with when I worked for Cyberscience Corporation between 1991
      and 1993. I'm sure a wikipedia search will throw some light. Host mirrorbow was
      the focus of my winter challenge (network connected IO device), netfs1020d is my
      Kyocera FS-1020D connected to the network and xpsgen2 is the Dell laptop I'm
      using right now.

      I mention all this because it took several aborted attempts at net installing
      NetBSD on a VAX before I hit this piece of knowledge (a quick email exchange
      which, by its' very nature might not have happened).

      So, what of the challenge. I feel like I'm stepping in well worn footprints by
      becoming so distracted. That and the beer! I started investigating how I could
      turn MMS (the OpenVMS make system) to my advantage, and am planning my first
      home-grown Macro-32 program to be a simple floating point addition affair (with
      output to the terminal of course - and that's the hard bit). This requires me to
      understand the macros defined in the code I have from the Sara Baase book.



      1.Retrochallenge BBS