RH channels:
LOGICAL ACTUAL TYPE MISCELLANEOUS
5 CHN1 EI
0 CHN0 SI MASK=0x03
1 CHN2 SI MASK=0x03
7 CHN3 CI PORT#=0x3
http://i.imgur.com/ZmLpwhV.jpg
So you have a CDDI (fddi over copper) interface and 3 SCSI ports.
http://i.imgur.com/KYl73d8.jpg
BOOT40.EXE tell me about hung SCSI devices (Shocker, none plugged in).
BTSCFC Can't find any channels
Can't tell if I'm missing a drive the rest of the OS would be on.
I think that "boot40" tells it to boot from chan4/drive0.
The DFxxx are KL10 cpu diagnostics, BIN are code for the chanel-cpu's
In you directory there is no operating system, it can still be on the
the disk in the OS file-system, but you need to teach the boot to look
at that drive..
Do you have more than 1 drive?
-P
On Thu, 12 Feb 2015, Peter Lothberg wrote:
Cory,
When you have sorted out the console thing, do:
NSP>show cpu assIGNMENT
CPU0 has the following channels assigned:
No IU channels
RH channels:
LOGICAL ACTUAL TYPE MISCELLANEOUS
5 CHN1 EI
0 CHN0 SI MASK=0x03
1 CHN2 SI MASK=0x03
7 CHN3 CI PORT#=0x3
http://i.imgur.com/ZmLpwhV.jpg
DTEs:
LOGICAL ACTUAL TYPE MISCELLANEOUS
0 FE PRIVILEGED
and
NSP>dir
http://i.imgur.com/KYl73d8.jpg
BOOT40.EXE tell me about hung SCSI devices (Shocker, none plugged in). BTSCFC Can't find any channels
Can't tell if I'm missing a drive the rest of the OS would be on.
-P
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
Grounding issue sorted. Trying diagnostics.
Booting compuserve monitor complains about file not found. Could be on a disk I don't have.
Sent from my iPhone
On Feb 13, 2015, at 01:37, Cory Smelosky <b4 at gewt.net> wrote:
On Fri, 13 Feb 2015, Paul_Koning at Dell.com wrote:
On Feb 12, 2015, at 12:41 PM, Johnny Billquist <bqt at softjar.se> wrote:
...
Start with just 7 bits no parity. Try both one and two stop bits. Then move on from there.
7 bits no parity is something I ve never seen. I would start with 8 bits no parity, one stop bit unless it s 110 bps. 7 bits with parity, that does come up on a few occasions. But while I ve seen 8 and 5 and even 6 bit serial comms used, I can t think of any 7 bits in the wild.
Looking like it's some grounding issue somewhere. Waiting until someone with better eyes had physical access and can trace it out...due to no schematics unless Peter has some.
paul
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On 2015-02-13 15:36, Paul_Koning at Dell.com wrote:
On Feb 13, 2015, at 9:06 AM, Clem Cole <clemc at ccc.com
<mailto:clemc at ccc.com>> wrote:
I agree, I never saw _/correctly/_ configured systems with anything
less than 8 bits. 7 with parity (8 total) as Paul said,
was pretty standard. particularly on modems. Early UNIX tty drivers
used to assume it and pretty much always AND 0x7F with the input
character.
Not only that, but some (BSD 2.9?) put out text with 0x80 ORed into the
output stream, which messes up modern terminal emulators.
It's still there in 2.11BSD, until the last (unofficial) patch set I sent out a few years ago which removed it.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2015-02-13 14:44, Paul_Koning at Dell.com wrote:
Yes, but that s 8 bits total. I was referring to 7 bits, no parity, no fixed extra bit like a mark bit.
Right. And as to the question about no devices actually ever using 7 bits, it is still a good thing to test, when you are trying to find patterns. But I don't actually know of any device that actually have been 7 bits pure. But it is one way of testing for possible strange parity issues.
We can go on discussing possible ways of troubleshooting serial ports for quite a while. And I'm happy to do so, if we really want to.
But in the current case, the problem seems to indeed have been grounding problems. So from that point of view, this isn't a problem any more.
Johnny
paul
On Feb 12, 2015, at 9:45 PM, pechter at gmail.com wrote:
I saw 7 bit mark and 7 even back in my old Field Service days in the 80s...
Bill
-----Original Message-----
From: Paul_Koning at Dell.com
To: hecnet at Update.UU.SE
Sent: Thu, 12 Feb 2015 20:59
Subject: Re: [HECnet] SC-40
On Feb 12, 2015, at 12:41 PM, Johnny Billquist <bqt at softjar.se> wrote:
...
Start with just 7 bits no parity. Try both one and two stop bits. Then move on from there.
7 bits no parity is something I ve never seen. I would start with 8 bits no parity, one stop bit unless it s 110 bps. 7 bits with parity, that does come up on a few occasions. But while I ve seen 8 and 5 and even 6 bit serial comms used, I can t think of any 7 bits in the wild.
paul
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Feb 13, 2015, at 9:06 AM, Clem Cole <clemc at ccc.com> wrote:
I agree, I never saw correctly configured systems with anything less than 8 bits. 7 with parity (8 total) as Paul said, was pretty standard. particularly on modems. Early UNIX tty drivers used to assume it and pretty much always AND 0x7F with the input character.
Not only that, but some (BSD 2.9?) put out text with 0x80 ORed into the output stream, which messes up modern terminal emulators.
Less than 8 does appear in some places. There s the old 5 bit code (Murray and friends, referred to as Baudot or RTTY by hams). There are a pile of 6 bit codes that were used by newspaper wire service data sources, carrying a variety of typesetting codes specific to the data carried. For example, stock data had lots of special codes for all the fractions then used for prices. I did some work on drivers for that, DL11s with an unusual collection of mode jumpers most likely.
paul
On Fri, Feb 13, 2015 at 8:44 AM, <Paul_Koning at dell.com> wrote:
Yes, but that s 8 bits total. I was referring to 7 bits, no parity, no fixed extra bit like a mark bit.
paul
I agree, I never saw correctly configured systems with anything less than 8 bits. 7 with parity (8 total) as Paul said, was pretty standard. particularly on modems. Early UNIX tty drivers used to assume it and pretty much always AND 0x7F with the input character.
Clem
Yes, but that s 8 bits total. I was referring to 7 bits, no parity, no fixed extra bit like a mark bit.
paul
On Feb 12, 2015, at 9:45 PM, pechter at gmail.com wrote:
I saw 7 bit mark and 7 even back in my old Field Service days in the 80s...
Bill
-----Original Message-----
From: Paul_Koning at Dell.com
To: hecnet at Update.UU.SE
Sent: Thu, 12 Feb 2015 20:59
Subject: Re: [HECnet] SC-40
On Feb 12, 2015, at 12:41 PM, Johnny Billquist <bqt at softjar.se> wrote:
...
Start with just 7 bits no parity. Try both one and two stop bits. Then move on from there.
7 bits no parity is something I ve never seen. I would start with 8 bits no parity, one stop bit unless it s 110 bps. 7 bits with parity, that does come up on a few occasions. But while I ve seen 8 and 5 and even 6 bit serial comms used, I can t think of any 7 bits in the wild.
paul
On Fri, 13 Feb 2015, Paul_Koning at Dell.com wrote:
On Feb 12, 2015, at 12:41 PM, Johnny Billquist <bqt at softjar.se> wrote:
...
Start with just 7 bits no parity. Try both one and two stop bits. Then move on from there.
7 bits no parity is something I ve never seen. I would start with 8 bits no parity, one stop bit unless it s 110 bps. 7 bits with parity, that does come up on a few occasions. But while I ve seen 8 and 5 and even 6 bit serial comms used, I can t think of any 7 bits in the wild.
Looking like it's some grounding issue somewhere. Waiting until someone with better eyes had physical access and can trace it out...due to no schematics unless Peter has some.
paul
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
I saw 7 bit mark and 7 even back in my old Field Service days in the 80s...
Bill
-----Original Message-----
From: Paul_Koning at Dell.com
To: hecnet at Update.UU.SE
Sent: Thu, 12 Feb 2015 20:59
Subject: Re: [HECnet] SC-40
On Feb 12, 2015, at 12:41 PM, Johnny Billquist <bqt at softjar.se> wrote:
=20
...
Start with just 7 bits no parity. Try both one and two stop bits. Then mo=
ve on from there.
7 bits no parity is something I=E2=80=99ve never seen. I would start with =
8 bits no parity, one stop bit unless it=E2=80=99s 110 bps. 7 bits with pa=
rity, that does come up on a few occasions. But while I=E2=80=99ve seen 8 =
and 5 and even 6 bit serial comms used, I can=E2=80=99t think of any 7 bits=
in the wild.
The SC40 expects a serial byte with values 0..127 (8 bits, MSB always
=0) no parity one stop bit.
--P