I already posted that I was working on it, so it should not be a very big surprise. DEUNA now works. At least, it works good enough for 2.11BSD – and very stable as well. I’ve even written a new web server for 2.11 – well, you’ve got to understand that 2.11 is a bit older than the concept of web servers. Even though there is a lot of code for simple web servers around on the net, most seem to assume the ‘new’ style of C – which is not that big a deal to convert, until you encounter the intricacies of varargs. Anyway, I decided that I would just roll my own. It seems only right to run your own web server on your own hardware, after all. And, in the process, I decided that I was not really interested in a ‘normal’ web server – I wanted something to browse the operating system with, not something that would serve me content. So, the web server I made gives you the sources, the text files, the directories, and if I get around to it it will give you octal dumps of the binaries. Would have been so brilliantly useful, 30 years ago. And in a way, it still is.
Anyway, Decnet also works. That is, I’ve not had time to test anything beyond a trivially simple 2-system network, with two nodes each running RSTS version 10. That was challenging enough – Decnet encodes it’s node address into the Ethernet card’s mac address, and as it turns out, I misread the specs of the Ethernet chip on the byte order of the mac address. It works now, but to find the mistake took me several nights of debugging. And the show counters command also basically works – at least, it doesn’t hang the system anymore like it did when I first tried it, but it still only produces random numbers. All the required hardware is there though – even the clock that is required for the seconds-since-last-reset fits in. It just needs some more microcode to implement the different counters.
Writing that microcode is not yet on the agenda though… All boards are now tasked with running 2.11BSD, or are in use for tweaking minor things in the DEUNA microcode. Even though I now have plenty of the PMODNIC100 and already had a lot of boards – I should be able to run more than two systems at the same time. However, I forgot that my Ethernet switch hasn’t got any free ports left… so, yes, well, eeehm, I could very well run tests with other OSses as well, but then I’d have to break off the stability tests of the systems I have running now. Would be a shame. I’ll get around to it, eventually. But not this month. Lots of other things demand attention as well, and rewiring my network isn’t even on the things to do list yet.
Which brings me to. The DEUNA itself. It’s an interesting collection of bits and pieces. First of all, the DEUNA that I implemented is a front end for the PMODNIC100 that Digilent sells. Or, more specifically, the ENC424J600 from Microchip – a brilliant tiny thing that has an SPI interface, and does all things that need doing to be Ethernet. The DEUNA frontend is basically a Unibus interface, with a cpu that runs microcode, a busmaster that copies data from the Unibus to the DEUNA, and a busmaster that copies data from the local DEUNA memories to the ENC424J600. Nifty hardware, that is… but the hardware, and by extension also the microcode for the DEUNA, is not compatible in any way with the real deal. Which means that running XXDP for the DEUNA is out of the question. And in turn, that makes verifying if the DEUNA-to-be works correctly a bit difficult. The microcode is also somewhat difficult to debug – it seems like stepping back into the early days of PDP-11 work to me – I mainly have had to rely on theory to find bugs, and only the occasional printf to console to help find a clue as to what is happening. There’s not that much debugging infrastructure in the DEUNA hardware and microcode just yet – probably that is because it’s not been a priority, and that’s because a lot of things already seem to work just fine.
Thus far, I’ve been able to find the answers for 2.11BSD and RSTS v10. At least, 2.11BSD works great – I’ve seen uptimes of several weeks so far, and I’m not really able to break things without cheating – for instance, flood pings work just fine, and all normal protocols work as they should and seem stable – also with uptimes ranging into weeks. And RSTS also seems to work fine – even though details like the read counters command is not really implemented yet. Ultrix-11 however has a problem; it fails because something appears to go wrong with the TCP acknowledge frames – even though the DEUNA microcode receives them and signals the frames to the upper layers, Ultrix appears not to be aware that the frames were received, so a session will stop after the TCP window is filled. I’m clueless as to what goes wrong. It might not even be a problem in my DEUNA; I’ve heard a suggestion that the same issue also may exist on ‘real’ hardware.
Most amazing about the whole DEUNA setup is that I’ve been able to fit an 11/70, a terminal including it’s own PDP-11 cpu to run the terminal microcode, and the DEUNA adapter including it’s own PDP-11 cpu for it’s microcode – all in the single smallish low cost FPGA that sits on the DE0 board. And the same thing also fits on the N2B1200 board. It should come as no surprise that for these configurations the 11/70 does not include floating point hardware – but still, three PDP-11 CPU’s in a single small and low cost FPGA. Luckily, thanks to Walter’s brilliant work on fixing the FPU simulator code, you don’t need floating point hardware to run a 2.11BSD system – so you can have a 11/70 without FP11, but with Ethernet and an embedded console, and have it run a complete 2.11BSD system on the DE0 board – with the ENC424J600 to connect it to Internet. Just make sure that you install the patches on a system that does include the FPU… then set FPSIM YES in your kernel configuration file, run make, probably tweak the makefile, make install, move the image to an SD card, and then you can boot it on your FPGA.
Curious? Surf to my de0 board at http://pdp11.sytse.net/.