date:20190220


On 2/20/19 12:23 PM, Paul Koning via cctalk wrote:
Please note that among LANs, there is Token Ring (802.5) and there is 
everything else.


I think it really depends on how you look at them.

From a frame formatting point of view, Ethernet is the odd ball when 
looking at how TCP/IP is carried.


Everything other than Ethernet (802.3) uses 802.2 or a medium specific 
varient of 802.2.  Then there's Ethernet which predominantly uses either 
Ethernet II for TCP/IP or 802.3 (a.k.a. "Raw") Ethernet frames for IPX.


FDDI is like Ethernet and like 802.4.  Token Ring is the oddball because 
(a) it doesn't have proper multicast addresses, and (b) for some reason 
IBM invented source-routed bridging and tied that to Token Ring.


Does it actually need a broadcast address like Ethernet when the ring 
passes through all the stations?  Or is that functionally comparable to 
a multicast?


FDDI is in no way at all like Token Ring.  The only thing the two have 
in common is "token" and "ring".  The MAC protocol is utterly different; 
the closest relative is 802.4 Token Bus.  And as far as addressing is 
concerned, FDDI is like 802.4 and Ethernet, with real multicast and 
general use of normal transparent bridges.


The only complication with FDDI (and 802.4, if you could find it) 
is that it only has 802.2 frames, not classic-Ethernet (with 16 bit 
protocol types).  So an FDDI to Ethernet bridge has to translate Ethernet 
frames to an 802.2 based encapsulation.  That is done by converting them 
to SNAP frames, as described in RFC 1042.


Intriguing.

$ReadingList++

Bridges like the DECbridge 500 and DECbridge 900 will do that; I assume 
Cisco does likewise.


FDDI didn't live all that long because 100 Mb Ethernet replaced it, but 
while it was out there it made a fine backbone for Ethernet-based LANs.


:-)



--
Grant. . . .
unix || die

Re: IBM 3174 C 6.4 Microcode Disks?


On 2/20/19 12:13 PM, Ken Seefried via cctalk wrote:

re: Cisco and IBM protocols

If you're really interested, all of this is exhaustively documented 
under the umbrella of Cisco's "IBM Feature Set".


Thank you Ken.  That's the type of information I'm wanting to figure out.

There's a *lot* here under the hood, but the last time I looked 
(admittedly, a while) a number of folks had web sites that documented 
the correct incantations for Hercules and common hardware.


You can bridge between TR (and FDDI) and ethernet on a Cisco, generally 
for non-routable protocols (e.g. NetBIOS); see: 'translational bridging'.


That meshes with what I think I've managed to figure out.

Both SNA and NetBIOS use 802.2 LLC frames with SNAP headers.  Token Ring 
and Ethernet are able to carry that without any problem.  Hence why they 
can be relatively bridged bridged without extensively modifying the frames.


If you're trying to get these protocols across an intermediary 'alien' 
network (like the corp FDDI backbone, or the Internet), there are things 
like DLSw.


I learned that while reading this week.  Now I want to see if DLSw can 
be used to connect two Windows machines using NetBIOS across an 
intermediary 'alien' network running TCP/IP.  }:-)


If you're trying to get TCP/IP from TR to ethernet and vice versa, 
routing generally works better/is simpler (IME),


ACK  Bridging between TCP/IP on 802.2 LLC frames with SNAP on Token Ring 
to Ethernet II frames on Ethernet is not nearly as simple.  Especially 
when routing inherently handles it.  Even Proxy ARP is a form of routing.


but Cisco has all sorts of bizarre encapsulation/translation features 
for different use cases should you need them.


*nod*

I'm sure I'll find more information than is healthy for me to learn.


You can also make the router look like an SNA concentrator (PU?).


~whimper~  I don't need to think about that.

I'd love to get a pair of mainframe (VMs?) running in a (non-Parallel) 
sysplex between a couple of Hercules instances.  The idea of using a 
router as an SNA PU is … intriguing.




--
Grant. . . .
unix || die

Re: IBM 3174 C 6.4 Microcode Disks?


On 2/20/19 4:24 PM, Kevin Monceaux via cctalk wrote:
I have the 2513 now.  I'm new to Cisco router commands and configuration. 
If you could give me a crash course on the commands that would display the 
parts of the configuration that would settle things for your curiosity, 
I'll see what it has.


Cool.

I've replied directly.  I have no idea how complex this will get, 
especially if we have to bypass the password, and don't want to get even 
further into the weeds.


I look forward to seeing what we can find out.



--
Grant. . . .
unix || die

Re: IBM 3174 C 6.4 Microcode Disks?

On 2/18/19 1:20 AM, Dave Wade via cctalk wrote:
So the 3174 does not do this. 3270 terminals don't talk SNA/3270 to the
3174 as defined in the IBM 3270 data streams. They are usually pretty dumb
and from what I can gather all keystrokes go to the 3174 just as for an
ASCII terminal. It only becomes a 3270 protocol when it exits the 3174.

Okay.

So I misunderstood ~> misspoke about the protocol on the coax side of
the 3174.

You get dumb terminals, either ASCII or 3270 Screens in, and at the
other side you connect 3270 over SNA/SDLC, SNA/Token Ring, BiSync,
X.25 or whatever.

But it sounds like the 3174 is functioning as an application layer
gateway in some capacity in that it translates from one thing / protocol
to another.

That’s exactly what a 3174 does. IBM calls it a Terminal Controller.

ACK

I think there is, but to me a gateway has LAN protocols on both sides.

Ah.

To me, a "gateway" can be network layer, application layer, or do other
things.

I'll give you that a "gateway", as in a network layer gateway or router,
does have network protocols that it routes / bridges between. (They may
be on a single interface, a la one-armed-router.)

The 3174 NEVER accepts any sort of incoming connections. Just physical
terminals.

Um … what do you consider the connections from remote 3174s (physically
/ logically) connecting to a local 3174 via Token Ring / Ethernet / SDLC
to be if not connections to the local 3174?

I'm using IBM's definition for "local" and "remote" in this context.

I can see some wiggle room for the connections from the remote 3174
being to the mainframe via the local 3174 and not actually to the local
3174.

That being said I still think that the 3270 connection from the RS/6000
are addressed /to/ the local 3174's Token Ring (MAC) address. Or is
this the above wiggle room too?

When used to connect network traffic to a mainframe the 3174 does not
terminate the TCPIP connection., it passes the frames across to the
channel. I may be wrong its been a long time since I did this and I
don't want to go delving into the VTAM documentation.

