{Catching up, after being on the road all day yesterday... Replies to quite a few people in this, sorry you'll have to read through it to find yours, didn't want to inundate the list with 17 replies.} We're going to make it public, but at the moment, it's a bit early for that; for one thing, we are working with hand-wire-wrapped prototypes, front-ending a ZTEX FPGA/uC (micro-controller) board, not a PCB card. And the 'software' (which includes FPGA code, we don't have any code for the uC yet) is in a very primitive state. We'll probably get a couple of controllers done (RK11, RP11, probably RL11, qetc) and then turn it loose for people to add others. We we get to the stage of turning it into a production PCB, we are definitely going to really encourage help for that step - doing PCB layout, etc, is sort of terra incognita for us both. Well, we'd need the wiki first! But I hope to have some news on that front soon - I've located an existing one, and am discussing with the person who runs it, using it for material from CCTalk. Not much more to say, at the moment. The plan is that it will be a dual QBUS card, with slots for two SD cards, and also one (or more) USB 2.0 connectors; although it will be possible to plug in memory sticks (to the USB), the SD cards will probably offer higher performance. Oh, and one will be able to configure virtual disks on on-board RAM; the contents won't survive a power cycle, but they will be very high performance, useful for swapping disks. We will definitely keep CCTalk posted when there is any news. Why do you think they are in our plan? :-) We love them too! :-) Well, like the originals, they will be half-panels (i.e. 5-1/4 inches). They will not be electrically compatible with the original DEC indicator panels (we plan on driving them like Guy, with just a clock and data on a couple of wires, not one wire per light - in fact, I'd like to use a common connector and electrical spec with Guy's, so they are compatible); making them electrically compatible would be a _lot_ of work, and I don't see that it would be worth it. However, they will be mechanically compatible with the DEC originals; our plan is that if someone has an original indicator panel PCB (I know at least one person here does), they could mount it with one of our new production bezel/inserts (with the light captions on it), and the whole thing will work. I.e. in the original DEC design, we're just replacing the PCB. Although 'classic' RP11/etc panels will probably be available (for purists), we intend to also do 'updated' panels which will drop a lot of lights that make no sense when you don't have a real disk (e.g. the shift registers) and replace them with useful lights that the originals don't have (e.g. full memory address, on the RP11). We'll probably do those too, but before that, we're thinking of doing an RP11+, i.e. an RP11 with the cyclinder address extended to 16 bits; i.e without changing the register format _other than using unused bits_ in the cyclinder address register. (Very easy for us to do, of course.) For those with the ability to tweak drivers, that will produce disks with 2^28 blocks, or 2^36 bytes, or 64GB. That's most of a large SD card... :-) Alas, we pretty much have to have a uC; it's pretty much mandator to support USB. And once you have one, there's a lot of stuff that's easier to do in a uC, e.g. reading the configuration of the virtual controllers, and configuring the FPGA to match, etc, etc. Because, for FPGA implementation, it's basically an RK11 with a few tweaks --> very easy to do! And with the RP11+ variant, it will support up to 65GB disks.. :-) That too! Although there's nothing to stop us doing light panels for controllers that never had them, e.g. RL11's! True, but my concept is that the eventual UNIBUS version will include ENABLE functionality (i.e. mapping boxes to 4MB memory, one for the CPU, and an 11/70-compatible UNIBUS map for DMA devices), and it could therefore _also_ 'emulate' a MASSBUS RP11, i.e. an RP11 with an additional 'extended memory address' like the identical registers on e.g. the MASSBUS RP04. (And yes, I know no such device ever existed, so unmodified DEC OS's won't support it, but...). Right, but since adding another controller on the QSIC will be a trivial configuration option, we assume no machines will have _only_ an RQ11 (our aname for the 'native' interface), but rather an RK11 and RQ11, RL11 and RQ11 etc. Boot off the first, only use the second once the OS is running. Well, there's always the RP11+! :-) And the 'RPV21' (again, I know this never existed) will, like the RLV21, have native 22-bit addressing. It's all 'software' (in the FPGA and the uC); so if we (in the community sense) upgrade the 'software' to support more controllers/disks, all boards could be upgraded to support them. Let's get the RK11 and RP11 working to start with, and then we'll figure out where to go from there. Which is why it's probably easier to just _also_ configure a standard RK11/RP11 whatever, and boot off that. (It's all 'software'! With the right FPGA load, you could have 127 RK11 controllers! :-) Noel