Getting a PDP2011 system to run is a bit of work, certainly if you are not familiar with FPGA’s and the vendor toolchains required to program them. On this page, I’ve tried to list some steps in ascending order of complexity, to make it easier to avoid pitfalls and help finding out what causes things not to work if it doesn’t go smoothly. I strongly suggest that you start trying out one of the bitstreams I publish on the download page first, even if you’re going to build your own configuration or want to use a board that I don’t support – it will show what to watch out for; but even if you don’t, what’s on this page may help you.

Getting the FPGA toolchain to work
You will need the vendor’s toolchain to download bitstreams onto the board, and to recompile the VHDL if you decide later that you want to create your own configuration. The toolchains are complex bits of software that have a steep learning curve – I suggest you try some of the tutorials and sample projects that the vendors provide.

Currently, I’m using ISE 14.7 for the Digilent boards, Quartus 13.0SP1 for the pre-Cyclone IV boards, and Quartus 22.1std.0 for the newer boards – all on Linux. The toolchains will probably work mostly the same on Windows, but I don’t have access to a Windows machine, so I can’t help you with it if you run into trouble.

Loading a bit stream
The first thing to check after you’ve managed to load one of the bitstreams into a board is whether or not it is communicating on the serial port – or if the embedded terminal is. Connect a serial port, and set it to 9600, 8 data bits, 1 stop bit, no parity. On Linux, minicom is the terminal software of choice; for Windows, hyperterm is the easiest to find (most people like Putty better though). Not sure what the current thing on the latest versions of Windows is (mentioning hyperterm probably shows my age…).

Some USB-to-serial converters don’t like to be configured and insist on their own idea of the right parameters; sending a few return characters usually does the trick.

If you chose one of the embedded terminal bitstreams, you’d need to connect a VGA screen at this point. About any VGA capable screen will work – it is driven at 640×480, 60Hz. Also connect a PS2 keyboard.
For either the embedded terminal or the serial console, you should see text appearing if you load the FPGA, or if you hit the button mapped to the reset input – usually that is the easiest pushbutton to reach.

On the embedded terminal, you will see ‘Hello, world: [PDP2011 vt10x]’ as the first message after power-up; this is the boot message of the terminal CPU – if you see this, it means that the terminal code is running. After that, or as the first output for the serial consoles, you should see text that is written by the boot roms of the main CPU; what you will see is dependent on the bootroms that are included. The default bootroms will also say ‘Hello world’, and then list the device space of the CPU – several lines of output. The original DEC M9312 boot code in the odt bootroms will however only output a single ‘@’.

If you get this far, you’ve established that a) the bitstream was loaded correctly, b) that you’re in communication with the board, and c) the boot code is running.

Connecting an SD card
Next step is to establish communication with an sd card to boot from. All bitstreams I distribute have a group of 4 leds somewhere on the board that show the status of the controller and sd card – the sdcard_debug signal, to be precise – and note that this has changed since the mid-2020 update to SDHC capable controllers; the way the leds light up is now different.

With the new SDHC capable version, the first led is on if the controller can not communicate with the card. The second is on if the card is SD but not SDHC. The third is on while the card is being read, and the fourth is on while the card is written onto.

To check SD card connectivity, follow these simple steps: 1) power up and load, or reset the board *without* an sd card. You will see the first two leds light up. 2) Now insert a card; the first led should go off immediately, and the second one too if the card is SDHC capable. If you don’t see any change, try another card.

If you get this far, you’ve established that communication to the sd card works. But the card needs to have a valid disk image on it for the system to boot from it.

Loading a card with a disk image
There’s two things that usually cause confusion in loading sd cards – how to do this on Windows, and how to make sure that your image is in the right place. The controllers require that the image starts at sector 0; this differs from the usual formatting of cards and disks in the PC world, because sector 0 is used there to contain the master boot record, which contains the partition layout of the card or disk. PDP2011 has no such thing as a master boot record, and cannot deal with partitions – that is a thing of operating systems.

