HECnet

hecnet@lists.dfupdate.se

15586 discussions

RE: [DECtec] Slight OT: SIMH Framebuffer support

by gregg.drwho8＠gmail.com

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."

12 years, 6 months

RE: [DECtec] Slight OT: SIMH Framebuffer support

by Mark＠infocomm.com

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

12 years, 6 months

[DECtec] [HECnet] RE: Slight OT: SIMH Framebuffer support

by Mark＠infocomm.com

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

12 years, 6 months

[DECtec] [HECnet] RE: Slight OT: SIMH Framebuffer support

by e.olofsen＠xs4all.nl

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

12 years, 6 months

Losing my fixed IP

by robert.jarratt＠ntlworld.com

-----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner- hecnet at Update.UU.SE] On Behalf Of Gregg Levine Sent: 15 June 2013 21:10 To: hecnet at update.uu.se Subject: Re: [HECnet] Losing my fixed IP On Sat, Jun 15, 2013 at 4:06 PM, Robert 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 Johnny Billquist Sent: 15 June 2013 16: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 I built the user mode router to do periodic DNS queries asynchronously so it will automatically get updated, provided you use a service like dyndns, and without any pauses waiting for DNS to respond. Hello! Robert if I remember correctly, it was originally built to run first on a R.Pi device, and as a service on Windows? (That should be a statement not a question, but I'm surmising my way across this thread.) Actually my primary platform is Windows, so that is where it is tested most. I have also run it on the R.Pi but not that much to be honest. Others have played with it on various Unix flavours. Regards Rob

12 years, 6 months

DECnet default access on RSX...

by bqt＠softjar.se

On 2013-06-15 18:51, Paul_Koning at Dell.com wrote: 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. No. It has to be enabled on both sides. Easy to test. If I just turn off outgoing proxy on a VMS node, proxy access does not work on RSX for the incoming connection. No matter what I do on the RSX side. 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

12 years, 6 months

Losing my fixed IP

by gregg.drwho8＠gmail.com

On Sat, Jun 15, 2013 at 4:06 PM, Robert 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 Johnny Billquist Sent: 15 June 2013 16: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 I built the user mode router to do periodic DNS queries asynchronously so it will automatically get updated, provided you use a service like dyndns, and without any pauses waiting for DNS to respond. Hello! Robert if I remember correctly, it was originally built to run first on a R.Pi device, and as a service on Windows? (That should be a statement not a question, but I'm surmising my way across this thread.) Incidentally Cory and Dave they are back. Right now there's a big glut of Daleks parked near you Dave. Better send the Doctor out first if a version of myself is visiting you. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again."

12 years, 6 months

Losing my fixed IP

by robert.jarratt＠ntlworld.com

-----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner- hecnet at Update.UU.SE] On Behalf Of Johnny Billquist Sent: 15 June 2013 16: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 I built the user mode router to do periodic DNS queries asynchronously so it will automatically get updated, provided you use a service like dyndns, and without any pauses waiting for DNS to respond.

12 years, 6 months

DECnet default access on RSX...

by Paul_Koning＠Dell.com

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

12 years, 6 months

DECnet default access on RSX...

by bqt＠softjar.se

On 2013-06-15 17:03, Paul_Koning at Dell.com wrote: On Jun 15, 2013, at 9:19 AM, Johnny Billquist wrote: On 2013-06-15 14:59, Bob Armstrong wrote: My workaround for that is to use DECnet proxy information. However, I'm not sure that is available in 11M. Sadly, there is no proxy support on M - only M+. I still don't understand how it works when talking to a VMS system, though? LENTO is doing the same thing in either case, but with a VMS system on the far end all is well and with an RSX system on the other end it doesn't work. In all cases, if account information is passed in the request, it is used. For any OS. If no account information is passed, but both requesting node includes proxy information, and responding nodes make use of proxy information, this is used to get an account under which to process the reqeuest. With VMS, if a request comes in without any account information, VMS applies the default account as the user under which to run the request. The requesting node have no involvement in this. 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. A variation which some OSs might use (I forgot) is to handle the case where a user name is supplied but no password. I wonder what the expected behavior of that should be? Seems like just failed access to me (unless the account actually have an empty password). Johnny

12 years, 6 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet