-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On Behalf Of Cory Smelosky
Sent: 23 December 2012 18:17
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] SIMH PDP-10 + Networking?
On 23 Dec 2012, at 13:14, "Rob Jarratt" <robert.jarratt at ntlworld.com>
wrote:
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-
hecnet at Update.UU.SE]
On Behalf Of Paul_Koning at Dell.com
Sent: 23 December 2012 17:08
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] SIMH PDP-10 + Networking?
On Dec 23, 2012, at 12:37 AM, John Wilson wrote:
From: <Paul_Koning at Dell.com>
FWIW, DMC and DMR are the same at the programmer level.
(Except for some trivial differences.) My notes say the limit on
outstanding TX or RX buffers is 7 for DMC vs. 64 for DMR. Also,
BSEL3 is a read/write reg that survives master clears on DMC but
gives diag completion status on DMR (which is how INIT.SYS tells them
apart).
And opcode 02 is HALTR on DMR and reserved on DMC. Is there other
stuff?
I didn't know of those details, or other differences that matter to a
driver.
The way I've seen it done is that a DMC driver (7 buffers max) works
fine
for
DMR, and there wasn't any real reason to do DMR-specific things.
Indeed, I have seen the source for a VMS driver that works for both
DMC and DMR, there appear to be some tiny differences in there that I
don't recall, but they are similar enough to use the same driver.
So, my question still stands: If I add DMC11 to the SIMH KS10
emulation, is there anyone who can help me with getting TOPS-10 to
work with it, or if you know how to get TOPS-20 V4.1 to work with it
that
would be even better.
I can't help with writing drivers, but i'd be willing to help with
testing. I think
the documentation covers this configuration of DMC links. I'm not the
best
with TOPS-10 or TOPS-20, but i'm learning.
Do you have any links to the relevant documentation?
They are somewhat different at the protocol level -- DMC uses an
older version of DDCMP and has some bugs in that implementation,
especially in the "high speed" (1 Mb/s) version.
Buggy WRT dealing with correct implementations, or buggy even
talking to each other? Just curious (I have a pair of them around
here
somewhere).
Buggy in the sense of not being 100% compliant to the DDCMP spec as
written. They talk fine to each other. If you want to have another
DDCMP implementation talk to them, you have to be aware of those
details. I
don't
remember them but can find them if needed -- they would be in the
NODVR (software DDCMP) RSTS/E driver sources.
paul
Yup, I'll probably create an account for you with sudo tomorrow, and then you can have a look at it.
The NAME->IP resolution works fine, if you could just turn that into IP->NAME I'd be very grateful.
Sampsa
On 23 Dec 2012, at 20:34, Dave McGuire <mcguire at neurotica.com> wrote:
On 12/23/2012 01:24 PM, sampsa at mac.com wrote:
So you're running an internal nameserver (bravo!) and your inverse
zone is hosed somehow?
Pretty much, yeah. But it resolves the names to IPs correctly, so I'm
happy with the current (temporary) setup.
I'll fix the reverse later.
Ok. I can help you with that when the time comes, if needed.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 12/23/2012 01:24 PM, sampsa at mac.com wrote:
So you're running an internal nameserver (bravo!) and your inverse
zone is hosed somehow?
Pretty much, yeah. But it resolves the names to IPs correctly, so I'm
happy with the current (temporary) setup.
I'll fix the reverse later.
Ok. I can help you with that when the time comes, if needed.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Yes but... The multinet-watch procedure does make use of DNS. That is
how dynamic IP addresses are resolved.
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE
[mailto:owner-hecnet at Update.UU.SE] On Behalf Of Bob Armstrong
Sent: Sunday, December 23, 2012 12:00
To: hecnet at Update.UU.SE
Subject: RE: [HECnet] MULTINET borks due to broken Bind9 setup?
Hmm - I'm missing something here. Multinet only uses IPs -
it doesn't use DNS, therefore how can bind screw it up?
Bob
On 23 Dec 2012, at 20:22, Dave McGuire <mcguire at neurotica.com> wrote:
So you're running an internal nameserver (bravo!) and your inverse
zone is hosed somehow?
Pretty much, yeah. But it resolves the names to IPs correctly, so I'm happy with the current (temporary) setup.
I'll fix the reverse later.
Sampsa
On 12/23/2012 01:19 PM, sampsa at mac.com wrote:
Weirdly enough, it tries to do a reverse lookup on the name server
when invoking NSLOOKUP.
Nslookup has done this forever.
Steve D's MWATCH (MULTINET Tunnel updater) uses NSLOOKUP to figure
out the new IP address for the tunnel.
As I don't need the internal name server on GORVAX, I just set the
name server to 8.8.8.8 and everything works.
So you're running an internal nameserver (bravo!) and your inverse
zone is hosed somehow?
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Weirdly enough, it tries to do a reverse lookup on the name server when invoking NSLOOKUP.
Steve D's MWATCH (MULTINET Tunnel updater) uses NSLOOKUP to figure out the new IP address for the tunnel.
As I don't need the internal name server on GORVAX, I just set the name server to 8.8.8.8 and everything works.
Sampsa
On 23 Dec 2012, at 20:17, Dave McGuire <mcguire at neurotica.com> wrote:
On 12/23/2012 11:20 AM, sampsa at mac.com wrote:
Any Bind gurus out here?
Can you contact me off list, having problem with reverse zones...
I can help you with BIND, but I don't see how Multinet could be borked
due to a borked BIND config.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 12/23/2012 11:20 AM, sampsa at mac.com wrote:
Any Bind gurus out here?
Can you contact me off list, having problem with reverse zones...
I can help you with BIND, but I don't see how Multinet could be borked
due to a borked BIND config.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 23 Dec 2012, at 13:14, "Rob Jarratt" <robert.jarratt at ntlworld.com> wrote:
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On Behalf Of Paul_Koning at Dell.com
Sent: 23 December 2012 17:08
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] SIMH PDP-10 + Networking?
On Dec 23, 2012, at 12:37 AM, John Wilson wrote:
From: <Paul_Koning at Dell.com>
FWIW, DMC and DMR are the same at the programmer level.
(Except for some trivial differences.) My notes say the limit on
outstanding TX or RX buffers is 7 for DMC vs. 64 for DMR. Also, BSEL3
is a read/write reg that survives master clears on DMC but gives diag
completion status on DMR (which is how INIT.SYS tells them apart).
And opcode 02 is HALTR on DMR and reserved on DMC. Is there other
stuff?
I didn't know of those details, or other differences that matter to a
driver.
The way I've seen it done is that a DMC driver (7 buffers max) works fine
for
DMR, and there wasn't any real reason to do DMR-specific things.
Indeed, I have seen the source for a VMS driver that works for both DMC and
DMR, there appear to be some tiny differences in there that I don't recall,
but they are similar enough to use the same driver.
So, my question still stands: If I add DMC11 to the SIMH KS10 emulation, is
there anyone who can help me with getting TOPS-10 to work with it, or if you
know how to get TOPS-20 V4.1 to work with it that would be even better.
I can't help with writing drivers, but i'd be willing to help with testing. I think the documentation covers this configuration of DMC links. I'm not the best with TOPS-10 or TOPS-20, but i'm learning.
They are somewhat different at the protocol level -- DMC uses an
older version of DDCMP and has some bugs in that implementation,
especially in the "high speed" (1 Mb/s) version.
Buggy WRT dealing with correct implementations, or buggy even talking
to each other? Just curious (I have a pair of them around here
somewhere).
Buggy in the sense of not being 100% compliant to the DDCMP spec as
written. They talk fine to each other. If you want to have another DDCMP
implementation talk to them, you have to be aware of those details. I
don't
remember them but can find them if needed -- they would be in the NODVR
(software DDCMP) RSTS/E driver sources.
paul
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On Behalf Of Paul_Koning at Dell.com
Sent: 23 December 2012 17:08
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] SIMH PDP-10 + Networking?
On Dec 23, 2012, at 12:37 AM, John Wilson wrote:
From: <Paul_Koning at Dell.com>
FWIW, DMC and DMR are the same at the programmer level.
(Except for some trivial differences.) My notes say the limit on
outstanding TX or RX buffers is 7 for DMC vs. 64 for DMR. Also, BSEL3
is a read/write reg that survives master clears on DMC but gives diag
completion status on DMR (which is how INIT.SYS tells them apart).
And opcode 02 is HALTR on DMR and reserved on DMC. Is there other
stuff?
I didn't know of those details, or other differences that matter to a
driver.
The way I've seen it done is that a DMC driver (7 buffers max) works fine
for
DMR, and there wasn't any real reason to do DMR-specific things.
Indeed, I have seen the source for a VMS driver that works for both DMC and
DMR, there appear to be some tiny differences in there that I don't recall,
but they are similar enough to use the same driver.
So, my question still stands: If I add DMC11 to the SIMH KS10 emulation, is
there anyone who can help me with getting TOPS-10 to work with it, or if you
know how to get TOPS-20 V4.1 to work with it that would be even better.
They are somewhat different at the protocol level -- DMC uses an
older version of DDCMP and has some bugs in that implementation,
especially in the "high speed" (1 Mb/s) version.
Buggy WRT dealing with correct implementations, or buggy even talking
to each other? Just curious (I have a pair of them around here
somewhere).
Buggy in the sense of not being 100% compliant to the DDCMP spec as
written. They talk fine to each other. If you want to have another DDCMP
implementation talk to them, you have to be aware of those details. I
don't
remember them but can find them if needed -- they would be in the NODVR
(software DDCMP) RSTS/E driver sources.
paul
