First

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 🙂