The reading that I've done since the start of this thread makes me think
that the connections from the RS/6000 would be SNA over Token Ring. As
I understand it, this means that they are 802.2 LLC SNAP frames carrying
something other than TCP/IP.

Perhaps the 3174 is receiving those frames and passing them on to the
mainframe via some form of routing or bridging.

Or perhaps the 3174 is extracting the SNA data off of the Token Ring
frames and passing just the SNA application layer data to the mainframe.

I suspect that VTAM documentation is in my future if I truly want to
understand this. Or maybe I'll get lucky and someone can answer my
pointed questions.

Its kind of odd. RS232 (so X.25/SDLC/HDLC/Bi-Sync) connections can only
be used to connect to a Mainframe, not another 3174.

That's contrary to what I have been reading this week.

Based on the reading that I've done (I can dig for sources if you want
me to), a remote 3174 can connect to a local 3174 via Token Ring /
Ethernet / SDLC.

This implies that the remote 3174 is connecting to another 3174. (See
additional comments below.)

The Token Ring or Ethernet interface can be used to connect traffic to
the mainframe But from what I remember the 3174 isn't too involved at
this level it is acting as a network router/bridge.

"too involved" is critical.

Just to confuse things this is an IBM manual where IBM does use it as a
"gateway"...

~chuckle~ Very little about IBM is simple.

http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/lan/GG24-3366-0_3174_Remote_Token-Ring_Gateway_Feb89.pdf

I have seen virtually identical diagrams to the one on page 15 where the
NCP was a local 3174 instead of the 3720 / 3725 / 3745.

Notice how the listed 3174 sub models are all the remote variety.

Take a look at page 54 of the following pdf.

http://www.bitsavers.org/pdf/ibm/3174/GG24-4172-0_Using_3174_in_TCP_IP_Networks_Jun94.pdf

The downstream 3174-13R can talk to either the upstream 3174-11L or the
3172.

Figure 244 on page 259 shows the same.

so using the Token Ring interface on a remote 3174 to connect SNA traffic
to the host via SDLC ... again no TCPIP, working at the frame level,
and the host end cannot be a 3174...

Figure 244 on page 259 tends to refute that.

This document seems to be from 94 verses the document you linked to
seeming to be from 89. Maybe things changed in the intervening years.

That really muddies the waters because it uses the term "3270" connection
in two senses. It uses it to refer to the co-ax type connection from
a work station (CUT or DFT) with with 3270 over Channel/SNA as defined
in the 3270 data streams manual and these really are different protocols.

I agree to your prior comment that this traffic between the terminals
and the 3174 terminal controller is not 3270.

That’s where you are going

Re: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info?

2019-02-20 Thread Fred Cisin via cctalk


> Ability to read MFM data with FM headers (RX50)



On 2/20/19 3:40 PM, Warner Losh wrote:

The RX50's are MFM encoded. There's no FM anything on it, unless it's
that way on all MFM diskettes.
Other DEC diskettes may have done this, but RX50's are just higher track
density, but old pre IBM-AT data encoding rate diskettes.
At least on the Rainbow the floppy chip is kept in MFM mode all the
time, unless you've written something to hack it to read alien disks.


On Wed, 20 Feb 2019, Chuck Guzis via cctalk wrote:

You're quite correct--I didn't notice the "RX50" until I'd posted.  No,
I was thinking (as probably was the OP) of RX02 double-density.


That was my mistake.  I wrote RX50, but I meant RX02.
And, as Chuck pointed out, the MFM data within the sectors is not quite 
the same as the MFM encoding used by others.


Sorry about that.

Re: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info?

2019-02-20 Thread Chuck Guzis via cctalk

On 2/20/19 3:40 PM, Warner Losh wrote:

> The RX50's are MFM encoded. There's no FM anything on it, unless it's
> that way on all MFM diskettes.
> 
> Other DEC diskettes may have done this, but RX50's are just higher track
> density, but old pre IBM-AT data encoding rate diskettes.
> 
> At least on the Rainbow the floppy chip is kept in MFM mode all the
> time, unless you've written something to hack it to read alien disks.

You're quite correct--I didn't notice the "RX50" until I'd posted.  No,
I was thinking (as probably was the OP) of RX02 double-density.

--Chuck

VCF Midwest 14: Date Announcement

2019-02-20 Thread Jason T via cctalk

Hello everyone - since people have already been asking (we even had
someone call the hotel to try to register - that's some refreshing
pro-activeness), we can confirm the date of this year's Vintage
Computer Festival Midwest will be:

September 14-15, 2019

2019 will bring a NEW LOCATION which will be announced in the coming
weeks.  So don't call the old hotel - they're already sad that they
lost us*.

Updates will be posted first to our site at http://vcfmw.org, as well
as our mailing list, which you can join there.

Thanks to all who have attended in the past and are considering it
this year.  This one will be something special**, for sure.

-jht

* Nothing wrong with the old place - we just outgrew it!
** Note that that is a measure of magnitude, not direction.

TI Explorer Lisp machine tapes

2019-02-20 Thread Al Kossow via cctalk



http://bitsavers.org/bits/TI/Explorer/cartridge_tapes

the 2.6.0 diag 6.0 bootable and 6.0 patches are probably the most interesting

has there been ANY posts about the Explorer simulator in the last decade?

I've also not verified any of them are what the label says

I ran into a couple that were overwritten. Some I know are correct, because
there were multiple copies.

Re: IBM 3174 C 6.4 Microcode Disks?

2019-02-20 Thread Sean Conner via cctalk

It was thus said that the Great Kevin Monceaux via cctalk once stated:
> Grant,
> 
> On Sat, Feb 16, 2019 at 07:36:11PM -0700, Grant Taylor via cctalk wrote:
>  
> > If the 2513 you have is the one that was used for this, I'd love to see 
> > the config, if it's still on there.  That would very likely settle 
> > things for my curiosity.
> 
> I have the 2513 now.  I'm new to Cisco router commands and configuration.
> If you could give me a crash course on the commands that would display the
> parts of the configuration that would settle things for your curiosity, I'll
> see what it has.

  The Cisco "command line" is quite nice and will always show you what it's
