Interrupts are now working, and as of yesterday (when I finally managed to get all the bugs out of my diagnostic - we can't use the DEC ones since it doesn't yet emulate a full RK drive) it will sit and read and write blocks as long as we let it, interrupting after each transfer. I'm about to upgrade the diagnostic to test more features, such as multi-block transfers, etc. Dave is about to start work on SD card support. Indeed! It seems to transfer a complete sector in about 600 usec, when running a 'disk' in RAM - it's only even that 'slow' because for some reason, which Dave is investigating, the CPU (an 11/73) seems to take about 1usec to do a DMA grant after the previous cycle, even when it and the QBUS are idle (the CPU is in a WAIT instruction while the transfer is happening, with my diagnostic). Each individual word seems to take about 900 nsec; not great, but not bad. Dave's going to look at that in some detail, too. And of course there are zero seek and rotational delays, so it will be pretty zoomy (although of course the SD 'disk' will also have that characteristic, but we don't yet know if the SD will support the full QBUS bandwidth, the way the RAM certainly will). But even if it is that fast, it's still probably worth having the RAM disk, because it will avoid putting write cycles on the SD card memory. (I myself plan to put /tmp, and pipes, on a RAM disk, for just that reason. In V6 Unix, at least, a system call to move pipes off the root disk is one line of code... :-) Noel