QSIC update

[Noel Chiappa]

    > From: Henk Gooijen

    >> He's now starting in on interrupt cycles; once those work, he
    >> effectively has emulation of a minimal small RK

    > sounds very good - nice progress!

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.

    > When you get to it, that will be a fast swap drive ;-)

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