Shim design (2)

So, picking up from where I ended up in the last post – basically, waiting for inspiration on how to best address the lack of elegance of the DE0nano + shim + PiDP-11. I did try several things – I made a lot of nice colourful 40-pin ribbon cables, different ways of folding and pushing them into the console box. Didn’t really work.

I discussed my shim plans with several people but the lightbulb, Eureka-style solution did not happen. What I did get was a new insight in how much difference there is in what people are looking for in terms of peripherals, and in how they want their system to look in the end – ranging from a finished box with only the bare essentials neatly connected on the rear end of the box, to a maxed-out PDP that pushes the limits of what was possible back in the day, and with wires all over the place. Not easy to find a common ground, a design that would potentially resonate with all of that.

Anyway, a bit of time passed without finding a solution… and then, just at the right moment when I got back home after a nice and long holiday… Jan Secker posted a message in the PiDP11 mailing list, about the CYC1000 FPGA board that he was hooking up to his PiDP11. By far the smallest FPGA board I’d seen, and also by far the cheapest – with exactly the right components on to form the basis of a nice PDP2011 system. The Cyclone-10 FPGA on it is the latest generation too – smaller structures on the chip, and that means higher clock speeds. And it’s comfortably large enough to hold a PDP2011/70 with FPU, PiDP console driver, disk and Ethernet controllers, and still have more than a quarter of its capacity free for other things…

In fact, there’s only one downside to the CYC1000 – it doesn’t have that many pins. Exactly enough for a ‘normal’ PDP2011 with PiDP-11 console, one disk, Ethernet, and one or two terminals. Just about perfect for a functional system, not quite so for the people looking for a maxed-out PDP. And that gave me the idea to go for two different streams – CYC1000 and a minimal lowest-possible-cost shim for the ‘normal’ systems, and DE0-nano for the maxed-out systems.

The design for the shim was relatively easy. As tempting as it was to put an sd card connector and ENC424 Ethernet front end and magnetics on, I decided not to do that and instead just rely on PMODs for all the extra bits – firstly because I felt a bit out of depth designing for the ENC424 chip, and anticipated that I’d have to do several prototype rounds to iron out mistakes; but secondly and maybe even more important, the complexities of sourcing the components, especially since I could not find a single supplier for all the parts I needed.

Afterwards, when the first prototype was already on my desk, another fairly essential reason occurred to me – the physical aspects of the PiDP-11 console box. As many messages on the PiDP mailing list have shown, it’s not entirely trivial to integrate connectors for Ethernet, serial and cards neatly on the rear lid of the box… and there’s hardly enough room for the bigger PMODs like NIC and full-size SD. But at least this way each owner can decide for himself how to make everything fit – while I dream about the next step and have everything work wirelessly!

Anyway, some photos for illustration:

The CYC1000 FPGA board as it comes out of its tiny box
With a 2×6 pin PMOD header soldered on
The smallest possible PDP2011 system. Console on the FTDI chip on the board, and one disk controller on the micro-SD.
Slightly bigger with a connector for a full size SD card
PMODs for micro-sd and Ethernet – since both only need one row of the 2×6 connector, a simple splitter cable works very nicely.
The shim!
CYC1000 mounted in the PiDP11. Note the RS232 port on top of the CYC1000.
View from the side – also showing the bypass resistors on the PiDP pcb.

Right, enough for today. The next instalment will have some more detail about the shim and the difficulties of logistics. I didn’t quite manage to post daily as I planned for this week – not many things work out according to plan currently. But it should be soon.

Shim design

I was thinking back on the spring of 2017, and first time Oscar came over to my home and showed his PiDP-11 prototype. Already then the subject of a ‘shim’ came up… but we didn’t really reach a conclusion. Nor did we on later meetings…

