<a SCSI device standard if and only if it uses the Common Command Set (CCS
<which is a standard. As for the electrical interface, you are right, it'
<absolutely the same everywhere. I think that even the original SASI and
<standard SCSI have the same electrical interface. However, the SASI comma

there is SCSI as in the device level and that would be analogous to 
say 802.x

Then there is CCS which is the analogue of say DECnet protocal.  Another 
words the next level up.


<set and CCS are certainly different and, IIRC, incompatible.

They may well be but it's not a problem.  I have the experience of 
putting a moden SCSI drive on a NCR5380 equipped z80 CP/M system designed 
in 1984 and by gosh and by golly old SCSI and modern drives do work.

I would boldly suggest that a more sophisticated system using the same 
silly chip can do the same thing.

<> Now what your talking about is CONSOLE ROM support... and that is whol
<> different can of worms.
<   First of all, the term "console ROM" is not entirely correct. Althoug
< <--------->
<console code is what has some kind of special property, something that
<distinquishes it from any other code that the MicroVAX can execute. My
<guess is that when it executes the CPU chip is in some special console

Try kernal mode.  you can do examine and deposits to anywhere in the 
memory map in physical mode.  However console code is in the same realm 
as romODT on the PDP-11s and serves as a crude diagnostic tool.  It's 
otherwise nothing special to the processor save for it's addressed in a 
convenient spot and can be used to provice some services like startup 
diagnostics.

<mode. VMB is the ROM boot code. Unlike the console code, it has NO specia
<properties, and it is no different from the OS or any other code. If

It is identical to console code save for its specific purpose.  It does 
things that require access to a vax processor running in kernal mode like 
playing with the memory maps.

<MicroVAX CPUs do have some console mode, this mode is OFF when VMB is
<executing. At least on Q-bus CPUs, it works as follows. When the machine 

It has to do with memory management.

<sitting at the ">>>" the console code is executing and apparently the CP
<is in some kind of console mode. Upon receiving the BOOT command, the
<console code copies VMB from ROM to RAM, takes the CPU out of the consol

The copy is done so that boot occurs in a nominal lifetime.  Like I said 
running out of eproms cripples the vax due to their gernerally slow
access times.  The other hald was with vmb in ram it's idenitical to the
780 and other brethern that came before.

<   Regarding the SCSI device support code in VMS/VMB on KA410 and other
<systems, they are COMPLETELY different. This is explained properly in 4

Yes and I said that in one sentenance.  The boot code in the VS2k is
limited to the fact that then the eproms used were smaller than those 
available say a year ot two later.  When it has to fit you slice off 
things you don't need.

<approved version of TK50 for KA410 is TK50Z-Fx. Unlike TK50Z-Gx, which ha
<two external connectors like all standard external SCSI devices, TK50Z-F
<has only one external connector and terminates the SCSI bus internally. (
<see three sockets on my TZK50 board that look like those for resistor
<networks.) TK50Z-Gx has external switches for setting the SCSI ID, while
<TK50Z-Fx certainly doesn't. Either it's internally jumpered to SCSI ID 1
<(this is what the TEST 50 configuration display suggests), or the concep

Well, I'm in the fortunate position of having seen the printset for both.

The basic board 54-17639-01 is IDENTICAL for both.  the address switches
you refer to are plugged in to a header and in place of those switches you 
can use those neat little shorting plugs.  You confusing packaging options 
of the same device.  I know as I was a review member for DEC STD 12 so I 
have a better than average idea of what all the DEC numbering and marking 
conventions are about.

<   But the most peculiar thing is how this version of TK50 is treated by
<VMS and VMB. Lo and behold, it appears as MUA0! Yes, MUA0, unit 0 on the
<first _TMSCP_ controller. How can it possibly be a standard SCSI tape

No the vs2k calls it MUA0 and my 3100 calls it mka7 same board.  The name 
is not carried in the scsi device but at the host and therefore if I had
access to the code I could call it anything I cared to.  On my PDP-11 is 
also known as MUn:!

<you ever used a TK50 on a Q-bus or UNIBUS system, you would have a
<different feeling for this digit "0" in "MUA0". As you probably know (I

Gee I have only a half dozen Qbus PDP-11s ranging from 11/03s to 11/73s.

<number to the card, which checks it itself. It is plausible that the sam
<happens on KA410, i.e., the TK50Z will see the request no matter whether

Your extrolation is called rubbing the pumkin, kids do that extroplating 
there is a pie inside.

<it's for MUA0, MUA1, or whatever (whether it will accept it is another
<matter). In this case it becomes clear as a day that the SCSI ID is eithe
<hard-coded in the KA410 MUAn driver or is ignored by TK50Z-Fx (that's wha
<I have meant earlier by the concept of SCSI ID being completely foreign t
<it).

It's hard wired as doing the scsi arbitration and select using the 5380 
is painful as hell, slow and eats that very valuable and scarce code 
space.

<   Maybe it was a TK50Z-Fx? Or maybe you were loading the boot program ov
<the net and then telling it to read the kernel from the tape? This would

First off I've never booted netbsd via scsi anything.  I may add that my 
adventures with Netbsd have been less than successful.  My current work 
with vs2k, MV-IIs and 3100m76 are VMS and Utrix at present.

<   You are refuting my statements on KA410 system ROM's limitations by
<saying that SCSI was too new at the time of KA410. But this doesn't make
<our lives easier. Also strictly speaking the real reason for the system R
<not supporting SCSI disk booting and formatting is that according to DEC
<you are not supposed to connect a SCSI disk at all. The reason that you a
<giving may be a reason for THAT, but no more.

In the year the vs2k was released there was no scsi disk product in dec.
The "scsi standard" was yet to be fixed in anything close to a solid.
At that time Ampro was lobbying for the early version of current scsi 
standard.  The implmentation was "what was needed to connect a remoted 
TK50" without the overhead of putting the full TK50 interface on the 
vs2k board.  IE: they needed a non-vax off board bus, at that time they
had eithernet (too costly to put in a tape), GPIB (good), or SCSI/SASI
which had been around for a while but still in flux. 

With the correct OS driver the scsi bus in a vs2k will conform to any 
standard physically possible using the ncr5380.

<Your suggestion about the ROM size is wrong. KA42 and KA41 have norma
<SCSI (CCS) code and their ROMs are 256 KB, just like on KA410.

They aren't 256kb (that would be a 27020 avalable about 8 years later).  
The eproms used are 27512 (64kb) x4 for a total of 64kw(32bit words). 

< You wrote:
<> I can't format MFM drive from my MVII
<> (KA630) console either and must use MDM for that.  Same difference
<   No, it isn't the same difference. Q-bus CPUs never have things like MF
<disk formatting in their ROMs, since Q-bus systems are freely configurabl

Actually formatting disk was considered a bad thing internally to DEC and 
was considered something to be reserved for field service.  Later systems
had the format capability as a result of Customer Services Systems 
Engineering lobbying for non tape/disk loaded diagnostics to cut service 
time/cost as TK50(tapes in general) were too damm slow.

<Why should KA630 give a preference to MFM disks over, say, RA81s? And ho
<is it going to tell whether it's an MFM disk or an RA81 in the first plac
<Telling this difference requires digging below the MSCP abstraction layer
<and that is a very bad thing to do for something as generic as a Q-bus CP

It's done and the OS knows its a RD53 or a RA82 it's hooked up to and with 
what adaptor as well.

<On BabyVAXen, on the other hand, everything is on the system board (or a
<least on a proprietary daughterboard that's tied tightly to the system
<board). Therefore, the diagnostics can be be built into the ROM. Also th
<architecture of BabyVAXen is so different from the software viewpoint fro
<that of classical VAXen that the ordinary MDM won't work at all. DEC had 

Retro revisionist history.  As someone that was in the engineering 
community inside DEC we (CSSE) were pushing for maintainability features 
to lower service costs at all levels.  Formatting is only a small part of 
that picture.  You'd be closer to the mark if you pointed out that the 
VS2k had better internal diagnostic than KA630 running MDM and it didn't 
take 40 minutes to load the tape.

<either write a completely different MDM (from scratch, since the
<architecture changes are too great to leverage even a single line of cod
<from the existing MDM), or build all diagnostics into the ROM, even the

MDM was a layer on ELN and was easily configured for any system.  We
did a prototype video printer interfacce to demo purposes and the 
operational code was a tape loaded ELN image that ran on a cobbled 
vs2k( the video was hacked to interface to a video LN03).

<left out for simplicity, but that this task was not intended to be doabl
<at all. Remember, DEC doesn't want you to connect SCSI disks to KA410s.

The concept didn't exist at the time.  If it was thought to sell it would 
have been done.  

<   Read the words immediately following the ones you have quoted! There 
<have mentioned two possible problems: assignment of SCSI IDs and mutuall
<intrusive probes.

The ID assingment is not a problem and on the host very changable in 
software.  Yes, device ID switches/jumpers are read by software and 
translated to a command for the 5380.  the probe is even less a probem.

<   Actually the similarity with IBM ROM BIOS is pretty good in this case
<The MicroVAX CPU system ROM can be called only with the memory managemen
<off. Similarly, IBM ROM BIOS can be called only in a standard real-mode
<environment (or at least an emulated one created via V86 mode).

The difference is that the PC bios is the base IO for the system.  The 
roms in most microvax system are not part of nor used by the running OS
as it loads it's own fully configured drivers.  The reason is this allows 
bug fixes and the secondary problem of slow eproms.

<   You wrote:
<> I spent some time today with my prom programmer and yes one of them
<> contains all 0FFh... fried since it will not program either.

<   It's a pity that we'll never know what code did it contain.

the old part was fried.  The new one that works for either vs2k or 3100 
works fine and disassembling 32k of z80 code is unappealing though I have 
the tools, skills and experience.

<them away). I'm really serious about revolutionizing the VAX hardware
<support. However, I also realize that this involves paramount work, and 

