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