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.5 for the Digilent boards, Quartus 13.0SP1 for the pre-Cyclone V boards, and Quartus 13.1 for the Cyclone-V boards – all on Linux. The toolchains will work the same on Windows, but the PDP2011 project includes a couple of utilities to compile Macro-11 sources into VHDL representation of rom and ram that are built to run on Linux – they can be converted to work on Windows or run under Cygwin etc, but I can’t support you if you  run into problems with that. The same goes for copying disk images to the sd cards.

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. 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 the easiest pushbutton to reach. On the embedded terminal, you will see ‘Hello world [t42]’ 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 bootrom that is included – either m9312X46 or m9312x47. The latter will also say ‘Hello world’, and then list the device space of the CPU – several lines of output. The original M9312 boot code in m9312x46 however will 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 that show the status of the controller and sd card – the rX_sdcard_debug signal, to be precise. If the controller has initialised the SD card, all four will be off – but if the controller cannot find the card, or if it cannot communicate to it, the leds will show in a dim/dim/full/dim pattern – this is caused by the controller constantly retrying the card initialisation sequence.

To check this, follow these simple steps: 1) power up and load, or reset the board *without* an sd card. You will see the dim/dim/full/dim pattern on some of the leds on the board – so you’ll know which leds to look for. 2) Now insert a card; the leds should go off immediately. If they do not, try another card.

These steps will work with both regular sd cards and sdhc cards – but you’ll need a regular sd card, the controllers are at present not capable of working with sdhc. Mostly, if a card is sdhc it will say so on the card, but if a card is bigger than 2Gb, it’s certainly sdhc.

If you get this far, you’ve established that communication to the sd card works.

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. The PDP2011 has no such thing as a master boot record, and cannot deal with partitions.

On Linux, this is relatively easy – copy the image using dd, and write it to the device itself – not to any of it’s partition subdevices. Something like ‘dd if=<image name> of=/dev/sdX’ – where X is the device of your card reader. To find out which X 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’, and the RL 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 bootroms, and it should work. Go play 🙂