7 Jan
2021
7 Jan
'21
6:38 p.m.
Well, with Dave's help we got the DSM-11 disk to boot on SIMH. Oddly
enough SIMH seems to read a raw RQDX1/2 disk pretty well.
sim> attach rq0 dsm.dsk
sim> set cpu 11/73,1m
Disabling RK
Disabling HK
Disabling TM
sim> boot rq0
Booting DSM-11...
DSM-11 Version 3.0A
Now running the baseline system.
<DKHER>:1 G ^STU
Exit
DSM-11 Version 3.0A Device #1 UCI:
Exit
DSM-11 Version 3.0A Device #1 UCI: ?
<NOUCI>:0
Exit
The problem is I don't remember how to use it anymore. Is there a PDF of
the DSM-11 manual anywhere? I think this was a clean install, but I'd
like to check it for data before putting it into archives.
Also which archive would be best for it?
CZ
8 Jan
8 Jan
9:59 a.m.
On Jan 7, 2021, at 9:38 PM, Chris Zach via cctalk
<cctalk at classiccmp.org> wrote:
Well, with Dave's help we got the DSM-11 disk to boot on SIMH. Oddly enough SIMH
seems to read a raw RQDX1/2 disk pretty well.
...
The problem is I don't remember how to use it anymore. Is there a PDF of the DSM-11
manual anywhere? I think this was a clean install, but I'd like to check it for data
before putting it into archives.
Neat.
I know nothing about DSM-11 other than the name, and the fact it was the OS on top of
which ASSIST-11 was implemented.
Some googling turns up this http://www.ps8computing.co.uk/dsm-11.html which is modestly
helpful.
And this: https://kevinmurrell.tripod.com/dsm-11.htm
And this:
http://h30266.www3.hpe.com/MasterIndex/installation_guide/installation_guid…
which suggests that semi-useful manuals might be found in the VMS documentation set,
possibly under the name "Digital Standard M" rather than "...MUMPS".
paul
10:16 a.m.
Any copy of this software available to play with?
Sergio
El vie., 8 ene. 2021 3:38, Chris Zach via cctalk <cctalk at classiccmp.org>
escribi?:
Well, with Dave's help we got the DSM-11 disk to
boot on SIMH. Oddly
enough SIMH seems to read a raw RQDX1/2 disk pretty well.
sim> attach rq0 dsm.dsk
sim> set cpu 11/73,1m
Disabling RK
Disabling HK
Disabling TM
sim> boot rq0
Booting DSM-11...
DSM-11 Version 3.0A
Now running the baseline system.
<DKHER>:1 G ^STU
Exit
DSM-11 Version 3.0A Device #1 UCI:
Exit
DSM-11 Version 3.0A Device #1 UCI: ?
<NOUCI>:0
Exit
The problem is I don't remember how to use it anymore. Is there a PDF of
the DSM-11 manual anywhere? I think this was a clean install, but I'd
like to check it for data before putting it into archives.
Also which archive would be best for it?
CZ
12:48 p.m.
A slightly newer version (3.3) is available from bitsaver.org/bits/DEC/pdp11/dsm-11
<http://bitsaver.org/bits/DEC/pdp11/dsm-11>
John.
On Jan 8, 2021, at 1:16 PM, Sergio Pedraja via cctalk
<cctalk at classiccmp.org> wrote:
Any copy of this software available to play with?
Sergio
El vie., 8 ene. 2021 3:38, Chris Zach via cctalk <cctalk at classiccmp.org>
escribi?:
> Well, with Dave's help we got the DSM-11 disk to boot on SIMH. Oddly
> enough SIMH seems to read a raw RQDX1/2 disk pretty well.
>
> sim> attach rq0 dsm.dsk
> sim> set cpu 11/73,1m
> Disabling RK
> Disabling HK
> Disabling TM
> sim> boot rq0
>
> Booting DSM-11...
>
> DSM-11 Version 3.0A
> Now running the baseline system.
>
> <DKHER>:1 G ^STU
> Exit
>
> DSM-11 Version 3.0A Device #1 UCI:
> Exit
>
> DSM-11 Version 3.0A Device #1 UCI: ?
> <NOUCI>:0
> Exit
>
> The problem is I don't remember how to use it anymore. Is there a PDF of
> the DSM-11 manual anywhere? I think this was a clean install, but I'd
> like to check it for data before putting it into archives.
>
> Also which archive would be best for it?
>
> CZ
>
23 Jan
23 Jan
7:49 a.m.
I have DSM-11 V4.0 (or it may be 4.1?) on a TK50 cartridge somewhere. When I manage to get
my MFM emulator board playing nicely in my 11/83 I could try building a base system for
people to play with.
I looked after eight DSM-11 systems for ten years (3x 11/70, 1x 11/44, 2x 11/84 and an
11/83 - the one I have at home now). I've probably forgotten most of what I knew back
then but I can still find my way around a system. I loved Mumps as a language - breaks
just about every rule of well behaved languages but so powerful with the integrated
database handling.
Martin
-----Original Message-----
From: cctalk <cctalk-bounces at classiccmp.org> On Behalf Of John Forecast via
cctalk
Sent: 08 January 2021 20:48
To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
Subject: Re: Got DSM-11 running, any manuals online?
A slightly newer version (3.3) is available from bitsaver.org/bits/DEC/pdp11/dsm-11
<http://bitsaver.org/bits/DEC/pdp11/dsm-11>
John.
On Jan 8, 2021, at 1:16 PM, Sergio Pedraja via cctalk
<cctalk at classiccmp.org> wrote:
Any copy of this software available to play with?
Sergio
8 Jan
8 Jan
5:19 p.m.
A copy of the disk image is at
https://www.crystel.com/pdp/dsm-11.30.dsk
Feel free to put it on more stable archives. It appears to be a freshly
genned system.
CZ
On 1/8/2021 1:16 PM, Sergio Pedraja wrote:
Any copy of this software available to play with?
Sergio
El vie., 8 ene. 2021 3:38, Chris Zach via cctalk <cctalk at classiccmp.org
<mailto:cctalk at classiccmp.org>> escribi?:
Well, with Dave's help we got the DSM-11 disk to boot on SIMH. Oddly
enough SIMH seems to read a raw RQDX1/2 disk pretty well.
sim> attach rq0 dsm.dsk
sim> set cpu 11/73,1m
Disabling RK
Disabling HK
Disabling TM
sim> boot rq0
Booting DSM-11...
DSM-11 Version 3.0A
Now running the baseline system.
<DKHER>:1 G ^STU
Exit
DSM-11 Version 3.0A Device #1 UCI:
Exit
DSM-11 Version 3.0A Device #1 UCI: ?
<NOUCI>:0
Exit
The problem is I don't remember how to use it anymore. Is there a
PDF of
the DSM-11 manual anywhere? I think this was a clean install, but I'd
like to check it for data before putting it into archives.
Also which archive would be best for it?
CZ
11:57 a.m.
On Thu, Jan 7, 2021 at 7:38 PM Chris Zach via cctalk <cctalk at classiccmp.org>
wrote:
Oddly enough SIMH seems to read a raw RQDX1/2 disk
pretty well.
That's good to know, but not really all that odd. Arguably the main purpose
of MSCP was to abstract away drive and controller differences.
5:16 p.m.
True, however SIMH has to write things to a "real" file that emulates
something of a disk. In this case I'm guessing it writes more as a super
powered RQDX2 in that the first cylinders do not have the disk
parameters and other odd stuff.
Which makes sense as the RQDX1 and 2 are simpler devices than the 3.
But as Dave pointed out, the last track on the disk is probably the bad
block revector table. So no clue as to how the disk remaps bad blocks,
but I don't think any of them were bad.
I'll put the image up on iguana tonight. If it's a blank system then
someone can fiddle around with it a bit.
CZ
On 1/8/2021 2:57 PM, Eric Smith wrote:
On Thu, Jan 7, 2021 at 7:38 PM Chris Zach via cctalk
<cctalk at classiccmp.org <mailto:cctalk at classiccmp.org>> wrote:
Oddly enough SIMH seems to read a raw RQDX1/2 disk pretty well.
That's good to know, but not really all that odd. Arguably the main
purpose of MSCP was to abstract away drive and controller differences.
5:54 p.m.
On Fri, Jan 8, 2021 at 6:16 PM Chris Zach <cz at alembic.crystel.com> wrote:
True, however SIMH has to write things to a
"real" file that emulates
something of a disk.
I thought the SIMH representation of an MSCP disk was just a linear array
of 512-byte blocks, from block 0 to block n-1, in which case, it's still
not at all surprising that any RQDXn, or any other MSCP disk with the
standard Unibus/Qbus MSCP port interface would "just work".
If I'm wrong about how the disk is represented by SIMH, then maybe it could
be more surprising.
6:29 p.m.
If so, then that's probably what the RQDX1/2 format *was*: Just a big
bunch of 512 byte blocks, starting at zero and going up to the top.
The controller had to know the geometry of the drive in order to move
the heads, know how many cylinders there were, etc. One thing I did
notice is the last cylinder of the disk is not formatted like the others
and throws a bunch of errors on the MFM_READ command on all tracks. It's
possible that the controller checks there first, then consults the ROM
based lookup tables to get the proper disk geometry. Which explains why
some controllers supported RD51,52 and later ones supported the 53 but
none supported the 54.
On the RQDX3 formatted disks, the first few tracks are also in a weird
format, it's possible that is where the controller stores the
head/cyl/sector format information. Note that a RQDX3 disk image does
not seem to be able to connect up to the RQ driver like the RQDX2 one.
Interesting stuff. I'm guessing if you remove the first couple of tracks
from the file one could then read the rest of the disk
on SIMH (as the
rest is probably just a big pile of blocks and that's all that
matters
to SIMH) unless there are remapped sectors in which case I have no idea
how those would work.
Fun stuff.
C
On 1/8/2021 8:54 PM, Eric Smith via cctalk wrote:
On Fri, Jan 8, 2021 at 6:16 PM Chris Zach <cz at
alembic.crystel.com> wrote:
True, however SIMH has to write things to a
"real" file that emulates
something of a disk.
I thought the SIMH representation of an MSCP disk was just a linear array
of 512-byte blocks, from block 0 to block n-1, in which case, it's still
not at all surprising that any RQDXn, or any other MSCP disk with the
standard Unibus/Qbus MSCP port interface would "just work".
If I'm wrong about how the disk is represented by SIMH, then maybe it could
be more surprising.
9 Jan
9 Jan
11:08 a.m.
To possibly be clearer the image of the disk was a raw dump of the disk
taken with the mfm emulator/reader board so it sees all the extra data the
controller puts on the disk and the bad sectors etc. As far as I know no
documentation exists of the low level format and revector table etc. For
RQDX3 the controller has extra information at the beginning of the disk so
mounting the raw image under SIMH doesn't work. The RQDX2 apperently puts its
information at the end. Might be possible to reverse engineer the format
if we get sector dump from the host to compare to the raw disk dump. Nobody
has decided to tackle that.
For the dump of my RD53 on Vaxstation RQDX3 head 0 sectors 0-2 are normal,
3-16 are funny format. Head 1 and 2 are all funny format. Head 3 sectors
0-2 are funny format. Removing those didn't work for me if I got my
dd commands correct.
On Fri, Jan 08, 2021 at 09:29:19PM -0500, Chris Zach wrote:
If so, then that's probably what the RQDX1/2
format *was*: Just a big bunch
of 512 byte blocks, starting at zero and going up to the top.
The controller had to know the geometry of the drive in order to move the
heads, know how many cylinders there were, etc. One thing I did notice is
the last cylinder of the disk is not formatted like the others and throws a
bunch of errors on the MFM_READ command on all tracks. It's possible that
the controller checks there first, then consults the ROM based lookup tables
to get the proper disk geometry. Which explains why some controllers
supported RD51,52 and later ones supported the 53 but none supported the 54.
On the RQDX3 formatted disks, the first few tracks are also in a weird
format, it's possible that is where the controller stores the
head/cyl/sector format information. Note that a RQDX3 disk image does not
seem to be able to connect up to the RQ driver like the RQDX2 one.
Interesting stuff. I'm guessing if you remove the first couple of tracks
from the file one could then read the rest of the disk on SIMH (as the rest
is probably just a big pile of blocks and that's all that matters to SIMH)
unless there are remapped sectors in which case I have no idea how those
would work.
Fun stuff.
C
On 1/8/2021 8:54 PM, Eric Smith via cctalk wrote:
On Fri, Jan 8, 2021 at 6:16 PM Chris Zach <cz
at alembic.crystel.com> wrote:
------------------------------ True, however SIMH has to write things to a
"real" file that emulates
something of a disk.
I thought the SIMH representation of an MSCP disk was just a linear array
of 512-byte blocks, from block 0 to block n-1, in which case, it's still
not at all surprising that any RQDXn, or any other MSCP disk with the
standard Unibus/Qbus MSCP port interface would "just work".
If I'm wrong about how the disk is represented by SIMH, then maybe it could
be more surprising.
12:06 p.m.
On Sat, Jan 9, 2021 at 12:08 PM David Gesswein via cctech <
cctech at classiccmp.org> wrote:
To possibly be clearer the image of the disk was a raw
dump of the disk
taken with the mfm emulator/reader board so it sees all the extra data the
controller puts on the disk and the bad sectors etc. As far as I know no
documentation exists of the low level format and revector table etc. For
RQDX3 the controller has extra information at the beginning of the disk so
mounting the raw image under SIMH doesn't work. The RQDX2 apperently puts
its
information at the end. Might be possible to reverse engineer the format
if we get sector dump from the host to compare to the raw disk dump.
Nobody
has decided to tackle that.
For the dump of my RD53 on Vaxstation RQDX3 head 0 sectors 0-2 are normal,
3-16 are funny format. Head 1 and 2 are all funny format. Head 3 sectors
0-2 are funny format. Removing those didn't work for me if I got my
dd commands correct.
DEC standard 144 of any help?
http://bitsavers.org/pdf/dec/standards/EL-00144_B_DEC_STD_144_Disk_Standard…
Warner
On Fri, Jan 08, 2021 at 09:29:19PM -0500, Chris Zach wrote:
If so, then
that's probably what the RQDX1/2 format *was*: Just a big
bunch
of 512 byte blocks, starting at zero and going up
to the top.
The controller had to know the geometry of the drive in order to move the
heads, know how many cylinders there were, etc. One thing I did notice is
the last cylinder of the disk is not formatted like the others and
throws a
bunch of errors on the MFM_READ command on all
tracks. It's possible that
the controller checks there first, then consults the ROM based lookup
tables
to get the proper disk geometry. Which explains
why some controllers
supported RD51,52 and later ones supported the 53 but none supported the
54.
On the RQDX3 formatted disks, the first few tracks are also in a weird
format, it's possible that is where the controller stores the
head/cyl/sector format information. Note that a RQDX3 disk image does not
seem to be able to connect up to the RQ driver like the RQDX2 one.
Interesting stuff. I'm guessing if you remove the first couple of tracks
from the file one could then read the rest of the disk on SIMH (as the
rest
is probably just a big pile of blocks and
that's all that matters to
SIMH)
unless there are remapped sectors in which case I
have no idea how those
would work.
Fun stuff.
C
On 1/8/2021 8:54 PM, Eric Smith via cctalk wrote:
> On Fri, Jan 8, 2021 at 6:16 PM Chris Zach <cz at alembic.crystel.com>
wrote:
>
> > True, however SIMH has to write things to a "real" file that
emulates
> > something of a disk.
> >
>
> I thought the SIMH representation of an MSCP disk was just a linear
array
> of 512-byte blocks, from block 0 to block
n-1, in which case, it's
still
> not at all surprising that any RQDXn, or any
other MSCP disk with the
> standard Unibus/Qbus MSCP port interface would "just work".
>
> If I'm wrong about how the disk is represented by SIMH, then maybe it
could
be more
surprising.
------------------------------
1:55 p.m.
On Sat, Jan 09, 2021 at 01:06:19PM -0700, Warner Losh wrote:
DEC standard 144 of any help?
http://bitsavers.org/pdf/dec/standards/EL-00144_B_DEC_STD_144_Disk_Standard…
Warner
Thanks for looking.
That standard is only capable of marking bad sectors. It doesn't have the
information on where the bad sectors were remapped to. I took a quick look
at the DSM image. It looks like cylinder 511 is where the controller
tables are. This cylinder does have a different format. The data didn't
match this standard.
2:59 p.m.
On Sat, Jan 9, 2021, 2:55 PM David Gesswein <djg at pdp8online.com> wrote:
On Sat, Jan 09, 2021 at 01:06:19PM -0700, Warner Losh
wrote:
The rainbow has a different way to mark this stuff. Maybe there is some
reuse in it? See "on disk format" in
http://www.bitsavers.org/pdf/dec/rainbow/ms-dos/QV068-GZ_Rainbow_MS-DOS_V2.…
which seemed oddly complex for such an early standard. It talks about N
spare tracks that remapped sectors land in... I've never had a disk image
that uses them though... worth a shot in the absence of other data...
Warner
DEC standard 144 of any help?
http://bitsavers.org/pdf/dec/standards/EL-00144_B_DEC_STD_144_Disk_Standard…
Warner
Thanks for looking.
That standard is only capable of marking bad sectors. It doesn't have the
information on where the bad sectors were remapped to. I took a quick look
at the DSM image. It looks like cylinder 511 is where the controller
tables are. This cylinder does have a different format. The data didn't
match this standard.
11 Jan
11 Jan
6:21 a.m.
On Jan 9, 2021, at 4:55 PM, David Gesswein via cctalk
<cctalk at classiccmp.org> wrote:
On Sat, Jan 09, 2021 at 01:06:19PM -0700, Warner Losh wrote:
DEC Std 144 is for older disks, not MSCP. It is the format for telling the OS where the
bad sectors are, so the file system creation tool can mark those sectors as unavailable.
That doesn't involve remapping (at least not on the OS I know). The bad sectors still
exist in the address space, they are just not free so they won't be used.
The MSCP revectoring is a more complex mechanism where the controller tweaks the logical
block numbering address space so it appears to be error-free. I assume it's a
generalization of the spare-sector feature of the RM80, but as others have pointed out,
with MSCP this was an internal matter of the controller and I don't know of any DEC
standard for it. In fact, the details are likely to depend on the properties of
individual drives.
paul
DEC standard 144 of any help?
http://bitsavers.org/pdf/dec/standards/EL-00144_B_DEC_STD_144_Disk_Standard…
Warner
Thanks for looking.
That standard is only capable of marking bad sectors. It doesn't have the
information on where the bad sectors were remapped to. I took a quick look
at the DSM image. It looks like cylinder 511 is where the controller
tables are. This cylinder does have a different format. The data didn't
match this standard.
8 Jan
8 Jan
5:17 p.m.
On Jan 8, 2021, at 2:57 PM, Eric Smith via cctalk
<cctalk at classiccmp.org> wrote:
On Thu, Jan 7, 2021 at 7:38 PM Chris Zach via cctalk <cctalk at classiccmp.org>
wrote:
Yes, but also to hide bad blocks. So the difference between a raw sector dump and a SIMH
container file is, minimally, the spare sectors. What that looks like depends on the
format; I have no idea what MSCP controllers did.
paul
Oddly enough SIMH seems to read a raw RQDX1/2
disk pretty well.
That's good to know, but not really all that odd. Arguably the main purpose
of MSCP was to abstract away drive and controller differences.
5:57 p.m.
On Fri, Jan 8, 2021 at 6:17 PM Paul Koning <paulkoning at comcast.net> wrote:
Yes, but also to hide bad blocks. So the difference
between a raw sector
dump and a SIMH container file is, minimally, the spare sectors. What that
looks like depends on the format; I have no idea what MSCP controllers did.
MSCP controllers do the bad block mapping, so AFAIK the disk _always_ looks
to the host like a linear array 0..n-1 of 512-byte blocks.
When accessing an MSCP disk, the host should not, unless running special
diagnostics, be able to distinguish what kind of disk is in use, aside from
that it has a particular block count.
9 Jan
9 Jan
10:10 a.m.
On Jan 8, 2021, at 8:57 PM, Eric Smith via cctalk
<cctalk at classiccmp.org> wrote:
On Fri, Jan 8, 2021 at 6:17 PM Paul Koning <paulkoning at comcast.net> wrote:
Yes. But perhaps I misunderstood; I thought the note to which I was replying described
taking a raw dump of the disk itself, not a logical copy via the MSCP controller.
paul
Yes, but also to hide bad blocks. So the
difference between a raw sector
dump and a SIMH container file is, minimally, the spare sectors. What that
looks like depends on the format; I have no idea what MSCP controllers did.
MSCP controllers do the bad block mapping, so AFAIK the disk _always_ looks
to the host like a linear array 0..n-1 of 512-byte blocks.
1390
days inactive
1405
days old
17 comments
8 participants
participants (8)
-
cz＠alembic.crystel.com -
djg＠pdp8online.com -
imp＠bsdimp.com -
john＠forecast.name -
mcr＠martin-reilly.com -
paulkoning＠comcast.net -
spacewar＠gmail.com -
spedraja＠gmail.com