expecting next when you press '?' at any point.  If I recall correctly,
"show config" will show the current saved configuration to the screen, and
"show running-config" will show the currently running configuration (it will
be different if you've made changes without saving them).  You don't even
need to type out the whole thing---just enough to disambiguate the command
(I think 'sh conf" is enough, maybe even "sh c").

  -spc

Re: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info?

2019-02-20 Thread Warner Losh via cctalk

On Tue, Feb 19, 2019 at 3:38 PM Chuck Guzis via cctalk <
cctalk@classiccmp.org> wrote:

> On 2/19/19 2:02 PM, Fred Cisin via cctalk wrote:
>
> > Ability to read MFM data with FM headers (RX50)
>
> It's not that simple.  There's the matter of "DEC MFM" which encodes a
> few bit patterns differently to avoid collision with FM headers.
>

The RX50's are MFM encoded. There's no FM anything on it, unless it's that
way on all MFM diskettes.

Other DEC diskettes may have done this, but RX50's are just higher track
density, but old pre IBM-AT data encoding rate diskettes.

At least on the Rainbow the floppy chip is kept in MFM mode all the time,
unless you've written something to hack it to read alien disks.

Warner

Re: IBM 3174 C 6.4 Microcode Disks?

2019-02-20 Thread Kevin Monceaux via cctalk

Grant,

On Sat, Feb 16, 2019 at 07:36:11PM -0700, Grant Taylor via cctalk wrote:

> If the 2513 you have is the one that was used for this, I'd love to see 
> the config, if it's still on there.  That would very likely settle 
> things for my curiosity.

I have the 2513 now.  I'm new to Cisco router commands and configuration.
If you could give me a crash course on the commands that would display the
parts of the configuration that would settle things for your curiosity, I'll
see what it has.

-- 

Kevin
http://www.RawFedDogs.net
http://www.Lassie.xyz
http://www.WacoAgilityGroup.org
Bruceville, TX

What's the definition of a legacy system? One that works!
Errare humanum est, ignoscere caninum.

Re: OT: Phone museum seeks new owner

2019-02-20 Thread ben via cctalk


On 2/19/2019 2:14 PM, geneb via cctalk wrote:

This message brought to you by the Totalitarian Touch Tone Terrorists(tm).
g.

How ever SMART PHONES have taken OVER. AI's rule the world. Evil 
computer laugh!

Re: IBM 3174 C 6.4 Microcode Disks?

2019-02-20 Thread William Donzelli via cctalk

> FDDI didn't live all that long because 100 Mb Ethernet replaced it, but while 
> it was out there it made a fine backbone for Ethernet-based LANs.

And a good sized chunk of the Internet ran over it for a good long while.

Also pretty bullet proof.

--
Will

Re: IBM 3174 C 6.4 Microcode Disks?

2019-02-20 Thread Ken Seefried via cctalk

On Wed, Feb 20, 2019 at 2:23 PM Paul Koning  wrote:
>
>
>
> > On Feb 20, 2019, at 2:13 PM, Ken Seefried via cctalk 
> >  wrote:
> >
> > ...
> > You can bridge between TR (and FDDI) and ethernet on a Cisco,
> > generally for non-routable protocols (e.g. NetBIOS); see:
> > 'translational bridging'.  If you're trying to get these protocols
> > across an intermediary 'alien' network (like the corp FDDI backbone,
> > or the Internet), there are things like DLSw.
>
> Please note that among LANs, there is Token Ring (802.5) and there is 
> everything else.  FDDI is like Ethernet and like 802.4.  Token Ring is the 
> oddball because (a) it doesn't have proper multicast addresses, and (b) for 
> some reason IBM invented source-routed bridging and tied that to Token Ring.
>
> FDDI is in no way at all like Token Ring.  The only thing the two have in 
> common is "token" and "ring".  The MAC protocol is utterly different; the 
> closest relative is 802.4 Token Bus.  And as far as addressing is concerned, 
> FDDI is like 802.4 and Ethernet, with real multicast and general use of 
> normal transparent bridges.
>

I didn't say TR was like FDDI.  I said you could bridge FDDI to
Ethernet using translation bridging.

Re: PDP-11 disk image question

2019-02-20 Thread Jerry Weiss via cctalk


On 2/20/19 1:25 PM, Glen Slick via cctalk wrote:

On Mon, Feb 18, 2019 at 2:24 PM Bill Gunshannon via cctalk
 wrote:

Theoretically, the SIMH emulated RA81 and the CMD emulated real
disk RA81 should be the same size because they are both supposed
to be RA81's.

I spent the time to get set up and verified that this assumption is
not correct. The CMD CQD MSCP SCSI controller firmware RA device type
feature appears to only change the reported MSCP media name string,
and has no effect on the reported MSCP size and geometry information.

I tried this on a CMD CQD-420/TM with firmware version (REV. B2L-00).
As far as I know the CQD-420 and the CQD-220A (but not the original
CQD-220) are almost identical. I used an IBM DDRS-39130D hard drive
with a 68-pin / 50-pin adapter. The DDRS-39130D is a native 9GB drive.
I used sg3-utils / sg_format to soft resize the drive to exactly 2GB
in capacity, 2,147,483,648 bytes, 4,194,304 blocks.

..
Paul K's explanation and Glen's example matches my own experience in 
this area. I don't have a CMD controller, but I move images between SIMH 
and both Emulex UC07 and Dilog SQ706A MSCP/SCSI Controllers. I've used 
RT11, XXDP, RSX11M+ and VAX VMS on both physical hard drives and SCSI2SD 
emulated disks.


The physical SCSI drives I use have SCSI reassign capability. This 
allows the controller/drive to manage media defects.  This is 
transparent to any of the OS'es. The controller presents the disk simply 
as a continuous logical disk of disk blocks and the geometry has no 
effect.    Space reserved for bad block replacement is not visible to 
the OS.


I make sure the number of logical blocks is maintained exactly as I move 
the images back and forth between SIMH and physical Machines. The disk 
type RA90, RA81, etc never makes a difference.  The MSCP controllers 
read the media size directly and report the disk logical capacity to VMS 
Drivers.


If I move an VMS ODS-2 SIMH disk image to a larger SCSI disk drive then 
problems will occur.  For ODS type volumes, my understanding is that 
bitmap.sys file won't have room to manage the extra space.   I also try 
to avoid edge cases for disk sizing that involve powers of two - e.g. 
2**32.   In my general experience, I have found boundary check problems 
in different situations (especially non-Digital).



Disk NASTY$DKA100:, device type DEC RA92, is online, mounted, file-oriented
    device, shareable, error logging is enabled.

    Error count    0    Operations 
completed   2653
    Owner process ""    Owner UIC  
[SYSTEM]

    Owner process ID        Dev Prot S:RWPL,O:RWPL,G:R,W
    Reference count   48    Default buffer 
size 512
    Total blocks 7603200    Sectors per 
track    63
    Total cylinders  474    Tracks per 
cylinder 255


    Volume label  "VAXVMS73"    Relative volume 
number    0
    Cluster size   9    Transaction 
count   155
    Free blocks  3072564    Maximum files 
allowed    419336
    Extend quantity    5    Mount 
count   1

    Mount status  System    Cache name "_NASTY$DKA100:XQPCACHE"
    Extent cache size 64    Maximum blocks in extent 
cache   307256
    File ID cache size    64    Blocks currently in extent 
cache 307161
    Quota cache size   0    Maximum buffers in FCP 
cache    557
    Volume owner UIC    [SYSTEM]    Vol Prot 
S:RWCD,O:RWCD,G:RWCD,W:RWCD


  Volume Status:  ODS-2, subject to mount verification, protected 
subsystems

  enabled, file high-water marking, write-through caching enabled.


I don't see a discrepancy on SCSI2SD V5 cards between configuration size 
and VMS reported block,  The size used is recorded on the SCSI2SD V5 
card.  The SCSI2SD V6 adapters store the drive configuration on the last 
block of the microSD and I believe reported capacity is reduced by 1.   
Perhaps the CMD is doing similar to allow the media to be interchanged 
between controllers.


  Jerry

Re: PDP-11 disk image question

2019-02-20 Thread Glen Slick via cctalk

On Mon, Feb 18, 2019 at 2:24 PM Bill Gunshannon via cctalk
 wrote:
>
> Theoretically, the SIMH emulated RA81 and the CMD emulated real
> disk RA81 should be the same size because they are both supposed
> to be RA81's.

I spent the time to get set up and verified that this assumption is
not correct. The CMD CQD MSCP SCSI controller firmware RA device type
feature appears to only change the reported MSCP media name string,
and has no effect on the reported MSCP size and geometry information.

I tried this on a CMD CQD-420/TM with firmware version (REV. B2L-00).
As far as I know the CQD-420 and the CQD-220A (but not the original
CQD-220) are almost identical. I used an IBM DDRS-39130D hard drive
with a 68-pin / 50-pin adapter. The DDRS-39130D is a native 9GB drive.
I used sg3-utils / sg_format to soft resize the drive to exactly 2GB
in capacity, 2,147,483,648 bytes, 4,194,304 blocks.

After using the "Z = Reset Controller" configuration option to reset
the CQD-420/TM firmware to its default state this was the
configuration reported by the firmware:

SCANNING SCSI DEVICES ATTACHED ...

DEV0: DU0  SCSI ID 0  LUN 0  IBM DDRS-39130D DC1B
  Disc ON,Sync ON,PMR ON,WWV OFF,Tag-Q OFF,RCT OFF,RA OFF,
DEV1: DU1  SCSI ID 1  LUN 0  OFFLINE
  Disc ON,Sync ON,PMR ON,WWV OFF,Tag-Q OFF,RCT OFF,RA OFF,
DEV2: DU2  SCSI ID 2  LUN 0  OFFLINE
  Disc ON,Sync ON,PMR ON,WWV OFF,Tag-Q OFF,RCT OFF,RA OFF,
DEV3: DU3  SCSI ID 3  LUN 0  OFFLINE
  Disc ON,Sync ON,PMR ON,WWV OFF,Tag-Q OFF,RCT OFF,RA OFF,
DEV4: MU0  SCSI ID 4  LUN 0  OFFLINE
  Disc ON,Sync ON,3-Density ON,Buffer ON,
DEV5: MU1  SCSI ID 5  LUN 0  OFFLINE
  Disc ON,Sync ON,3-Density ON,Buffer ON,
DEV6: MU2  SCSI ID 6  LUN 0  OFFLINE
  Disc ON,Sync ON,3-Density ON,Buffer ON,
DEV7  SCSI ID 7  HOST ADAPTER, SCSI Reset ON,Density Mode ON,Default Tape OFF,
  Rew/Im OFF,Eject Disk ON,Truncate Size OFF,RCT size= OFF,RA dev= DEF,
  Rsv/Rls Option ON,MSCP credit = 16,sync rate = 04 MB/sec,
  RSX FP OFF,Sel Timeout = 250 ms
  (PMR=Prevent Medium Removal   WWV=Write W/Verify)

Then a KA660 VAX console sees the device like this:

>>>SHOW DEV
UQSSP Disk Controller 0 (772150)
-DUA0 (RA90)

UQSSP Tape Controller 0 (774500)

Then VMS booted on the KA660 VAX sees the device like this:

$ MOUNT /FOREIGN BA215$DUA0:
%MOUNT-I-MOUNTED, OVMSVAXSYS mounted on _BA215$DUA0:
$ SHOW DEVICE /FULL BA215$DUA0:

Disk BA215$DUA0:, device type RA90, is online, allocated, deallocate on
dismount, mounted foreign, file-oriented device, shareable, available to
cluster, error logging is enabled.

Error count0Operations completed  4
Owner process   "SYSTEM"Owner UIC  [SYSTEM]
Owner process ID0214Dev ProtS:RWPL,O:RWPL,G:R,W
Reference count2Default buffer size 512
Total blocks 4194302Sectors per track   217
Total cylinders 1933Tracks per cylinder  10

Volume label"OVMSVAXSYS"Relative volume number0
Cluster size   0Transaction count 1
Free blocks0Maximum files allowed 0
Extend quantity0Mount count   1
Mount status ProcessACP process name ""

  Volume Status:  Unknown ACP type.

One question here is why does VMS see 4194302 blocks when a SCSI Read
Capacity command of the drive reports 4194304 blocks? Is the CMD
CQD-420/TM firmware reserving a block or two?

Anyway, I then tried to recreate the configuration of the original
post as I understand it, partitioning the one physical SCSI drive into
four logical MSCP device units, and turning on the RA81 type feature
for those four MSCP device units.

Note that now DEV0: DU0 through DEV3: DU3 all map the the same SCSI ID
0, they all have the RA feature set to ON, and the RA dev type is set
to 81.

SCANNING SCSI DEVICES ATTACHED ...

DEV0: DU0  SCSI ID 0  LUN 0  IBM DDRS-39130D DC1B
  Disc ON,Sync ON,PMR ON,WWV OFF,Tag-Q OFF,RCT OFF,RA ON,
DEV1: DU1  SCSI ID 0  LUN 0  IBM DDRS-39130D DC1B
  Disc ON,Sync ON,PMR ON,WWV OFF,Tag-Q OFF,RCT OFF,RA ON,
DEV2: DU2  SCSI ID 0  LUN 0  IBM DDRS-39130D DC1B
  Disc ON,Sync ON,PMR ON,WWV OFF,Tag-Q OFF,RCT OFF,RA ON,
DEV3: DU3  SCSI ID 0  LUN 0  IBM DDRS-39130D DC1B
  Disc ON,Sync ON,PMR ON,WWV OFF,Tag-Q OFF,RCT OFF,RA ON,
DEV4: MU0  SCSI ID 4  LUN 0  OFFLINE
  Disc ON,Sync ON,3-Density ON,Buffer ON,
DEV5: MU1  SCSI ID 5  LUN 0  OFFLINE
  Disc ON,Sync ON,3-Density ON,Buffer ON,
DEV6: MU2  SCSI ID 6  LUN 0  OFFLINE
  Disc ON,Sync ON,3-Density ON,Buffer ON,
DEV7  SCSI ID 7  HOST ADAPTER, SCSI Reset ON,Density Mode ON,Default Tape OFF,
  Rew/Im OFF,Eject Disk ON,Truncate Size OFF,RCT size= OFF,RA

Re: IBM 3174 C 6.4 Microcode Disks?

> On Feb 20, 2019, at 2:13 PM, Ken Seefried via cctalk  
> wrote:
> 
> ...
> You can bridge between TR (and FDDI) and ethernet on a Cisco,
> generally for non-routable protocols (e.g. NetBIOS); see:
> 'translational bridging'.  If you're trying to get these protocols
> across an intermediary 'alien' network (like the corp FDDI backbone,
> or the Internet), there are things like DLSw.

Please note that among LANs, there is Token Ring (802.5) and there is 
everything else.  FDDI is like Ethernet and like 802.4.  Token Ring is the 
oddball because (a) it doesn't have proper multicast addresses, and (b) for 
some reason IBM invented source-routed bridging and tied that to Token Ring.  

FDDI is in no way at all like Token Ring.  The only thing the two have in 
common is "token" and "ring".  The MAC protocol is utterly different; the 
closest relative is 802.4 Token Bus.  And as far as addressing is concerned, 
FDDI is like 802.4 and Ethernet, with real multicast and general use of normal 
transparent bridges.

The only complication with FDDI (and 802.4, if you could find it) is that it 
only has 802.2 frames, not classic-Ethernet (with 16 bit protocol types).  So 
an FDDI to Ethernet bridge has to translate Ethernet frames to an 802.2 based 
encapsulation.  That is done by converting them to SNAP frames, as described in 
RFC 1042.  Bridges like the DECbridge 500 and DECbridge 900 will do that; I 
assume Cisco does likewise.

FDDI didn't live all that long because 100 Mb Ethernet replaced it, but while 
it was out there it made a fine backbone for Ethernet-based LANs.

paul

Re: PDP-11 disk image question




> On Feb 20, 2019, at 2:09 PM, Paul Koning via cctalk  
> wrote:
> 
> ...
> No, that's not what the symptoms say.  If you were dealing with geometry 
> confusion, you'd fail much earlier.  For example, if you were to take a RSTS 
> system built on an RP06, and image-copied it to an RM05, it would fit fine 
> (the RM05 is much bigger).  And since the "device cluster size" is 9 for 
> both, 

Typo. 8, not 9.  DCS is a power of 2, the smallest value such that device size 
/ DCS is < 65536.

paul

RE: IBM 3174 C 6.4 Microcode Disks?

2019-02-20 Thread Ken Seefried via cctalk

re: Cisco and IBM protocols

If you're really interested, all of this is exhaustively documented
under the umbrella of Cisco's "IBM Feature Set".  There's a *lot* here
under the hood, but the last time I looked (admittedly, a while) a
number of folks had web sites that documented the correct incantations
for Hercules and common hardware.

You can bridge between TR (and FDDI) and ethernet on a Cisco,
generally for non-routable protocols (e.g. NetBIOS); see:
'translational bridging'.  If you're trying to get these protocols
across an intermediary 'alien' network (like the corp FDDI backbone,
or the Internet), there are things like DLSw.

If you're trying to get TCP/IP from TR to ethernet and vice versa,
routing generally works better/is simpler (IME), but Cisco has all
sorts of bizarre encapsulation/translation features for different use
cases should you need them.

You can also make the router look like an SNA concentrator (PU?).

KJ

Re: PDP-11 disk image question

> On Feb 20, 2019, at 1:43 PM, Charles Anthony via cctalk 
>  wrote:
> 
> On Wed, Feb 20, 2019 at 9:21 AM Glen Slick via cctalk 
> wrote:
> 
>> On Wed, Feb 20, 2019 at 8:57 AM Charles Anthony via cctalk
>>  wrote:
>>> 
>>> However, in the original posters case, the SIMH disk image is being
>> copied
>>> to the RA81 drive without the benefit of the MSCP controller (if I
>>> understand correctly). This would lead to track misalignment and could
>>> result in the observed behavior.
>> 
>> How could you possibly write to a real RA81 drive without going
>> through a real KDA50 or UDA50 MSCP controller? Nothing like that is
>> happening in the original post. Just the disk size was chosen to be
>> that of an RA81, and the issue is to exactly match the emulated disk
>> size to that configured by the hardware, which is an MSCP SCSI
>> controller and drive in this case.
>> 
> 
> 
> Re-reading the original post, it it not clear to me how the disk write was
> accomplished; I am not familiar with the mentioned hardware. If the data
> was written to the RA81 with a controller that correctly did the spare
> sector mapping, then my spare sector hypothesis is wrong.

Your confusion stems from the fact you think of "spare sector" as something 
that is visible.  It is not.  Programs can only deal with program-visible 
properties of devices.  For MSCP disks, which is what we have here, the only 
program visible addressing is LBA addressing.  There IS no geometry from the 
program point of view.  

"spare sectors" are an internal detail in the MSCP controller that allows it to 
deliver an error-free device.  It has no relevance to programmers and it 
probably shouldn't have been mentioned in the documentation in the first place.

> The reported symptoms sound like a disk geometry issue; the data passes
> through several systems on the way to RSTS, and it seems likely to me that
> one of the steps is damaging the data.

No, that's not what the symptoms say.  If you were dealing with geometry 
confusion, you'd fail much earlier.  For example, if you were to take a RSTS 
system built on an RP06, and image-copied it to an RM05, it would fit fine (the 
RM05 is much bigger).  And since the "device cluster size" is 9 for both, the 
file system would even be basically valid (apart probably from a too-small 
storage bitmap, but that wouldn't prevent reading data).

However, the RM05 wouldn't boot at all, because the boot loader has been told 
it's on an RP06 and it would use the RP06 numbers for converting LBA to 
cylinder, track, sector values.  Since the sectors/track differs (22 vs. 32) 
all the boot loader reads would go to the wrong place.  It would be loading 
utter nonsense into memory.

In the original problem, the boot loader worked fine.  It loaded all of INIT 
successfully (because INIT got far enough to discover the disks and attempt to 
find INIT.SYS, and it did so without crashing).  You wouldn't get anywhere 
close to that point if you had a geometry issue.

paul

Re: OT: Phone museum seeks new owner

2019-02-20 Thread ED SHARPE via cctalk

lots  of  piles  of  phones...

some  areas  a  real  mess...
this  guy  gets the hoarder  award  for   wooden  phone  cascaras

back  when  the payphone  biz  went  privatized and legal  also   that  way   
Ron had  conversion kits... 


he  did  well in the     make  your  kitchen into a  country  kitchen  
craze  sold  lots  of  cobbled  to   work    oak  phones   for    the  
kitchen.  there  was a  good  market  back in the  70s   not  much  now  though 
 the old  people that remember the 'LASSIE"   wood  phone in  their  house as  
kids  are  dying off  now...

really interesting   guy     very  odd business model

ed#
In a message dated 2/20/2019 11:26:20 AM US Mountain Standard Time, 
cctalk@classiccmp.org writes:
So...how 'bout them phones? (hint, hint)

Does anyone know if they have any CO stuff?

(only a tiny, tiny fraction of telephone collectors care, even a tiny
bit, about CO stuff)

--
Will

Re: PDP-11 disk image question

2019-02-20 Thread Charles Anthony via cctalk

On Wed, Feb 20, 2019 at 9:21 AM Glen Slick via cctalk 
wrote:

> On Wed, Feb 20, 2019 at 8:57 AM Charles Anthony via cctalk
>  wrote:
> >
> > However, in the original posters case, the SIMH disk image is being
> copied
> > to the RA81 drive without the benefit of the MSCP controller (if I
> > understand correctly). This would lead to track misalignment and could
> > result in the observed behavior.
>
> How could you possibly write to a real RA81 drive without going
> through a real KDA50 or UDA50 MSCP controller? Nothing like that is
> happening in the original post. Just the disk size was chosen to be
> that of an RA81, and the issue is to exactly match the emulated disk
> size to that configured by the hardware, which is an MSCP SCSI
> controller and drive in this case.
>

Re-reading the original post, it it not clear to me how the disk write was
accomplished; I am not familiar with the mentioned hardware. If the data
was written to the RA81 with a controller that correctly did the spare
sector mapping, then my spare sector hypothesis is wrong.

The reported symptoms sound like a disk geometry issue; the data passes
through several systems on the way to RSTS, and it seems likely to me that
one of the steps is damaging the data.

As I lack experience with or access to the specific hardware, I am
speculating about the exact failure mode. I do however believe that it is
highly likely that disk geometry is the root of the problem. Having no no
further specific ideas about the failure mode, I will shut up now.

-- Charles

Re: IBM 3174 C 6.4 Microcode Disks?

2019-02-20 Thread Al Kossow via cctalk




On 2/19/19 7:39 PM, Jim Stefanik via cctalk wrote:

> Well, it turns out my floppies are for *3274* rather than 3174.  But, 
> that said, if anyone needs any of them, let me know: just shipping cost. 

I can use them. I ended up with one w/o media

Re: OT: Phone museum seeks new owner

2019-02-20 Thread William Donzelli via cctalk

So...how 'bout them phones? (hint, hint)

Does anyone know if they have any CO stuff?

(only a tiny, tiny fraction of telephone collectors care, even a tiny
bit, about CO stuff)

--
Will

Re: OT: Phone museum seeks new owner

2019-02-20 Thread Eric Korpela via cctalk

If a company (or its owners if not shielded from liability) has any assets
in the EU they can be seized (up to 4% of the company's total value) for
violating GDPR.  Apparently, Lee Enterprises has assets in Europe, and
doesn't want to spend the non-trivial time, effort and expense (or lost
revenue) to achieve compliance.

On Tue, Feb 19, 2019 at 11:42 AM Grant Taylor via cctalk <
cctalk@classiccmp.org> wrote:

> On 02/19/2019 10:18 AM, geneb via cctalk wrote:
> > So basically, they're blocking EU users from a website due to a law that
> > has no effect in the US?  Amazing.
>
> I thought I had heard from a number of people that GDPR could still bite
> people in other countries.  I don't remember the how, just that it could
> be done.
>
>
>
> --
> Grant. . . .
> unix || die
>

-- 
Eric Korpela
korp...@ssl.berkeley.edu
AST:7731^29u18e3

Re: PDP-11 disk image question

> On Feb 20, 2019, at 11:57 AM, Charles Anthony  
> wrote:
> 
> 
> 
> On Wed, Feb 20, 2019 at 5:38 AM Paul Koning  wrote:
> 
> 
> You're misinterpreting "spare".  MSCP exposes the user address space as 
> contiguous LBAs, for which it uses 51 sectors per track.  The spare sector is 
> used to do bad sector replacement.  That is invisible to users, it doesn't 
> affect the LBA addressing.  dd, like any other host-resident code, sees the 
> user address space.  It will copy MSCP devices correctly.
> 
>  
> 
> Yes; I agree that the MSCP conceals the spare sector when RSTS accesses the 
> disk through MSCP in the case of the *hardware*. 
> 
> However, in the original posters case, the SIMH disk image is being copied to 
> the RA81 drive without the benefit of the MSCP controller (if I understand 
> correctly). This would lead to track misalignment and could result in the 
> observed behavior.

No.  The original case isn't an actual RA81 at all, it's a non-DEC device that 
emulates an RA81.  Emulation means acting like an RA81 from the program point 
of view, which means as seen via MSCP.  There is no such thing as an RA81 
"without... MSCP controller".

> The SIMH MSCP emulation is not doing the spare sector correctly; it is not 
> including the spare sectors on the RA81 disk image.

It operates correctly because SIMH emulates the program point of view, so it 
exposes the user LBA space, not the internal structure.  For the same reason, 
it doesn't emulate sector headers, ECC codes, or servo fields.  None of that is 
visible to the software.

paul

Re: OT: Phone museum seeks new owner

2019-02-20 Thread Noel Chiappa via cctalk

> From: Grant Taylor

> I agree with your logic.
> However your valid logic

Anyone who thinks logic starting from common sense has anything to do with
the workings of legal systems is likely in for a rude awakening at some
point.

Noel

Re: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info?

On Wed, 20 Feb 2019 at 18:08, Eric Korpela via cctalk
 wrote:
>
> Don't forget hard sector CompuColor II,  GCR, and variable speed GCR.  :)

Well, yes, OK, but one step at a time.

Step 1: a generic USB floppy controller that allows 5¼" and 8" (and
other standard Shugart-interface) FDDs to be attached to USB and seen
by the OS on the system as floppy drives. That seems to be either
coming or here.

Step 2: some smart driver software for the above to enable weird disk
formats that a standard WD FDD controller could read.

Step 3: something very smart that enables weird
non-WDD-disk-controller disks (e.g. Mac 400/800 kB and Amiga disks)
that were written in fairly standard drives.

Step 4 is when you get to all the non-hard-sectored drives and so on...

-- 
Liam Proven - Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk - Google Mail/Hangouts/Plus: lpro...@gmail.com
Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven
UK: +44 7939-087884 - ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

Re: OT: Phone museum seeks new owner

On Wed, 20 Feb 2019 at 17:16, geneb via cctalk  wrote:

> Based on what I've read, the only possible way the GDPR could apply to a
> US company (with no EU physical presence) is if you're selling or
> marketing directly to EU citizens.

This could be but it's quite a widespread problem.

E.g.

If I go to:

https://www.nydailynews.com/

or

I get:

https://www.tribpub.com/gdpr/nydailynews.com/

«
Unfortunately, our website is currently unavailable in most European
countries. We are engaged on the issue and committed to looking at
options that support our full range of digital offerings to the EU
market. We continue to identify technical compliance solutions that
will provide all readers with our award-winning journalism.
»

See:
https://www.theregister.co.uk/2018/05/25/tronc_chicago_tribune_la_times_gdpr_lock_out_eu_users/

TBH mostly I neither know nor care. Occasionally I click a link and
get a blanket "sorry, no" message.

Also applies to lots of Youtube videos: I just get a "video
unavailable" message.

-- 
Liam Proven - Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk - Google Mail/Hangouts/Plus: lpro...@gmail.com
Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven
UK: +44 7939-087884 - ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

Re: OT: Phone museum seeks new owner

That was meant to say...

Or:

https://www.chicagotribune.com/

-- 
Liam Proven - Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk - Google Mail/Hangouts/Plus: lpro...@gmail.com
Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven
UK: +44 7939-087884 - ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

Re: PDP-11 disk image question

2019-02-20 Thread Glen Slick via cctalk

On Wed, Feb 20, 2019 at 8:57 AM Charles Anthony via cctalk
 wrote:
>
> However, in the original posters case, the SIMH disk image is being copied
> to the RA81 drive without the benefit of the MSCP controller (if I
> understand correctly). This would lead to track misalignment and could
> result in the observed behavior.

How could you possibly write to a real RA81 drive without going
through a real KDA50 or UDA50 MSCP controller? Nothing like that is
happening in the original post. Just the disk size was chosen to be
that of an RA81, and the issue is to exactly match the emulated disk
size to that configured by the hardware, which is an MSCP SCSI
controller and drive in this case.

Re: Ultimate FDC? (Was: IBM 6360 - Filesystem(ish) info?

2019-02-20 Thread Eric Korpela via cctalk

On Tue, Feb 19, 2019 at 4:39 PM Chuck Guzis via cctalk <
cctalk@classiccmp.org> wrote:

> On 2/19/19 3:40 PM, William Sudbrink via cctalk wrote:
> > A design that can manage Ohio Scientific as well would be nice.
>
> Might as well add Victor 9000...
>

Don't forget hard sector CompuColor II,  GCR, and variable speed GCR.  :)

-- 
Eric Korpela
korp...@ssl.berkeley.edu
AST:7731^29u18e3

Re: PDP-11 disk image question

2019-02-20 Thread Charles Anthony via cctalk

On Wed, Feb 20, 2019 at 5:38 AM Paul Koning  wrote:

>
>
> You're misinterpreting "spare".  MSCP exposes the user address space as
> contiguous LBAs, for which it uses 51 sectors per track.  The spare sector
> is used to do bad sector replacement.  That is invisible to users, it
> doesn't affect the LBA addressing.  dd, like any other host-resident code,
> sees the user address space.  It will copy MSCP devices correctly.
>
>

Yes; I agree that the MSCP conceals the spare sector when RSTS accesses the
disk through MSCP in the case of the *hardware*.

However, in the original posters case, the SIMH disk image is being copied
to the RA81 drive without the benefit of the MSCP controller (if I
understand correctly). This would lead to track misalignment and could
result in the observed behavior.

The SIMH MSCP emulation is not doing the spare sector correctly; it is not
including the spare sectors on the RA81 disk image.

-- Charles

Re: OT: Phone museum seeks new owner

2019-02-20 Thread W2HX via cctalk

I found this link from forbes on this issue. Apologies in advance as this site 
has lots of ads on it, but it is forbes.com

https://www.forbes.com/sites/forbestechcouncil/2017/12/04/yes-the-gdpr-will-affect-your-u-s-based-business/#4fb0c03d6ff2

From: cctalk  on behalf of geneb via cctalk 

Sent: Wednesday, February 20, 2019 11:15 AM
To: Grant Taylor; General Discussion: On-Topic and Off-Topic Posts
Subject: Re: OT: Phone museum seeks new owner

On Wed, 20 Feb 2019, Grant Taylor via cctalk wrote:

> On 2/20/19 7:39 AM, geneb wrote:
>> They may have a physical presence in the EU, which would cause the GDPR to
>> apply to them.  However, for companies with no physical presense in the EU,
>> I don't see how the law could apply.
>
> I agree with your logic.
>
> However your valid logic is contrary to my understanding.
>
> I've seen reference to too many entities that don't have a presence in the EU
> that are doing things like blocking EU access to websites specifically
> because of GDPR.
>
> I don't have details on /how/ GDPR applies or /why/ people in the US are
> running scared of it.  But I've seen many references to people doing exactly
> that.

Based on what I've read, the only possible way the GDPR could apply to a
US company (with no EU physical presence) is if you're selling or
marketing directly to EU citizens.  For the sites and "services" I
provide, the EU is invited to see Figure One. ;)

g.

--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby.  Geeks collect hobbies.

ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!

Re: OT: Phone museum seeks new owner

2019-02-20 Thread geneb via cctalk


On Wed, 20 Feb 2019, Grant Taylor via cctalk wrote:


On 2/20/19 7:39 AM, geneb wrote:
They may have a physical presence in the EU, which would cause the GDPR to 
apply to them.  However, for companies with no physical presense in the EU, 
I don't see how the law could apply.


I agree with your logic.

However your valid logic is contrary to my understanding.

I've seen reference to too many entities that don't have a presence in the EU 
that are doing things like blocking EU access to websites specifically 
because of GDPR.


I don't have details on /how/ GDPR applies or /why/ people in the US are 
running scared of it.  But I've seen many references to people doing exactly 
that.


Based on what I've read, the only possible way the GDPR could apply to a 
US company (with no EU physical presence) is if you're selling or 
marketing directly to EU citizens.  For the sites and "services" I 
provide, the EU is invited to see Figure One. ;)


g.


--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby.  Geeks collect hobbies.

ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!

Re: OT: Phone museum seeks new owner

> On Feb 20, 2019, at 10:53 AM, Grant Taylor via cctalk  
> wrote:
> 
> On 2/20/19 7:39 AM, geneb wrote:
>> They may have a physical presence in the EU, which would cause the GDPR to 
>> apply to them.  However, for companies with no physical presense in the EU, 
>> I don't see how the law could apply.
> 
> I agree with your logic.
> 
> However your valid logic is contrary to my understanding.
> 
> I've seen reference to too many entities that don't have a presence in the EU 
> that are doing things like blocking EU access to websites specifically 
> because of GDPR.

There is ample precedent for small companies staying away from stuff because of 
fear of regulations or other legal hassles (like certain software licenses).  
Those fears aren't necessarily based on solid foundations.  But when the 
possible downside is major legal hassles and bad publicity, and even 
investigating the potential threat is expensive (paying specialized lawyers in 
various countries) it makes sense simply to stay away and incur no risk.

paul

Re: OT: Phone museum seeks new owner


On 2/20/19 7:39 AM, geneb wrote:
They may have a physical presence in the EU, which would cause the GDPR 
to apply to them.  However, for companies with no physical presense in 
the EU, I don't see how the law could apply.


I agree with your logic.

However your valid logic is contrary to my understanding.

I've seen reference to too many entities that don't have a presence in 
the EU that are doing things like blocking EU access to websites 
specifically because of GDPR.


I don't have details on /how/ GDPR applies or /why/ people in the US are 
running scared of it.  But I've seen many references to people doing 
exactly that.




--
Grant. . . .
unix || die

Re: OT: Phone museum seeks new owner

2019-02-20 Thread geneb via cctalk


On Tue, 19 Feb 2019, Grant Taylor via cctalk wrote:


On 02/19/2019 01:17 PM, geneb via cctalk wrote:

I'd be very interested in how that would be possible.


I don't know.

But I do know that there are a lot of companies here in the US that are 
filtering their website like this.


They may have a physical presence in the EU, which would cause the GDPR to 
apply to them.  However, for companies with no physical presense in the 
EU, I don't see how the law could apply.


g.


--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby.  Geeks collect hobbies.

ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!

Re: PDP-11 disk image question

> On Feb 19, 2019, at 11:55 PM, Glen Slick via cctalk  
> wrote:
> 
> On Sat, Feb 16, 2019 at 1:20 PM Bill Gunshannon via cctalk
>  wrote:
>> 
>> I have a CQD=220A/MT configured for 6 disks and one tape.
>> As for disk types, you can toggle RA ON or OFF on each drive.
>> You can specify one RA type that will be in effect for any
>> disk with RA ON.  Types are: RA70, RA80, RA81, RA82, RA90 and RA92.
> 
> Looking at this further, I don't believe the CMD CQD RA type option
> does what you think it does. I don't believe it has any effect on the
> reported geometry of the MSCP unit, I believe it only changes the
> reported type name of the MSCP unit.

So this might be relevant.  If the reported size is sufficiently different, 
things will break.  

For MSCP, RSTS cares about the device size (LBA count).  It pays no attention 
to reported "geometry".  It displays the reported device type string (in INIT 
"Hardware List" option) but it doesn't care about what those are.  If a 
gigabyte disk claims it's an RX50 (or an RX98), RSTS will happily display that 
string without any objections.

paul

Re: PDP-11 disk image question




> On Feb 19, 2019, at 10:26 PM, Charles Anthony  
> wrote:
> 
> 
> 
> On Tue, Feb 19, 2019 at 10:14 AM Paul Koning  wrote:
> 
> ...
>> So indeed the correct sector count is 51 (the other one is a spare, a 
>> technique used by DEC as far back as the RM80).
>> 
> 
> I am concerned that the spare is the issue. If the track has 52 sectors, and 
> one is reserved as a spare, is that spare included in the LBA calculation? If 
> it is, then SIMH is wrong; the first sector of the second track written in 
> the spare sector, throwing all of the remaining data out of alignment, with 
> the symptom of RSTS booting but not being able to find INIT.SYS.
> 
> If the spare sector exists and SIMH is not allocation space for it, then the 
> disk image will not copy correctly with 'dd'. (However, dd might be coereced 
> into doing the right thing with 'dd if=... of=... ibs=26112 obs=26624'; 
> reading 512*51 byte records (a SIMH track) and writing 512*52 byte records (a 
> RA81 h/w track)).
> 
> -- Charles

You're misinterpreting "spare".  MSCP exposes the user address space as 
contiguous LBAs, for which it uses 51 sectors per track.  The spare sector is 
used to do bad sector replacement.  That is invisible to users, it doesn't 
affect the LBA addressing.  dd, like any other host-resident code, sees the 
user address space.  It will copy MSCP devices correctly.

paul

Re: HDDs (Was: PDP-11/45 RSTS/E boot problem