PDP2011

It’s been a long time coming: the support for Oscar Vermeulen’s PiDP-11 console – in fact, I’ve been working on it, on and off, for over two years. Not that it was particularly difficult, but other things got in the way. The latest of those ‘other’ things was probably the worst so far – the roof of my work room started leaking, and directly above the table with all my FPGA setups on it. In short, I was lucky because I was at home and noticed immediately when the dripping started. But on the other hand I’m still months away from a return to normal, and I haven’t decided yet if I will ever restore my work room to its previous state of joyful disorder.
Back to the console. People have requested some kind of console like interface since I first published about PDP2011, and before Oscar came around, I always said that it was going to be very, very difficult. But something in my mind fired a spark when I saw the prototype panel he had made, and not long after I had the basics of the interactions done – and a sort of proof that it could be done. But interfacing the real panel also came with a couple challenges – that I had hoped to finish before the 2018 summer holidays, but looking back that was a bit too optimistic.
Still, at that time I was convinced it would only take one major change to finish things – the workings of the address selector knob. Again something that I had worried about, but that after I worked out how, it was actually not that difficult. But something unexpected did turn out to be difficult: how to actually drive the LEDs on the console.
In fact there were two challenges. First, to make the LEDs update as smoothly and frequently as possible without ghosting – lighting LEDs that aren’t driven by the intended signals. For the LEDs on the FPGA boards I was using for development that is not an issue, since all LEDs are directly connected to outputs. But on the PiDP-11 console panel, the LEDs are multiplexed and driven by a UDN2981A darlington array IC – and that really limits the speed by which the console can be updated. I’ve found that if the update speed is higher than about 30kHz, ghosting becomes visible – although it is a bit dependent on the types of LED, because my lab test board can deal with a bit higher speed. Then, also, the multiplexer itself needs several cycles to drive the banks of leds and read the switches. After some iterations to find out what works best, including cycles to switch from output to input and vice versa, and pause cycles in between driving banks of LEDs to further reduce ghosting, I’m now using 16 cycles to fully update the panel. Combine that with the (somewhat slower than full) speed I’m using to drive the multiplexer, in the setup I’m using now, the panel gets a complete refresh at a rate of about 435Hz.
And that brings me to the second challenge. At first, I thought it would be enough to show the state of a signal when the corresponding LED would be updated – in essence, taking a semi-random sample and showing that until the next refresh. But that turned out to be insufficient; some of the well-known wait loop displays didn’t work very well, and also the EKBA test program did not show the correct values. So I came up with the idea to do a simple or – if the signal was on in the period between panel updates, it would set the corresponding LED on. That also didn’t work very well… so with some reluctance, I should admit, I decided to implement the theoretically best solution given the multiplexed nature of the console: a counter that tracks how many cycles a signal is on, and setting a threshold for how many cycles will cause a LED to be on.
I was a bit worried that having adders for each of the LEDs on the console would make a real dent in the FPGA capacity, but no problem there. And it passes all the tests that the previous solutions didn’t – the wait loops look convincing, and all the well-known values appear as they should.
So, after some weeks of experimenting, playing with old software and running tests to establish the right values for the console update cycle and the LED threshold, that’s where I am now. There are still a couple of differences with a real console that I am aware of (and very likely a lot more that I’m not, but I’m counting on you to help me with those…)

• On a real 11/70, the pause led lights up on a memory access – that is, a ‘real’ access, not one that is found in the cache. But since PDP2011 doesn’t have a cache, if I’d follow that pattern, the pause led would be lit all the time – correctly according to the description, but also different than ‘the real thing’ – most of the time. So I made a somewhat arbitrary decision not to set the pause led for memory access. It does still light up for NPR access, such as when one of the disk controllers is using the bus.
• PDP2011 only shows the instruction word in the bus register – not the subsequent fetches. It’d probably not be overly complicated to implement, but for now, I kind of like it this way.
• The microcode adr FPU/CPU display is completely different. The microcode state numbers make no sense for PDP2011, and also, when I tried to implement a couple of the more obvious ones, I found that the resulting display did not look very convincing in practice. So what I did instead is that I assigned one LED to each of the major instruction groups; so now the display gives a quick overview of what kind of instructions make up the bulk of the work for the CPU.

