OpenBSD Journal

OpenBSD/vax on SIMH

Contributed by grey on from the software emulating hardware dept.

Thanks to Matthias Kilian for writing in with the following:

Ever wanted to see OpenBSD running on a vax?

Those who don't have appropriate hardware available can use a simulated vax, as described on the new vax-SIMH page.

Thanks to Mark Kettenis for this fine documentation.

(Comments are closed)

Comments

  1. By m0rfick (68.104.14.15) on

    ok, i'm stumped, i have it running, but how do i get it to communicate with my network?

    i have two nics, rl0 and xl0, rl0 connected to the cablemodem and xl0 is plugged into an otherwise empty hub for the moment. i have tried connecting xq to both of those interfaces with no luck.

    what am i missing?

    Comments

    1. By Marco S Hyman (208.201.244.214) marc@snafu.org on http://www.snafu.org

      I used: "at xq0 em0" where em0 is the only interface on this box.
      I assigned an open address in my subnet when configuring the simulated
      system.

      208.201.244.208 assigned to "vax.snafu.org"
      208.201.244.209 dumbcat.snafu.org (web, mail, dns server)
      208.201.244.214 neko.snafu.org (host running simh-vax)

      vax.snafu.org can talk to any host *except* neko, the host
      running simh-vax. This is a problem in that the data I need
      to get to the simulate vax lives on neko. I suspect it is
      a libpcap issue... any ideas for workarounds?

      Comments

      1. By Mark Kettenis (82.92.89.47) kettenis@openbsd.org on

        If you have a second machine that you can set up as a router, there's an easy way around this. Make the router forward packets between two subnets, say 192.168.0.0/24 and 192.168.1.0/24, make sure the machine that hosts the simulator has an address in one of these subnets (i.e. 192.168.0.11), and use an address in the other subnet for OpenBSD/vax running in the simulator (i.e. 192.168.1.22).

        Mark

  2. By Simon (217.157.132.75) on

    It could be useful if you happed to have some old binary only software which only run on OpenBSD, or one of the OS which OpenBSD can emulate, of Vax. Other than that I don't really see the usefulness.

    Of cause there are the "Because I can" and "Just for fun" argumentation which Im always willing to accept.

    Comments

    1. By Anonymous Coward (68.202.41.228) on

      Running on a variety of different architectures helps to expose bugs in software (and compilers). Sometimes you make assumptions about certain things which happen to hold true for the architecture you usually use, but which are invalid on another platform. Sometimes you discover that a certain algorithm performs badly on a class of machines.

      It's just good hygiene for making quality software.

    2. By djm@ (61.95.66.134) on

      How about: "I'd like to play with OpenBSD/vax, but my wife would kill me if I brought another machine home"

      Comments

      1. By Anonymous Coward (210.84.167.218) on

        ...and she probably wouldn't like the extra power consumption of a vax either.

        Comments

        1. By Miod Vallat (212.234.41.17) miod@ on

          Actually, some Vax are barely eating any watts. The so-called Vax laptop (VAXstation VLC) and the MicroVax 3100m30 (but not other 3100 submodels) require less than 100W.

          Of course, those aren't the fastest vaxens on the planet. But if you can afford 400W, the 4000-10x are incredibly fast (for a vax).

          Comments

          1. By Chris (144.178.101.183) on

            The Vaxstation 4000 VLC is a great little computer, about 3cm high with a 40cm square footprint. The VLC stood for "very low cost", and it's performance is more in league with the 3100 series machines than the 4000 ones. It can only have one onboard hard drive, but it does have an external SCSI port and a framebuffer. Anyone looking for a Vax machine to play around on should really try and track one down.

            Just to see how it would cope, I used my VLC as a webserver for a few months last year. It was running a NetBSD -current snapshot, and performed remarkably well! I'm planning on updating it with a more recent NetBSD -current at some point, as someone recently wrote support for the framebuffer (something that was long believed to be too much effort thankns to a lack of documentation for the hardware).

            Chris

    3. By Janne Johansson (82.182.176.20) on

      I'd say it would be a creative way of combining the "need" for a GHz vax compiler with the "rule" of openbsd to always let all platforms compile their own code. And then yes, I know *no* emulator would give you the feeling of your existing 3-4GHz while emulated, but if you get the equivalent of 3-400 vax-MHz then you'd kick ass in some respects. I'd love to play openbsd-amiga/m68k on UAE for instance, and if my computer could give me an environment where the endresult felt like a m68k@500MHz and have access to a big part of my 1G ram, it'd be a real monster. For me. And it would be running a honest-to-god real native gcc for producing openbsd-m68k code, even though it might not expose bugs in dma and such. Anyone who have build X11 or started Gimp on a m68k machine would know that the feeling of a 500MHz 68k would be awesome. I figure the same goes for sun4c/m, vax, old mips and so on.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]