2.11BSD patch 497-499

[Johnny Billquist]

More patches have been released since I last sent out a notice.

497 dealt with some Fortran issues.

498 was some bug fixing and improvements in the kernel.

499 was just released now, and is huge. Bugfixes and improvements, and
updating all of libc to more modern C standards.

As always:

This and previous updates to 2.11BSD are available at the following
locations:

ftp://ftp.dfupdate.se/pub/pdp11/2.11BSD
https://www.tuhs.org/Archive/Distributions/UCB/2.11BSD/Patches/
ftp://ftp.2bsd.com/2.11BSD
http://www.2bsd.com/2.11BSD/

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

[John D. Bruner]

"Huge" may be an understatement. Kudos - despite its size, I encountered
only a couple of minor hiccups while applying the patches and rebuilding
everything from source. (One of these hiccups was my own fault).

Hmm, I wonder how long this would take on a real PDP-11/70.

--John

> --
> You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/pidp-11/2c05dd0a-3390-4805-ae19-d6fb9e68d1a0%40softjar.se.

[Steven A. Falco]

On 1/13/26 09:47 AM, Johnny Billquist wrote:
> More patches have been released since I last sent out a notice.
>
> 497 dealt with some Fortran issues.
>
> 498 was some bug fixing and improvements in the kernel.
>
> 499 was just released now, and is huge. Bugfixes and improvements, and updating all of libc to more modern C standards.

I'm attempting to install patch 499 but I am seeing some concerning errors like:

cc -i -O -o graph graph.c -lplot -lm
Undefined:
__iob
__flsbuf
*** Exit 1

Stop.

Has anyone successfully installed this patch? I have been installing all the released patches in order, so this one _should_ work.

Also, there is this comment in the patch:

Later in 2026 patch 500 will be the formal announcement (/VERSION
change) and release of "2.11BSD: The 35th Anniversary Edition" with
new distribution tape image.

I guess I could just wait for the new distribution tape and reinstall a clean system from that.

Steve

[John D. Bruner]

I successfully applied all of the patches. In my case there were
a few files where the patching failed (in one case, because I
had changed it to work around a now-fixed issue with long divide).
I found the xxx# files and applied the patches manually. After
that, everything built OK except for /usr/src/games/warp - which
I fixed up.

__iob and __flsbuf are both part of stdio, so it sounds like
something there may not have been patched correctly.

--John

On Wednesday, January 14th, 2026 at 14:39, Steven A. Falco <steve...@gmail.com> wrote:

>
>
> On 1/13/26 09:47 AM, Johnny Billquist wrote:
>
> > More patches have been released since I last sent out a notice.
> >
> > 497 dealt with some Fortran issues.
> >
> > 498 was some bug fixing and improvements in the kernel.
> >
> > 499 was just released now, and is huge. Bugfixes and improvements, and updating all of libc to more modern C standards.
>
>
> I'm attempting to install patch 499 but I am seeing some concerning errors like:
>
> cc -i -O -o graph graph.c -lplot -lm
> Undefined:
> __iob
> __flsbuf
> *** Exit 1
>
> Stop.
>

> Has anyone successfully installed this patch? I have been installing all the released patches in order, so this one should work.

>
> Also, there is this comment in the patch:
>
> Later in 2026 patch 500 will be the formal announcement (/VERSION
> change) and release of "2.11BSD: The 35th Anniversary Edition" with
> new distribution tape image.
>
> I guess I could just wait for the new distribution tape and reinstall a clean system from that.
>
> Steve
>

> --
> You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/pidp-11/9a960f06-f8b8-454a-9f40-cf552afa5763%40gmail.com.

[Malcolm Ray]

To be honest, having been burned by patch 490, I'm inclined to wait a
while on this one, and see what problems (if any) people identify with
it. Or just wait for the anniversary edition and do a fresh install at
that point.

[Steven A. Falco]

I agree, Malcolm. I don't know how to determine what happened. I did check for *# files and didn't see any patching errors.

Steve

[Adam Thornton]

The only thing that bit me was that apparently at some point in the past a unistd.h patch had failed, and I was missing `F_OK` and a couple other definitions.  Once I added those in by hand it was pretty smooth.

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/pidp-11/1b426abc-b931-44f2-b1d5-58bb3c23491d%40gmail.com.

[terri-...@glaver.org]

On Wednesday, January 14, 2026 at 6:49:45 PM UTC-5 Sheepless wrote:

To be honest, having been burned by patch 490, I'm inclined to wait a
while on this one, and see what problems (if any) people identify with
it. Or just wait for the anniversary edition and do a fresh install at
that point.

An issue that crops up in some of these patches is that the disk image

you started from came from some place and may have had prior patches

missed, incompletely applied, etc. For example, the Covello disk image

has an incomplete install of 482 done (/etc/disktab was not installed,

among other issues with that patch) and had a failed 445 patch. So, a

number of these disk images aren't solid bases for when one of these
mega-patches is released.

Everyone should do a "bare metal" install from tape (even if all are emu-

lated) at least once. And once will likely be enough for most people 8-}

There should be both a 500 full install tape as well as pre-built disk

images ("traditional" 11/70 with RM05 disks and TU77 tape, as well as

"modern" 11/70 with MSCP disks and TU81 tape). Traditional represents

what would have been common "back in the day", using 2 of the four

possible Massbus adapters, and would be faster than the "modern" sys-

tem, since the Unibus was not particularly fast on the 11/70. Plus, you

only had 3 hex slots for Unibus devices - slot 40 was reserved for the

console interface card, slot 44 was was either a terminator or Unibus out

to an expansion chassis, leaving only a quad slot. So you usually couldn't 

fit everything in the 11/70 chassis. The only way to do it would be:

o UDA50 MSCP disk controller - 2 slots
o DELUA Ethernet controller - 1 slot (a DEUNA was 2 slots and wouldn't

   fit)
o KLESI TU81 controller (quad board in the bottom of slot 44)

[terri-...@glaver.org]

On Wednesday, January 14, 2026 at 5:39:11 PM UTC-5 steve...@gmail.com wrote:

I'm attempting to install patch 499 but I am seeing some concerning errors like:

cc -i -O -o graph graph.c -lplot -lm
Undefined:
__iob
__flsbuf
*** Exit 1

Stop. 

That looks like you missed part of the installation process. Here's the text

description (the actual commands are given elsewhere in the instructions):

    BEFORE starting the compilation a "make clean" is done to remove
    any old .o files that may be present.  A .o file compiled with the
    old stdio.h will cause an undefined symbol ("__iob") error and halt
    the build.
 

[Johnny Billquist]

I'll try and get both setups done for the future "clean" distribution
disk/tape of 2.11BSD. ANd Terri is absolutely right about the
questionable disk images people are using to do further work on.

But just a small comment on "speed" of the old hardware. While it is
true that the Massbus is much faster than the Unibus, and particularly
so on an 11/70, the end result is actually that an 11/70 with MSCP is
faster than any Massbus disk. The reason is simple - newer disks have
much better seek times, and MSCP even allows the controller to optimize
seeks when there are multiple I/O going on, to an extent that Massbus
disks can't. And seek times are huge compared to transfer times, and the
win with Massbus is just about the actual transfer. Just take a look at
the seek times of any Massbus disk, and get depressed. :)

And if you happen to have a SCSI MSCP controller for Unibus, and some
modern SCSI disks, you'll blow the massbus clean out of the water. (Your
I/O will be completed long before the massbus disk have even gotten to
the right track.)

