"sokolov@alpha.CES.CWRU.Edu" "Michael Sokolov" writes:

>Does this door actually say "VAXstation 3500" on it? Do you know if it
>comes directly from DEC or has been tinkered with? So far the only thing I
>know about VAXstation 3500 is the following line from Jim Agnew's
>_MicroVAX/VAXstation Systems FAQ_:
>>  0A | 1 | 65D | 2.8   | Q      | VAXstation 3200, 3500   | Mayfair/GPX
>   The processor type of 0A and subtype of 1 indicate the KA650 series of
>Q-bus CPUs, and Mayfair is the general nickname for the MicroVAX 3 series,
>which is based on these CPUs. In this case "Mayfair/GPX" tells me that it
>has GPX-level video. The performance of 2.8 VUPs tells me that the CPU is
>clocked at 22 MHz and the 64 KB cache is in place. This is just like the
>ordinary KA650. So far so good.
>   What's really strange in that line is that it indicates that the
>software-accessible CPU ID is "65D". Actually, a lot of my assumptions,
>some of which I express on port-vax, are based on these CPU IDs from that
>FAQ. So far I have been assuming that they come from the hardware and are
>therefore authentic. But now I'm beginning to question that. Although I

The "CPU ID" above is just a VMS construct: VMS identifies the CPU early in the 
boot sequence and then loads the appropriate image with various cpu-dependent 
routines (e.g. scribbling to console, error-handling etc.). Since writing to the 
console differs depending on whether the console is graphics- or serial-based, 
VMS uses different load images in the two cases (and in some cases there are 
three images: one for non-WS, one for mono-WS and one for colour-WS).

The SID (0A above) and XSID (1 above) come from the hardware (the SID from an
internal processor register and the XSID usually from an EPROM).

[snip]

>the ordinary KA650. I was assuming that DEC has incorporated the GPX-level
>graphics into the KA650 CPU and called it KA65D.

Nope - the KA650 scans the Q-bus and if it finds a QVSS or QDSS, it uses it as a 
graphics console. DEC shipped VAXstation 3200/3500 systems with a KA650-B rather 
than a KA650-A, but both function identically. The only difference is a bit set 
in the XSID to let the OS know what variant is installed.

>   Systems in BA213 enclosures have muddied the water. The I/O distribution
>panel is gone, and now there are covers on top of Q-bus cards. I have never
>seen a VAXstation in a BA213, only MicroVAXen. The latter use an MMJ cable
>instead of BCC08 for the console, and the cover on top of the CPU has an
>MMJ on it. Pins 8 and 9 don't exist on the MMJ, so they are shorted
>internally by the circuit on the back of the cover. (But not the KA650 CPU
>itself! KA650 can replace a KA630 without doing anything to the console: a
>MicroVAX II will become a MicroVAX 3, and a VAXstation II will become a
>VAXstation 3.) What this internal shorting means is that you cannot select
>the graphical console no matter what you do with the console cable. The
>only way you can do that is to disconnect the internal cable between the
>CPU itself and the cover. The question is, how did DEC make VAXstations in
>BA213 enclosures? The trick with disconnecting the internal cable doesn't


Making a VAXstation 3 out of a MicroVAX 3 is always the same: add a VCB01 or 
VCB02 (actauuly, I'm not certain that a VCB01 always works ...). There is no 
trick with shorting pins here and there, that's just for the MicroVAX/VAXstation 
2000. Of course, in a BA213 box you need the appropriate panel insert with the
vido connector. You can force usage of the serial console on a VAXstation II/III 
by sending a BREAK when power-cycling. Otherwise, if the CPU finds a graphics 
board, it uses it.

Antonio

Antonio Carlini                            Mail: carlini@marvin.enet.dec.com
DECnet-Plus for OpenVMS Engineering
Digital Equipment Corporation              Worton Grange, Reading, England