What a pity you didn't mention the Texas MSP430 single-chip system instead ;-)
Quote from: http://www.eg3.com/msp430.htm
"The MSP430 is a micro-controller family from Texas Instruments. Built around a 16-bit CPU, the MSP430 is designed for low cost, low power consumption embedded applications. The architecture is reminiscent of the DEC PDP-11. "
My first views upon this architecture makes me wonder where quite some of the addressing modes went, but this is certainly closer to a real PDP than any AVR!
All my best' to all PDP fan s
/G ran
On 2010-10-23 17:36, Paul Koning wrote:
GCC is way too big to fit on a PDP11. But it makes a fine cross-compiler. In fact, it can cross-compile for lots of smaller things, like AVR single chip microcontrollers (things that cost only a dollar or two).
paul
On Oct 23, 2010, at 10:47 AM, Pontus Pihlgren wrote:
On Fri, Oct 22, 2010 at 08:45:53PM -0400, Paul Koning wrote:
Does anyone here use gcc for the pdp11?
No, but I'm curious. Do you mean to run in on a PDP-11 or would you use
it to cross compile stuff?.
/P
GCC is way too big to fit on a PDP11. But it makes a fine cross-compiler. In fact, it can cross-compile for lots of smaller things, like AVR single chip microcontrollers (things that cost only a dollar or two).
paul
On Oct 23, 2010, at 10:47 AM, Pontus Pihlgren wrote:
On Fri, Oct 22, 2010 at 08:45:53PM -0400, Paul Koning wrote:
Does anyone here use gcc for the pdp11?
No, but I'm curious. Do you mean to run in on a PDP-11 or would you use
it to cross compile stuff?.
/P
On Fri, Oct 22, 2010 at 08:45:53PM -0400, Paul Koning wrote:
Does anyone here use gcc for the pdp11?
No, but I'm curious. Do you mean to run in on a PDP-11 or would you use
it to cross compile stuff?.
/P
Does anyone here use gcc for the pdp11?
I've been doing some work on it to clean it up. For one thing, it now builds, which certainly is a useful start... :-)
I've been playing with the idea of writing an 82586 driver (UGH!) for the Pro for RSTS, and seeing how disgustingly sick that chip is, doing it from scratch, or even seriously transforming existing assembly language drivers, is an unpleasant notion. On the other hand, doing it in C (more precisely, borrowing from, say, the NetBSD driver, changed as needed) seems more palatable.
I *think* gcc is close to being able to handle that job. So I'll probably be using it for that purpose. Am I the only user of that compiler or are there others?
paul
On 22/10/10 13:31, Johnny Billquist wrote:
On 10/22/10 14:20, Mark Wickens wrote:
Greetings
Following the hard disk tragedy earlier this month BUBBLE has risen
again like a Phoenix from the flames, and as a consequence the website
is now back up and, apart from the WALL, working much is it did pre-crash.
There is now a robust backup schedule in place to make sure this
situation never arises again.
I was thinking about Sampsa's phone directory program again - is there a
way to implement this so that it doesn't cause network issues?
Do it from VMS? :-)
It is only the Linux DECnet that causes my (and others?) logs to fill with data about not reached nodes.
Johnny
Ah OK
I couldn't remember the exact problem, but that now has jogged my memory.
VAX/VMS is the obvious choice for me ;)
Thanks, Mark.
On 10/22/10 14:20, Mark Wickens wrote:
Greetings
Following the hard disk tragedy earlier this month BUBBLE has risen
again like a Phoenix from the flames, and as a consequence the website
is now back up and, apart from the WALL, working much is it did pre-crash.
There is now a robust backup schedule in place to make sure this
situation never arises again.
I was thinking about Sampsa's phone directory program again - is there a
way to implement this so that it doesn't cause network issues?
Do it from VMS? :-)
It is only the Linux DECnet that causes my (and others?) logs to fill with data about not reached nodes.
Johnny
Greetings
Following the hard disk tragedy earlier this month BUBBLE has risen again like a Phoenix from the flames, and as a consequence the website is now back up and, apart from the WALL, working much is it did pre-crash.
There is now a robust backup schedule in place to make sure this situation never arises again.
I was thinking about Sampsa's phone directory program again - is there a way to implement this so that it doesn't cause network issues?
Regards, Mark.
On 2010-10-17 05:54, Steve Davidson wrote:
Let's take this off-line and figure something out. It looks like we are
pretty close anyway. How does that sound? If we come up with a mapping
then everyone could be on the right page with minimal confusion. This will
have to wait for a few hours - I need to get some sleep.
No problem. Take some sleep (I should too), and we can talk tomorrow. Maybe someone else have some opinion or views as well?
Right now I'm using the groups I mentioned earlier, but it would take me about five minutes to change it all, if I need to. So I guess it's just to decide how we'll do this, and I'll fix my end.
If you can think of some algorithmic way to set up a mapping, fine. Otherwise we'll just grab numbers out of the blue and "assign" them.
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
Johnny Billquist
On 2010-10-17 05:44, Steve Davidson wrote:
Johnny Billquist
On 2010-10-17 05:16, Steve Davidson wrote:
Johnny Billquist
On 2010-10-17 04:01, Johnny Billquist wrote:
So here is a new suggestion for the bridge which is "hubbed" around Update.
0 Publicly available systems
1 Update
2 BQT
Let me know, and I'll happily assign LAT groups for others as well.
Small correction to that list:
0 Public systems
1 Update
2 Update
3 BQT
4 BQT
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
Johnny,
The way I do it around here is use group 0 for public access. It is the
default group anyway. I use group 19, which is also my DECnet area for my
private use. This allows us to have 63 private areas if we map to DECnet area
numbers. Areas from 64 to 255 can be special case. I use 64 whe I want to
combine my group with someone else.
Nice that we agree on group 0. :-)
However, I see very little need to combine groups. If you want to
combine groups, just set the port to access both groups instead.
I would suggest that
group 0 be public
group 1 through 63 be private based on DECnet area # (self managed)
groups 64-255 be managed (and reserved) (each area could have 4 such #s)
I see a problem with that. Areas are not a good separation here. There
are several different people in area 1, for instance, which don't really
match the groups of systems that might be public or private.
I am (as you might have noticed) separating me (BQT) from Update, even
though we're both in area 1. There are more people in area 1 as well,
which I would believe it would make more sense to place in other groups
as well.
Also, I have further separated my groups into two parts. General access
systems and special services.
So, for me and Update, it now looks like this:
0 General public access
1 General public access for Update users
2 Consoles for Update machines
3 General access for my systems
4 Consoles for my systems
So, for Update terminal servers, I have set them to see machines in
group 0 and 1.
For my terminal servers, I see group 0,1 and 3 by default (since I'm
also using Update machines regularly).
When I need to fool around with systems, I also add group 2 and 4.
When Update people would need to fool around, they would add group 2,
they don't have access to my systems in general, and there is no point
for them to see those (my console) services.
I hope you see the point here.
Because I am already using group 64 I am reserving it. I make it available to
others when it makes sense for me to "share" as it were. Reserved groups
should be by invitation only because as you point out the list does get
cluttered.
No problem with that. I'm definitely no where near group 64 so far.
But I also think that people should not set their machines to be in
other groups than their own unless it is very obvious that the machines
actually belong in several groups.
But (as you probably know), there is no way to prevent anyone from
setting up any group numbers they want, so this will be very much by
voluntary participation.
The use of passwords is a great idea for the DECservers we have in HECnet.
Some of mine have it, some do not - personal choice.
Just making suggestions. :-)
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
When I rebuilt BUBBLE for Mark I enabled group 4 for his local group of
machines and group 19 so that we could go back and forth as necessary.
This was prior to your announcement of groups you proposed to use.
I just made a proposition because I started thinking that the list when
I do a "SHOW SERVICE" starts to look a bit long and cluttered with
machines that really are irrelevant for me to see.
However, I have absolutely no problem using other groups for me and
Update, so it's not about the numbers as such. But I definitely can't
work with a mapping to area numbers, since area numbers don't reflect
any division as such. It's more of a connectivity issue, with different
levels of routers.
Also, since LAT is not routed, this numbering scheme is very local to
the machines connected to this specific bridge segment, and is not
global for HECnet as a whole.
So I'll happily move myself to another LAT group. I just want two groups
for Update, and two for myself, so I can make a sensible separation
between different groups of services. And it would be nice to not have a
bunch of services in group 0 which are private, and possibly even not
general connections to login services.
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
Let's take this off-line and figure something out. It looks like we are
pretty close anyway. How does that sound? If we come up with a mapping
then everyone could be on the right page with minimal confusion. This will
have to wait for a few hours - I need to get some sleep.
-Steve
On 2010-10-17 05:44, Steve Davidson wrote:
Johnny Billquist
On 2010-10-17 05:16, Steve Davidson wrote:
Johnny Billquist
On 2010-10-17 04:01, Johnny Billquist wrote:
So here is a new suggestion for the bridge which is "hubbed" around Update.
0 Publicly available systems
1 Update
2 BQT
Let me know, and I'll happily assign LAT groups for others as well.
Small correction to that list:
0 Public systems
1 Update
2 Update
3 BQT
4 BQT
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
Johnny,
The way I do it around here is use group 0 for public access. It is the
default group anyway. I use group 19, which is also my DECnet area for my
private use. This allows us to have 63 private areas if we map to DECnet area
numbers. Areas from 64 to 255 can be special case. I use 64 whe I want to
combine my group with someone else.
Nice that we agree on group 0. :-)
However, I see very little need to combine groups. If you want to
combine groups, just set the port to access both groups instead.
I would suggest that
group 0 be public
group 1 through 63 be private based on DECnet area # (self managed)
groups 64-255 be managed (and reserved) (each area could have 4 such #s)
I see a problem with that. Areas are not a good separation here. There
are several different people in area 1, for instance, which don't really
match the groups of systems that might be public or private.
I am (as you might have noticed) separating me (BQT) from Update, even
though we're both in area 1. There are more people in area 1 as well,
which I would believe it would make more sense to place in other groups
as well.
Also, I have further separated my groups into two parts. General access
systems and special services.
So, for me and Update, it now looks like this:
0 General public access
1 General public access for Update users
2 Consoles for Update machines
3 General access for my systems
4 Consoles for my systems
So, for Update terminal servers, I have set them to see machines in
group 0 and 1.
For my terminal servers, I see group 0,1 and 3 by default (since I'm
also using Update machines regularly).
When I need to fool around with systems, I also add group 2 and 4.
When Update people would need to fool around, they would add group 2,
they don't have access to my systems in general, and there is no point
for them to see those (my console) services.
I hope you see the point here.
Because I am already using group 64 I am reserving it. I make it available to
others when it makes sense for me to "share" as it were. Reserved groups
should be by invitation only because as you point out the list does get
cluttered.
No problem with that. I'm definitely no where near group 64 so far.
But I also think that people should not set their machines to be in
other groups than their own unless it is very obvious that the machines
actually belong in several groups.
But (as you probably know), there is no way to prevent anyone from
setting up any group numbers they want, so this will be very much by
voluntary participation.
The use of passwords is a great idea for the DECservers we have in HECnet.
Some of mine have it, some do not - personal choice.
Just making suggestions. :-)
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
When I rebuilt BUBBLE for Mark I enabled group 4 for his local group of
machines and group 19 so that we could go back and forth as necessary.
This was prior to your announcement of groups you proposed to use.
I just made a proposition because I started thinking that the list when I do a "SHOW SERVICE" starts to look a bit long and cluttered with machines that really are irrelevant for me to see.
However, I have absolutely no problem using other groups for me and Update, so it's not about the numbers as such. But I definitely can't work with a mapping to area numbers, since area numbers don't reflect any division as such. It's more of a connectivity issue, with different levels of routers.
Also, since LAT is not routed, this numbering scheme is very local to the machines connected to this specific bridge segment, and is not global for HECnet as a whole.
So I'll happily move myself to another LAT group. I just want two groups for Update, and two for myself, so I can make a sensible separation between different groups of services. And it would be nice to not have a bunch of services in group 0 which are private, and possibly even not general connections to login services.
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
