As some of you know I've been working (on and off again) a multi-function Unibus board that contains all of the more difficult items to allow a PDP-11/20 to run Unix V1 entirely within the CPU chassis. Other than the CPU and the RK11-D controller, everything else will be on the MEM11 board. Here's the background on what the MEM11 is and the current progress. What's on the board is the following: * Up to 124KW of non-volatile memory * Console Emulator ROM * 4 Boot ROMs selected from 32 images on the board * 2 DL11 SLUs * RF11 controller with non-volatile memory emulating 8 RS11 drives * KE11 EAE * KW11K * KW11L * KW11P * KW11W I know I went overboard with the KW11s as only the KW11L (line-time clock) is needed. Early on, because of the number of devices and trying to fit all of this on a SPC-sized board so it can fit in the 11/20 chassis (can't fit in hex sized cards) I decided to "soft" configure everything. That is, all of the configuration of the MEM11 will be done over one of the serial ports. To get everything to fit on a board that small, I would need to have a reasonable level of integration. This meant that I would be using an FPGA and with a few exceptions all components will be SMT (sorry folks, no kits on this one). I originally thought I would do everything in Verilog with no microprocessor (for a whole host of reasons). I quickly realized that my Verilog coding skills were not up to a task that large so I put the project on hold while I regrouped. I figured that I would have to integrate some sort of microprocessor core into the FPGA but was not happy with any that I was finding. They were either very simple cores with poor tools support or very complex (ie big) cores that had reasonable tools. About 18 months ago, I came across a paper by James Bowman titled "J1: a small Forth core for FPGAs". Best of all it was implemented in about 200 lines of Verilog (ie it was incredibly small). Also available was a complete cross environment (written in Forth of course). It produced very tight code. I spent a while trying to understand the J1, the cross build environment and getting familiar with Forth again. I got serious in November 2014 in laying out the structure of how to put everything together. I decided that the J1 would be fast enough (should see ~100MIPs on the FPGA I plan to use) to actually do most of the device emulation code in Forth with only enough Verilog to offload some of the more performance critical bits. For example, the J1 is fast enough to actually receive the Unibus transaction, read a word from the FRAM and complete the Unibus transaction and still be close to maximum Unibus throughput. I've spent most of my time writing Forth code to implement the emulation of the devices and the configuration UI. I decided that by writing the Forth code first, I would have a pretty good idea of how everything will go together. What the H/W will look like will fall out from that and if I do have to change the H/W interface only small changes will need to be made to the S/W. Forth lends itself to building up from a very low level to a high level where the high level is isolated from many of the low level details. I've been coding furiously. As of tonight I have ~60% of the emulation code written and 100% of the configuration UI (and it all builds). I'll be working on finishing off the emulation code and then starting on the Verilog. Since I want to get familiar with running the J1 in a real FPGA, I'll be building code and testing the configuration UI on one of my FPGA development boards. This also has the advantage of having (mostly) tested code when I actually have real MEM11 hardware. A few comments on the capabilities. Everything is configurable through the configuration UI (ie you'll be able to change everything regarding what devices are enabled, what they're base addresses are, the interrupt vector, priority, frequency of the line clock, etc, etc). Basically, as I've been reading up on the devices, if there's a jumper or option on the device, there will be a way to set it through the configuration UI. I also decided that to upload/download ROM images, memory images, etc that I would provide XMODEM capabilities. One thing that I decided on was that I wanted to be able to send code updates to folks and not require them to have a JTAG probe in order to perform an update (and hence the desire for XMODEM). So the code in the FPGA is basically just a boot-loader that loads an image from an area of non-volatile memory on the board. I'm allowing for 4 J1 images (16KB each...the code address space for the J1) plus a "safe" boot image that no matter how screwed up everything is, you'll be able to fall back to that image. As I was competing the configuration UI, I found that I couldn't have both the configuration UI and the emulation code both fit in 16K (strings take up a lot of space). By the time I was done with the configuration UI I was hitting up against the 16K limit (presently there's about 200 bytes free and there's a bit more refactoring that I could do if I need to get really aggressive). So my insight in having a boot loader and organizing along those lines paid off. ;-) I'm sure there are a number of folks who will want one and are eager to know what it'll cost. ;-) I have a basic BOM for the MEM11, but I haven't cost it out in a while so while I *think* I know what it'll cost to produce, I'm not going to give out pricing (even though a few folks know what my target is) until after I have a prototype built and working. Also, since there will be a high level of integration, I'm only going to offer this only as a fully assembled and tested unit with all of the FPGA programming, ROM emulation images, J1 code images and a reasonable configuration setup. As I said, as of tonight, I've finished the configuration UI. I'll be working on finishing up the emulation code. This is the biggest risk since I won't really be able to test the emulation code until I have an actual prototype board built. Once all of the code is written, I'll be working on the Verilog. During all of this, I'll be doing some testing on my FPGA evaluation board. Given my progress so far, I'm hoping (fingers crossed) to be testing a prototype some time in June/July 2015. Once I have the prototype tested, I'll have a good idea of the remaining work that needs to be done. At that point, I'll let folks know what the cost will be and will start to take orders. Once I have a reasonable number of (committed) orders, I'll do a production run. Ok, so this has been much longer than I expected. ;-) I'll update folks as the project progresses. TTFN - Guy

The original purpose of the shield is presumably to satisfy 1980s-era FCC emissions rules preventing stomping over HF, but that boat has *long* sailed and HF is just a wasteground now.

(Here in EU-land, we never needed to give a damn about FCC regulations even back then.)