It all seems so simple. The PiDP-11 has a connector, the FPGA board has a connector, and some peripherals need to be interfaced. But then the questions start… which FPGA board? how will the whole thing fit into the rear end of the console? which peripherals go on, and how will those fit in and how will things like Ethernet cables and sd cards come in to the console? Oscar’s initial idea was to make a board of the same size as the lid of the console box, and make a DE0-nano sized hole in it so you could still reach the switches on the DE0-nano and see the blinkenlights. And I wanted to try to include some kind of multiport usb-to-serial, because I was getting fed up with the amount of cables on my work desk…

We didn’t manage to reach a conclusion on that. As time passed, I did some experiments with my usb-to-serial idea and ordered a pcb for it – including component assembly, because I didn’t feel like soldering lots of tiny SMD. That was a lot of fun to do, and the board turned out nicely – with only one real mistake in the prototype: the connector for the PMODNIC was upside down. Or maybe the right way up, because – as I found out – it’s more logical to have the whole board upside down…

Anyway – in practice the board worked very well, but there were two things about it that I really didn’t like – to connect it to the DE0-nano and to the PiDP console you’d need two 40-pin ribbon cables; one even with a male connector on. Lots of work to make, unwieldy and adding quite a bit to the kit cost. And the other thing: stacked to the DE0-nano, it would stick out beyond the rear end of the PiDP-11 console box…

That was basically the end of the DE0 shim – a nice experiment, and I’m using them still for my test bench, but not for the PiDP console. I didn’t really decide not to continue with it, it was more a thing of waiting for the idea that would make it into a nice project again. But that idea didn’t really come.

Until the CYC-1000 arrived… but that’s the subject of tomorrow’s post.

prototype shim pcb for de0nano and pidp-11 console

Here’s one of the few remaining prototypes… two more are in use; actually, my always-on 211bsd system runs with one, and it would have had an uptime of over a year now if I hadn’t made a mistake with the FPGA software some time in January…

New but the same

One of those things I’ve postponed for years but now finally done – migrate my old server running Fedora 20 to something new. It turned out to be a mix of surprisingly easy and surprisingly difficult. The wordpress migration for instance turned out to be easier than I thought – but, the new version in some inexplicable way messed up the layout of some posts. I’m taking the easy way out on that one: I’ll just reformat some of the posts.

More difficult though was that I’ve also had to move version management from cvs to git. In itself, cvs still works, but the tooling around it doesn’t – including even the cvs to git migration tools. Not really an issue for the pdp2011 stuff since I partly used git tooling for that already, but some other projects still in cvs didn’t migrate easily.

Maybe the migration would have been easier if I’d kept up with the latest versions a bit more. Or if the server would be less of a do-everything machine. But on the other side, there’s also definitely the complexity of projects running over several decades, despite technology changing all the time. And, getting older myself, of course it is inevitable to wonder whether all of the changes are really worth it. Did cron have to change to anachron? did ntpd have to be changed to chronyd? is git better than cvs, is wordpress better with blocks? Did Unix ever get better after v7, or after 211BSD?

Anyway, with the server migration out of the way though I can go back to the interesting stuff and resume work on the shim kit and sdhc support. Updates real soon now, I promise 🙂

The smallest PDP-11 ever!


62.5 by 25mm. That is how big the smallest ever PDP-11 system is, based on the CYC1000 FPGA board from Trenz Electronic. It’s not a small PDP-11 though – it is a full PDP-11/70 with PiDP11 front panel console, RH70+RP06 disk, DEUNA ethernet controller, and two serial ports. Ok, it is a bit bigger if you connect all that, but still smaller than all the other boards I’ve worked on so far.
The FPGA is Altera/Intel’s latest generation Cyclone, and it is pretty fast – it runs the CPU of the PDP2011 at 12Mhz. There is an FTDI chip that is used for programming the board; it can be used as a console port as well. And a 8Mbyte SDRAM chip, 8 leds, two really tiny buttons, a 2×6 pin row suited for connecting PMODs … exactly what we need to run PDP2011 on!
To make connecting the PiDP11 front panel easier, I have designed a ‘shim’, a small board – also 62.5 by 25mm – to be mounted under the FPGA board. It maps the GPIOs to the side of the FPGA board to a 40 pin header for the PiDP11 panel, and a 2×6 pin header for an extra serial port.

