PDP2011

When I started the shim design, I hadn’t really thought about logistics at all – but sort of assumed that if people were interested, I’d mail them a shim and maybe the connectors too. The first prototype run of the board worked nicely – and my first beta tester was able to get it to work without any real challenges. There was a challenge for me though… Mailing a tiny PCB, even within The Netherlands, proved to be more difficult than I had thought. Took me two tries, and a trip to the store to get those special plastic bubble envelopes. The regular envelope I sent first did arrive with a nice apologetic message from the post office. Not the contents though.

Having gone through that I was unpleasantly surprised though that the Dutch Post no longer allows any materials to be mailed without a proper box and a declaration of the content – and the minimum rate to for instance the US is now EUR 11. And if you want track and trace, that becomes EUR 29.50. Slightly over the top, considering that I pay less than that to order a batch of PCBs from China AND have them delivered to my home…

So that is why I’ve decided to put the gerber files for the PCB on the download page – so you can have the board produced yourself, and share what is left of a batch with PiDP-users near you. The gerbers are produced in Eagle with Seeed’s rules – I’m not sure if they’ll work with other board producers, you’ll have to check yourself.

Meantime, I do still have a batch of shims, and Oscar gets a much better rate from the Swiss post than I can find in NL – and maybe a percentage of people would need both the shim and a PiDP-11 anyway. So there is the idea that he would do the distribution for me, but we haven’t actually worked out the details yet, and it’s not an easy task to align our schedules. Might still be a while.

So those are basically the options – if you are in a hurry, you can order a batch of PCBs directly, or you can get one from me and pay the ridiculous Dutch postage, or you can wait for us to work out something better.

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.

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…

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!

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.