Johnny

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com

> <mailto:pidp-11+u...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/pidp-11/

> ec614d81-331d-4b24-9f35-3e585033038bn%40googlegroups.com <https://
> groups.google.com/d/msgid/pidp-11/
> ec614d81-331d-4b24-9f35-3e585033038bn%40googlegroups.com?
> utm_medium=email&utm_source=footer>.

[terri-...@glaver.org]

On Friday, January 16, 2026 at 8:27:23 AM UTC-5 b...@softjar.se wrote:

I'll try and get both setups done for the future "clean" distribution
disk/tape of 2.11BSD. ANd Terri is absolutely right about the
questionable disk images people are using to do further work on.

But just a small comment on "speed" of the old hardware. While it is
true that the Massbus is much faster than the Unibus, and particularly
so on an 11/70, the end result is actually that an 11/70 with MSCP is

faster than any Massbus disk. [...]

True for almost all combinations of real hardware. 

On the PiDP-11 (since we're in that group, and I doubt people with real 

11/70s like Johnny are going to reconfigure their hardware on my say-

so) the RM05/TU77 should be just as fast as the MSCP disk / TU81 tape. 

Possibly even some microseconds faster due to the RH70/RM05 being a 

less complex emulation than an MSCP controller and drive(s). 

However,  the RH70/TU77 will be faster than any other DEC tape drive - it 

is a 125IPS vacuum-column drive, so it can write short records without 

"shoe-shining"  like the TU8x streamers (the TU81 would hit 75IPS if you 

kept it continuously fed, otherwise 25IPS or slower). And as far as rewind 

goes (unloading a tape reel to load the next one), the TU77 was 440IPS 

while the TU81 was only 192IPS. (IPS is "Inches Per Second"). A non-DEC 

SCSI card and tape drive could probably beat a TU77 due to higher record-

ing density.

The biggest advantage MSCP has in emulation is that you can have arbi-

trarily large disks (the DEC RA73 was the largest "real" MSCP disk at 2GB,

as the 3.5GB RA74 was cancelled). SIMH will let you specify whatever 

size you want. The highest-capacity Massbus drive was the RP07 which

held 512MB. Trivias: The RP07 was built by ISS and the underlying hard-

ware (without the Massbus bits) was designed as an IBM 3370 alterna-

tive. Also, despite being named an "RP" model, it was actually an "RM" as

far as programming goes (there are slight differences in the registers be-

tween RM and RP, which is why some operating systems allowed mixing

them on the same Massbus while others insisted on all-RM or all-RP

buses).

 

[Steven A. Falco]

I tried again, and found patch failures on the "warp" game and on "mp", both on the makefiles. But I don't know of a way to fix them - a simple discrepancy wouldn't be a problem, but the errors in those two are more extensive than I am comfortable with. If there was a fully patched system on line with ftp access, then I could grab the correct files. But this isn't a high priority - I'll just wait for the new tape image to appear.

Thanks,
Steve

[Johnny Billquist]

We are mixing two topics here, which might confuse some people. So for
everyone else (apart from Terri), please pay attention to if we're
talking emulation or real hardware. Very different truths apply. :-)

On 16/01/2026 15.23, terri-...@glaver.org wrote:
> On Friday, January 16, 2026 at 8:27:23 AM UTC-5 b...@softjar.sewrote:
>
> I'll try and get both setups done for the future "clean" distribution
> disk/tape of 2.11BSD. ANd Terri is absolutely right about the
> questionable disk images people are using to do further work on.
>
> But just a small comment on "speed" of the old hardware. While it is
> true that the Massbus is much faster than the Unibus, and particularly
> so on an 11/70, the end result is actually that an 11/70 with MSCP is
> faster than any Massbus disk. [...]
>
>
> True for almost all combinations of real hardware.

Well, if we talk disks, then modern disks will beat any Massbus disk by
a large margin. And MSCP is just disks, not tapes.

> On the PiDP-11 (since we're in that group, and I doubt people with real
> 11/70s like Johnny are going to reconfigure their hardware on my say-
> so) the RM05/TU77 should be just as fast as the MSCP disk / TU81 tape.
> Possibly even some microseconds faster due to the RH70/RM05 being a
> less complex emulation than an MSCP controller and drive(s).

On emulation, speedwise what disk you emulate will most likely make no
noticeable difference. Same with tapes.
The programming to access a massbus disk will require writing to
multiple registers, doing computations to get from logical block to
physical sector/track/cylinder, and then on the emulation side doing the
reverse, getting back from sector/track/cylinder to a logical block. And
you might have separate seek requests from disk accesses, and each
register access means going into the device emulation code and process
the register read/write. With MSCP you instead just set up the
information in memory, which actually just tells which logical block you
want, and then do a single poke at one device register, after which the
device emulation reads out the information from memory, and already have
all the information in a nice order to access the underlying storage.
I would suspect it's going to be faster than the massbus access. But
again, in the end, the times here are miniscule.

> However,  the RH70/TU77 will be faster than any other DEC tape drive - it
> is a 125IPS vacuum-column drive, so it can write short records without
> "shoe-shining"  like the TU8x streamers (the TU81 would hit 75IPS if you
> kept it continuously fed, otherwise 25IPS or slower). And as far as rewind
> goes (unloading a tape reel to load the next one), the TU77 was 440IPS
> while the TU81 was only 192IPS. (IPS is "Inches Per Second"). A non-DEC
> SCSI card and tape drive could probably beat a TU77 due to higher record-
> ing density.

Now we're talking real hardware again, and now we're talking tapes.
And I can only agree. The massbus tape drives are much faster than any
TMSCP tape drive you can hook up to the Unibus (which is essentially
only the TK50 and TU81). With a SCSI controller you could basically set
up any kind of tape drive with SCSI. But I don't think you'll find any
SCSI tape drive with comparable speeds to the TU77 either. However,
density wise, modern SCSI tape drives like DDS, DLT or whatever, are on
a completely different level, which affects primarily transfer speeds.
So reads/writes to those will far outperform a TU77 (or TU78), but seek
times are not great.

But tape drives don't usually do that much seeking to start with.

> The biggest advantage MSCP has in emulation is that you can have arbi-
> trarily large disks (the DEC RA73 was the largest "real" MSCP disk at 2GB,
> as the 3.5GB RA74 was cancelled). SIMH will let you specify whatever
> size you want. The highest-capacity Massbus drive was the RP07 which
> held 512MB. Trivias: The RP07 was built by ISS and the underlying hard-
> ware (without the Massbus bits) was designed as an IBM 3370 alterna-
> tive. Also, despite being named an "RP" model, it was actually an "RM" as
> far as programming goes (there are slight differences in the registers be-
> tween RM and RP, which is why some operating systems allowed mixing
> them on the same Massbus while others insisted on all-RM or all-RP
> buses).

Agreed. And I'm running with 8G drives on my physical as well as
emulated RSX systems (8G being the limit that RSX impose. Something I
should explore lifting...).

.con dis full att for du0:
DU0: CPA DUA0: Online,Accpath,Context,Driver,Type=RZ29
.

And yeah, type can be any arbitrary string. It's sad/annoying that simh
have this fixed idea what the identity of a disk should be (or have that
been fixed now?).

Johnny

[terri-...@glaver.org]

On Friday, January 16, 2026 at 9:34:59 AM UTC-5 steve...@gmail.com wrote:

