Re: rtVAX300 .. need help..

[Roger Ivie <rivie%ridgenet.net@localhost>]

On Wed, 9 Jan 2013, Holm Tiffe wrote:
> But, there are some standards made by DEC, at most you can see them in the
> QBUS Machines, almost everything is working the same, at least from the
> register side of view.

Yes, *once* you get on the QBus side of the world. On the VAX side of
the QBus adapter, things are different.

MicroVAX I was a pure QBus machine. It didn't have a bus adapter and
used real QBus memory. No scatter/gather map.

MicroVAX II had a scatter/gather map, yes.

Most, but not all, CVAX-based machines used CQBIC, which was highly
compatible with the MicroVAX II QBus adapter, but not entirely so. One
difference between CQBIC and the MicroVAX II involved the way the
scatter/gather map was managed; CQBIC treated it like a small cache
instead of something like a content-addressable memory. A chunk of
system memory was reserved to hold the scatter/gather map. When you
performed QBus DMA, the CQBIC might need to do extra DMA on the bus in
order fetch the scatter/gather entry.

This usually worked well, but ran into trouble on the VAXstation
3520/3540. When DEC wanted a QBus adapter for that machine, its first
idea was to slap a CQBIC down next to a FBIC and call it a day. This
usually worked ok, until ...

The 3520/3540 used a custom bus (MBUS) with write-back cache with split
transactions and fair arbitration. If the CQBIC needed to fetch a 
scatter/gather entry, it was *possible* that the entry lied in some other 
node's cache. If so, that node had to kick its local processor off the bus 
to fetch it from the cache. Since the bus had split transactions and fair 
arbitration, it could be quite a long time before that node was able to
return the scatter/gather entry; if the bus was busy, *all* the other
nodes on the system might be able to do a transaction before the
scatter/gather transfer could be completed.

Only *after* the scatter/gather fetch was complete could the actual DMA
transaction be performed. And, for the DMA transaction, the whole
shebang started over again.

With the QBus timeout timer ticking away while all this was going.

About the only QBus device that could live with the situation was the
TK-50, so the CQBIC-based QBus adapter was dubbed FTAM (for Firefox Tape
Adapter Module) and sold in situations where the only device on the QBus
would be the TK-50.

So a second QBus adapter was needed, one not based on CQBIC. Which I
designed.

My first idea for this adapter was to put 4MB of RAM on the adapter and
have the processor move data into and out of that RAM. QBus timing would
be completely independent of the MBUS timing and quite peppy.

But I made the mistake of trying to sell the idea to VMS as "just like
the MicroVAX I!" I pulled back a bloody stump because VMS had just
managed to stomp out the last vestige of MicroVAX I code and thought it
was good riddance.

So my only choice was to design an adapter that could tolerate the
MBUS timing.

In order to do so, I had to tightly control what the MBUS was up to;
when the QBUS is granted, the FQAM seizes control of the MBUS (using a
hack they added to MBUS arbitration in a failed attempt to fix FTAM's
problem) and keep the bus 100% busy with short transactions so that the
FQAM could be guaranteed that, when it was ready to perform a DMA
transaction, it wouldn't have to wait for a lengthy transaction started
by another node to complete.

Consequently:

- The scatter/gather map moved *back* to the QBus adapter, instead of
  being a reserved chunk of system memory like it was for a CQBIC
  system.
- The Firefox could not get *any* work done while QBus DMA was going on.
  I simply could not allow another node to start a transaction.

For the rtVAX 300, you are on the *inside* of the QBus adapter. So you
are aware of these differences that are normally hidden by the operating
system's adapter support code.
--
roger ivie
rivie%ridgenet.net@localhost