Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Optimised XXDP drivers

140 views
Skip to first unread message

Mark Sterk

unread,
Dec 17, 2000, 4:52:24 AM12/17/00
to

I always wondered why xxdp boots so much faster from a RL01/02 drive
than from a RDxx.. device.
Some time ago I heard a rumor that xxdp uses a badly written MSCP driver
and only the RLxx driver was optimized, according to the same rumor
someone had written a better MSCP driver.

Can one of you guys confirm this or give me a URL where I can find such
a driver.

Thanks,

Mark


paramucho

unread,
Dec 17, 2000, 8:56:36 AM12/17/00
to
On Sun, 17 Dec 2000 09:52:24 GMT, Mark Sterk <str...@chello.nl> wrote:

>
>
>I always wondered why xxdp boots so much faster from a RL01/02 drive
>than from a RDxx.. device.
>Some time ago I heard a rumor that xxdp uses a badly written MSCP driver
>and only the RLxx driver was optimized, according to the same rumor
>someone had written a better MSCP driver.

Are you sure that the RLxx driver was optimised? The RLxx hardware had
some significant problems locating tracks which caused DEC to issue
updated drivers.

Someone (Chester) did write a better MSCP driver for RT-11.

Jeff Campbell

unread,
Dec 18, 2000, 11:53:17 AM12/18/00
to
I think the XXDP MSCP is written as a non-interrupt driver device
drive - that is it loops waiting for command and response packet
ownership flag bits. Also the driver reinits the virtual circuit between
the host CPU and the controller more frequently that an operating system
would. Both of these behaviors make for slow performance.

Jeff Campbell
n8...@arrl.net

Mark Sterk

unread,
Dec 18, 2000, 5:47:28 PM12/18/00
to

Jeff Campbell wrote:

> I think the XXDP MSCP is written as a non-interrupt driver device
> drive - that is it loops waiting for command and response packet
> ownership flag bits. Also the driver reinits the virtual circuit between
> the host CPU and the controller more frequently that an operating system
> would. Both of these behaviors make for slow performance.
>
> Jeff Campbell
> n8...@arrl.net
>

I think they just needed a quick and dirty solution to get a disk working and
they never bothered to do it the right way.

Mark


paramucho

unread,
Dec 18, 2000, 7:36:33 PM12/18/00
to
On Mon, 18 Dec 2000 16:53:17 GMT, Jeff Campbell
<jcam...@ins-msi.com> wrote:

>I think the XXDP MSCP is written as a non-interrupt driver device
>drive - that is it loops waiting for command and response packet
>ownership flag bits. Also the driver reinits the virtual circuit between
>the host CPU and the controller more frequently that an operating system
>would. Both of these behaviors make for slow performance.

The versions I've seen of XXDP don't seem to use any interrupts at
all.


Ian

John Santos

unread,
Dec 18, 2000, 9:25:10 PM12/18/00
to

I always assumed this was deliberate. How do you boot diagnostics
on a system with broken DMA arbitration? Turn off interrupts and
use a polling driver (i.e. watch the "device ready" bit in the CSR.)

We used to have a DIVA RP03 emulator that worked fine until we upgraded
the 11/40 CPU to an Able Microverter with a Unibus adapter. After
that, RSTS/E wouldn't boot unless you pressed "Break" followed by "P"
on the console about 20 times. This was because the DIVA microprocessor
(an external SEL computer, IIRC) would get locked up servicing the
CSR emulation and wouldn't get a chance to transfer the data. The
break would halt the CPU and give the microprocessor a chance to
do its DMA. It took about 20 transfers to load enough of the monitor
for it to switch to doing DMA's with interrupts to load the rest.
The hardware boot apparently either triggered a DMA request for block
0 of the disk, but didn't wait around for success, or it did a pure
non-DMA, not-interrupt transfer, which worked fine. (I don't remember
which.) And RSTS/E used DMA plus interrupts, which also worked fine.