If soldered together, it is small enough that the whole thing will nicely fit into the PiDP11 case, and the back panel will still fit. I don’t think that will be the case if the two are connected with sockets… but, since the CYC1000 is also the cheapest board I’ve seen so far, I don’t think sockets are really needed.
In the next weeks, I will write up a howto for the boards, and add the bitstreams for the FPGA to the download page. I haven’t made up my mind if I will be selling the shim (maybe even as a kit with all the headers you’d need) or if I will just publish the gerbers so everyone that wants one can order from their favourite PCB shop themselves. If you’re interested in either option, let me know – that’ll help me make up my mind!

A possible issue with SDHC

The new SDHC capable RH controller works great. I’ve mainly used it for 2.11BSD so far, and everything works faster, more responsive, and nicer with it. Compiling the kernel, playing with Ingres – no problems at all.
But this little command line:

while true; do /usr/games/fortune;echo;echo;sleep 2;done

after a random number of fortunes bombs out with the message

true: cannot execute

and it doesn’t with the old style controller.
I’m not sure I’m able to explain properly how weird this is. But it correlates perfectly well with the new controller, and I’m able to reproduce it easily (although it may take a couple of hours of running the while loop before it occurs). All other likely causes – clock speed too high, card broken, issues with the board or FPGA, memory etc – have been excluded.
I’ve been thinking for a couple days on how to isolate the issue, but that isn’t easy – it doesn’t predictably occur, and I’m not sure yet where to go looking. Maybe the best for now is to continue with what I wanted to do anyway – check the old XXDP test programs against the new controller, and add multiple disk support. There’s a good chance that will help finding what causes this.
In the meantime, I don’t think this should stop you from using the SDHC version – other than this weirdness, it seems pretty stable, and everything else I’ve thrown at it works fine. But keep an eye on things, do your backups, and be sure to contact me if you see something similarly weird happening!

SDHC

It’s been a long time coming, but I’m happy to announce that I have finally finished SDHC support. Ehh, well, just for the RH/RP06 though. And the RH still only supports just one disk.
The reason it took so long is that besides just adding SDHC I’ve also redone enough of the disk controller that it now only claims the bus to do high-speed, max 256 cycle transfers – basically, reading or writing a whole sector in one go. The old controller would lock the bus from the moment the ‘go’ bit in the controller was set, until the end of the transaction – and, depending on the card speed and the length of the transaction, that could take a really long time.
The old controller would also run the interface to the SD card at the CPU clock speed, but the new one uses a fixed 25Mhz clock – usually at least double the CPU speed. Although a lot of time in the card interaction is still going to be spent waiting for the card to finish reading or writing a sector and I think most of that waiting is not dependent on the interface – but it will still make a bit of difference.
I did some simple benchmarking to see how much faster the new controller would be.  For the first test, the run was as follows: load a copy of my 2.11BSD system onto a card, then run time make in the /usr/src/sys/PDP2011 directory – once on my old DE0Nano with the old controller, and once on another DE0Nano with the new controller:

de0n old : 1624.8 real       945.2 user       496.0 sys     (100/14=7.14)
de0n new : 1570.4 real      1000.6 user       263.3 sys     (90/14=6.42)

Hmm, a bit faster, but not as much as I had hoped for… and, I’m not quite sure why, but with all the console stuff enabled, I couldn’t get either board to run at full speed; the max I could get out of the old version was some 7Mhz at the cpu, and 6.42 for the new version. Surprising, since there shouldn’t be a direct speed impact in most of the console logic… it’ll need some debugging. In the meantime, to make the test of the SD controller a bit more interesting, I did a run with the console stuff disabled:

de0n new : 1082.8 real       626.4 user       159.4 sys     (140/14=10 - without pidp11 console)