I tried again, and found patch failures on the "warp" game and on "mp", both on the makefiles.

  OK, you're either using the Covello image or an earlier image the Covello was 

built from that had a failed 455 patch.

 

 If there was a fully patched system on line with ftp access, then I could grab the correct files.

  I could kit up an RM05-based install with very little trouble, but at this point the

last thing we need is another unofficial image floating around. So I agree with you

waiting for the official 500 tape or disk images. 

[terri-...@glaver.org]

On Friday, January 16, 2026 at 9:38:59 AM UTC-5 b...@softjar.se wrote:

We are mixing two topics here, which might confuse some people. So for
everyone else (apart from Terri), please pay attention to if we're
talking emulation or real hardware. Very different truths apply. :-) 

Quite true. Given that we're in the PiDP-11 group, I was expecting an

emulation-only audience. But certainly some people (cough, cough 8-)

with real hardware also hang out here - I work on two real 11/70's my-

self, including one I converted from MSCP with a UDA50 and RF73s to

an SC72 (3rd-party RH clone) with a pair of Fujitsu Eagles pretending

to be 4 RP06 drives. Hint: If you ever find yourself in a similar situation

and your OS install asks if you want "Overlapped seeks", answer "no".

 

[...] With MSCP you instead just set up the

information in memory, which actually just tells which logical block you
want, and then do a single poke at one device register, after which the
device emulation reads out the information from memory, and already have
all the information in a nice order to access the underlying storage.
I would suspect it's going to be faster than the massbus access. But
again, in the end, the times here are miniscule.

Depending on how accurately SIMH emulates the UDA50, there may well

be a bunch of additional overhead there. However, the SIMH PDP-11 emu-

lation (both CPU and peripherals) doesn't come close to passing XXDP

diagnostics, so it probably isn't doing a bunch of low-level stuff. In con-

trast, the SIMH VAX emulation does pass the EVKA? diagnostic suite. 

And yeah, type can be any arbitrary string. It's sad/annoying that simh
have this fixed idea what the identity of a disk should be (or have that
been fixed now?).

You should be able to do:

set rq0 ra92

set rq0 rauser=8000

attach rq0 somefile.dsk

but what you end up with is:

sim> set rq0 ra92
sim> set rq0 rauser=8000
sim> attach rq0 somefile.dsk
%SIM-INFO: RQ0: Creating new file: somefile.dsk
sim> sh rq0
RQ0     8003MB, attached to somefile.dsk, write enabled
        RA8U, UNIT=0, autosize
        SIMH format

But if you then exit SIMH and restart it, and do:

sim> set rq0 ra92
sim> attach rq0 -F simh somefile.dsk
sim> show rq0
RQ0     8003MB, attached to somefile.dsk, write enabled
        RA92, UNIT=0, autosize
        SIMH format

You have to specify "-F simh" on the attach or it will goof and assume

that the disk image is in raw format.

 

 Agreed. And I'm running with 8G drives on my physical as well as  

emulated RSX systems (8G being the limit that RSX impose. Something I 

should explore lifting...).

And RSTS/E knows its an RA92, and also knows it is too big (RDS 1.2 only

supports pack cluster sizes up to 64, and gets quite upset when it sees an

oversized disk):

Option: <Start> HA LI

  Name  Address Vector  Comments

  [...]

  RU0:   172150  P340   UDA50A  Units: 0(RA92)

  [...]

Option: <Start> DSK

Disk? RU0
DU0 disk capacity is too large.DU0 disk capacity is too large.Pack ID?

Note that this is on Open-SIMH 4.1.0-current 2632755a. It is likely that

the ancient version of SIMH required by the PiDP-11 REALCONS mods

won't understand this.

[Johnny Billquist]

On 16/01/2026 16.24, terri-...@glaver.org wrote:
> On Friday, January 16, 2026 at 9:38:59 AM UTC-5 b...@softjar.sewrote:
>
> We are mixing two topics here, which might confuse some people. So for
> everyone else (apart from Terri), please pay attention to if we're
> talking emulation or real hardware. Very different truths apply. :-)
>
>
> Quite true. Given that we're in the PiDP-11 group, I was expecting an
> emulation-only audience. But certainly some people (cough, cough 8-)
> with real hardware also hang out here - I work on two real 11/70's my-
> self, including one I converted from MSCP with a UDA50 and RF73s to
> an SC72 (3rd-party RH clone) with a pair of Fujitsu Eagles pretending
> to be 4 RP06 drives. Hint: If you ever find yourself in a similar situation
> and your OS install asks if you want "Overlapped seeks", answer "no".

Well, you're the one who started talking about real hardware. ;-)

And I can see how overlapped seeks might become a very bad idea if you
have one drive pretending to be two... That just becomes very, very,
bad. Hey, I'll do a seek on that second drive while the first one is
doing a transfer... *exploding head*

> [...] With MSCP you instead just set up the
> information in memory, which actually just tells which logical block
> you
> want, and then do a single poke at one device register, after whichthe
> device emulation reads out the information from memory, and already
> have
> all the information in a nice order to access the underlying storage.
> I would suspect it's going to be faster than the massbus access. But
> again, in the end, the times here are miniscule.
>
>
> Depending on how accurately SIMH emulates the UDA50, there may well
> be a bunch of additional overhead there. However, the SIMH PDP-11 emu-
> lation (both CPU and peripherals) doesn't come close to passing XXDP
> diagnostics, so it probably isn't doing a bunch of low-level stuff. In con-
> trast, the SIMH VAX emulation does pass the EVKA? diagnostic suite.

The simulation is definitely not doing more than enough to function.
However, from a simulation point of view, something like MSCP is
actually much more efficient than old style disk interfaces. But it's
more complicated to write the emulation to start with.
But nothing of the DUP is basically there, and if you were to run the
MSCP diagnostics under the VAX diagnostics, it would fail miserably as well.

Not sure if Bob ever went and really dived into the PDP-11 emulation for
correctness the same way he did the 3900. I think other VAXen have lots
of issues and won't necessarily pass any diagnostics either.

> And yeah, type can be any arbitrary string. It's sad/annoying that simh
> have this fixed idea what the identity of a disk should be (or have
> that
> been fixed now?).
>
>

> You /should/ be able to do:

>
> set rq0 ra92
> set rq0 rauser=8000
> attach rq0 somefile.dsk

How about I want to say that the disk is a "RZ29", or maybe a "BQT00"?
Should not be a problem, except simh makes it one...

Johnny

>  Agreed. And I'm running with 8G drives on my physical as well as
> emulated RSX systems (8G being the limit that RSX impose. SomethingI
> should explore lifting...).
>
>
> And RSTS/E knows its an RA92, and also knows it is too big (RDS 1.2 only
> supports pack cluster sizes up to 64, and gets quite upset when it seesan
> oversized disk):

With RSX, the "name" is purely decoration. Nothing actually cares what
it says. It's just getting the actual size from the disk as such, and
deals with that. And for RSX, if the disk is larger than 8G, it will be
truncated to 8G.
There is code in RSX to use 32-bit LBNs instead of 24-bit. But I have
never tried enabling it, and it might not work as is. But that would be
interesting to play with. Which is what I'm thinking about...

Johnny

[terri-...@glaver.org]

On Friday, January 16, 2026 at 10:35:42 AM UTC-5 b...@softjar.se wrote:

Well, you're the one who started talking about real hardware. ;-) 

Just to the extent of why one might prefer a "classic" 11/70 peripheral