The cure was to patch the RSTS/E boot driver (a small bit of code
stored in block 0 of the disk) to do something in memory (a register-only
busy wait didn't seem to work), by pushing a small constant onto
the stack, decrementing it to 0, popping it, and then checking the
device CSR. Had to do this everytime we installed a new version
of RSTS/E or re-wrote the boot block on the disk...

--
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539

paramucho

unread,
Dec 18, 2000, 9:59:58 PM12/18/00
to
On Mon, 18 Dec 2000 21:25:10 -0500, John Santos <JO...@egh.com> wrote:

>On Tue, 19 Dec 2000, paramucho wrote:
>
>> On Mon, 18 Dec 2000 16:53:17 GMT, Jeff Campbell
>> <jcam...@ins-msi.com> wrote:
>>
>> >I think the XXDP MSCP is written as a non-interrupt driver device
>> >drive - that is it loops waiting for command and response packet
>> >ownership flag bits. Also the driver reinits the virtual circuit between
>> >the host CPU and the controller more frequently that an operating system
>> >would. Both of these behaviors make for slow performance.
>>
>> The versions I've seen of XXDP don't seem to use any interrupts at
>> all.
>
>I always assumed this was deliberate. How do you boot diagnostics
>on a system with broken DMA arbitration? Turn off interrupts and
>use a polling driver (i.e. watch the "device ready" bit in the CSR.)

That's my assumption too.


>The cure was to patch the RSTS/E boot driver (a small bit of code
>stored in block 0 of the disk) to do something in memory (a register-only
>busy wait didn't seem to work), by pushing a small constant onto
>the stack, decrementing it to 0, popping it, and then checking the
>device CSR. Had to do this everytime we installed a new version
>of RSTS/E or re-wrote the boot block on the disk...

There are people who make their name out of doing things like this.
They call their products "boot block viruses".

I've had to patch the odd boot block. Getting RT-11 to boot from a
system that DEC maintenance engineers had munged for testing purposes
was my favorite. They'd disabled various bits in the interface...


Ian


Michael Moroney

unread,
Dec 19, 2000, 10:22:17 PM12/19/00
to
Mark Sterk <str...@chello.nl> writes:

MSCP disks are painfully slow under XXDP because XXDP is continuously
resetting the controller. The RL02 controller/drive recovers almost
instantly while MSCP devices do some selftests, configuration etc. before
it can execute the read/whatever.

-Mike

Mark Sterk

unread,
Dec 21, 2000, 4:58:00 PM12/21/00
to

Jeff Campbell wrote:

> I think the XXDP MSCP is written as a non-interrupt driver device
> drive - that is it loops waiting for command and response packet
> ownership flag bits. Also the driver reinits the virtual circuit between
> the host CPU and the controller more frequently that an operating system
> would. Both of these behaviors make for slow performance.
>
> Jeff Campbell
> n8...@arrl.net
>

Mmmmmmm.

Sounds like I have to hang on to the RL02
That's a shame replacing some of these units with RDxx or RAxx drives would
mean a great space and sound reduction.


Thanks,
Mark

Zane H. Healy

unread,
Dec 22, 2000, 12:25:49 AM12/22/00
to
Mark Sterk <str...@chello.nl> wrote:
> Sounds like I have to hang on to the RL02
> That's a shame replacing some of these units with RDxx or RAxx drives would
> mean a great space and sound reduction.

Personally I'd recommend avoiding RDxx drives, on the other hand I've got
some RA72's and RA73's I've used on one of my systems (as well as RA90's I
didn't). My personal preference is SCSI, with ESDI coming in second.

If I have to run RDxx drives, I try to limit myself to RD52's and RD54's
(won't touch RD53's with a 10 foot pole). About the only reason I can think
of I'd have to use a RDxx drive is in my Pro380 which I believe would limit
me to a RD52, though I do have a VAXstation II/RC I'm trying to keep 'pure'
(which is a crazy thing to do on a couple fronts).

I consider a good SCSI controller a worth while investment as it will let
you use modern disks (though your OS might not be able to access all of the
disk). Besides it's nice to have a CD backup that you can boot from in an
emergency!

Zane


Jeff Campbell

unread,
Dec 22, 2000, 10:35:29 AM12/22/00
to
MSCP will boot from floppies as well - RX50, RX33. There the speed
loss isn't as apparent due to the floppy rotation rate.

8-)

Jeff Campbell
n8...@arrl.net

Mark Sterk wrote:
>
> Jeff Campbell wrote:
>
> ? I think the XXDP MSCP is written as a non-interrupt driver device
> ? drive - that is it loops waiting for command and response packet
> ? ownership flag bits. Also the driver reinits the virtual circuit between
> ? the host CPU and the controller more frequently that an operating system
> ? would. Both of these behaviors make for slow performance.
> ?
> ? Jeff Campbell
> ? n8...@arrl.net
> ?

Megan

unread,
Dec 26, 2000, 12:32:48 AM12/26/00
to
i...@beathoven.com (paramucho) writes:

>The versions I've seen of XXDP don't seem to use any interrupts at
>all.

As it was explained to me many years ago, if interrupts don't work,
then xxdp wouldn't boot... but if it doesn't use interrupts, and
uses PIO, then it has a better chance to work. The diagnostics
can then test the interrupt code.

Megan Gentry
Former RT-11 Developer

+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry!zk3.dec.com |
| Unix Support Engineering Group | (home): mbg!world.std.com |
| Compaq Computer Corporation | addresses need '@' in place of '!' |
| 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ |
| Nashua, NH 03062 | "pdp-11 programmer - some assembler |
| (603) 884 1055 | required." - mbg KB1FCA |
+--------------------------------+-------------------------------------+

0 new messages