Maximum address would be 47.1023, so 47.1113 is invalid.
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE
[mailto:owner-hecnet at Update.UU.SE] On Behalf Of Johnny Billquist
Sent: Monday, December 10, 2012 22:01
To: hecnet at Update.UU.SE
Cc: sampsa at mac.com
Subject: Re: [HECnet] New node, SIIRI - 47.113
On 2012-12-09 16:30, sampsa at mac.com wrote:
Johnny,
When you get a chance can you register this for me?
sampsa
Uh. Hi, Sampsa. I already have SIIRI at 47.1113. Is that
wrong? Let me know if I should change 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 2012-12-09 16:30, sampsa at mac.com wrote:
Johnny,
When you get a chance can you register this for me?
sampsa
Uh. Hi, Sampsa. I already have SIIRI at 47.1113. Is that wrong? Let me know if I should change 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
Yeah, it was those articles that i spotted earlier. I'm being a bit of an idiot though, stumbling on how to recompile the damn kernel for bridge support.
On Mon, Dec 10, 2012 at 10:24 AM, Jordi Guillaumes i Pons <jg at jordi.guillaumes.name> wrote:
El 10/12/2012, a les 11:21, Tony Blews <tonyblews at gmail.com> va escriure:
The bridge is running on a different Pi, but what i'm trying to do is get it up and going on the same one as the image.
The problem is that they can't talk to each other. I know there is a workaround, but I can't work it out.
Oh, I understand.
I use vde to overcome that problem. Perhaps these posts will be of help:
http://ancientbits.blogspot.com.es/2012_09_01_archive.htmlhttp://ancientbits.blogspot.com.es/2012/06/simh-39-using-vde-for-fun-and.ht…
Right now I'm running 5 simh simulators, a KLH10 instance and the bridge at one Pi. :)
Jordi Guillaumes i Pons
jg at jordi.guillaumes.name
HECnet: BITXOV::JGUILLAUMES
El 10/12/2012, a les 11:21, Tony Blews <tonyblews at gmail.com> va escriure:
The bridge is running on a different Pi, but what i'm trying to do is get it up and going on the same one as the image.
The problem is that they can't talk to each other. I know there is a workaround, but I can't work it out.
Oh, I understand.
I use vde to overcome that problem. Perhaps these posts will be of help:
http://ancientbits.blogspot.com.es/2012_09_01_archive.htmlhttp://ancientbits.blogspot.com.es/2012/06/simh-39-using-vde-for-fun-and.ht…
Right now I'm running 5 simh simulators, a KLH10 instance and the bridge at one Pi. :)
Jordi Guillaumes i Pons
jg at jordi.guillaumes.name
HECnet: BITXOV::JGUILLAUMES
The bridge is running on a different Pi, but what i'm trying to do is get it up and going on the same one as the image.
The problem is that they can't talk to each other. I know there is a workaround, but I can't work it out.
On Mon, Dec 10, 2012 at 10:17 AM, Jordi Guillaumes i Pons <jg at jordi.guillaumes.name> wrote:
El 10/12/2012, a les 10:26, Tony Blews <tonyblews at gmail.com> va escriure:
What I'd like to do is run the bridge program on the same raspberry that the SIMH image runs on, but I have no idea how to do this. I seem to recall a post about doing it recently, but I can't recall how to view the list archives.
Running the bridge in the Pi is a non-issue. You just have to recompile it and you are set.
As for running DECnet, there is no decnet support in the raspbian kernel. I have tried to build myself a kernel with decnet support (cross-compiling it from another machine) and my first try was a complete failure (the new kernel crashes during boot). I will give it another try...
On the other hand, since I am running KLH10 in the same machine the main interface is hijacked by a virtual TOPS-20 machine, so I won't be able to run native linux decnet anyway... :)
Jordi Guillaumes i Pons
jg at jordi.guillaumes.name
HECnet: BITXOV::JGUILLAUMES
El 10/12/2012, a les 10:26, Tony Blews <tonyblews at gmail.com> va escriure:
What I'd like to do is run the bridge program on the same raspberry that the SIMH image runs on, but I have no idea how to do this. I seem to recall a post about doing it recently, but I can't recall how to view the list archives.
Running the bridge in the Pi is a non-issue. You just have to recompile it and you are set.
As for running DECnet, there is no decnet support in the raspbian kernel. I have tried to build myself a kernel with decnet support (cross-compiling it from another machine) and my first try was a complete failure (the new kernel crashes during boot). I will give it another try...
On the other hand, since I am running KLH10 in the same machine the main interface is hijacked by a virtual TOPS-20 machine, so I won't be able to run native linux decnet anyway... :)
Jordi Guillaumes i Pons
jg at jordi.guillaumes.name
HECnet: BITXOV::JGUILLAUMES
Hi,
Despite me not doing anything different apart from rebooting my machine, TARDIS is back up.
This has spurred me into action.
What I'd like to do is run the bridge program on the same raspberry that the SIMH image runs on, but I have no idea how to do this. I seem to recall a post about doing it recently, but I can't recall how to view the list archives.
Ideally I'd like to be the bridge, the TARDIS SIMH image and Linus DECnet on the same machine. Is this possible?
Tony.
Jordi Guillaumes i Pons
Barcelona - Catalunya - Europa
El 04/12/2012, a les 22:55, "Boyanich, Alastair" <Alastair.Boyanich at au.fujitsu.com> va escriure:
I've not messed around with TOPS-10/20 and only VMS on simh, but there
you need specify which O/S is running inside the VM and specify it with
something like:
set cpu idle=VMS
Well, KLH10 os a different beast. You have to patch the guest OS to do a write to an " idler" device so the simulator knows the guest is not doing anything and it can enter a wait state until next timer tick or interrups happens. This patch is included in the Panda monitor and it works as expected...
... Unless you happen to be using a "high performance" host system (he, and the Pi seems to fit that class lol...). Then you have to build the simulator to use a synchronous implementation for the timers and device interrupts (see https://groups.google.com/forum/m/?fromgroups#!msg/alt.sys.pdp10/vHcQ49tjMa…) and the idler simply does not work at all. Unfortunately it seem there is no fix for this problem (see https://groups.google.com/forum/m/?hl=en&fromgroups#!msg/alt.sys.pdp10/xndb…) so I will have to live with it. Not a big problem in the raspi anyway...
(Apologies for the double post... The bus just caught a bump and my finger moved to the send button when I was completing the message :))
Jordi Guillaumes i Pons
Barcelona - Catalunya - Europa
El 04/12/2012, a les 22:55, "Boyanich, Alastair" <Alastair.Boyanich at au.fujitsu.com> va escriure:
I've not messed around with TOPS-10/20 and only VMS on simh, but there
you need specify which O/S is running inside the VM and specify it with
something like:
set cpu idle=VMS
Well, KLH10 os a different beast. You have to patch the guest OS to do a write to an " idler" device so the simulator knows the guest is not doing anything and it can enter a wait state until next timer tick or interrups happens. This patch is included in the Panda monitor and it works as expected...
... Unless you happen to be using a "high performance" host system (he, and the Pi seems to fit that class lol...). Then you have to build the simulator to use a synchronous implementation for the timers and device interrupts (see https://groups.google.com/forum/m/?fromgroups#!msg/alt.sys.pdp10/vHcQ49tjMa…) and the idler simply does not work at all. Unfortunately it seem there is no fix for this problem (see https://groups.google.com/forum/m/?hl=en&fromgroups#!msg/alt.sys.pdp10/xndb…) so I will have to liv
