On 16 Jan 2013, at 17:29, hvlems at zonnet.nl wrote:
Ethernet over mainspower runs at 50 Mb/s (a friend uses such a product). It is reliable but both rooms are on the same phase.
Wireless is your best bet. Two accesspoints in "remote bridge mode" ought to do the job.
If all else fails run ethernet over a phone line, 10 Mb/s is feasible depending on distance.
Any suggestions for access point models? I need one that doesn't suck if I go that approach.
------Origineel bericht------
Van: Cory Smelosky
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: [HECnet] Multi-floor household (DECnet) routing help needed
Verzonden: 16 januari 2013 23:12
Hello!
I'm going to be moving some of my equipment to the basement here for several reasons (heat produced, noise, space, et cetera), and in planning i'm hitting a roadblock: networking.
I've come up with several ideas:
Wireless client-bridge: Linksys e1000 is garbage and doesn't like to pass DECnet or any of those protocols, so i'd either need a workaround or a better router. (workaround being: a virtual cisco tunnel to my other virtual cisco?) (Other router: /real/ Cisco or a another suggestion from someone on this list)
Powerline ethernet: Is this reliable yet? How are the transfer speeds?
Or: Adding a phone jack, getting DSL on the second line here. (installation costs, but would actually be $2 more/month to upgrade current plan + add a second identical plan not counting hardware rental fees, setup costs, and that stuff)
Running cables all the way from the second floor isn't viable.
Any (viable) options i'm missing?
--
Cory Smelosky
http://gewt.net/ Personal stuff!
http://gimme-sympathy.org/ My permanently-a-work-in-progress pet project.
--
Cory Smelosky
http://gewt.net/ Personal stuff!
http://gimme-sympathy.org/ My permanently-a-work-in-progress pet project.
On Jan 15, 2013, at 10:22 PM, Gregg Levine wrote:
On Tue, Jan 15, 2013 at 11:00 AM, <Paul_Koning at dell.com> wrote:
...
Focal, Coral, Jovial (gag), Mumps. Then from the outside world: Algol-60, Algol-68,...
Hello!
What's wrong with Jovial? We've built a great air traffic control
system around it. Too bad the hardware is old enough to vote.
The designer clearly demonstrated that he has few brain cells and none of them contain any knowledge about structured programming languages or for that matter any of the design principles that make Algol-60 what it is.
I don't remember enough of the details, but that much was immediately obvious by inspection, and my conclusion was that I know all I need to know and I will never look for more.
paul
Ethernet over mainspower runs at 50 Mb/s (a friend uses such a product). It is reliable but both rooms are on the same phase.
Wireless is your best bet. Two accesspoints in "remote bridge mode" ought to do the job.
If all else fails run ethernet over a phone line, 10 Mb/s is feasible depending on distance.
------Origineel bericht------
Van: Cory Smelosky
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: [HECnet] Multi-floor household (DECnet) routing help needed
Verzonden: 16 januari 2013 23:12
Hello!
I'm going to be moving some of my equipment to the basement here for several reasons (heat produced, noise, space, et cetera), and in planning i'm hitting a roadblock: networking.
I've come up with several ideas:
Wireless client-bridge: Linksys e1000 is garbage and doesn't like to pass DECnet or any of those protocols, so i'd either need a workaround or a better router. (workaround being: a virtual cisco tunnel to my other virtual cisco?) (Other router: /real/ Cisco or a another suggestion from someone on this list)
Powerline ethernet: Is this reliable yet? How are the transfer speeds?
Or: Adding a phone jack, getting DSL on the second line here. (installation costs, but would actually be $2 more/month to upgrade current plan + add a second identical plan not counting hardware rental fees, setup costs, and that stuff)
Running cables all the way from the second floor isn't viable.
Any (viable) options i'm missing?
--
Cory Smelosky
http://gewt.net/ Personal stuff!
http://gimme-sympathy.org/ My permanently-a-work-in-progress pet project.
On Jan 15, 2013, at 9:09 PM, Jordi Guillaumes i Pons wrote:
El 15/01/2013, a les 17:56, Johnny Billquist <bqt at softjar.se> va escriure:
That it would... Anyone have GCC setup to generate something that can be linked under RSX?
Can't do that. But I'd bet it can generate code that can be linked under BSD2.11
(BTW the bug I found in the PDP-11 gas assembler is still there)
BSD support was removed from GCC, but I would think it could be put back.
Generating code that can link under RSX probably amounts to writing a libc for RSX, then (for now) tweaking the generated assembly code and assembling/linking under RSX. I haven't tried that, but I was planning to do that with RSTS (I'm hoping to use an existing DECNA driver written in C as the basis for one for RSTS).
I have a "bare metal simh" hacked up newlib, just good enough to run the execution tests of the GCC test suite.
Right now the main issue seems to be that some floating point code kills the compiler. I've tried for a long time to get it to deal correctly with ac4/ac5 which can't directly load/store to memory, and haven't succeeded yet. It's supposed to be possible. I may end up disabling those two registers for now.
paul
On Jan 16, 2013, at 5:21 PM, <Paul_Koning at Dell.com>
wrote:
On Jan 16, 2013, at 3:17 PM, Cory Smelosky wrote:
On 15 Jan 2013, at 20:25, Jordi Guillaumes i Pons <jg at jordi.guillaumes.name> wrote:
El 15/01/2013, a les 20:27, Paul_Koning at Dell.com va escriure:
When I build it with the default build settings (async I/O enabled) both PDP11 and VAX hang at boot. Built with NOASYNCH and it runs fine. I haven't tried other platforms.
I have. Mark is working on the hang issues. He has fixed some of the bugs, but that asynch code seems to be specially hard to debug. BTW it is a multicore-multiprocessor issue also observed in other operating systems.
I'm curious if anyone else has tried it, or has ideas of what's wrong here. When it gets in this state, I have to kill the process; it won't answer interrupts or even SIGTERM.
I run it with asynch disabled for the time being.
When I try that, it fails to link.
Undefined symbols for architecture x86_64:
"_clock_gettime", referenced from:
_todr_wr in ccGqWyaE.o
_todr_resync in ccGqWyaE.o
_todr_rd in ccGqWyaE.o
ld: symbol(s) not found for architecture x86_64
I noticed that one. Find clock_gettime. It's currently conditional on two things one of which is async support. Take away that second check.
paul
I should have just looked it up first rather than answering from memory. Here is the fix:
diff --git a/sim_timer.c b/sim_timer.c
index 6044643..8c1e9e7 100644
--- a/sim_timer.c
+++ b/sim_timer.c
@@ -402,7 +402,7 @@ if (tim > SIM_IDLE_MAX)
tim = 0;
return tim;
}
-#if !defined(_POSIX_SOURCE) && defined(SIM_ASYNCH_IO)
+#if !defined(_POSIX_SOURCE)
#ifdef NEED_CLOCK_GETTIME
typedef int clockid_t;
int clock_gettime(clockid_t clk_id, struct timespec *tp)
paul
On Jan 16, 2013, at 3:17 PM, Cory Smelosky wrote:
On 15 Jan 2013, at 20:25, Jordi Guillaumes i Pons <jg at jordi.guillaumes.name> wrote:
El 15/01/2013, a les 20:27, Paul_Koning at Dell.com va escriure:
When I build it with the default build settings (async I/O enabled) both PDP11 and VAX hang at boot. Built with NOASYNCH and it runs fine. I haven't tried other platforms.
I have. Mark is working on the hang issues. He has fixed some of the bugs, but that asynch code seems to be specially hard to debug. BTW it is a multicore-multiprocessor issue also observed in other operating systems.
I'm curious if anyone else has tried it, or has ideas of what's wrong here. When it gets in this state, I have to kill the process; it won't answer interrupts or even SIGTERM.
I run it with asynch disabled for the time being.
When I try that, it fails to link.
Undefined symbols for architecture x86_64:
"_clock_gettime", referenced from:
_todr_wr in ccGqWyaE.o
_todr_resync in ccGqWyaE.o
_todr_rd in ccGqWyaE.o
ld: symbol(s) not found for architecture x86_64
I noticed that one. Find clock_gettime. It's currently conditional on two things one of which is async support. Take away that second check.
paul
Hello!
I'm going to be moving some of my equipment to the basement here for several reasons (heat produced, noise, space, et cetera), and in planning i'm hitting a roadblock: networking.
I've come up with several ideas:
Wireless client-bridge: Linksys e1000 is garbage and doesn't like to pass DECnet or any of those protocols, so i'd either need a workaround or a better router. (workaround being: a virtual cisco tunnel to my other virtual cisco?) (Other router: /real/ Cisco or a another suggestion from someone on this list)
Powerline ethernet: Is this reliable yet? How are the transfer speeds?
Or: Adding a phone jack, getting DSL on the second line here. (installation costs, but would actually be $2 more/month to upgrade current plan + add a second identical plan not counting hardware rental fees, setup costs, and that stuff)
Running cables all the way from the second floor isn't viable.
Any (viable) options i'm missing?
--
Cory Smelosky
http://gewt.net/ Personal stuff!
http://gimme-sympathy.org/ My permanently-a-work-in-progress pet project.
On 2013-01-16 21:17, Steve Davidson wrote:
The PDP-11 "C" compiler was a buyout. It started life out as a PASCAL compiler. The first project leader (J. Bishop) works for Intel - on the West Coast.
I believe that to be incorrect.
I had to search through my archives of stuff, to check, as it didn't match my hazy memories.
The project leader for the DEC PDP-11 C compiler was Thomas Krupinski, and he was the project leader all the way from the beginning to the end. And it was never a PASCAL compiler, nor did it start outside of DEC.
Here is excerpts from a conversation I had with him a number of years ago:
***
> I wouldn't be surprised if DEC C was written in MACRO-11. I very much
> doubt DECUS C was involved anyway.
I suspect you are referring to Digital's PDP-11 C. A
couple years before this project was begun, an
engineer was tasked with investigating if it would be
feasable to "productize" DECUS C. The engineer
concluded it wasn't. PDP-11 C is written mostly in C,
with a very small amount of code written in MACRO-11.
The compiler compiles itself for the RT-11, RSX and
RSTS/E versions, and is compiled by VAXC (PDP-11C
preceeded DEC C) for a cross compiler running on VMS
and producing PDP-11 code. The compiler will produce
either .obj files or MACRO-11 (or both). The latter
was useful when a member of the RSTS/E group
implemented a CUSP in PDP-11 C while it was still in
beta - Management wouldn't let him release it since it
was compiled with an unreleased product (strange, that
never stopped folks from releasing code written using
the BLISS-11 compiler), so he simply compiled it to
MACRO-11, and checked that in, since MACRO-11 was
supported...
> none used DECUS C as a bootstrap as far as I know.
I can confirm that PDP-11 C did not bootstrap using
DECUS C.
Tom Krupinski
Project leader for PDP-11 C V1.0, V1.1, V1.2
(And the engineer who did the DECUS C investigation)
***
I have not talked with him in ages now...
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-01-16 21:26, Steve Davidson wrote:
Is their a version of PCC that could generate PDP-11 assembly code?
Generating assembly code is only half of the problem. To compile and run this thing, you also need enough parts of a C library to make it work, and matching calling conventions between your compiled code and that C library...
Johnny
-Steve
________________________________
From: owner-hecnet at Update.UU.SE on behalf of John Wilson
Sent: Tue 1/15/2013 21:46
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Benchmarks - WHETSTONE.C
On Tue, Jan 15, 2013 at 05:56:33PM +0100, Johnny Billquist wrote:
That it would... Anyone have GCC setup to generate something that can
be linked under RSX?
That's a tall order (adding .OBJ to binutils?) ... and lately I think GCC for
PDP-11s is pretty badly broken. I built the (then-)latest GCC to cross-compile
for PDP-11s a few weeks ago (working on porting Conticki) and it's pretty
broken -- stack frames get all tangled up on any function with >2 locals.
Turning off frame pointers or enabling optimization just makes it worse.
I did a temporary hack which got it generating seemingly correct (but *awful*)
code, but I didn't understand how it worked well enough to really fix it. It
seems like it's trying to keep track of modifications to SP but apparently on
*any* modification it assumes that it's lost track of the top of the stack
(even if the modification was push and then pop, i.e. no net change) and tries
to dig its way out with the frame pointer (which it gets off by a word).
But anyway ... I would think a GAS-to-MACRO translator wouldn't be too
difficult to write, since GCC doesn't depend too heavily on GASsisms.
John Wilson
D Bit
--
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