emulation over a "modern" peripheral emulation.

 

And I can see how overlapped seeks might become a very bad idea if you
have one drive pretending to be two... That just becomes very, very,
bad. Hey, I'll do a seek on that second drive while the first one is
doing a transfer... *exploding head* 

It isn't actually that bad, since most (sane) 3rd-party controllers will

queue the seek even if the host OS requests overlapping ones. But

it does stall performance a bit, because the controller queue fills up

with seek - I/O - seek - I/O - seek - I/O instead of I/O - I/O - seek - I/O. 

 

The simulation is definitely not doing more than enough to function.
However, from a simulation point of view, something like MSCP is
actually much more efficient than old style disk interfaces. But it's
more complicated to write the emulation to start with.
But nothing of the DUP is basically there, and if you were to run the
MSCP diagnostics under the VAX diagnostics, it would fail miserably as well.

You have to emulate command packets with the queue depth of the

UDA50 or some operating systems will get upset. Likewise for handling

operations on multiple drives. But even a Raspberry Pi is so much faster

than an actual 11/70 that the controller emulation could be inefficient

and nobody would notice. Just like the PDP2011 uses one FPGA running

separate code to handle emulating the CPU, Ethernet, and a VT100. 

 Not sure if Bob ever went and really dived into the PDP-11 emulation for
correctness the same way he did the 3900. I think other VAXen have lots
of issues and won't necessarily pass any diagnostics either.

The MicroVAXen may well be the most hackish of the bunch, with the

3900 being the best of the lot. The "classic" VAXen (7xx, 86x0) pass

the architectural diagnostics. Peripherals are another matter entirely.

And don't get me started on the unnatural acts the DEUNA diags do.

How about I want to say that the disk is a "RZ29", or maybe a "BQT00"?
Should not be a problem, except simh makes it one... 

With RSX, the "name" is purely decoration. Nothing actually cares what
it says. It's just getting the actual size from the disk as such, and
deals with that. And for RSX, if the disk is larger than 8G, it will be
truncated to 8G.

SIMH imposes arbitrary limits, but at the same time allows completely 

impossible configurations:

sim> set cpu 11/70 4m fpp
Disabling XQ
sim> set rq krq50
sim> set rq0 rx50
sim> set rq0 rauser=8000
sim> att rq0 otherfile.dsk
%SIM-INFO: RQ0: Creating new file: otherfile.dsk
sim> det rq0
sim> set rq0 rx50
sim> att rq0 -F simh otherfile.dsk
sim> sh rq0
RQ0     8003MB, attached to otherfile.dsk, write enabled
        RX50, UNIT=0, autosize
        SIMH format

And then, boot RSTS/E from another disk:

  Name  Address Vector  Comments
  RU0:   172150  P320   KRQ50   Units: 0(RX50)

For those not following this, SIMH allowed me to attach a Q-bus CD-ROM

controller to a Unibus 11/70 and create an 8GB RX50 floppy disk on that

CD-ROM controller.

So I can't think of any reason it shouldn't allow you to create an MSCP

device with any name you like, maybe with:

SET RQn RANAME=FOOBAR

I'd propose it to Open-SIMH ("Classic" SIMH doesn't change, and GitHub

SIMH - as opposed to Open-SIMH - has some nonsense where it whines

about RQDX3s on Unibus systems, even if you don't ask for them, dis-

able them, etc.) except I have too much on my plate already. Johnny, do

you want to float it as a suggestion to Paul Koning?

[Johnny Billquist]

On 16/01/2026 17.17, terri-...@glaver.org wrote:
> On Friday, January 16, 2026 at 10:35:42 AM UTC-5 b...@softjar.se wrote:
>
> And I can see how overlapped seeks might become a very bad idea if you
> have one drive pretending to be two... That just becomes very, very,
> bad. Hey, I'll do a seek on that second drive while the first one is
> doing a transfer... *exploding head*
>
>
> It isn't actually that bad, since most (sane) 3rd-party controllers will
> queue the seek even if the host OS requests overlapping ones. But
> it does stall performance a bit, because the controller queue fills up
> with seek - I/O - seek - I/O - seek - I/O instead of I/O - I/O - seek -
> I/O.

Oh, I didn't mean to imply that the disk heads would actually explode.
But it's clearly not a useful pattern. One disk can't be doing two
different operations at the same time, so the controller obviously will
need to serialize this, and so that overlapped seek isn't going to be
overlapped after all. It shouldn't really cost you much, but it's still
not useful. Don't know about RSTS/E, but with RSX, the queue of
operations to the device will be the same either way. There is no extra
entry because of a seek. It's just that a read/write will be done in two
steps. First the seek, and then the requested operation. But maybe it's
more costly in RSTS/E?

> The simulation is definitely not doing more than enough to function.
> However, from a simulation point of view, something like MSCP is
> actually much more efficient than old style disk interfaces. But it's
> more complicated to write the emulation to start with.
> But nothing of the DUP is basically there, and if you were to run the
> MSCP diagnostics under the VAX diagnostics, it would fail miserably
> as well.
>
>
> You have to emulate command packets with the queue depth of the
> UDA50 or some operating systems will get upset. Likewise for handling
> operations on multiple drives. But even a Raspberry Pi is so much faster
> than an actual 11/70 that the controller emulation could be inefficient
> and nobody would notice. Just like the PDP2011 uses one FPGA running
> separate code to handle emulating the CPU, Ethernet, and a VT100.

The queue of packets, as well as multiple drives, are a very simple
thing. And you need to have that working right for any OS to operate.
Diagnostics more or less will require DUP and so on, though, which
normal operation don't care at all about.

But also, yes. Speed of emulator is so fast, and underlying disk cache
usually as well, so disk speeds are pretty much the same whatever
controller you emulate.

>  Not sure if Bob ever went and really dived into the PDP-11
> emulation for
> correctness the same way he did the 3900. I think other VAXen have lots
> of issues and won't necessarily pass any diagnostics either.
>
>
> The MicroVAXen may well be the most hackish of the bunch, with the
> 3900 being the best of the lot. The "classic" VAXen (7xx, 86x0) pass
> the architectural diagnostics. Peripherals are another matter entirely.
> And don't get me started on the unnatural acts the DEUNA diags do.

If the VAX-11 machines pass diagnostics, that's a clear improvement to a
few years ago. I know I talked with Mark about multiple issues in the
8600 in the past, and at one point when talking with Bob is basically
said that the 8600 is based on the 11/780, which in turn was just a hack
to be able to boot VMS, and no attempt was ever made to check how well
it confirms to actual machines.

> How about I want to say that the disk is a "RZ29", or maybe a "BQT00"?
> Should not be a problem, except simh makes it one...
>
> With RSX, the "name" is purely decoration. Nothing actually cares what
> it says. It's just getting the actual size from the disk as such, and
> deals with that. And for RSX, if the disk is larger than 8G, it will be
> truncated to 8G.
>
>
> SIMH imposes arbitrary limits, but at the same time allows completely
> impossible configurations:

It's the arbitrary limitations that annoy me. :-)