On top of that, microcode single stepping obviously does not work – after all, there is no microcode. And I’m not quite sure that the instruction single stepping shows all the right values, or if the LEDs are updated at the appropriate time – when pressing or releasing the switches, that kind of thing. But I think that overall I’m pretty close.
So, what’s next? Oscar and I were thinking on making a simple interface board to easily connect the console to the DE0Nano board – nothing complex needs to be done, it is just a matter of connecting the pins on the console board to the proper pins on the FPGA. But we haven’t gotten around to that yet. So, for now, the best thing is a bunch of wires, similar to what I’ve been using for my test setup – those 40-pin breakout cables that the Raspberry Pi community use are very helpful. And, if you use a DE0Nano board like I am, you’ll also still need to hook up serial port and SD card. For that reason, I’m not yet distributing bitstreams for the console – getting it to work is not yet for the faint of heart. But, the latest sources are on the download page – if you’re thinking of building a bitstream for the console, the directory cons-de0n-basic is the place to start.
And now, it is high time that I start working on SDHC support – but, it’s not the first time I said that, and, the roof still needs fixing…

Booting a PDP-11 is something that I have maybe overlooked a bit, in trying to approach the ‘real thing’. In the history of PDP2011, it’s not that long ago really that I added the M9312 boot roms option – and I really still prefer my own boot code. Partly because PDP2011 can be different models with different peripherals according to the configuration, and my own boot code shows what has been configured. Easy to keep track of what kind of system is in an FPGA that way. And also faster.
However, the M9312 boot roms and the monitor included in them have certainly proved their value. For one, the monitor works with Jörg Hoppe’s PDP11GUI,  allowing loading and dumping of memory and disks – which, if nothing else, opens up the possibility of easily copying disk images to and from a PDP2011 system, other than physically removing SD cards – to the point that I’m now actually considering other flash memory media besides SD cards. For instance because those other flash media could potentially be lots cheaper. Very interesting for designing a shim board for connecting to Oscar Vermeulen’s console, potentially adding a couple low cost flash components for the disks instead of the SD card connectors…
And that brings me to the subject that’s been on my mind. Because Oscar’s console is very definitely an 11/70, and 11/70 is one of the models of PDP11 that had a very specific different way of booting – even if it had the same regular M9312 in it, there was a specific boot rom for it, with its specific tests, without the monitor, and with a specific method of booting.
In general, PDP11 hardware would ‘boot’ using the power fail trap vector 024, and 11/70 follows this pattern. The M9312 would then detect the boot, and during the memory cycles to fetch the trap vector and PS the M9312 would ‘wire-or’ the values set on its micro switches to make the processor load the vector from its boot roms – one bigger 512 word rom for diagnostics and the monitor, or in case of the 11/70 for diagnostics only; and 4 smaller 128 word roms for booting from many different peripherals – at least 20 different types of disks supported by DEC alone, but also magnetic tape units, paper tape readers, punch card readers, and network cards – serial and Ethernet. So the most important thing about booting for an 11/70 administrator would be to choose the device boot roms, and set the switches (the ‘address offset switch bank $1’) on the M9312 card to the preferred boot medium – or to the diagnostics.

The switches on the M9312 card could be used to make the cpu to start the boot code in one of the small roms directly – most likely booting your preferred operating system from one of the hard disks. But you could also set it to start at the diagnostics code in the lower rom, and then use the console switches to determine to which location in the smaller device specific boot roms to jump.

And that’s what I’ve been thinking about – how to do that for PDP2011. With Oscar’s console, it is obviously possible to let the system boot in the 11/70 console style, have it run the specific 11/70 rom with its diagnostics, and then boot from one of the roms according to the setting on the console switches. But… well, I’m not sure what that would add. Booting the fpga PDP11 isn’t really going to be ‘really’ the same as the ‘real thing’, ever – for one, the power fail vector doesn’t really make sense like it did in the days of core memory. Nor can an fpga do wired or – sure I can work my way around that with another multiplexer implied from another if statement in the code, but it’d seem a bit awkward, and especially in the address calculation, I can really miss another layer of complexity. It wouldn’t make the system run any faster, that’s for sure.
So, what is on my mind is that while it isn’t really the way that a ‘real’ 11/70 would boot, the M9312 monitor is actually probably better in terms of flexibility and user friendliness. And for those that would rather directly boot from a specific device without bothering with console interaction, it’s fairly easy to do so by reconfiguring the start address in the PDP2011 code – basically, today’s equivalent of setting switches on the M9312 card. And, well, obviously it would be possible to add physical switches on a shim card, or use switches that are on the fpga board, or some combination – but on the target board that I’m working on now, the de0nano, there aren’t enough switches and I’d rather use them for something else probably.
In short, I’m a bit hesitant to add the special /70 boot rom – I’m not saying that I never will, but I think the monitor rom is far easier and more flexible to use, and for fixed setups the old style pdp2011 roms will probably work better, maybe in combination with a changed start address in the top source file. If I’m going to add it, it’ll probably not be the default. That should be the monitor, I think.