I never considered it a problem but, I know where and how to find data I 
need.  But then I've cultivated that skill over the last 29 years. 

<floppies, and TK50 tapes. However, their architecture is completely
<different. The obvious difference is that the IIs are Q-bus and the 2000

The bus or lack thereof is different however, the archetecture is still 
vax.

<Q-bus system, you'll see a slave processor (usually Z80) and one or more
<EPROM chips on almost every Q-bus card. On KA410 there are no slave

Actually the RQDXn it's a T-11, TQK50 is 80186, DEQNA/DELQA custom logic,
DHV-11 is 2 8051, the only z80 is on the SCSI adaptor.  Within vax systems
z80s were rarely used.

<classical VAXen are design the relieve the CPU of as much work as possibl

...and emulate existing unibus adaptors on the larger vaxen.

<down on the expensive intelligent controllers. And so a completely new
<architecture was designed from scratch. The same RDxx disks are used, bu
<their software interface doesn't even resemble MSCP. The same TK50 tapes

Of course not, you missing the t-11, rom and ram inbetween.  What's 
missed is MSCP is the protocal between the driver and the OS and the 
driver can speak anything it wishes to the physical device.

<are used, but their software interface doesn't even resemble TMSCP.

Again how could it? the 9224 hdc/fdc has no way of looking like a MSCP
device.  It is however the same device used on the rqdx3... and the 
driver code has the hardware level abstraction lofted from the t-11.
Keeping in mind you don't tak MSCP (or tmscp) to the physical device
RD54s are MFM and hve no clue about MSCP and the TK50 drive is in a 
similar state though somewhat smarter.  The MSCP/TMSCP is the 
abstraction that standardizes the interface between the OS and the 
driver.  It's up to the driver and any underlying hardware to translate 
that higer protocal to something useable to the eventual hardware itself.
It so happens that RQDXn are smart enough to do the lions share of the 
physical level work that's all.  There is noting to say that all that 
could not be broght back into the vax level driver, and the VS2k 
implementation did exactly that.