> sim> set cpu 11/70 4m fpp
> Disabling XQ
> sim> set rq krq50
> sim> set rq0 rx50
> sim> set rq0 rauser=8000
> sim> att rq0 otherfile.dsk
> %SIM-INFO: RQ0: Creating new file: otherfile.dsk
> sim> det rq0
> sim> set rq0 rx50
> sim> att rq0 -F simh otherfile.dsk
> sim> sh rq0
> RQ0     8003MB, attached to otherfile.dsk, write enabled
>         RX50, UNIT=0, autosize
>         SIMH format
>
> And then, boot RSTS/E from another disk:
>
> Name  Address Vector  Comments
>   RU0:   172150  P320   KRQ50   Units: 0(RX50)
>
> For those not following this, SIMH allowed me to attach a Q-bus CD-ROM
> controller to a Unibus 11/70 and create an 8GB RX50 floppy disk on that
> CD-ROM controller.

That's what you think. But as I said - those are just strings. There is
nothing that says that was actually an RX50 floppy. That is just a
string the drive or controller reports to you. And those strings have
nothing to do with what the actual device or media is.
Same thing with controllers, actually.

This is where people sometimes get a bit confused, and simh is really
helping propagate such confusion by insisting that these names actually
means something.

*They don't*

They are just strings reported by the subsystems without any actual
relationship to actual device or media. MSCP is really just giving you a
block addressable device with a certain number of blocks. And that's all
there is. You can call that whatever you want to.

And so anything, with any name, can be used as anything with any name.
It's just a bunch of blocks.

> So I can't think of any reason it shouldn't allow you to create an MSCP
> device with any name you like, maybe with:
>
> SET RQn RANAME=FOOBAR

Right. The only "limitation" is that the device name have at most 3
letters, and then a number which can be represented by 7 bits.

> I'd propose it to Open-SIMH ("Classic" SIMH doesn't change, and GitHub
> SIMH - as opposed to Open-SIMH - has some nonsense where it whines
> about RQDX3s on Unibus systems, even if you don't ask for them, dis-
> able them, etc.) except I have too much on my plate already. Johnny, do
> you want to float it as a suggestion to Paul Koning?

I might already have complained about this one multiple times, including
to Paul, who knows all about it. :-D

Johnny

[terri-...@glaver.org]

On Friday, January 16, 2026 at 11:38:12 AM UTC-5 b...@softjar.se wrote:

[...] Don't know about RSTS/E, but with RSX, the queue of

operations to the device will be the same either way. There is no extra
entry because of a seek. It's just that a read/write will be done in two
steps. First the seek, and then the requested operation. But maybe it's
more costly in RSTS/E?

All this emulation (either in SIMH or in a real 11/70 with an SC72) is

happening "behind the operating system's back". If the OS requests

simultaneous seeks on two "drives" that are actually one physical disk, 

the controller will serialize them, hopefully in a manner that gets some 

I/O done in between.

I do know of a case (in OS/360, I think) where a dual-actuator drive

scribbled on the wrong area...

 

If the VAX-11 machines pass diagnostics, that's a clear improvement to a
few years ago. I know I talked with Mark about multiple issues in the
8600 in the past, and at one point when talking with Bob is basically
said that the 8600 is based on the 11/780, which in turn was just a hack
to be able to boot VMS, and no attempt was ever made to check how well
it confirms to actual machines.

Running internal register sanity checks on VAX 8600 simulator.
*** Good Registers in VAX 8600 simulator.
VAX 8600 simulator Open SIMH V4.1-0 Current        git commit id: 6e9324e0
Running Hardware Core Test (EVKAA)
*** PASSED - VAX 8600 Hardware Core Instruction test EVKAA
Starting VAX Diagnostic Supervisor
Running - VAX Basic Instructions Exerciser EVKAB
*** PASSED - VAX Basic Instructions Exerciser EVKAB
Running - VAX Floating Point Instructions Exerciser EVKAC
*** PASSED - VAX Floating Point Instructions Exerciser EVKAC
Running - VAX Compatibility Mode Instructions Exerciser EVKAD
*** PASSED - VAX Compatibility Mode Instructions Exerciser EVKAD
*** All Diagnostic Supervisor tests PASSED *** 

> SIMH imposes arbitrary limits, but at the same time allows completely
> impossible configurations:

It's the arbitrary limitations that annoy me. :-)

Understood.

 

That's what you think. But as I said - those are just strings. There is
nothing that says that was actually an RX50 floppy. That is just a
string the drive or controller reports to you. And those strings have
nothing to do with what the actual device or media is.
Same thing with controllers, actually.

We're taking about a 22-bit Q-bus controller sitting on an 18-bit Unibus.
Or, even odder, a case of an 18-bit Unibus controller sitting on a 22-bit

Q-bus. I doubt [m]any PDP-11 operating systems would know to allo-

cate a bounce buffer in low memory for the case of an 11/73 with a

RK611 controller. Of course, being an emulator it can just say "it's

magic". RSTS/E does have some sanity checks, mostly for J11 quirks

but there's some for an ENABLE/34 (I think that's what it was called).

This is where people sometimes get a bit confused, and simh is really
helping propagate such confusion by insisting that these names actually
means something.

*They don't*

If we're talking about MSCP or SCSI device identifiers, agreed. But the

various oddball combinations of hardware are generally allowed. In the

specific case of an RK611 on an 11/73, if there's more than 18 bits worth

of memory, you get:

sim> set hk enable
%SIM-ERROR: HK device not compatible with system bus

But in 128KB or less, it'll let you do it. At least it checks. 8-}

> So I can't think of any reason it shouldn't allow you to create an MSCP
> device with any name you like, maybe with:
>
> SET RQn RANAME=FOOBAR

Right. The only "limitation" is that the device name have at most 3
letters, and then a number which can be represented by 7 bits.

Device name (DUA0 or whatever) hadn't come up yet in this conver-

sation. I was talking about model names (and I thought you were,

too). For MSCP device names, the longest DEC ones I know of are

5 characters (ESExx, RRD40, etc.) but I believe longer ones are al-

lowed. I'd have to pull out my MSCP Architecture Reference binder

and check, but I'm already way late for a conference.

> I'd propose it to Open-SIMH ("Classic" SIMH doesn't change, and GitHub
> SIMH - as opposed to Open-SIMH - has some nonsense where it whines
> about RQDX3s on Unibus systems, even if you don't ask for them, dis-
> able them, etc.) except I have too much on my plate already. Johnny, do
> you want to float it as a suggestion to Paul Koning?

I might already have complained about this one multiple times, including
to Paul, who knows all about it. :-D

OK, I'll mention it to Paul the next time we have a long chat about stuff. 

[Adam Thornton]

While I'm looking forward to starting over with a clean 500 master, one thing that I think would really, _really_ help would be an online tree of all the current files in a correctly patched virgin image.

Ideally, this'd be hosted at GitHub or GitLab or somewhere, but...

For instance, at some point in the past (no idea when), unistd.h didn't get correctly patched on my system.  I took a stab at what I needed to do, and got 499 to build, but something I went looking for, and failed, was a /usr/src tree from patchlevel 499, because then I could have just grabbed the raw file content and slapped it onto my own copy, because I know I don't WANT any local mods there.

Adam

[Johnny Billquist]

On 2026-01-16 18:21, terri-...@glaver.org wrote:
> On Friday, January 16, 2026 at 11:38:12 AM UTC-5 b...@softjar.se wrote:
>
> That's what you think. But as I said - those are just strings. There is
> nothing that says that was actually an RX50 floppy. That is just a
> string the drive or controller reports to you. And those strings have
> nothing to do with what the actual device or media is.
> Same thing with controllers, actually.
>
>
> We're taking about a 22-bit Q-bus controller sitting on an 18-bit Unibus.

