Port-vax archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: rtVAX300 .. need help..



On 2013-01-09 23:13, Holm Tiffe wrote:
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.

In general I don't have much time to get involved in what you are trying to do, but it would appear that you lack a little too much knowledge to make much progress here.

You need to understand more and better how the VAX works, what "registers" mean in different contexts, and sometimes I also wonder if you might need a little more knowledge on low level stuff in general. I don't know, but some of your questions might suggest this.

Just a few short comments. The VAX internal registers are not memory mapped, ever. That would be against the architecture specification. There are special instructions you use to access the processor internal registers.

There is not an "interrupt controller". I think I've only seen such a beast on PCs, and some modern embedded stuff. Interrupts are handled by the CPU as a part of normal operations. As for the three internal registers related to interrupts, you even listed them yourself. They are (among other things) used to cause interrupts from software.

However, there are various bus adapters, which maps addresses back and forth, which can be relevant, and which you might need to understand more about.
The same goes for the MMU in general, and how buses work.

Sorry that I can't be of more help. The questions you ask are just going to take too much time to work through. You can sit down with an existing CPU implementation and start by understanding that one (the uVAX II for example), and then, once you understand the details of that one, you should have a pretty straight forward time of getting your board up and running. If you don't have the time for those studies, I doubt you'll pull this off.

        Johnny



--
Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt%softjar.se@localhost             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


Home | Main Index | Thread Index | Old Index