prboom-mso5k

prboom-mso5k copied to clipboard

*** DOOM for the Rigol MSO5000 series ***

The Rigol MSO5000 runs Linux under the hood, and it's possible (at least for the 01.01.02.03 and 01.01.02.04 firmwares) to get a root login to mess around with the system. Obviously, Doom needs to be able to run on this. I've given this a try, using prboom as a base. As the front panel and framebuffer are not entirely nonstandard, I have modified prboom slightly to accomodate this.

• WARNING

Note that I give absolutely no guarantee on what this software does on your scope. On mine, it runs Doom, as intended, but I cannot guarantee it will not break something on yours. I also have no clue what Rigols warranty service will say about a scope that has run Doom. All in all: while this software has been put together in good faith, if you run this on your scope, note that you do so at your own risk.

• How to try this

• Download the release archive prboom-mso5k.zip and unzip the contents to an USB stick. Archive is here: https://github.com/Spritetm/prboom-mso5k/releases/download/v1.0/prboom-mso5k.zip
• Insert USB stick into your MSO5000-series scope
• Connect the scope to an Ethernet network and configure it to get an IP.
• Using putty or ssh, connect to the IP of the scope. Username is root, and password is root for 01.01.02.03 firmware, Rigol201 for 01.01.02.04 firmwares.
• Run Doom by entering: cd /media/sda1 ./doom.sh

Note that sometimes Doom hangs on the startup screen. If after 10 seconds, nothing happens, kill Doom by pressing ctrl-C, and re-run the ./doom.sh command.

• Controls:

• 'STOP/RUN' - show/hide main menu
• Trigger level knob: menu item selection up/down
• 'SINGLE': choose selected menu item
• 'SEARCH', <, [], > buttons in navigate section: forward, backward, left, right
• 'CLEAR': fire weapon
• 'AUTO': open door
• Multi-functional knob: select weapon

To exit the game, just power off your 'scope.

• How to recompile from source:

• Have a little-endian Arm Linux system at the ready, which we'll use as a build system. I used a Raspberry Pi with minibian installed; raspbian or vanilla Debian will probably also work.
• Install make, gcc and git on the build system using 'apt-get install make gcc git' or something.
• Create the build/install directory mkdir /doom
• Download and unpack libsdl wget https://www.libsdl.org/release/SDL-1.2.15.tar.gz tar -xvf SDL-1.2.15.tar.gz cd SDL-1.2.15
• Configure and compile sdl ./configure --disable-audio --disable-video-nanox --disable-video-x11 --enable-video-fbcon
  --disable-video-directfb --disable-video-aalib --disable--video-caca --disable-video-opengl
  --without-x --disable-threads --disable-dga --disable-video-dga --disable-video-x11-vm
  --disable-video-x11-xv --disable-video-x11-xinerama --disable-video-x11-xme
  --disable-video-x11-xrandr --prefix=/doom make make install
• Grab prboom from Github git clone https://github.com/Spritetm/prboom-mso5k
• Configure and compile cd prboom-mso5k ./mso5k-configure.sh make
• Collect files mkdir /doom/dist cp src/prboom-plus data/prboom-plus.wad doom.sh /doom/dist
• Add the shareware doom1.wad (or any other Doom wadfile) to /doom/dist
• The files in /doom/dist can now be copied to an USB stick; proceed as if you have created the USB stick from release files.

• Notes on my changes

Most happened in src/SDL/i_video.c as the 'normal' SDL interface code is located there. The code is mostly intact, aside from two major changes. First of all, the framebuffer of the MSO5000 series is a bit wonky: it actually has three framebuffers. This is needed as the hardware projects the actual curve without software intervention, and as such you have at least a framebuffer that sits behind the trace (for e.g. the graticule) and one that sits on top of the trace (e.g. for dialogs). The kernel driver implements this using an ioctl on /dev/fb0: you use the ioctl to select the framebuffer you want, then you use mmap() to get the actual selected framebuffer memory. Note Doom only uses the front one.

The front panel keys are controlled by a separate controller, which communicates with the main CPU using a serial connection at 1MBaud at /dev/ttyPS1. When a button is pressed or a knob is turned, the front panel will send a packet of 16 bytes. The first one always is 0xAA and can be used as a sync byte or something; the last two are a checksum or timestamp or something. The state of the buttons is encoded in the bits: if a button is pressed, its bit is zero, if it is released, it returns to one. The rotary buttons basically have their two quadrature outputs connected to two adjacent bits. (Use 'hd /dev/ttyPS1' to look at this.)