Well. Controllers have a slightly more relevant difference, yes. In that
the addressing differs if we talk about different buses. But an RQDX3 or
a KDA50 makes no difference to the PDP-11 (pick any other Qbus MSCP
controller as well if you want to). The controller can call itself
whatever. It still works the same from the software point of view.

The disks obviously don't care what bus your system have.

> Or, even odder, a case of an 18-bit Unibus controller sitting on a 22-bit
> Q-bus. I doubt [m]any PDP-11 operating systems would know to allo-
> cate a bounce buffer in low memory for the case of an 11/73 with a
> RK611 controller. Of course, being an emulator it can just say "it's
> magic". RSTS/E does have some sanity checks, mostly for J11 quirks
> but there's some for an ENABLE/34 (I think that's what it was called).

Note that an RK611 is not an MSCP controller by any definition, and thus
is something completely different and irrelevant here.
It's MSCP where disk "names" are just meaningless strings. Disk types
for other controllers are a different story.

> This is where people sometimes get a bit confused, and simh is really
> helping propagate such confusion by insisting that these names actually
> means something.
>
> *They don't*
>
>
> If we're talking about MSCP or SCSI device identifiers, agreed. But the
> various oddball combinations of hardware are generally allowed. In the
> specific case of an RK611 on an 11/73, if there's more than 18 bits worth
> of memory, you get:

Again. This was about MSCP.

> > So I can't think of any reason it shouldn't allow you to create
> an MSCP
> > device with any name you like, maybe with:
> >
> > SET RQn RANAME=FOOBAR
>
> Right. The only "limitation" is that the device name have at most 3
> letters, and then a number which can be represented by 7 bits.
>
>
> Device name (DUA0 or whatever) hadn't come up yet in this conver-
> sation. I was talking about model names (and I thought you were,
> too). For MSCP device names, the longest DEC ones I know of are
> 5 characters (ESExx, RRD40, etc.) but I believe longer ones are al-
> lowed. I'd have to pull out my MSCP Architecture Reference binder
> and check, but I'm already way late for a conference.

I was talking about model names. Sorry for using wrong/confusing
terminology.

The ones you think of as 5 characters are in fact three characters, plus
that number.

Basically, it's all encoded in one 32-bit number (you'll find this if
you look up the manual). First you have five 5-bit values, which are
letters. The first two letters are "class" (or something like that),
followed by up to three letters which is the model name, followed by a
7-bit number which gives the whole thing.

So an RA81 is actually given as "DURA_<81>" (I hope you get the notion I
used here.)

PDP-11 OSes don't care about the "class" name, but VMS makes use of it,
which is why the RA60 is DJ: and not DU:
The full 32-bit value for an RA60 is "DJRA_<60>". (I think it was DJ,
right?)

There can't be any type name with more than 3 characters. It would be
impossible to encode. But something like "BQT00" would work just fine.

[terri-...@glaver.org]

[Please forgive my brevity - I've got my nose right up against a tiny 14"

screen to read this and related documentation since I'm in a hotel room

with malfunctioning climate control in 27-degreee (F) weather.]

On Friday, January 16, 2026 at 7:48:45 PM UTC-5 b...@softjar.se wrote:

Well. Controllers have a slightly more relevant difference, yes. In that
the addressing differs if we talk about different buses. But an RQDX3 or
a KDA50 makes no difference to the PDP-11 (pick any other Qbus MSCP
controller as well if you want to). The controller can call itself
whatever. It still works the same from the software point of view.

I don't recall offhand if there's a bit specifying whether MSCP BBR is host-

initiated or controller initiated, or if the port driver bases that decision on

controller models it knows about.

I really should do a test SIMH build that "takes off the guardrails" and

lets you do things like put a KDB50 on a Q-bus system, as well as allow-

ing arbitrary device type and media names, and see what goes "kaboom".

 

The disks obviously don't care what bus your system have. 

To a great extent, true for MSCP. But an RD54 appears as a DU-class de-

vice even though its physical interface is ST506. The same is true of the

early CD-ROM devices which use the LSMI interface. But certainly any

combination of real-world disk + controller that speaks MSCP is going

to look pretty much the same to the host OS. And I doubt a host OS is

going to go out of its way to check for impossible combinations and re-

ject them.

 

> Or, even odder, a case of an 18-bit Unibus controller sitting on a 22-bit
> Q-bus. I doubt [m]any PDP-11 operating systems would know to allo-
> cate a bounce buffer in low memory for the case of an 11/73 with a
> RK611 controller. Of course, being an emulator it can just say "it's
> magic". RSTS/E does have some sanity checks, mostly for J11 quirks
> but there's some for an ENABLE/34 (I think that's what it was called).

Note that an RK611 is not an MSCP controller by any definition, and thus
is something completely different and irrelevant here.
It's MSCP where disk "names" are just meaningless strings. Disk types
for other controllers are a different story.

I was just trying (badly, apparently 8-) to say that SIMH goes out of its way

to support some impossible bus/controller combinations while being

picky about drive model names in MSCP. 

I do remember a not-too-ancient heated debate about whether it made

sense for SIMH to separately report the UDA50 vs. the UDA50A, even

though to SIMH it was just a change in the model number byte. "Why do

you want that?" "Well, it's two different variants of a real controller!". SIMH

has the luxury of going (as my cat would say) "Feh!", whereas commercial

emulators have to implement what customers want, or they aren't buying,

even if the VMS device is connected to something utterly different in the

host. I helped getting FDDI added to AlphaVM because without FDDI in the

emulated system it was "no sale".

 

> If we're talking about MSCP or SCSI device identifiers, agreed. But the
> various oddball combinations of hardware are generally allowed. In the
> specific case of an RK611 on an 11/73, if there's more than 18 bits worth
> of memory, you get:

Again. This was about MSCP. 

And again, SIMH allows "impossible in the real world" combinations of hard-

ware but doesn't let you pick your own MSCP device names. I am expressing

support for your assertion, please give me a little credit 8-) 

 

I was talking about model names. Sorry for using wrong/confusing
terminology.

The ones you think of as 5 characters are in fact three characters, plus
that number.

Basically, it's all encoded in one 32-bit number (you'll find this if
you look up the manual). First you have five 5-bit values, which are
letters. The first two letters are "class" (or something like that),
followed by up to three letters which is the model name, followed by a
7-bit number which gives the whole thing.

RAD50? Plus 2 more RAD50 characters and the remaining bits treated as a

numeric value? I'm surprised DEC was so skimpy on storage for these names,

particularly when compared to the size of an MSCP packet 8-)

Trivia: A number of DEC [T]MSCP controllers will do the "heavy lifting" for

you if you just write the ASCII of the device class ("MU", for example) into

the CSR. You get test for ready, rewind, wait for ready, read block 0 (or 1)

into memory, all in the magic of 16 bits. A lot of 3rd-party controllers didn't

know about (or bother) implementing that tidbit and I had a sideline of

modifying MXV11-B3 (IIRC) ROMs to do it "the hard way" for some OEMs

(by stealing space from other bootstraps that were not needed).

So an RA81 is actually given as "DURA_<81>" (I hope you get the notion I
used here.)

PDP-11 OSes don't care about the "class" name, but VMS makes use of it,
which is why the RA60 is DJ: and not DU:
The full 32-bit value for an RA60 is "DJRA_<60>". (I think it was DJ,
right?)

Yes, for no explicable reason. It can't be removable vs. fixed, since the RX50

