Some weeks ago I was involved in a discussion about how the leds on the 11/70 should work – more specifically, how to deal with the differences in the ‘real’ hardware and Oscar Vermeulen’s PiDP-11 console. I had what I thought was a rather nice idea, but it wasn’t received very well – and, given the lack of real and working 11/70 systems about, it wasn’t very easy to find out what was ‘right’. So I thought about it for a while, and decided to focus on something else for a while. The idea I came up with was to revisit the old 11/70 test programs. The first one in the set, EKBA, I had already managed to run flawlessly, but I didn’t spend much time with the second one, EKBB.
Maybe it was my subconscious playing a trick, because EKBB is – as far as I know, at least – the only program that includes a console test… and that very quickly proved that my nice idea for the console wasn’t working at all. But after reverting it, I then decided to have a look at all the other error messages that EKBB was throwing at me. Mainly these were in two categories – DIV condition codes and stack limit behaviour.
The DIV condition codes caused a bit of a headache – again, I should probably say, but because the last time I looked at this bit of core is already 8 years ago, the details had slipped a bit. I did manage to fix a couple of the error – messages, I should probably add, because functionally it did work correctly already; what the tests do is determine at which point the DIV instruction is aborted in a number of edge cases such as divide by zero.
More interesting really were the errors about the stack limit.
Originally, PDP2011 was going to be something like an 11/94 – since that seemed the most interesting model, and also I had the listings for the ZKDJ test that showed the actual workings of the machine in much greater detail than the manuals did. When that worked, I added the other models mostly by selectively disabling bits of the core for 11/94. But, 11/94 may have the highest number, but it isn’t in all respects the most complex machine – and, one of those is the stack limit, which is a lot more complex and different in 11/70 (and 11/45 too, for that matter). And, the version that I had implemented might pass the tests for the J-11 cpus, 11/34 and 11/44, but it certainly did not pass the tests for 11/70.
Turns out I had misunderstood quite a bit of the way it is supposed to work. For instance, I had assumed that the initial (after reset) value of the stack limit register should be 400. But actually, it should be 0 – and the limit of 376 and 340 above that is arranged in logic. And, even more of a surprise, the stack limit mechanism also protects the PSW from being overwritten by the stack – and in the 11/45, even more internal registers are.
So as usual the interesting question is, how can it be that PDP2011 systems of all possible configurations – including quite a few 11/70 – have run since November 2011 and this bug wasn’t ever found? I’d speculate that the operating systems usually don’t run into yellow or red stack traps – and if they do, it is probably a secondary effect of something else going wrong. If that is the case, the errors wouldn’t be recoverable, and then it doesn’t matter so much if the trap mechanism doesn’t work entirely as it should.
Anyway, it’s fixed now. Not that EKBB now passes flawlessly – there are a few puzzles left in it. But first up now is to go back to the console and the leds. And oh, what I almost forgot – thanks to Jörg Hoppe for providing the listings of these tests, and obviously Al Kossow too for everything Bitsavers. None of this would be possible without freely accessible documentation.