Re: rtVAX300 .. need help..

[Holm Tiffe <holm%freibergnet.de@localhost>]

Roger Ivie wrote:

> 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


...in the meantime I think about abandoning that project.
I think I have really simple and near stupid questions about the
architecture that may be is realized on that shitty ISA Board with the
CVAX on it. Nobody tries to even recognize those questions.

Again: What exactly are that MISC CPU internal registers?

sc->sc_vsregs = vax_map_physmem(VS_REGS, 1);
                sc->sc_intreq = (char *)sc->sc_vsregs + 15;
                sc->sc_intclr = (char *)sc->sc_vsregs + 15;
                sc->sc_intmsk = (char *)sc->sc_vsregs + 12;

It seems clearly interrupt related. Are those "Real" CPU Hardware that is
memory mapped or is that a junk of registers from a "chipset" is located
differnt in the physical address space of SOME machines and SOME of them
are CVAX based?

Here is another set of "Registers":

/*
 * Miscellaneous registers common on most VAXststions.
 */
struct vs_cpu {
        u_long  vc_hltcod;      /* 00 - Halt Code Register */
        u_long  vc_410mser;     /* 04 - VS2K */
        u_long  vc_410cear;     /* 08 - VS2K */
        u_char  vc_intmsk;      /* 0c - Interrupt mask register */
        u_char  vc_vdcorg;      /* 0d - Mono display origin */
        u_char  vc_vdcsel;      /* 0e - Video interrupt select */
        u_char  vc_intreq;      /* 0f - Interrupt request register */
#define vc_intclr vc_intreq
        u_short vc_diagdsp;     /* 10 - Diagnostic display register */
        u_short pad4;           /* 12 */
        u_long  vc_parctl;      /* 14 - Parity Control Register */
#define vc_bwf0 vc_parctl
        u_short pad5;           /* 16 */
        u_short pad6;           /* 18 */
        u_short vc_diagtimu;    /* 1a - usecond timer KA46 */
        u_short vc_diagtme;     /* 1c - Diagnostic time register */
#define vc_diagtimm vc_diagtme  /* msecond time KA46 */
};

the next intmsk and inreq registers ..and I'm sure I'll find more.

I'm shure I ready that thing about the CQBIC and the FTAM with the TK50
before in the last 3 days, don't know where, but I read that.
I'm trying to find pieces of information that points me the right
direction to go, but for sure, what you wrote above doesn't help me much
since I do have neighter an Mbus nor an Qbus and I don't want to make an
adapter between them.

Please don't get me wrong, it's not that this isn't interresting,
but it is far away from that what I'm trying todo. I had some time the last
days but this time is going to end now. I have my own business and have to
make a living for my family, so I'm short on time.
Next thing is, I'm not an natural english speaker, sometimes I have
problems to recognize how that's meant what one writes, sometimes I have
problems to express myself. I was never in UK, never in the US and my
english is coming entirely from reading/writing Mails with people like you
and from working on Unix machines.

I got the first signs of life from that rtVAX in a relative short time
with the help from Mouse und yours, but with that little effort that I
could make the last days, the project "porting NetBSD to an rtVAX300 board"
will take for ever..

In short: If I ask if there is an dedicated Interrupt controller in the
other VAXen or if it is normal that CPU REGs are mapped to Address Space,
then it isn't much help to read that none of the machines are water cooled.

Regards,

Holm
-- 
      Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, 
     Freiberger Straße 42, 09600 Oberschöna, USt-Id: DE253710583
  www.tsht.de, info%tsht.de@localhost, Fax +49 3731 74200, Mobil: 0172 8790 741