floppy and the RC25 cartridge are both DU. Maybe somebody didn't like the

RA60, or maybe it really did need special handling.

 

There can't be any type name with more than 3 characters. It would be
impossible to encode. But something like "BQT00" would work just fine.

Squinting at my tiny screen without glasses:

     1                        Table C-3: Disk Drive/Media Identifier Values (cont.)
     2     +----------+---------+-------+---------------------------+--------------------------------+
     3     |Model Byte|  Device | Media |   Media Type Identifier   |          Drive/Media           |
     4     | (decimal)|Type Name| Name  +---------------+-----------+        Characteristics         |
     5     |          |         |       |     octal     |    hex    |                                |
     6     +----------+---------+-------+---------------+-----------+--------------------------------+
     7     |    20    | see Appendix H, Table H-2                                                    |
     8     +----------+---------+-------+---------------+-----------+--------------------------------+
     9     |    21    |    DI   | RF30  | 021144,060036 | 2264,601E | 150 MB, 5.25" , fixed, half    |
    10     |          |         |       |               |           | height (DSSI Disk Server)      |
    11     +----------+---------+-------+---------------+-----------+--------------------------------+
    12     |    22    |    DI   | RF71  | 021144,060107 | 2264,6047 | 400 MB, 5.25" , fixed, half    |
    13     |          |         |       |               |           | height (DSSI Disk Server)      |
    14     +----------+---------+-------+---------------+-----------+--------------------------------+
    15     |  23 - 24 | see Appendix H, Table H-2                                                    |
    16     +----------+---------+-------+---------------+-----------+--------------------------------+
    17     |    25    |    DU   | ESE20 | 022513,031224 | 254B,3294 | 120 MB Solid State disk drive  |
    18     |          |         |       |               |           | with data retention            |
    19     +----------+---------+-------+---------------+-----------+--------------------------------+
    20     |    26    |    DU   | RRD40 | 022545,021050 | 2565,2228 | 500  MB,   4.75",   removable, |
    21     |          |         |       |               |           | DAD (optical) format           |
    22     +----------+---------+-------+---------------+-----------+--------------------------------+
    23     |    27    |    DI   | RF31  | 021144,060037 | 2264,601F | 381 MB, 5.25" fixed, half      |
    24     |          |         |       |               |           | height (DSSI Disk Server)      |
    25     +----------+---------+-------+---------------+-----------+--------------------------------+
    26     |    28    |    DI   | RF72  | 021144,060110 | 2264,6048 | 1 GB, 5.25", fixed, full       |
    27     |          |         |       |               |           | height (DSSI Disk Server)      |
    28     +----------+---------+-------+---------------+-----------+--------------------------------+
    29     |    29    |    DU   | RA92  | 022544,010134 | 2564,105C | 1.5 GB, 9", fixed              |
    30     +----------+---------+-------+---------------+-----------+--------------------------------+
    31     |    30    | unassigned                                                                   |
    32     +----------+---------+-------+---------------+-----------+--------------------------------+
    33     |    31    | see Appendix H, Table H-2                                                    |
    34     +----------+---------+-------+---------------+-----------+--------------------------------+
    35     |    32    | unassigned                                                                   |
    36     +----------+---------+-------+---------------+-----------+--------------------------------+
    37     |    33    |    DI   | RFH31 | 021144,062037 | 2264,641F | 190.5 MB, 5.25" fixed, half    |
    38     |          |         |       |               |           | height (DSSI Disk Server)      |
    39     +----------+---------+-------+---------------+-----------+--------------------------------+
    40     |    34    |    DI   | RFH72 | 021144,062110 | 2264,6448 | 500 MB, 5.25", fixed, full     |
    41     |          |         |       |               |           | height (DSSI Disk Server)      |
    42     +----------+---------+-------+---------------+-----------+--------------------------------+
    43     |    35    |    DI   | RF73  | 021144,060111 | 2264,6049 | 2 GB, 5.25", fixed             |
    44     |          |         |       |               |           | (DSSI Disk Server)             |
    45     +----------+---------+-------+---------------+-----------+--------------------------------+
    46     |    36    |    DI   | RFH73 | 021144,062111 | 2264,6449 | 1 GB, 5.25", fixed             |
    47     |          |         |       |               |           | (DSSI Disk Server)             |
    48     +----------+---------+-------+---------------+-----------+--------------------------------+

 What happens if you use one of the unassigned device model bytes? There

doesn't seem to be much rhyme or reason - we have DU intermingled with
DI. For that matter, would the encoding of DUESE<20> break if instead it was

BQTSE<20>? If RA60s are so special that they had to be DJ, what happens

if a PDP-11 OS driver sees a BQ device type name instead of a DU one?

Maybe it's all just display fluff and nothing cares. Certainly the port/device

driver combo can figure out that you can't write to a CD-ROM, presumably

by looking at other info in the returned device characteristics (writable CDs

didn't appear in VMS until SCSI / IDE models - the earlier ones had no pro-

vision for writing in hardware). And then we go off into another unrelated-to-

PDP-11 discussion, where the VMS DQDRIVER for IDE CD-ROMs supports

2048-byte sectors (because DEC had become such a niche market for op-

tical drive makers that they were having trouble getting 512-byte support,

even on SCSI drives. As I recall, DEC had built up a rather large inventory of

512-byte SCSI CD-ROMS due to "final lifetime buy" notices from manufac-

turers. I believe Plextor was the last company to introduce a new 512-byte-

capable SCSI CD-ROM.

Going off on another tangent, didn't DEC have large (12" before caddy) mag-

neto-optical drives that were also MSCP on the host side? Presumably they

needed special handling in the VMS DUDRIVER as well.

[Johnny Billquist]

On 2026-01-17 04:16, terri-...@glaver.org wrote:
> [Please forgive my brevity - I've got my nose right up against a tiny 14"
> screen to read this and related documentation since I'm in a hotel room
> with malfunctioning climate control in 27-degreee (F) weather.]
>
> On Friday, January 16, 2026 at 7:48:45 PM UTC-5 b...@softjar.sewrote:
>
> Well. Controllers have a slightly more relevant difference, yes. In
> that
> the addressing differs if we talk about different buses. But an
> RQDX3 or
> a KDA50 makes no difference to the PDP-11 (pick any other Qbus MSCP
> controller as well if you want to). The controller can call itself
> whatever. It still works the same from the software point of view.
>
>
> I don't recall offhand if there's a bit specifying whether MSCP BBR is host-
> initiated or controller initiated, or if the port driver bases that
> decision on
> controller models it knows about.

I don't think there is any information about that at all. It's just that
a controller that handles it on its own will never report bad blocks
that need replacing. But I could be remembering wrong.
But essentially, that means you don't know or have different code. You
just have some handling of reported bad blocks, if you want to, or just
report, ignore and continue if not. The 2.11BSD driver for example does
not handle bad block replacement.

> I really should do a test SIMH build that "takes off the guardrails" and
> lets you do things like put a KDB50 on a Q-bus system, as well as allow-
> ing arbitrary device type and media names, and see what goes "kaboom".

Again. How do you even know if it's a KDB50? And a KDB50 would be
something you connect to VAXBI, so I don't think it uses a structure in
memory that looks the same as for Qbus controllers. But the identity
bytes reported by the controller are not used by the drivers for
anything. At least not in RSX, and from what I gathered from Paul K.
RSTS/E don't either. Even though RSTS/E sometimes is a bit more picky/weird.

> The disks obviously don't care what bus your system have.
>
>
> To a great extent, true for MSCP. But an RD54 appears as a DU-class de-
> vice even though its physical interface is ST506. The same is true of the
> early CD-ROM devices which use the LSMI interface. But certainly any
> combination of real-world disk + controller that speaks MSCP is going
> to look pretty much the same to the host OS. And I doubt a host OS is
> going to go out of its way to check for impossible combinations and re-
> ject them.

Again. The disk don't care. Yes, an RD54 have a ST506 interface. Talking
to an RQDX3. But the disk don't know what an RQDX3 is even. It just
talks ST506, no matter what you connect it to.
And from the PDP-11 point of view, accessing an RD54 via an RQDX3 or an
RA73 via a KDA50 works exactly the same. And if you access that same
RA73 via an UDA50 on a Unibus machine is no different from the disk
point of view.

And there are no "impossible" combinations. The PDP-11 might query the
controller for an identity of a disk. But that is just a string, and
there are no strings that are "impossible". You can have a disk or
controller that says anything, and it's fine. It's just a string with no
actual meaning to the system. It only have some kind of meaning to humans.

> > Or, even odder, a case of an 18-bit Unibus controller sitting on
> a 22-bit
> > Q-bus. I doubt [m]any PDP-11 operating systems would know to allo-
> > cate a bounce buffer in low memory for the case of an 11/73 witha
> > RK611 controller. Of course, being an emulator it can just say "it's
> > magic". RSTS/E does have some sanity checks, mostly for J11 quirks
> > but there's some for an ENABLE/34 (I think that's what it was
> called).
>
> Note that an RK611 is not an MSCP controller by any definition, and
> thus
> is something completely different and irrelevant here.
> It's MSCP where disk "names" are just meaningless strings. Disk types
> for other controllers are a different story.
>
>
> I was just trying (badly, apparently 8-) to say that SIMH goes out of
> its way
> to support some impossible bus/controller combinations while being
> picky about drive model names in MSCP.

