On Feb 15, 2013, at 9:24 PM, Johnny Billquist wrote:
On 2013-02-16 03:03, Paul_Koning at Dell.com wrote:
The thing to do would be to see what happens if you load some multicast address (such as broadcast) into slot 0 of the 16-entry address match table, and the station address into slot 1. For a QNA, that's perfectly fine because all slots are equivalent and the device doesn't do any MOP. It may be that this was a later restriction that RSTS didn't obey. Or it may be a bad assumption in the real LQA that wasn't documented -- or maybe it's just a bad assumption in the SIMH emulation. I haven't yet looked for LQA manuals to give more clues.
Ah. I thought you had already checked documentation.
Well, I did now, and simh is right. Page 3-31 of the DELQA manual states that the first address is used as the source address for system ID messages.
Which edition? I'm looking at EK-DELQA-UG-002 (from Bitsavers) and it can't find anything like that.
So I guess RSTS/E just sets it up wrong.
More precisely, RSTS/E is written to DEQNA specs, which don't constrain which address goes where.
I guess I should see about constructing a patch for this.
paul
On Sat, Feb 16, 2013 at 4:33 PM, Johnny Billquist <bqt at softjar.se> wrote:
On 2013-02-16 01:13, Johnny Billquist wrote:
Hi. As I'm working on my TCP/IP for RSX, I just noticed something that I
think looks funny in Linux. But right now my head is also spinning, so
maybe there is something I've just forgotten, or don't know, which
explains this. But if anyone can shed some light, I'd be interested.
Just for the record - I *think* that TCP/IP in Linux is misbehaving, but
it's not really hurting anything, but I like my TCP/IP to really do
things as right and optimal as possible.
[...]
Any thoughts, opinions or knowledge always welcome.
Not that I've come any closer to figuring it all out, however I thought I
should mention that I've checked some more against both NetBSD and OS/X and
neither show the behavior I observe in Linux, so I think I'm just going to
attribute this to a crappy implementation on the Linux side. That's not the
first time Linux code turns out to be bad, so I'm not totally surprised...
(And yes, I also tried VMS actually... :-) )
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
Hello!
Johnny I've been arguing with the stack for Linux for about as many
years as I've known about the idea of emulating our friends, the
PDP-11 crowd and those Vaxes. And sadly it happens to be something of
a kludge. Alan Cox and the others behind it are constantly sorting it
out. Fact is, three-quarters of it, happens to be from the land of BSD
and fitted into it rather awkwardly.
So your discoveries must be a surprise to a lot of us, but it confirms
what I've known all along.
Incidentally Dave this isn't your fault.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On 2013-02-16 01:13, Johnny Billquist wrote:
Hi. As I'm working on my TCP/IP for RSX, I just noticed something that I
think looks funny in Linux. But right now my head is also spinning, so
maybe there is something I've just forgotten, or don't know, which
explains this. But if anyone can shed some light, I'd be interested.
Just for the record - I *think* that TCP/IP in Linux is misbehaving, but
it's not really hurting anything, but I like my TCP/IP to really do
things as right and optimal as possible.
[...]
Any thoughts, opinions or knowledge always welcome.
Not that I've come any closer to figuring it all out, however I thought I should mention that I've checked some more against both NetBSD and OS/X and neither show the behavior I observe in Linux, so I think I'm just going to attribute this to a crappy implementation on the Linux side. That's not the first time Linux code turns out to be bad, so I'm not totally surprised...
(And yes, I also tried VMS actually... :-) )
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 Sat, Feb 16, 2013 at 3:16 PM, Dave McGuire <mcguire at neurotica.com> wrote:
On 02/16/2013 03:15 PM, Gregg Levine wrote:
I was watching the MOP Console system ID messages from DECnet/E on
simh, with an emulated LQA. Noticed something odd: the source address
was broadcast. That's not valid, of course. The question is why that
happened.
The answer is that the emulation uses the address in slot 0 of the
address filter as the source address. The hardware doesn't care what
order the addresses go in as far as filtering is concerned; DECnet/E
puts broadcast in slot 0 and the physical address in slot 1, followed
by any multicast addresses.
Is the SIMH behavior also what a real LQA does? That would be an
interesting DECnet/E bug if so... Or does a real LQA just use the
physical address, as a UNA would?
Hi, Paul. Sorry for not responding sooner. Busy, as usual. However, I
did mark this for some later investigation. However, I now realize that
it's not trivial for me to test, as it would appear a RSTS/E system
would help. :-)
I honestly don't know how a real LQA do. Maybe John Wilson knows more,
since he have been digging into these kind of questions way more than
most people I know...
Or else if you have some realistic suggestion on how I would test this
on my machine, as I do have a 11/93 with a real LQA here (although an
LQA plus).
I can provide access to my RSTS/E machine with a DELQA if that would
be helpful.
Hello!
Only if the occupants next to the machine who happened to be needing
it to keep warm mean. Just six cats of both sizes.
They do.
But what's that big hairy something else doing outside your place?
Gyrating suggestively.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
That word there should be "mind". (Fast keyboard and slow mind.) And
the big hairy thing is trying to get someone out to play with.
Supposedly there's enough stuff on the ground to drive everyone to
distraction.
Did anyone see the news concerning last week's asteroid strike in
Russia? It's being blamed on someone who happens to be on our list.
(And not me.)
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On 02/16/2013 03:15 PM, Gregg Levine wrote:
I was watching the MOP Console system ID messages from DECnet/E on
simh, with an emulated LQA. Noticed something odd: the source address
was broadcast. That's not valid, of course. The question is why that
happened.
The answer is that the emulation uses the address in slot 0 of the
address filter as the source address. The hardware doesn't care what
order the addresses go in as far as filtering is concerned; DECnet/E
puts broadcast in slot 0 and the physical address in slot 1, followed
by any multicast addresses.
Is the SIMH behavior also what a real LQA does? That would be an
interesting DECnet/E bug if so... Or does a real LQA just use the
physical address, as a UNA would?
Hi, Paul. Sorry for not responding sooner. Busy, as usual. However, I
did mark this for some later investigation. However, I now realize that
it's not trivial for me to test, as it would appear a RSTS/E system
would help. :-)
I honestly don't know how a real LQA do. Maybe John Wilson knows more,
since he have been digging into these kind of questions way more than
most people I know...
Or else if you have some realistic suggestion on how I would test this
on my machine, as I do have a 11/93 with a real LQA here (although an
LQA plus).
I can provide access to my RSTS/E machine with a DELQA if that would
be helpful.
Hello!
Only if the occupants next to the machine who happened to be needing
it to keep warm mean. Just six cats of both sizes.
They do.
But what's that big hairy something else doing outside your place?
Gyrating suggestively.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On Sat, Feb 16, 2013 at 3:01 PM, Dave McGuire <mcguire at neurotica.com> wrote:
On 02/15/2013 08:53 PM, Johnny Billquist wrote:
I was watching the MOP Console system ID messages from DECnet/E on
simh, with an emulated LQA. Noticed something odd: the source address
was broadcast. That's not valid, of course. The question is why that
happened.
The answer is that the emulation uses the address in slot 0 of the
address filter as the source address. The hardware doesn't care what
order the addresses go in as far as filtering is concerned; DECnet/E
puts broadcast in slot 0 and the physical address in slot 1, followed
by any multicast addresses.
Is the SIMH behavior also what a real LQA does? That would be an
interesting DECnet/E bug if so... Or does a real LQA just use the
physical address, as a UNA would?
Hi, Paul. Sorry for not responding sooner. Busy, as usual. However, I
did mark this for some later investigation. However, I now realize that
it's not trivial for me to test, as it would appear a RSTS/E system
would help. :-)
I honestly don't know how a real LQA do. Maybe John Wilson knows more,
since he have been digging into these kind of questions way more than
most people I know...
Or else if you have some realistic suggestion on how I would test this
on my machine, as I do have a 11/93 with a real LQA here (although an
LQA plus).
I can provide access to my RSTS/E machine with a DELQA if that would
be helpful.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Hello!
Only if the occupants next to the machine who happened to be needing
it to keep warm mean. Just six cats of both sizes.
But what's that big hairy something else doing outside your place?
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On 02/15/2013 08:53 PM, Johnny Billquist wrote:
I was watching the MOP Console system ID messages from DECnet/E on
simh, with an emulated LQA. Noticed something odd: the source address
was broadcast. That's not valid, of course. The question is why that
happened.
The answer is that the emulation uses the address in slot 0 of the
address filter as the source address. The hardware doesn't care what
order the addresses go in as far as filtering is concerned; DECnet/E
puts broadcast in slot 0 and the physical address in slot 1, followed
by any multicast addresses.
Is the SIMH behavior also what a real LQA does? That would be an
interesting DECnet/E bug if so... Or does a real LQA just use the
physical address, as a UNA would?
Hi, Paul. Sorry for not responding sooner. Busy, as usual. However, I
did mark this for some later investigation. However, I now realize that
it's not trivial for me to test, as it would appear a RSTS/E system
would help. :-)
I honestly don't know how a real LQA do. Maybe John Wilson knows more,
since he have been digging into these kind of questions way more than
most people I know...
Or else if you have some realistic suggestion on how I would test this
on my machine, as I do have a 11/93 with a real LQA here (although an
LQA plus).
I can provide access to my RSTS/E machine with a DELQA if that would
be helpful.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 02/16/2013 01:36 PM, Michael Holmes wrote:
Just looked like there wasn't any more efforts focusing on Mac OS X,
since its not a large commercial platform.
Heh. C'mon. It's a GIGANTIC commercial platform. People who aren't
porting to OS X now will be porting to OS X later.
Better yet, though, would be to write the software in a portable
fashion in the first place, and avoid using OS X's hokey whiz-bang
"extensions" to UNIX. Then, very litte "porting" will be necessary,
whichever direction you're going. It's readily possible; I've been
doing it for years.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Thanks Brian.
I understand the focus on the commercial side first and then those efforts spinning off benefits to the personal/hobbyist side.
Just looked like there wasn't any more efforts focusing on Mac OS X, since its not a large commercial platform.
I'd appreciate if you could pass along the question if there are any continuing efforts for Mac OS X.
Mike
Sent from my iPhone
On Feb 16, 2013, at 1:13 PM, "Brian Schenkenberger, VAXman-" <system at TMESIS.COM> wrote:
Michael Holmes <mholmes10 at hotmail.com> writes:
Anyone know of a good Alpha emulator that runs on OS X?
I had Personal Alpha on my WinXP laptop, but haven't touched it since I
got my MacBookPro couple years ago.=20
Would like to run something like person alpha on OSX, cuz running it on
WinXP under VM Fusion on OSX is kinda slow (and decnet doesn't seem to
be able to talk the real boxes due to all the virtual networking).
I found articles about ES40 project for OSX, but looks like it ran out
of steam.
That is/was Camiel Vanderhoeven. He's working with Migration Specialties
Inc. (MSI) these days on a commecial Alpha emulation. I've been actively
working with them (MSI) on a parallel project. If you want, I could ask
him if he'd mind entertaining question from you about the ES40 project.
I'm running AlphaVM-Free from EmuVM on Linux. I suspect that one of the
reasons Artem has not ported it to OSX is that he doesn't have anything
running OSX. You could ask him. His email is: artem.alimarin at gmail.com
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
Michael Holmes <mholmes10 at hotmail.com> writes:
Anyone know of a good Alpha emulator that runs on OS X?
I had Personal Alpha on my WinXP laptop, but haven't touched it since I
got my MacBookPro couple years ago.=20
Would like to run something like person alpha on OSX, cuz running it on
WinXP under VM Fusion on OSX is kinda slow (and decnet doesn't seem to
be able to talk the real boxes due to all the virtual networking).
I found articles about ES40 project for OSX, but looks like it ran out
of steam.
That is/was Camiel Vanderhoeven. He's working with Migration Specialties
Inc. (MSI) these days on a commecial Alpha emulation. I've been actively
working with them (MSI) on a parallel project. If you want, I could ask
him if he'd mind entertaining question from you about the ES40 project.
I'm running AlphaVM-Free from EmuVM on Linux. I suspect that one of the
reasons Artem has not ported it to OSX is that he doesn't have anything
running OSX. You could ask him. His email is: artem.alimarin at gmail.com
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.