Ah, that’s more like it!
Then, for a second test, I was curious how fast different types and brands of cards would go. So, I took a handful of fairly low end but current micro-SDHC cards against my old micro-SD (without HC). Not entirely fair of course, since there is about a 10 year age difference… but then, the cards I checked were the cheapest I could find from a local supplier. Oh, I’m not at all sure all SDHC cards are from the same generation, so don’t read too much into the brand name columns…

san old    1897.0 real       623.1 user       149.2 sys     (Sandisk SD (not HC) 512Mb >10 years old)
san grey   1070.8 real       628.7 user       152.9 sys     (Sandisk Ultra Class-10 UHS1 16GB 'up to 80MB/s')
san red    1059.8 real       626.9 user       155.4 sys     (Sandisk Ultra Class-10 UHS1 16GB 'up to 98MB/s')
adata      1020.6 real       633.1 user       152.6 sys     (Adata Premier UHS-1 Class-10 16GB)
transcend  1053.4 real       632.7 user       151.7 sys     (Transcend Premium UHS1 32Gb 'up to 90B/s')
kingston   1047.0 real       630.2 user       152.7 sys     (Kingston Class-4 8GB)

So, almost twice as fast, I hear you think. Well, maybe even better, and that’s something I should probably already have mentioned for the first test: one of the things with the long and frequent locking of the bus is that it would cause missed clock interrupts – basically, that occurs whenever the bus is locked longer than one timer interrupt. And with the heavy I/O during a kernel build… those missed interrupts easily cause the clock to run slow by more than a minute with the old controller, but it’s dead on with the new one. But the ‘time’ command doesn’t know about that… Compare the ‘de0n old’ time of 1624.8 real with the ‘san old’ time of 1897 real, and then factor in the difference in clock speed as noted by the user time… oh, and the difference in sys time? that’s also the time that the bus is locked waiting for the card, excluding clock skew caused by missed interrupts.
The new controller causes the system to remain a lot more responsive under load, it’s really noticeable if you try to login another telnet or serial connection while a build is running. And the disk reporting in vmstat and iostat finally make some sense… in the old version, that didn’t work because the CPU didn’t notice any elapsed time as it was basically frozen during I/O.
I’ve mainly tested the new controller with 2.11BSD and RSX-11MP, and only as RP06. I don’t think that surprises are likely with the other OSses though, but you never know – and, unlike the old version, the new version hasn’t been tested against the old RM test programs yet. I had kind of hoped to add support for multiple disks in the same go, but I hadn’t counted on the complexity of the RH70/RH11 controller in combination with the disks – where some of the control registers are part of the controller, and some are in the disk. So to support multiple disks, it will become necessary to rework those registers that reside in the disk into multiples as well. Not really a trivial exercise. Similarly, I had also hoped that reworking the RK and RL controllers to use the new shared SDHC-SPI backend. No luck though, there’s still a bug in the RK that I can’t find, and I’ve not had time to even start on the RL.
So all of that will have to wait till the winter. Meantime I’ll put up a tar of the latest sources on the download page, but, it’s at best beta quality for now, and as I said, only the RH/RP06 is new, RK and RL are still old.
Oh. Almost forgot. The new controller does use a bit more resources than the old one did – that shouldn’t really be a surprise, since it does implement an extra buffer, and copying from and to it. In comparison with some of the other parts of the PDP2011 system it’s not that big of a deal though. But, maybe the old DE0 board is really too small now.
And another thing: I changed the debug/status LEDs for the new controller. LED0 is now off when the card is online, on when it is not – or while recovering from an error. LED1 is on when the card is not SDHC, off when it is. LED2 is on while doing a read. LED3 is on while doing a write.

Wiring