Ok. That is true. However, it certainly did happen that people put an
RK611 on a Qbus system via a bus adapter from Qbus to Unibus. So it's
less impossible than one might first think.

> I do remember a not-too-ancient heated debate about whether it made
> sense for SIMH to separately report the UDA50 vs. the UDA50A, even
> though to SIMH it was just a change in the model number byte. "Why do
> you want that?" "Well, it's two different variants of a real
> controller!". SIMH
> has the luxury of going (as my cat would say) "Feh!", whereas commercial
> emulators have to implement what customers want, or they aren't buying,
> even if the VMS device is connected to something utterly different in the
> host. I helped getting FDDI added to AlphaVM because without FDDI in the
> emulated system it was "no sale".

Unless you want to emulate some internal bugs and so on, there is no
real point in having both the UDA50 and UDA50A. But I don't see any
problems allowing you to set the actual ID reported by the emulated
controller to anything you can dream of.

> > If we're talking about MSCP or SCSI device identifiers, agreed.
> But the
> > various oddball combinations of hardware are generally allowed.
> In the
> > specific case of an RK611 on an 11/73, if there's more than 18
> bits worth
> > of memory, you get:
>
> Again. This was about MSCP.
>
>
> And again, SIMH allows "impossible in the real world" combinations of hard-
> ware but doesn't let you pick your own MSCP device names. I am expressing
> support for your assertion, please give me a little credit 8-)

:-D

> I was talking about model names. Sorry for using wrong/confusing
> terminology.
>
> The ones you think of as 5 characters are in fact three characters,
> plus
> that number.
>
> Basically, it's all encoded in one 32-bit number (you'll find this if
> you look up the manual). First you have five 5-bit values, which are
> letters. The first two letters are "class" (or something like that),
> followed by up to three letters which is the model name, followed by a
> 7-bit number which gives the whole thing.
>
>
> RAD50? Plus 2 more RAD50 characters and the remaining bits treated as a
> numeric value? I'm surprised DEC was so skimpy on storage for these names,
> particularly when compared to the size of an MSCP packet 8-)

No. It's not Radix50.
The layout is like this:
Five 5-bit values, which are letters. You can have 32 different values
in a 5-bit value. So all letters are possible, but numbers are not.
Then after those five 5-bit letters, you have a 7-bit number.

So an RA81 would be coded like this:

+-----+-----+-----+-----+-----+-------+
|00100|10101|10010|00001|00000|1010001|
+-----+-----+-----+-----+-----+-------+

D U R A _ 81

Basically, 1=A and so on. And the number is just a binary number with
seven bits.

And then you can do that as a 32-bit number, and that's the type ID for
the disk.

> So an RA81 is actually given as "DURA_<81>" (I hope you get the
> notion I
> used here.)
>
> PDP-11 OSes don't care about the "class" name, but VMS makes use ofit,
> which is why the RA60 is DJ: and not DU:
> The full 32-bit value for an RA60 is "DJRA_<60>". (I think it was DJ,
> right?)
>
>
> Yes, for no explicable reason. It can't be removable vs. fixed, since
> the RX50
> floppy and the RC25 cartridge are both DU. Maybe somebody didn't like the
> RA60, or maybe it really did need special handling.

I can't see any reason for that about the RA60. And on any PDP-11 OS,
the RA60 is a DU: device. It's only VMS that decided to go with a
different name for it.

>  What happens if you use one of the unassigned device model bytes? There
> doesn't seem to be much rhyme or reason - we have DU intermingled with
> DI. For that matter, would the encoding of DUESE<20> break if instead it was
> BQTSE<20>? If RA60s are so special that they had to be DJ, what happens
> if a PDP-11 OS driver sees a BQ device type name instead of a DU one?

Nothing strange happens at all. At least not anywhere I've seen, or with
code I've looked at. This information is, in RSX, only used by the error
logger, and the type name is shown when you look at the device as a
user. That's it. The software itself actually only cares about the
reported capacity of the drive, which is independent of the type string.

> Maybe it's all just display fluff and nothing cares.

That is the case. And that is why I think it's silly that simh tries to
make it appear otherwise.

> Certainly the port/
> device

> driver combo can figure out that you can't write to a CD-ROM, presumably
> by looking at other info in the returned device characteristics
> (writable CDs
> didn't appear in VMS until SCSI / IDE models - the earlier ones had no pro-
> vision for writing in hardware).

Right.

> And then we go off into another
> unrelated-to-
> PDP-11 discussion, where the VMS DQDRIVER for IDE CD-ROMs supports
> 2048-byte sectors (because DEC had become such a niche market for op-
> tical drive makers that they were having trouble getting 512-byte support,
> even on SCSI drives. As I recall, DEC had built up a rather large
> inventory of
> 512-byte SCSI CD-ROMS due to "final lifetime buy" notices from manufac-
> turers. I believe Plextor was the last company to introduce a new 512-byte-
> capable SCSI CD-ROM.

DEC wasn't the only one. SUN also required CD roms that did 512 byte
sectors. And many (most?) CD rom drives I've come across will do that
happily, even today. I have a CD-rom hooked up to a PDP-11...
But yes, read only. Writing to CD rom is not something any MSCP SCSI
controller I've seen will know how to do.

> Going off on another tangent, didn't DEC have large (12" before caddy) mag-
> neto-optical drives that were also MSCP on the host side? Presumably they
> needed special handling in the VMS DUDRIVER as well.

Yes. RRV40.
WORM drives, as they were called. If I remember right, they looked more
like tape drives, I think.