Retro emulation

I have written about a number of projects that I have done in recreating old computers like the HP2000/Access and the DEC PDP-10. To give this some impact and a sense of how these might have been used in the past, I have done a couple of videos for the /r/retrobattlestations reddit.

This first one show an emulated HP2000/Access system running a graphical 3D noughts and crosses game on an emulated Tektronix 4014.

This second one shows the startup of DEC PDP-10 TOPS-10 7.04 and the execution of the worlds first multi user dungeon, Essex university MUD, on a simulated old CRT terminal.

About Quentin

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

7 Responses to Retro emulation

  1. Bernard says:

    Thanks for the nice demo! I’m trying hard to get this image working in SIMH. Would it be possible to provide a ready-made image?

  2. Bernard says:

    The TOPS-10 demo of MUD1 looks great; the ./pdp10_start command, is that a shell script mounting the tape image ? Thanks !

  3. Bernard says:

    Looking good on my side, users just login as ‘mud’ then “run mud[2011,2776]”
    so everyone share the same land from richard’s PPN.
    On my side, I can login as richard and step in as archwiz.
    I’m trying to find a way to force the login user to step into the mud automatically

    I know it’s a long shot, but it seems we can control the login user up to
    a certain degree with react:

    .r react
    REACT>change [2011,2011]
    USER>program-to-run MUD.EXE[2011,2076]
    User [2011,2011] MUD changed

    A total of one user changed

    Then on the telnet side:

    .login mud
    Job 12 PDP10 TTY0
    [LGNLAS Last access to [2011,2011] succeeded on 26-Jan-122:22:46:38]
    22:57 26-Jan-122 Wednesday

    ?MUD.EXE not found

    Actually I found that if you use legit? commands like HELP or SYSTAT as “program-to-run”,
    it works well. Do you know any trick to run the mud “as a command”?
    (not sure if I explain this properly)


    • Quentin says:

      OK, that’s not how I have set up on my PDP and it looks to me like you have the wrong PPN in the program-to-run clause of the account. I have the MUD executable and data files in [2011,2011] and I have a MUDGUEST account in [2653,2653]. The MUD executable should have 055 as the protection. So my account setup for MUDGUEST looks like this:

      PPN: [2653,2653]
      User name: MUDGUEST
      Profile default: [2653,%] or [%,%]
      * Personal name: -none-
      * Distribution location: -none-
      * Mailing address: -none-

      * Expiration date: never
      * LOGIN times: Weekdays 0:23 Weekends 0:23
      * Access types: Local, Remote, Subjob of batch, Batch
      Requirements for LOGIN:
      Account and remark strings are not required
      Name is not required
      Password is not required
      Password change not required
      Minimum password length: -none-
      Password change interval: -none-
      Password changes are prohibited
      * Schedular type: 0
      Program to run: DSK:MUD.EXE[2011,2011]

      * Context-quotas: Contexts 4, Total pages 1000
      * Core Limits: Physical 512, Virtual 512
      * ENQ/DEQ quota: 100
      * IPCF quotas: Send 2, Receive 5, PIDs 2
      * Privileges: -none-
      * Spooled device bits: -none-
      * Watch bits: -none-

      * Structure quotas:
      Structure Quota in Quota out Reserved Status
      --------- ----------- ---------- ---------- ----------
      DSKB -infinite- -infinite- 0

      Administrative data:
      Profile last changed by [1,2] at 14-Dec-18 16:45:03
      Last access succeeded on 14-Dec-18 16:43:35
      Last password change at 14-Dec-18 16:43:25

  4. Bernard says:

    You’re right, the proper PPN to run the MUD should be the [2011,2011] one.
    If Richard wants to step in as archwiz, he has to “run mud[2011,2011]” from his PPN.

    The “DSK:MUD.EXE[2011,2011]” line in REACT is doing exactly what I want.

    Thank you !

Leave a Reply