On 2013-06-16 15:11, Johnny Billquist wrote:
On 2013-06-16 14:58, Steve Davidson 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: Saturday, June 15, 2013 12:51
To: bqt at softjar.se
Cc: hecnet at Update.UU.SE; bob at jfcl.com
Subject: Re: [HECnet] DECnet default access on RSX...
On Jun 15, 2013, at 11:14 AM, Johnny Billquist wrote:
On 2013-06-15 17:03, Paul_Koning at Dell.com wrote:
On Jun 15, 2013, at 9:19 AM, Johnny Billquist wrote:
...
Proxy access is not standardized or documented (at the
protocol level). I think it's simply this: the access
control fields in the session control protocol are optional.
If they are omitted, it's up to the receiving node to decide
what to do about it (if the application protocol in question
has the notion of access control). In some systems, the
answer is "reject". In others, the answer is "use a default
account" (RSTS has this).
Well, proxy is something that needs to be enabled on both
sides for it to work, so it definitely involves passing some
information in the packets. So it has to be documented
somewhere. Keep searching.
I don't think so. RSTS has no notion of proxy, but I
distinctly remember having proxies on VMS work when accessed
from RSTS with no access control specified.
paul
I have a proxy from PLUTO::[1,2] to SGC::SYSTEM. The behavior is
exactly what Paul says it is.
How do you know it is a proxy access, and not the default DECnet account
in VMS?
Here is one RSX system to another, as illustration:
.set /host
Host=JOCKE RSX-11M-PLUS V5.0 BL88
.ncp set exec out prox dis
.nft mim::info.txt/li
NFT -- Error in reading directory MIM::INFO.TXT
Access control rejected
.ncp set exec out prox ena
.nft mim::info.txt/li
Directory MIM::DU4:[BQT]
16-JUN-13 15:09:17
INFO.TXT;1 8./35. 08-JUL-10 10:54:52
Total of 8./35. Blocks in 1. Files
.
Tell you what. Anyone who wants to play with proxy, just try talking to
MIM without giving an account. With proxy disabled at your end (or if
you lack the capability), you will not be able to talk with MIM, while
if you enable proxy at your end, you will.
Oh yeah, and to show that you are probably not using proxy information when talking to SGC::
.ncp set exec out prox dis
.nft sgc::info.txt/li
Directory SGC::SYS$SPECIFIC:[DECNET]
16-JUN-13 15:24:22
INFO.TXT;1 6./9. 30-DEC-11 13:11:22
Total of 6./9. Blocks in 1. Files
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 2013-06-16 14:58, Steve Davidson 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: Saturday, June 15, 2013 12:51
To: bqt at softjar.se
Cc: hecnet at Update.UU.SE; bob at jfcl.com
Subject: Re: [HECnet] DECnet default access on RSX...
On Jun 15, 2013, at 11:14 AM, Johnny Billquist wrote:
On 2013-06-15 17:03, Paul_Koning at Dell.com wrote:
On Jun 15, 2013, at 9:19 AM, Johnny Billquist wrote:
...
Proxy access is not standardized or documented (at the
protocol level). I think it's simply this: the access
control fields in the session control protocol are optional.
If they are omitted, it's up to the receiving node to decide
what to do about it (if the application protocol in question
has the notion of access control). In some systems, the
answer is "reject". In others, the answer is "use a default
account" (RSTS has this).
Well, proxy is something that needs to be enabled on both
sides for it to work, so it definitely involves passing some
information in the packets. So it has to be documented
somewhere. Keep searching.
I don't think so. RSTS has no notion of proxy, but I
distinctly remember having proxies on VMS work when accessed
from RSTS with no access control specified.
paul
I have a proxy from PLUTO::[1,2] to SGC::SYSTEM. The behavior is
exactly what Paul says it is.
How do you know it is a proxy access, and not the default DECnet account in VMS?
Here is one RSX system to another, as illustration:
.set /host
Host=JOCKE RSX-11M-PLUS V5.0 BL88
.ncp set exec out prox dis
.nft mim::info.txt/li
NFT -- Error in reading directory MIM::INFO.TXT
Access control rejected
.ncp set exec out prox ena
.nft mim::info.txt/li
Directory MIM::DU4:[BQT]
16-JUN-13 15:09:17
INFO.TXT;1 8./35. 08-JUL-10 10:54:52
Total of 8./35. Blocks in 1. Files
.
Tell you what. Anyone who wants to play with proxy, just try talking to MIM without giving an account. With proxy disabled at your end (or if you lack the capability), you will not be able to talk with MIM, while if you enable proxy at your end, you will.
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
-----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: Saturday, June 15, 2013 12:51
To: bqt at softjar.se
Cc: hecnet at Update.UU.SE; bob at jfcl.com
Subject: Re: [HECnet] DECnet default access on RSX...
On Jun 15, 2013, at 11:14 AM, Johnny Billquist wrote:
On 2013-06-15 17:03, Paul_Koning at Dell.com wrote:
On Jun 15, 2013, at 9:19 AM, Johnny Billquist wrote:
...
Proxy access is not standardized or documented (at the
protocol level). I think it's simply this: the access
control fields in the session control protocol are optional.
If they are omitted, it's up to the receiving node to decide
what to do about it (if the application protocol in question
has the notion of access control). In some systems, the
answer is "reject". In others, the answer is "use a default
account" (RSTS has this).
Well, proxy is something that needs to be enabled on both
sides for it to work, so it definitely involves passing some
information in the packets. So it has to be documented
somewhere. Keep searching.
I don't think so. RSTS has no notion of proxy, but I
distinctly remember having proxies on VMS work when accessed
from RSTS with no access control specified.
paul
I have a proxy from PLUTO::[1,2] to SGC::SYSTEM. The behavior is
exactly what Paul says it is.
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE
[mailto:owner-hecnet at Update.UU.SE] On Behalf Of Johnny Billquist
Sent: Saturday, June 15, 2013 11:12
To: hecnet at Update.UU.SE
Cc: Paul_Koning at Dell.com; md.benson at gmail.com
Subject: Re: [HECnet] Losing my fixed IP
On 2013-06-15 16:59, Paul_Koning at Dell.com wrote:
On Jun 15, 2013, at 7:26 AM, Johnny Billquist wrote:
On 2013-06-13 08:23, Mark Benson wrote:
Due to the limits on our ability to get internet service of any
decent speed, we're having to change packages meaning we
will lose
out fixed IP in November. I'd like to work towards being able to
stay on HECnet before then using STAR69 to maintain my connection.
Well, do you know if you'll get different addresses often?
Many ISPs give dynamic IP addresses, but you actually stay on
the same address for months, which makes it a rather small
problem. I haven't had a change in address in over 6 months myself.
And even if you do, with dynamic DNS you still have a
hostname that stays fixed. All you need is for the things
that connect to you, or check your address, to be able to
deal with names.
Well, they also need to recheck every so often... :-) My
bridge program, for example, only do name resolution when
processing the config file.
Johnny
Multi-Watch's check interval is configurable by the user - a system-wide
logical actually.
-Steve
-----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: Saturday, June 15, 2013 10:59
To: hecnet at Update.UU.SE
Cc: md.benson at gmail.com
Subject: Re: [HECnet] Losing my fixed IP
On Jun 15, 2013, at 7:26 AM, Johnny Billquist wrote:
On 2013-06-13 08:23, Mark Benson wrote:
Due to the limits on our ability to get internet service of any
decent speed, we're having to change packages meaning we will lose
out fixed IP in November. I'd like to work towards being
able to stay
on HECnet before then using STAR69 to maintain my connection.
Well, do you know if you'll get different addresses often?
Many ISPs give dynamic IP addresses, but you actually stay on
the same address for months, which makes it a rather small
problem. I haven't had a change in address in over 6 months myself.
And even if you do, with dynamic DNS you still have a
hostname that stays fixed. All you need is for the things
that connect to you, or check your address, to be able to
deal with names.
paul
This is how the Multi-Watch hook into Multinet works.
-Steve
On Sun, Jun 16, 2013 at 1:18 AM, Mark Pizzolato - Info Comm
<Mark at infocomm.com> wrote:
On Saturday, June 15, 2013 at 10:01 PM, Gregg Levine wrote:
On Sun, Jun 16, 2013 at 12:51 AM, Mark Pizzolato - Info Comm
<Mark at infocomm.com> wrote:
On Thursday, June 13, 2013 at 7:47 PM, Gregg Levine wrote:
On Thu, Jun 13, 2013 at 9:07 PM, Mark Pizzolato - Info Comm
<Mark at infocomm.com> wrote:
On Tuesday, June 11, 2013 at 8:42 AM, Mark Pizzolato wrote:
On Tuesday, June 11, 2013 at 8:36 AM, Sampsa Laine write:
This looks cool, anyone try it?
http://www.9track.net/simh/video/
Hi Sampsa,
How timely of you to observe this today.
Just last night I got code pieces from Matt Burke (the guy at
9track.net) to add VCB01 (QVSS) support to the simh codebase for
the MicroVAX I and MicroVAX II simulators.
I'm in the process of merging that code and adding the necessary
build mechanisms to the makefile as we speak.
This will be cleaned up and visible at
https://github.com/simh/simh in at most a couple of days....
For folks who build their own binaries, the latest github code has
a
VAXStation I and VAXStation II with the MonoChrome QVSS video
capabilities.
sim> SET CPU MODEL=VAXSTATION
enables the video subsystem.
The VAXStation I has a limit of 4MB of RAM, the VAXStation II has a
limit of
16MB.
The makefile should just build the right thing if the development
support
for libSDL is installed on your platform.
Please provide bug reports and/or other feedback with issues
created at https://github.com/simh/simh/issues
There is a glitch in my scripts which build and package the windows
binaries
which is failing to build the simulators with video support, so folks
who count on the Windows Binaries will have to wait until I fix this.
The Windows Binaries (including VAXStation I and VAXStation II) are
now available at: https://github.com/simh/Win32-Development-Binaries
Download the latest zip file.
Hello!
Nice to know Mark. Any suggestions for implementing it on a Raspberry
Pi system w/ 512MB of memory?
I don't see any reason it wouldn't work as long as you've got the right SDL
development pieces available.
I did get the code outside of your screen idea to build properly.
I'm not sure what this sentence means.... what does "code outside of your
screen idea" mean?
- Mark
Hello!
Oh sorry. I meant everything contained within the entire SIMH retrieval
except for the screen presentation method.
I think you are trying to say that all simulators except the MicroVAX I (VAXStation I) and MicroVAX II (VAXStation II) built. OK, that is expected. Numerous folks are running the latest code on Raspberry Pi systems. The QVSS video on the MicroVAX I and MicroVAX II simulators was just merged into the code base last week.
If you can't get the MicroVAX I and MicroVAX II to build, I'm going to need more information to help. Please create an issue at https://github.com/simh/simh/issues to record the problem and to contain the details of chasing this down to a solution.
Please Include the output produced when you attempted to build these simulators.
Thanks.
- Mark
Hello!
That's just it Mark. After using the git pull <repository name>
command to pull everything into the source directory I chose, I then
entered the created one, examined everything briefly, and then entered
the command make and off it went.
I first made the BIN directory, and then did that. I did need to build
the Altair ones out of sequence however. Also the Nova one as well. I
did not make the ones for the older IBM machines or the other
simulators that I wasn't familiar with.
I found that the screen thing needed the SDL library and I wasn't
ready to massage the repositories that make up Debian on Raspberry Pi
to find that one so I let wait.
My only complaint is that when I ran the vax simulation to confirm
that was all working, it then told me that the IDLE function was
disabled, that was when I asked it about the devices.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On Saturday, June 15, 2013 at 10:01 PM, Gregg Levine wrote:
On Sun, Jun 16, 2013 at 12:51 AM, Mark Pizzolato - Info Comm
<Mark at infocomm.com> wrote:
On Thursday, June 13, 2013 at 7:47 PM, Gregg Levine wrote:
On Thu, Jun 13, 2013 at 9:07 PM, Mark Pizzolato - Info Comm
<Mark at infocomm.com> wrote:
On Tuesday, June 11, 2013 at 8:42 AM, Mark Pizzolato wrote:
On Tuesday, June 11, 2013 at 8:36 AM, Sampsa Laine write:
This looks cool, anyone try it?
http://www.9track.net/simh/video/
Hi Sampsa,
How timely of you to observe this today.
Just last night I got code pieces from Matt Burke (the guy at
9track.net) to add VCB01 (QVSS) support to the simh codebase for
the MicroVAX I and MicroVAX II simulators.
I'm in the process of merging that code and adding the necessary
build mechanisms to the makefile as we speak.
This will be cleaned up and visible at
https://github.com/simh/simh in at most a couple of days....
For folks who build their own binaries, the latest github code has
a
VAXStation I and VAXStation II with the MonoChrome QVSS video
capabilities.
sim> SET CPU MODEL=VAXSTATION
enables the video subsystem.
The VAXStation I has a limit of 4MB of RAM, the VAXStation II has a
limit of
16MB.
The makefile should just build the right thing if the development
support
for libSDL is installed on your platform.
Please provide bug reports and/or other feedback with issues
created at https://github.com/simh/simh/issues
There is a glitch in my scripts which build and package the windows
binaries
which is failing to build the simulators with video support, so folks
who count on the Windows Binaries will have to wait until I fix this.
The Windows Binaries (including VAXStation I and VAXStation II) are
now available at: https://github.com/simh/Win32-Development-Binaries
Download the latest zip file.
Hello!
Nice to know Mark. Any suggestions for implementing it on a Raspberry
Pi system w/ 512MB of memory?
I don't see any reason it wouldn't work as long as you've got the right SDL
development pieces available.
I did get the code outside of your screen idea to build properly.
I'm not sure what this sentence means.... what does "code outside of your
screen idea" mean?
- Mark
Hello!
Oh sorry. I meant everything contained within the entire SIMH retrieval
except for the screen presentation method.
I think you are trying to say that all simulators except the MicroVAX I (VAXStation I) and MicroVAX II (VAXStation II) built. OK, that is expected. Numerous folks are running the latest code on Raspberry Pi systems. The QVSS video on the MicroVAX I and MicroVAX II simulators was just merged into the code base last week.
If you can't get the MicroVAX I and MicroVAX II to build, I'm going to need more information to help. Please create an issue at https://github.com/simh/simh/issues to record the problem and to contain the details of chasing this down to a solution.
Please Include the output produced when you attempted to build these simulators.
Thanks.
- Mark
On Sun, Jun 16, 2013 at 12:51 AM, Mark Pizzolato - Info Comm
<Mark at infocomm.com> wrote:
On Thursday, June 13, 2013 at 7:47 PM, Gregg Levine wrote:
On Thu, Jun 13, 2013 at 9:07 PM, Mark Pizzolato - Info Comm
<Mark at infocomm.com> wrote:
On Tuesday, June 11, 2013 at 8:42 AM, Mark Pizzolato wrote:
On Tuesday, June 11, 2013 at 8:36 AM, Sampsa Laine write:
This looks cool, anyone try it?
http://www.9track.net/simh/video/
Hi Sampsa,
How timely of you to observe this today.
Just last night I got code pieces from Matt Burke (the guy at
9track.net) to add VCB01 (QVSS) support to the simh codebase for the
MicroVAX I and MicroVAX II simulators.
I'm in the process of merging that code and adding the necessary
build mechanisms to the makefile as we speak.
This will be cleaned up and visible at https://github.com/simh/simh
in at most a couple of days....
For folks who build their own binaries, the latest github code has a
VAXStation I and VAXStation II with the MonoChrome QVSS video
capabilities.
sim> SET CPU MODEL=VAXSTATION
enables the video subsystem.
The VAXStation I has a limit of 4MB of RAM, the VAXStation II has a limit of
16MB.
The makefile should just build the right thing if the development support
for libSDL is installed on your platform.
Please provide bug reports and/or other feedback with issues created
at https://github.com/simh/simh/issues
There is a glitch in my scripts which build and package the windows binaries
which is failing to build the simulators with video support, so folks who count
on the Windows Binaries will have to wait until I fix this.
The Windows Binaries (including VAXStation I and VAXStation II) are now available at: https://github.com/simh/Win32-Development-Binaries
Download the latest zip file.
Hello!
Nice to know Mark. Any suggestions for implementing it on a Raspberry Pi
system w/ 512MB of memory?
I don't see any reason it wouldn't work as long as you've got the right SDL development pieces available.
I did get the code outside of your screen idea to build properly.
I'm not sure what this sentence means.... what does "code outside of your screen idea" mean?
- Mark
Hello!
Oh sorry. I meant everything contained within the entire SIMH
retrieval except for the screen presentation method.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On Thursday, June 13, 2013 at 7:47 PM, Gregg Levine wrote:
On Thu, Jun 13, 2013 at 9:07 PM, Mark Pizzolato - Info Comm
<Mark at infocomm.com> wrote:
On Tuesday, June 11, 2013 at 8:42 AM, Mark Pizzolato wrote:
On Tuesday, June 11, 2013 at 8:36 AM, Sampsa Laine write:
This looks cool, anyone try it?
http://www.9track.net/simh/video/
Hi Sampsa,
How timely of you to observe this today.
Just last night I got code pieces from Matt Burke (the guy at
9track.net) to add VCB01 (QVSS) support to the simh codebase for the
MicroVAX I and MicroVAX II simulators.
I'm in the process of merging that code and adding the necessary
build mechanisms to the makefile as we speak.
This will be cleaned up and visible at https://github.com/simh/simh
in at most a couple of days....
For folks who build their own binaries, the latest github code has a
VAXStation I and VAXStation II with the MonoChrome QVSS video
capabilities.
sim> SET CPU MODEL=VAXSTATION
enables the video subsystem.
The VAXStation I has a limit of 4MB of RAM, the VAXStation II has a limit of
16MB.
The makefile should just build the right thing if the development support
for libSDL is installed on your platform.
Please provide bug reports and/or other feedback with issues created
at https://github.com/simh/simh/issues
There is a glitch in my scripts which build and package the windows binaries
which is failing to build the simulators with video support, so folks who count
on the Windows Binaries will have to wait until I fix this.
The Windows Binaries (including VAXStation I and VAXStation II) are now available at: https://github.com/simh/Win32-Development-Binaries
Download the latest zip file.
Hello!
Nice to know Mark. Any suggestions for implementing it on a Raspberry Pi
system w/ 512MB of memory?
I don't see any reason it wouldn't work as long as you've got the right SDL development pieces available.
I did get the code outside of your screen idea to build properly.
I'm not sure what this sentence means.... what does "code outside of your screen idea" mean?
- Mark
Hi Erik,
Thanks for giving this a try. No extra configuration steps should be necessary.
Please create an issue at: https://github.com/simh/simh/issues and outline your problem. Include the output of SHOW VERSION from within the simulator.
- Mark
On Saturday, June 15, 2013 at 2:24 PM, Erik Olofsen wrote:
Hi Mark and others trying QVSS support,
Compiling a microvax2 with the QVSS display under Ubuntu on a laptop was
successful. Booting an image for my VAXStation 3100 with device XQA0 was
also successful and it was possible to login at the DECWindows login screen
and the usual windows appeared - great!!!
Unfortunately, the mouse does not work (moving and clicking), although
with ctrl-right-shift the mouse releases. This is not really an issue with the
QVSS display, and it could be because I used a VAXStation 3100 image; but
should a mouse be configured in simh's initialization file?
Erik
On Thu, Jun 13, 2013 at 06:07:46PM -0700, Mark Pizzolato - Info Comm wrote:
On Tuesday, June 11, 2013 at 8:42 AM, Mark Pizzolato wrote:
On Tuesday, June 11, 2013 at 8:36 AM, Sampsa Laine write:
This looks cool, anyone try it?
http://www.9track.net/simh/video/
Hi Sampsa,
How timely of you to observe this today.
Just last night I got code pieces from Matt Burke (the guy at
9track.net) to add VCB01 (QVSS) support to the simh codebase for the
MicroVAX I and MicroVAX II simulators.
I'm in the process of merging that code and adding the necessary
build mechanisms to the makefile as we speak.
This will be cleaned up and visible at https://github.com/simh/simh
in at most a couple of days....
For folks who build their own binaries, the latest github code has a
VAXStation I and VAXStation II with the MonoChrome QVSS video
capabilities.
sim> SET CPU MODEL=VAXSTATION
enables the video subsystem.
The VAXStation I has a limit of 4MB of RAM, the VAXStation II has a limit of
16MB.
The makefile should just build the right thing if the development support
for libSDL is installed on your platform.
Please provide bug reports and/or other feedback with issues created
at https://github.com/simh/simh/issues
There is a glitch in my scripts which build and package the windows binaries
which is failing to build the simulators with video support, so folks who count
on the Windows Binaries will have to wait until I fix this.
Thanks.
- Mark Pizzolato
--
DECtec mailing list
http://dectec.info
To unsubscribe from this list see page at:
http://dectec.info/mailman/listinfo/dectec_dectec.info
--
DECtec mailing list
http://dectec.info
To unsubscribe from this list see page at: http://dectec.info/mailman/listinfo/dectec_dectec.info
