26 Feb
2002
26 Feb
'02
10:31 a.m.
Hi.
Now that my RX01/02 driver for NetBSD and the accompanying "NetBSD
device driver writing HOWTO" is nearly finished, I am looking forward
for further challenges. I think will stay in the disk (and tape)
department and write support for DSSI. I know that this is not a trivial
task, but I will give it a serious try. So I have the usual problem:
docs.
I need docs about DSSI, the protocols that are used on it, the host
adapter chips (SII and SHAC), MSCP, SCS, ... The KA6[46789]0 CPU and
KDA50 / UDA50 programmers manuals should be a good start. So if this
docs are online somwhere on the net, please give me a link.
Thanks for your help.
--
tsch??,
Jochen
Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
26 Feb
26 Feb
2:04 p.m.
I have the UDA50 manual (BTW: anyone have a UDA50?) that I can
copy for you. I would assume that peeking into the Ultrix 4.2
source code could be of great help. If there are any copyright
issues, one could make a cleanroom reverse engineering approach,
where someone sits down and writes an english document that
describes what happens with the protocol and someone else re-
implements it. But I heard someone was working on getting Ultrix
to be open source, in which case one could port massive amounts
of DEC hardware support over, including XMI.
However, I thought that NetBSD already supports RA disks, so,
the MSCP protocol should be there. Also, the 4.3 BSD sources
include MSCP devices, so there is source to peek into, right?
regards,
-Gunther
Jochen Kunz wrote:
Hi.
Now that my RX01/02 driver for NetBSD and the accompanying "NetBSD
device driver writing HOWTO" is nearly finished, I am looking forward
for further challenges. I think will stay in the disk (and tape)
department and write support for DSSI. I know that this is not a trivial
task, but I will give it a serious try. So I have the usual problem:
docs.
I need docs about DSSI, the protocols that are used on it, the host
adapter chips (SII and SHAC), MSCP, SCS, ... The KA6[46789]0 CPU and
KDA50 / UDA50 programmers manuals should be a good start. So if this
docs are online somwhere on the net, please give me a link.
Thanks for your help.
--
Gunther Schadow, M.D., Ph.D. gschadow(a)regenstrief.org
Medical Information Scientist Regenstrief Institute for Health Care
Adjunct Assistant Professor Indiana University School of Medicine
tel:1(317)630-7960 http://aurora.regenstrief.org
6:51 p.m.
On 2002.02.27 05:04 Gunther Schadow wrote:
I have the UDA50 manual
Do you have a scanner?
;-)
(BTW: anyone have a UDA50?)
Aha. The 11/780
demands its tribute. ;-)
I would assume that peeking into the Ultrix 4.2
source code could be of great help.
This may lead to serious copyright problems,
even with a "cleanroom
reverse engineering approach". I think BSD has suffered enough from such
problems. Additionaly Ultrix may be that different, that it may be
easier to write somthing new from scratch, than port ancient Ultrix code
to NetBSD.
But I heard someone was working on getting Ultrix
to be open source, in which case one could port massive amounts
of DEC hardware support over, including XMI.
If "open source" ==
"BSD licence" this would be a really big help.
However, I thought that NetBSD already supports RA
disks, so,
the MSCP protocol should be there.
Yes. NetBSD has already MSCP drivers. But
guessing a bus protocol on
bais of a device driver is somewhat painful. Also guessing is no good
bais for new code. But reading a tech. man. _and_ existing code is very
effective. (One of the lessons I learned while writing the RX01/02
driver. :-) )
--
tsch??,
Jochen
Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
9:03 p.m.
On Wed, 27 Feb 2002, Jochen Kunz wrote:
:-) I have a bunch of UDA50, both for my PDP-11s, and for the 8650.
True about the copyright problems.
However, the Ultrix driver is a beautiful beast. When you declare an MSCP
disk, you don't say where it's located. You just say:
disk ra<x> at mscp drive <y>
Controllers are declared as:
controller uda0 at uba0
controller uq0 at uda0
controller hsc0 at ci0
And then the disks can be either at hsc0 or uq0, and you can move them
without problems.
DSSI is yet another, and so on...
This nice solution comes from the fact that Ultrix divided the driver into
two parts (as does all DEC OSes), the class driver and the port
driver. The class driver handles all mscp disks, no matter how they are
connected to the system. The port driver handles the passing of the
physical messages between the controller and the system. Port drivers are
individual for each type of hardware. Port drivers can also be used by
other stuff than MSCP, such as DUP, TMSCP, or IP for that matter.
True. And also, the NetBSD RA support have some bug in it, along with
being very much tied to the UDA50/KDA50 right now.
Johnny
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)update.uu.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2002.02.27 05:04 Gunther Schadow wrote:
I would really like to get my hands on the UDA50 programming manual. It
seems to be extremely rare.
I have the UDA50 manual
Do you have a
scanner? ;-) (BTW: anyone
have a UDA50?)
Aha. The 11/780 demands its tribute. ;-) I would assume
that peeking into the Ultrix 4.2
source code could be of great help.
This may lead to serious copyright problems,
even with a "cleanroom
reverse engineering approach". I think BSD has suffered enough from such
problems. Additionaly Ultrix may be that different, that it may be
easier to write somthing new from scratch, than port ancient Ultrix code
to NetBSD. However, I
thought that NetBSD already supports RA disks, so,
the MSCP protocol should be there.
Yes. NetBSD has already MSCP drivers. But
guessing a bus protocol on
bais of a device driver is somewhat painful. Also guessing is no good
bais for new code.
11:14 p.m.
On Wed, Feb 27, 2002 at 12:03:49PM +0100, Johnny Billquist wrote:
:-) I have a bunch of UDA50, both for my PDP-11s, and
for the 8650.
Hmpf. I need the machine for a UDA50. Don't you have a PDP 11/70
handy? ;-)
However, the Ultrix driver is a beautiful beast. When
you declare an MSCP
disk, you don't say where it's located. You just say:
disk ra<x> at mscp drive <y>
Controllers are declared as:
controller uda0 at uba0
controller uq0 at uda0
controller hsc0 at ci0
And then the disks can be either at hsc0 or uq0, and you can move them
without problems.
DSSI is yet another, and so on...
This is also true for NetBSD. From my knowledge
the shebang should
be build like this:
mainbus0 at root
ibus0 at mainbus0
shac0 at ibus0
sii0 at ibus0
dssibus* at shac?
dssibus* at sii?
scs* at dssibus?
mscpbus* at scs?
(SCS, System Communication Services seams to be the protocol that
is spoken on a DSSI bus and that transports MSCP. Got this from
http://www3.sympatico.ca/n.rieck/docs/vax_vms_storage_notes.html)
Maybe HSC instead of SCS, don't know, I hve no manuals...
I can get a KA680 TM from a friend. So what is really needed
is information about DSSI. (I am afraid that this is hard to get.)
True. And also, the NetBSD RA support have some bug in
it, along with
being very much tied to the UDA50/KDA50 right now.
As Ragge already stated, at
least the last objection is not true
anymore. The NetBSD MSCP stuff resides now in sys/dev/mscp what means
that it is machine independent. This also implies proper abstraction
of the MSCP stuff from the underlieing controller hardware.
--
tsch??,
Jochen
Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
11:12 p.m.
On Wed, 27 Feb 2002, Jochen Kunz wrote:
[...]
I'll have to blame my bad memory for still living in the old ra driver...
You both are probably absolutely correct, so I withdraw my claims. :-)
Now I only wish I had some time to try finding the bugs in the mscp
driver...
Johnny
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)update.uu.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Wed, Feb 27, 2002 at 12:03:49PM +0100, Johnny
Billquist wrote:
I might. Can you affort the transport? :-)
:-) I have a bunch of UDA50, both for my PDP-11s,
and for the 8650.
Hmpf. I need the machine for a UDA50. Don't you have a PDP
11/70
handy? ;-) However, the
Ultrix driver is a beautiful beast. When you declare an MSCP
disk, you don't say where it's located. You just say:
disk ra<x> at mscp drive <y>
Controllers are declared as:
controller uda0 at uba0
controller uq0 at uda0
controller hsc0 at ci0
And then the disks can be either at hsc0 or uq0, and you can move them
without problems.
DSSI is yet another, and so on...
This is also true for NetBSD. From my knowledge
the shebang should
be build like this: True. And
also, the NetBSD RA support have some bug in it, along with
being very much tied to the UDA50/KDA50 right now.
As Ragge already stated, at
least the last objection is not true
anymore. The NetBSD MSCP stuff resides now in sys/dev/mscp what means
that it is machine independent. This also implies proper abstraction
of the MSCP stuff from the underlieing controller hardware.
27 Feb
27 Feb
12:38 a.m.
Johnny Billquist wrote:
>:-) I have a bunch of UDA50, both for my PDP-11s, and for the 8650.
Johnny, were you suggesting you have a *spare* one among them?
>However, the Ultrix driver is a beautiful beast.
When you declare an MSCP
>disk, you don't say where it's located. You just say:
>disk ra<x> at mscp drive <y>
>
>Controllers are declared as:
>controller uda0 at uba0
>controller uq0 at uda0
>controller hsc0 at ci0
>
>And then the disks can be either at hsc0 or uq0, and you can move them
>without problems.
>DSSI is yet another, and so on...
>
Jochen Kunz wrote:
This is also true for NetBSD. From my knowledge the
shebang should
be build like this:
mainbus0 at root
ibus0 at mainbus0
shac0 at ibus0
sii0 at ibus0
dssibus* at shac?
dssibus* at sii?
scs* at dssibus?
mscpbus* at scs?
If I'm not mistaken the whole idea stems from BSD anyway (just as
the whole Ultrix does.) In 386/BSD and early FreeBSD the config(8)
syntax distinguished controller from device. Here this is from
GENERIC.allvax of 4.3 BSD:
controller mba0 at nexus ?
controller mba1 at nexus ?
...
disk hp0 at mba? drive 0
disk hp1 at mba? drive ?
...
master ht0 at mba? drive ?
tape tu0 at ht0 slave 0
tape tu1 at ht0 slave 1
master mt0 at mba? drive ?
tape mu0 at mt0 slave 0
tape mu1 at mt0 slave 1
controller uba0 at nexus ?
controller uba1 at nexus ?
...
controller uda0 at uba? csr 0172150 vector udaintr
disk ra0 at uda0 drive 0
disk ra1 at uda0 drive 1
...
controller bi0 at nexus ?
controller kdb0 at bi0 csr 0 vector kdbintr
disk kra0 at kdb0 drive 0
disk kra1 at kdb0 drive 1
disk kra2 at kdb0 drive 2
disk kra3 at kdb0 drive 3
So, just want the record to be straight, the beautiful design most
probably comes from Berkeley. I do admit though that they don't
seem to have a separate mscp controller, which I though Ultrix had,
but again, I should be looking before talking ...
cheers,
-Gunther
--
Gunther Schadow, M.D., Ph.D. gschadow(a)regenstrief.org
Medical Information Scientist Regenstrief Institute for Health Care
Adjunct Assistant Professor Indiana University School of Medicine
tel:1(317)630-7960 http://aurora.regenstrief.org
12:51 a.m.
On Wed, 27 Feb 2002, Gunther Schadow wrote:
If someone have a PEP-70/HC-70 kit to trade with, yes.
Johnny
Billquist wrote:
>:-) I have a bunch of UDA50, both for my PDP-11s, and for the 8650.
Johnny, were you suggesting you have a *spare* one among them? If I'm not mistaken the whole idea stems from BSD
anyway (just as
the whole Ultrix does.) In 386/BSD and early FreeBSD the config(8)
syntax distinguished controller from device.
That's a different issue. The idea DEC had with MSCP is that you separate
the disk controlling from actually transporting the commands to the
disk. So you actually have a two-layer controller.
BSD did not have that at the 4.3 era.
Here this is from
GENERIC.allvax of 4.3 BSD:
controller mba0 at nexus ?
controller mba1 at nexus ?
...
disk hp0 at mba? drive 0
disk hp1 at mba? drive ?
Note that you don't any concept of the abstract disk for massbus. Instead
massbus disks are massbus disks. There is no abstract layer even in
hardware. You directly access the different control and status registers.
controller uba0 at nexus ?
controller uba1 at nexus ?
...
controller uda0 at uba? csr 0172150 vector udaintr
disk ra0 at uda0 drive 0
disk ra1 at uda0 drive 1
...
controller bi0 at nexus ?
controller kdb0 at bi0 csr 0 vector kdbintr
disk kra0 at kdb0 drive 0
disk kra1 at kdb0 drive 1
disk kra2 at kdb0 drive 2
disk kra3 at kdb0 drive 3
So, just want the record to be straight, the beautiful design most
probably comes from Berkeley. I do admit though that they don't
seem to have a separate mscp controller, which I though Ultrix had,
but again, I should be looking before talking ...
No, you noted correctly. BSD don't have a separate mscp
controller. Instead they have a different driver for each hardware
controller, which also means that you have ra for disks attached to
UDA50/KDA50 while you have kra for disks attached to KDB50.
Yet they are all MSCP controllers, talking the same language. However,
there are some differences on how you actually talk to a KDB50 compared
to a UDA50.
They sit on totally different buses...
Johnny
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)update.uu.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
1:37 a.m.
On Wed, Feb 27, 2002 at 09:38:25AM -0500, Gunther Schadow wrote:
[PDP 11/70]
Johnny, were you suggesting you have a *spare* one
among them?
I am afraid he has. They have plenties of big, old DEC iron up there
Sweden... Sometimes I think about rentig a _BIG_ truck and driving
up to the polar circle and "clean-up" the "computer junk" that they
have
in their basements... ;-)
If I'm not mistaken the whole idea stems from BSD
anyway (just as
the whole Ultrix does.) In 386/BSD and early FreeBSD the config(8)
syntax distinguished controller from device. Here this is from
GENERIC.allvax of 4.3 BSD:
The whole autoconfig(9) stuff changed on the way from
4.3BSD to
4.4BSD (AFAIK) and again from 4.4BSD to todays NetBSD. So this
4.3BSD stuff is mostly obsolete. If you are interrested in the
NetBSD autoconfig(9) system wait for a week or two and you can
review my NetBSD device driver writing HOWTO. Perhaps you are
willing to to the German => English translation?
--
tsch??,
Jochen
Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
1:58 a.m.
Jochen Kunz wrote:
The whole autoconfig(9) stuff changed on the way from
4.3BSD to
4.4BSD (AFAIK) and again from 4.4BSD to todays NetBSD. So this
4.3BSD stuff is mostly obsolete. If you are interrested in the
NetBSD autoconfig(9) system wait for a week or two and you can
review my NetBSD device driver writing HOWTO. Perhaps you are
willing to to the German => English translation?
We'll see about that, but I'm glad that it's in one language that
I can read :-) (Why didn't you write it in English in the first
place, sounds like you have no problems with that?)
-Gunther
--
Gunther Schadow, M.D., Ph.D. gschadow(a)regenstrief.org
Medical Information Scientist Regenstrief Institute for Health Care
Adjunct Assistant Professor Indiana University School of Medicine
tel:1(317)630-7960 http://aurora.regenstrief.org
3:04 a.m.
On Wed, Feb 27, 2002 at 10:58:26AM -0500, Gunther Schadow wrote:
We'll see about that, but I'm glad that
it's in one language that
I can read :-)
I know... And AFAIK you have no knowledge about NetBSD kernel
hacking.
So this would be a good test if that doc is understandable by a
kernel hacking newbie.
(Why didn't you write it in English in the first
place, sounds like you have no problems with that?)
Because I need _much_ more
thime to express complex thaughts
in English. I wanted to concentrate my work on the driver and
the documentation instead wasting energy for finding the right
words in an foreign language.
--
tsch??,
Jochen
Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
3:15 a.m.
Jochen Kunz wrote:
On Wed, Feb 27, 2002 at 10:58:26AM -0500, Gunther
Schadow wrote:
Well, you are just about right. I am the proud writer of one FreeBSD
device driver though, for the Genius hand-scanner, an ISA DMA device. I
figured everything out from (1) the skinny manual, (2) disassembling
the DOS driver, and (3) the FreeBSD-2.something kernel code. I did
this by immitating what I saw and building my own theories why things
look as they look. And I did get it to work. The only reason why
I didn't program the IRQ controll was that I had no idea how the
device would use it.
I am glad someone finally takes the time explaining to me why things
are done the way they are done. And yes, I finally bought the McKusick
and Leffler's 4.3BSD book just a few months ago.
regards
-Gunther
--
Gunther Schadow, M.D., Ph.D. gschadow(a)regenstrief.org
Medical Information Scientist Regenstrief Institute for Health Care
Adjunct Assistant Professor Indiana University School of Medicine
tel:1(317)630-7960 http://aurora.regenstrief.org
We'll see about that, but I'm glad that
it's in one language that
I can read :-)
I know... And AFAIK you have no knowledge about NetBSD kernel hacking.
So this would be a good test if that doc is understandable by a
kernel hacking newbie. 
1 a.m.
On Wed, Feb 27, 2002 at 02:14:35PM +0100, Jochen Kunz wrote:
dssibus* at sii?
scs* at dssibus?
mscpbus* at scs?
(SCS, System Communication Services seams to be the protocol that
is spoken on a DSSI bus and that transports MSCP. Got this from
http://www3.sympatico.ca/n.rieck/docs/vax_vms_storage_notes.html)
Maybe HSC instead of SCS, don't know, I hve no manuals...
I can get a KA680 TM from a friend. So what is really needed
is information about DSSI. (I am afraid that this is hard to get.)
SCA/SCS can be spoken on DSSI/CI (and ethernet too), but it is not needed
to speak with locally connected MSCP devices.
(I think so. I am not sure, and I do not have the docs at hand.)
--
-Roar
1:55 a.m.
On Wed, Feb 27, 2002 at 04:00:14PM +0100, roart(a)nvg.ntnu.no wrote:
SCA/SCS can be spoken on DSSI/CI (and ethernet too),
but it is not needed
to speak with locally connected MSCP devices.
You mean it is possible to speak MSCP
on a DSSI bus without
an additional protocol layer?
Or do you mean that (only?) non-DSSI controllers a la RQDXx and
[KU]DA50 can speak MSCP without SCA/SCS?
(I think so. I am not sure, and I do not have the docs
at hand.)
I hope they exist / are available at all.
--
tsch??,
Jochen
Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
3:09 a.m.
On Wed, 27 Feb 2002, Jochen Kunz wrote:
On Wed, Feb 27, 2002 at 04:00:14PM +0100,
roart(a)nvg.ntnu.no wrote:
I have got a very strong feeling I was wrong. (Sorry)
But if you have to talk SCA/SCS with the DSSI-devices, that might be a
problem, since SCA/SCS is not published, and no implementations are
available.
(The Ultrix implementation may be closest, even though it is limited)
Look at
http://minnie.tuhs.org/Quasijarus/vaxhw/mscp_clu.html
(This was written by Sokolov; feel free to correct it)
--
-Roar
SCA/SCS can be spoken on DSSI/CI (and ethernet
too), but it is not needed
to speak with locally connected MSCP devices.
You mean it is possible to speak
MSCP on a DSSI bus without
an additional protocol layer?
Or do you mean that (only?) non-DSSI controllers a la RQDXx and
[KU]DA50 can speak MSCP without SCA/SCS?
(I think so. I am not sure, and I do not have the
docs at hand.)
I hope they exist / are available at all.
6:01 a.m.
On 2002.02.27 18:09 Roar Thron?s wrote:
But if you have to talk SCA/SCS with the DSSI-devices,
that might be a
problem, since SCA/SCS is not published, and no implementations are
available.
(The Ultrix implementation may be closest, even though it is limited)
Look at
http://minnie.tuhs.org/Quasijarus/vaxhw/mscp_clu.html
(This was written by Sokolov; feel free to correct it)
Aha. Now I get a more deeper
view into this whole mess and it leads me
to the frustrating conclusion: _Proper_ DSSI / CI support requires
detaild documentation about SCA. As this seams to be unavailable, the
whole project stopes right here. :-(((
Maybe it will be possible to implement a "pragmatic approach", read: A
ugly and evil hack. This is truely not the (Net)BSD way of life,
nevertheless worth a thought (probably).
DSSI and CI are just two physical transport methods for SCA (Systems
Communication Architecture). In fact the SHAC is mainly a CI adapter on
a chip, i.e. if we get DSSI support, we will have CI support as well.
This is no simple thing.
--
tsch??,
Jochen
Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
3:06 a.m.
(SCS, System Communication Services seams to be the
protocol that is spoken on a DSSI bus and that transports
MSCP. Got this from
http://www3.sympatico.ca/n.rieck/docs/vax_vms_storage_notes.html)
Nice intro Glossary, but no entry on SDI. That's been troubling
me lately... Why were there both DSSI and SDI drives around
at the same time and how did the SE know which to use?
EG the link says "Basic MSCP(*) required to undertand RFxx drives"
but when you go to that(*) page it's all on the RAxx series.
Is it that DSSI/RFxx is more self contained and SDI/RAxx is
faster, but requires a better ($$) controller? Could RA / RF be
cross used? Clues please.
John A.
Compare and Contrast...
6:49 a.m.
On 2002.02.27 18:06 John Allain wrote:
Nice intro Glossary, but no entry on SDI. That's
been troubling
me lately... Why were there both DSSI and SDI drives around
at the same time and how did the SE know which to use?
SE?
DSSI and SDI are two very different things. DSSI and CI are physical
transports for SCA (Systems Communication Architecture) and differ only
in the hardware. In fact the SHAC DSSI adapter is mostly a CI adapter on
a chip. MSCP is a subpart of SCA. SCA defines much more than disk and
tape IO...
SDI is only a (more or less dumb) high speed serial disk interface.
You may read: http://minnie.tuhs.org/Quasijarus/vaxhw/mscp_clu.html
--
tsch??,
Jochen
Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
6:16 p.m.
--- Johnny Billquist <bqt(a)update.uu.se> wrote:
On Wed, 27 Feb 2002, Jochen Kunz wrote:
> On 2002.02.27 05:04 Gunther Schadow wrote:
>
> > I have the UDA50 manual
Would that be EK-UDA50-UG-003? That's all I could turn up after
pawing through stuff that isn't in storage. Found a nice chart
of Standard Unibus vs. Modified Unibus on page 2-8. I can see why
it's a bad idea to put a terminator card that's expecting to live
in a standard slot into a MUD slot - battery (+5VDC, +/-15VDC) and
core (+20VDC, -5VDC) voltages abound on pins in MUD slots that are
grounds on a standard slot!
I would really like to get my hands on the UDA50
programming manual. It
seems to be extremely rare.
I'd say so. I used to work at a shop that manufactured 3rd party
peripherals. We had lots of docs, VMS fiche, etc. We never had
UDA50 internals docs. I presume because of licensing and patents,
etc., that those docs were pricey from DEC.
> > (BTW: anyone have a UDA50?)
Me, along with the Qbus and VAXBI equivalents. No spares. Sorry. Got
more machines and disks than controllers.
-ethan
__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://greetings.yahoo.com
8333
days inactive
8335
days old
18 comments
6 participants
participants (6)
-
allain＠panix.com -
bqt＠update.uu.se -
erd_6502＠yahoo.com -
gunther＠aurora.regenstrief.org -
jkunz＠unixag-kl.fh-kl.de -
roart＠nvg.ntnu.no