<   Normally when the hardware architecture undergoes a drastic change a
<large portion of the OS has to be rewritten from scratch. Dunno about
<Ultrix, but in VMS this was done in a very peculiar way. One thing that w
<confusing me for a long time is the choice of device names in the KA410
<version of VMB and the corresponding VMS drivers. On KA410 the MFM disks

Your looking at the pumkin again and seeing pie.  The VMB looses space to 
the mscp call to another piece of code that does MSCP to hardware.  the 
VMS drivers do that as well so that to VMS it's still MSCP and the driver 
does the logical to physical abstraction internally where the qbus version 
does it to the qbus device level where the task is completed by the t-11
on the RQDX.  Same process different only in that two processers split the 
task rather than doing it all in the vax cpu.  There is however a penelty 
of performance.  The VAX is now spinning cycles on stuff that was farmed 
out to a t-11 before.

<8600. VMS and VMB, on the other hand, choose to call them DUAn, which mea
<drive n on the first _MSCP_ controller. Furthermore, although I don't kno
<anything about VMS, it seems to me that it really does treat these disks 
<MSCP. Apparently, for marketing or other reasons DEC wanted a II and a 20
<to be able to use the same RD54, call it the same name, and make it work

It was a convenience to having a uniform OS with minimal changes.  the 
fact that the end drives are MFM is unimportant and I have a q-bus CMD 
scsi that looks just like a RQDX3 to anyone on the Qbus.  They did that
so the VMS driver for the RQDX would not know the difference. By making 
device look the same at the driver level you avoid changing the OS and 
restrict your scope of change to a driver(if at all).  It's good sense 
to have a kernal that is uniform and unaffected by a hardware change.  
IE: I don't have to recompile VMS to run on a vs2k or a KA630.  As it 
works out since the devices are standardized a bootable RD54 from my 
MV-II also will boot nicely on the VS2k without any changes. this makes 
creating additional disks for my systems that use MFM drives very easy.

<the same. The last part is important, since I think that in VAXclusters V
<ascribes some special meaning to MSCP disks that doesn't apply to other

Not that I know of.  

<disks. It seems like VMS has drivers for different types of MSCP, like
<UNIBUS/Q-bus MSCP and BI MSCP, and then there are higher layers like

The reason for that is to talk to a MSCP device on U/Q is done differently 
that for BI, it's another layer of abstraction.  BI is not a slaved bus 
like u/q.  Also devices on BI carry different addresses and packet size 
limits unike a raw bus like Q where devices are addressed slaves with
maybe the ability to do DMA.

<clustering support. In this light it seems like the MFM disks on KA410 ar
<supported by yet another "MSCP" driver that internally does in software
<what RQDXn does in hardware (firmware actually): converts from logical
<blocks to cylinders, heads, and sectors. As a result, VMS and VMB can li
<that the RDxx disks are MSCP without the user suspecting anything. I
<wonder, how does Ultrix behave in this regard? Does it also lie that thes
<disks are MSCP by using the ra driver, or does it use a special non-MSCP
<driver like NetBSD?

It lies.  Ultrix for my vs2k on rd54 also will boot in the mv-ii on a 
RQDX3.  You claim the archtecture is different, I can say that when the
configured media of two DEC OSs can be move between a KA630 and the vS2k
on a given rd53/54 and work the same it must be similar somehow?


Allison