On Linux, creating a bootable disk image is relatively easy – copy the image using dd, and write it to the device itself – not to any of its partition subdevices. Something like ‘dd if=<image name> of=/dev/sdX’ – where X is the device of your card reader. To find out which device name your card reader uses, insert a card in it, then look in /var/log/messages to see which device was just changed. Make sure you’re not dd’ing to /dev/sda – that is usually your hard disk, and things will get seriously messed up if you write directly to that.

On Windows, there’s a lot of tools that will do the trick – but as I don’t use Windows, I can’t help you with that.

It’s probably easiest to start with an RK image of RT-11 – that’s small, will boot very quickly, and will not require you to do anything to get it to boot correctly; once you’ve verified that that works and you’ve gone through all the steps to get to a working PDP2011 system, you can move on to more complex things.

A slightly more complex scenario is to start with an RL image of one of the XXDP disks. To use RL images, you must first reformat the image with the sdfmt utility – this will copy the RL image in chunks of 256 bytes, and insert 256 bytes padding after each of those chunks. This is required because the sd cards work only with 512 byte ‘sectors’, but the RL disk has 256 byte sectors – if you forget to do this, the image on the card will not be readable by the controller, and you’ll not be able to boot from it.

The sdfmt utility works as follows: sdfmt -i <input image> -o <reformatted output image>. You can give multiple input images to it by repeating the ‘-i <input image’;  the utility will make sure each image ends up in the right place in the output. As you’d probably expect, the utility is made for Linux and will likely work just fine with Cygwin or even natively if you recompile it on Windows, but I won’t be able to help you if it doesn’t.

Booting the OS
Insert the sd card into the board, optionally reload the FPGA with the bitstream, press the reset button, optionally enter the boot command for the disk you want to boot from if you have the M9312 odt bootroms, and it should work. Go play 🙂


AndrewZ March 14, 2021 Reply

This is a very cool web page. I programmed PDP-11’s in high school, RSTS, and also in college, BSD. I have a fondness for the PDP-11 architecture and having re-learning Macro-11 with the thought of writing an article. I’m also thinking it would be fun to have a PDP-11 to tinker with. Not sure I could master the intricacies of FPGA but it’s great to see someone who has.

FayeS May 1, 2023 Reply

It has been years since I expressed an interest and got all setup to do this… and then got busy (I’m sure you know what that’s like)… but now I have Quartus running on my M1 MacBook Pro (In an arm64 Ubuntu VM running FEX) and I was able to coerce the tools into making me an .rbf so that I could use openFPGALoader to dump it on the CYC1000 and I got this after dd’ing your unix image to an SDHC:

: xp(0,0,0)unix
Boot: bootdev=05000 bootcsr=0176700

2.11 BSD UNIX #5: Sat Oct 31 18:56:40 CST 2020

attaching de0 csr 174510

Which means, I think that the FPGA is doing great and that I might have to sdfmt your image?.. that or connect an Ethernet cable.

Either way, this is progress and I couldn’t be happier. Along the way I came across a Nexys Video card (Artix7), so might do a port when I get a round tuit.

sytse May 1, 2023 Reply

Hello Faye

if 211bsd gets stuck after the ‘attaching de0’ message, then the OS is waiting for a status change in the DEUNA. But that’ll never happen, because the xu logic in the fpga is not talking to the enc424 chip – either because a wire is loose, or because there’s no enc424 at all.

A simple fix is to edit the top.vhd file to disable the xu (ie, DEUNA), like ‘have_xu => 0’. Or else connect the enc424, or even an esp32 for wireless networking with the latest version.

(edit:) Oh I forgot to mention, yes, the fpga is working, the cpu is running, memory is ok, the OS is doing fine, the console is up, the disk controller and disk are online. Everything except the DEUNA, in short.

Leave a Reply