As a byproduct of the PiDP-11 console support, I’ve defined a more or less ‘standard’ pin layout for the 40-pin connector on most of the Intel/Altera/Terasic FPGA boards – obviously carrying all the signals for the console itself, but also for the most basic peripherals that all PDP2011 systems need: a serial port for the console, an additional serial port, and the SPI interface signals for the Ethernet chip and the sd card for a disk. Basic, for sure, but also more than enough for enjoying the PDP-ness, and all of it conveniently fits on the 40 pins.
In the history of PDP2011, I’ve been using jumper wires to make all the required connections. That was easy enough with the older boards, as those usually had serial port and card connectors already – so mostly only some debugging stuff or the PMODNIC100 needed to be hooked up. But, DE0Nano was already a bit more of a challenge – mostly because there weren’t enough power pins to make direct connections to several PMODs. And then the console… well, the Raspberry Pi marketplace does have 40-pin jumper cables, those do come in handy. But, I’m thinking about a standard peripheral board to connect FPGA board, console panel, serial ports, sd card, and the PMODNIC100 together.
So far, I’ve set up the standard pin layout for three boards – obviously DE0Nano, but also DE10-Lite and DE0-CV. Like so:

To de0nano pin de10lite pin de0cv pin connector pin
rx1 PIN_T9 PIN_V10 PIN_H16 1
tx1 PIN_F13 PIN_W10 PIN_A12 2
rx2 PIN_R9 PIN_V9 PIN_H15 3
tx2 PIN_T15 PIN_W9 PIN_B12 4
panel_row[1] PIN_T14 PIN_V8 PIN_A13 5
panel_row[2] PIN_T13 PIN_W8 PIN_B13 6
panel_col[2] PIN_R13 PIN_V7 PIN_G17 7
rts1 PIN_T12 PIN_W7 PIN_D13 8
xu_debug 9
cts1 PIN_T11 PIN_V5 PIN_G17 10
VCC5 11
GND 12
panel_col[1] PIN_T10 PIN_W5 PIN_G14 13
sdcard_miso PIN_R11 PIN_AA15 PIN_J18 14
panel_xled[2] PIN_P11 PIN_AA14 PIN_J19 15
panel_xled[3] PIN_R10 PIN_W13 PIN_G11 16
panel_col[8] PIN_N12 PIN_W12 PIN_H10 17
panel_xled[4] PIN_P9 PIN_AB13 PIN_J11 18
sdcard_sclk PIN_N9 PIN_AB12 PIN_H14 19
sdcard_cs PIN_N11 PIN_Y11 PIN_A15 20
sdcard_mosi PIN_L16 PIN_AB11 PIN_J13 21
panel_xled[5] PIN_K16 PIN_W11 PIN_L8 22
panel_col[9] PIN_R16 PIN_AB10 PIN_A14 23
panel_col[6] PIN_L15 PIN_AA10 PIN_B15 24
panel_col[7] PIN_P15 PIN_AA9 PIN_C15 25
panel_col[5] PIN_P16 PIN_Y8 PIN_E14 26
panel_col[3] PIN_R14 PIN_AA8 PIN_G18 27
xu_mosi PIN_N16 PIN_Y7 PIN_E16 28
VCC3.3 29
GND 30
panel_col[4] PIN_N15 PIN_AA7 PIN_F14 31
panel_col[10] PIN_P14 PIN_Y6 PIN_G15 32
panel_col[11] PIN_L14 PIN_AA6 PIN_G16 33
xu_cs PIN_N14 PIN_Y5 PIN_F12 34
xu_miso PIN_M10 PIN_AA5 PIN_G16 35
panel_row[0] PIN_L13 PIN_Y4 PIN_G15 36
panel_col[0] PIN_J16 PIN_AB3 PIN_G13 37
panel_xled[0] PIN_K15 PIN_Y3 PIN_G12 38
xu_sclk PIN_J13 PIN_AB2 PIN_J17 39
panel_xled[1] PIN_J14 PIN_AA2 PIN_K16 40

The actual pin layout and the signals that go on the connector are already pretty much fixed – I’d like of course to be able to add more, like RTS/CTS  for the second serial port, but there aren’t enough pins and I don’t see which others I could take out – except maybe xu_debug, but that’s only one. What I am still thinking about is to make a small PCB that connects everything together; but there is a surprising number of details to consider. I should probably do my next post on that subject.
Meantime, I’m working on a new sd card controller that will support SDHC cards, finally!

Console

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…

Stack limit

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.

Booting 11/70

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.