19 Oct
2015
19 Oct
'15
12:30 a.m.
These are the cards in the DecServer 550. Looks to be an expansion
chassis with 108 ports or so.
Thanks
Jim
Photos of the DecServer 550
https://drive.google.com/folderview?id=0B4AXJXpUCE-hQ2lsc2lqS3VHd0U&usp…
19 Oct
19 Oct
12:42 a.m.
Interesting. I thought Tthe DECserver 550 was merely the big brother in
the terminal server line. But it looks like it is essentially a
PDP-11/53 with 1.5MW of ram, you need new boot roms though. Pretty nice.
http://home.windstream.net/engdahl/kdj11.htm
/P
On Mon, Oct 19, 2015 at 12:30:00AM -0700, jwsmobile wrote:
These are the cards in the DecServer 550. Looks to be an expansion
chassis with 108 ports or so.
Thanks
Jim
Photos of the DecServer 550
https://drive.google.com/folderview?id=0B4AXJXpUCE-hQ2lsc2lqS3VHd0U&usp…
12:57 a.m.
On 10/19/2015 12:42 AM, Pontus Pihlgren wrote:
Interesting. I thought Tthe DECserver 550 was merely
the big brother in
the terminal server line. But it looks like it is essentially a
PDP-11/53 with 1.5MW of ram, you need new boot roms though. Pretty nice.
http://home.windstream.net/engdahl/kdj11.htm
/P
Thanks for the link. I've already been analyzing that. Tomorrow will
pull it out, clean it off and see what more details can be had. The KDJ
was an interesting surprise.
We may have enough to do the conversion talked about in the articles he
has, but they aren't for the faint hearted w/o reading all that he has
there.
We may have the RQ controller which is pretty much an essential bit to
have. The disk drive is another matter. Will take some rummaging
around to find a suitable candidate.
Thanks
Jim
On Mon, Oct 19, 2015 at 12:30:00AM -0700, jwsmobile wrote:
These are the cards in the DecServer 550. Looks
to be an expansion
chassis with 108 ports or so.
Thanks
Jim
Photos of the DecServer 550
https://drive.google.com/folderview?id=0B4AXJXpUCE-hQ2lsc2lqS3VHd0U&usp…
7:32 a.m.
On Oct 19, 2015, at 3:42 AM, Pontus Pihlgren
<pontus at Update.UU.SE> wrote:
Interesting. I thought Tthe DECserver 550 was merely the big brother in
the terminal server line. But it looks like it is essentially a
PDP-11/53 with 1.5MW of ram, you need new boot roms though. Pretty nice.
It's been a while, but I think it may be a member of the "pluto" family.
The original plan for terminal servers was that they would run CTERM. But the initial
Pluto terminal server was incredibly slow, not surprising given how complex that protocol
is. So an AD project was started which created LAT, originally also in a PDP-11 processor
(perhaps even the same one, I forgot). And that turned out to be so superior in practice
that it ended up being the main product instead of the original plan. But we still have
CTERM as a leftover from all this.
paul
9:17 a.m.
On 2015-10-19 16:32, Paul Koning wrote:
Yeah, that should be PLUTO.
It's based on RSX, and talks LAT. I never knew that they considered
using CTERM (a horrible protocol).
The interface in PLUTO, once it has booted, is pretty much like other
DECservers, as far as I understand. But they were larger, more flexible,
and so on, than later DECserver models, since they were built on PDP-11s
in a Qbus chassis.
Johnny
On Oct 19, 2015, at 3:42 AM, Pontus Pihlgren
<pontus at Update.UU.SE> wrote:
Interesting. I thought Tthe DECserver 550 was merely the big brother in
the terminal server line. But it looks like it is essentially a
PDP-11/53 with 1.5MW of ram, you need new boot roms though. Pretty nice.
It's been a while, but I think it may be a member of the "pluto" family.
The original plan for terminal servers was that they would run CTERM. But the initial
Pluto terminal server was incredibly slow, not surprising given how complex that protocol
is. So an AD project was started which created LAT, originally also in a PDP-11 processor
(perhaps even the same one, I forgot). And that turned out to be so superior in practice
that it ended up being the main product instead of the original plan. But we still have
CTERM as a leftover from all this.
10:42 a.m.
On Oct 19, 2015, at 12:17 PM, Johnny Billquist <bqt
at update.uu.se> wrote:
On 2015-10-19 16:32, Paul Koning wrote:
Yeah, that should be PLUTO.
It's based on RSX, and talks LAT. I never knew that they considered using CTERM (a
horrible protocol).
Oh yes... and I think the original PLUTO was an 11/23, which would certainly explain why
it had performance issues.
CTERM was an attempt to wrap a single protocol around the terribly inconsistent semantics
of the terminal drivers in all the DEC operating systems, and to export as much as
possible to the server end. In other words, the goal of the protocol was to be line
oriented as much as possible. That meant, for example, exporting the command line editing
machinery to the server. That doesn't seem so bad until you realize that the server
has to be told a whole lot about what is going on at the client in order to do that. The
eventual goal was to have not just command line mode but also other modes, like screen
editing mode (think distributed EDT). That's why there are two layers, with the
foundation layer common to all modes, and Cterm the first of the modes to be defined.
Some example of the complexities: the ability to define what characters are line edings;
immediate vs. delayed echo; command line completion in TOPS-20; and so on.
When the dust settled, the 36 bit machines were starting to disappear around this time,
and management was trying to do similar things to PDP11s in general and non-RSX in
particular, so CTerm ended up being really just a ridiculously complex way of doing what
the old VMS terminal protocol did just as well.
paul
On Oct 19, 2015, at 3:42 AM, Pontus Pihlgren
<pontus at Update.UU.SE> wrote:
Interesting. I thought Tthe DECserver 550 was merely the big brother in
the terminal server line. But it looks like it is essentially a
PDP-11/53 with 1.5MW of ram, you need new boot roms though. Pretty nice.
It's been a while, but I think it may be a member of the "pluto" family.
The original plan for terminal servers was that they would run CTERM. But the initial
Pluto terminal server was incredibly slow, not surprising given how complex that protocol
is. So an AD project was started which created LAT, originally also in a PDP-11 processor
(perhaps even the same one, I forgot). And that turned out to be so superior in practice
that it ended up being the main product instead of the original plan. But we still have
CTERM as a leftover from all this.
11:30 a.m.
On 2015-10-19 19:42, Paul Koning wrote:
An interesting way to describe it.
I've always looked at CTERM as an RPC service that essentially have all
the functions of the VMS terminal driver. Makes it easy to implement in
VMS, as you have a 1:1 mapping. Makes it horrible for everyone else,
since other systems do not have the same functionality in the terminal
driver, and now have to implement all the remote procedure calls of the
VMS terminal driver, and somehow map that into how the native terminal
driver works...
Johnny
On Oct 19, 2015, at 12:17 PM, Johnny Billquist
<bqt at update.uu.se> wrote:
On 2015-10-19 16:32, Paul Koning wrote:
Yeah, that should be PLUTO.
It's based on RSX, and talks LAT. I never knew that they considered using CTERM (a
horrible protocol).
Oh yes... and I think the original PLUTO was an 11/23, which would certainly explain why
it had performance issues.
CTERM was an attempt to wrap a single protocol around the terribly inconsistent semantics
of the terminal drivers in all the DEC operating systems, and to export as much as
possible to the server end. In other words, the goal of the protocol was to be line
oriented as much as possible. That meant, for example, exporting the command line editing
machinery to the server. That doesn't seem so bad until you realize that the server
has to be told a whole lot about what is going on at the client in order to do that. The
eventual goal was to have not just command line mode but also other modes, like screen
editing mode (think distributed EDT). That's why there are two layers, with the
foundation layer common to all modes, and Cterm the first of the modes to be defined.
Some example of the complexities: the ability to define what characters are line edings;
immediate vs. delayed echo; command line completion in TOPS-20; and so on.
When the dust settled, the 36 bit machines were starting to disappear around this time,
and management was trying to do similar things to PDP11s in general and non-RSX in
particular, so CTerm ended up being really just a ridiculously complex way of doing what
the old VMS terminal protocol did just as well. On Oct 19, 2015, at 3:42 AM, Pontus Pihlgren
<pontus at Update.UU.SE> wrote:
Interesting. I thought Tthe DECserver 550 was merely the big brother in
the terminal server line. But it looks like it is essentially a
PDP-11/53 with 1.5MW of ram, you need new boot roms though. Pretty nice.
It's been a while, but I think it may be a member of the "pluto" family.
The original plan for terminal servers was that they would run CTERM. But the initial
Pluto terminal server was incredibly slow, not surprising given how complex that protocol
is. So an AD project was started which created LAT, originally also in a PDP-11 processor
(perhaps even the same one, I forgot). And that turned out to be so superior in practice
that it ended up being the main product instead of the original plan. But we still have
CTERM as a leftover from all this.
11:43 a.m.
On Oct 19, 2015, at 2:30 PM, Johnny Billquist <bqt
at Update.UU.SE> wrote:
On 2015-10-19 19:42, Paul Koning wrote:
You can certainly view it as an RPC, and given that Cterm ended up basically doing VMS,
looking at it as the RPC version of the VMS terminal driver is reasonably accurate. But
the original version aimed to support both VMS and TOPS-20 as primary clients, and other
operating systems as well. So it was supposed to be an RPC version of the union of all
terminal drivers. Which means that a full CTERM server (as opposed to client) would be
hard to do for everyone, even VMS.
paul
...
CTERM was an attempt to wrap a single protocol around the terribly inconsistent semantics
of the terminal drivers in all the DEC operating systems, and to export as much as
possible to the server end. ...
An interesting way to describe it.
I've always looked at CTERM as an RPC service that essentially have all the functions
of the VMS terminal driver. Makes it easy to implement in VMS, as you have a 1:1 mapping.
Makes it horrible for everyone else, since other systems do not have the same
functionality in the terminal driver, and now have to implement all the remote procedure
calls of the VMS terminal driver, and somehow map that into how the native terminal driver
works...
11:46 a.m.
On 2015-10-19 20:43, Paul Koning wrote:
The amount of swearwords from TOPS-20 people exceed all others combined,
in my experience. So if they intended CTERM to be something reasonable
for TOPS-20 it was an utter failure. :-)
And it's really silly and sad, considering that something like telnet is
very simple and straight forward, and can be done right on both VMS and
TOPS-20, and will in the end work much better for people connecting from
one to the other, than using CTERM...
(I have the same issues with CTERM under RSX. telnet makes so much more
sense.)
Johnny
On Oct 19, 2015, at 2:30 PM, Johnny Billquist
<bqt at Update.UU.SE> wrote:
On 2015-10-19 19:42, Paul Koning wrote:
You can certainly view it as an RPC, and given that Cterm ended up basically doing VMS,
looking at it as the RPC version of the VMS terminal driver is reasonably accurate. But
the original version aimed to support both VMS and TOPS-20 as primary clients, and other
operating systems as well. So it was supposed to be an RPC version of the union of all
terminal drivers. Which means that a full CTERM server (as opposed to client) would be
hard to do for everyone, even VMS. ...
CTERM was an attempt to wrap a single protocol around the terribly inconsistent semantics
of the terminal drivers in all the DEC operating systems, and to export as much as
possible to the server end. ...
An interesting way to describe it.
I've always looked at CTERM as an RPC service that essentially have all the functions
of the VMS terminal driver. Makes it easy to implement in VMS, as you have a 1:1 mapping.
Makes it horrible for everyone else, since other systems do not have the same
functionality in the terminal driver, and now have to implement all the remote procedure
calls of the VMS terminal driver, and somehow map that into how the native terminal driver
works...
11:55 a.m.
On Oct 19, 2015, at 2:46 PM, Johnny Billquist <bqt
at update.uu.se> wrote:
On 2015-10-19 20:43, Paul Koning wrote:
The amount of swearwords from TOPS-20 people exceed all others combined, in my
experience. So if they intended CTERM to be something reasonable for TOPS-20 it was an
utter failure. :-)
Yes.
On Oct 19, 2015, at 2:30 PM, Johnny Billquist
<bqt at Update.UU.SE> wrote:
On 2015-10-19 19:42, Paul Koning wrote:
You can certainly view it as an RPC, and given that Cterm ended up basically doing VMS,
looking at it as the RPC version of the VMS terminal driver is reasonably accurate. But
the original version aimed to support both VMS and TOPS-20 as primary clients, and other
operating systems as well. So it was supposed to be an RPC version of the union of all
terminal drivers. Which means that a full CTERM server (as opposed to client) would be
hard to do for everyone, even VMS. ...
CTERM was an attempt to wrap a single protocol around the terribly inconsistent semantics
of the terminal drivers in all the DEC operating systems, and to export as much as
possible to the server end. ...
An interesting way to describe it.
I've always looked at CTERM as an RPC service that essentially have all the functions
of the VMS terminal driver. Makes it easy to implement in VMS, as you have a 1:1 mapping.
Makes it horrible for everyone else, since other systems do not have the same
functionality in the terminal driver, and now have to implement all the remote procedure
calls of the VMS terminal driver, and somehow map that into how the native terminal driver
works... And it's really silly and sad, considering that
something like telnet is very simple and straight forward, and can be done right on both
VMS and TOPS-20, and will in the end work much better for people connecting from one to
the other, than using CTERM...
(I have the same issues with CTERM under RSX. telnet makes so much more sense.)
Sure, telnet in character mode (not line mode) works for everyone because it doesn't
try to export any real work to the server end.
For the same reason, the older remote terminal protocols (the set of 4, before Cterm was
perpetrated) work great. Those simply export primitives suitable for the OS in question.
Simple line mode with the ability to switch to character mode for RSTS, character mode all
the time for TOPS-20, and a much simpler RSX and VMS terminal driver QIO RPC for those two
operating systems. All these are so easy that RSTS can implement them all, quite unlike
Cterm.
paul
7:32 a.m.
On Mon, Oct 19, 2015 at 3:42 AM, Pontus Pihlgren <pontus at update.uu.se> wrote:
Interesting. I thought Tthe DECserver 550 was merely
the big brother in
the terminal server line. But it looks like it is essentially a
PDP-11/53 with 1.5MW of ram, you need new boot roms though. Pretty nice.
Yep. It's essentially an S-box KDJ11 with different ROMs. I happen
to have a CPU board from one, but not the box itself.
One of these days, I plan to burn "real" PDP-11 ROMs and bring 2.11BSD
up on mine. That and my Pro380 are my only KDJ11 machines.
-ethan
9:28 a.m.
I would appreciate thoughts on the conversion of the processor to normal
PDP11 eproms.
The page pointed to earlier has a mention of that too, but the poster
had access to another "real" KDJ and I am guessing copied that.
I don't have access to any version of the system with appropriate eproms
and would appreciate any pointers to the binaries needed.
As to the condition most of the material is the result of moving it from
where it was stored. It will be totally disassembled and tested before
being brought back up. There is about 5 or 6 large deep freeze (for
reference) sized piles of material being sent for e-waste from the place
that is pretty much just junk material under the weather.
Think of this as a Dusenberg rescued from a barn though.
thanks for all the suggestions and observations.
Next thing to go over is a Sun 4/260 "mini" tower. Gads those were
heavy. Back is still aching from moving that.
Jim
On 10/19/2015 7:32 AM, Ethan Dicks wrote:
On Mon, Oct 19, 2015 at 3:42 AM, Pontus Pihlgren
<pontus at update.uu.se> wrote:
Interesting. I thought Tthe DECserver 550 was
merely the big brother in
the terminal server line. But it looks like it is essentially a
PDP-11/53 with 1.5MW of ram, you need new boot roms though. Pretty nice.
Yep.
It's essentially an S-box KDJ11 with different ROMs. I happen
to have a CPU board from one, but not the box itself.
One of these days, I plan to burn "real" PDP-11 ROMs and bring 2.11BSD
up on mine. That and my Pro380 are my only KDJ11 machines.
-ethan
10:03 a.m.
Not sure what you expect a "conversion" means. Creating new PROMs imply
finding actual proms, a prom programmer, the code to program into the
PROMs, and then just replace the proms on the card.
Only the last piece will actually require any modification of the card,
and I would expect them to be socketed anyway, so replacing means just
removing the old proms, and inserting the new ones.
The note also mentioned that you might want/need to install a pull-up.
But it would still be an extremely simple process. You just need the
right bits...
Johnny
On 2015-10-19 18:28, jwsmobile wrote:
I would appreciate thoughts on the conversion of the
processor to normal
PDP11 eproms.
The page pointed to earlier has a mention of that too, but the poster
had access to another "real" KDJ and I am guessing copied that.
I don't have access to any version of the system with appropriate eproms
and would appreciate any pointers to the binaries needed.
As to the condition most of the material is the result of moving it from
where it was stored. It will be totally disassembled and tested before
being brought back up. There is about 5 or 6 large deep freeze (for
reference) sized piles of material being sent for e-waste from the place
that is pretty much just junk material under the weather.
Think of this as a Dusenberg rescued from a barn though.
thanks for all the suggestions and observations.
Next thing to go over is a Sun 4/260 "mini" tower. Gads those were
heavy. Back is still aching from moving that.
Jim
On 10/19/2015 7:32 AM, Ethan Dicks wrote:
On Mon, Oct 19, 2015 at 3:42 AM, Pontus Pihlgren
<pontus at update.uu.se>
wrote:
Interesting. I thought Tthe DECserver 550 was
merely the big brother in
the terminal server line. But it looks like it is essentially a
PDP-11/53 with 1.5MW of ram, you need new boot roms though. Pretty nice.
Yep.
It's essentially an S-box KDJ11 with different ROMs. I happen
to have a CPU board from one, but not the box itself.
One of these days, I plan to burn "real" PDP-11 ROMs and bring 2.11BSD
up on mine. That and my Pro380 are my only KDJ11 machines.
-ethan
11:57 a.m.
On 10/19/2015 10:03 AM, Johnny Billquist wrote:
Not sure what you expect a "conversion"
means. Creating new PROMs
imply finding actual proms, a prom programmer, the code to program
into the PROMs, and then just replace the proms on the card.
Only the last piece will actually require any modification of the
card, and I would expect them to be socketed anyway, so replacing
means just removing the old proms, and inserting the new ones.
That is basically what I said. I don't have one that isn't part of a
DecServer and i need images, or someone with a non DecServer to provide
them.
I guess you restated what I said. if you have one, I'd appreciate copies.
I didn't post the original link from the top of this thread, you might
want to read it. I'm just stating what someone did back in the 2001
time frame and posted a page about the conversion and info on his
experiences.
The note also mentioned that you might want/need to
install a pull-up.
But it would still be an extremely simple process. You just need the
right bits...
What I said.
Johnny
On 2015-10-19 18:28, jwsmobile wrote:
I would appreciate thoughts on the conversion of
the processor to normal
PDP11 eproms.
The page pointed to earlier has a mention of that too, but the poster
had access to another "real" KDJ and I am guessing copied that.
I don't have access to any version of the system with appropriate eproms
and would appreciate any pointers to the binaries needed.
As to the condition most of the material is the result of moving it from
where it was stored. It will be totally disassembled and tested before
being brought back up. There is about 5 or 6 large deep freeze (for
reference) sized piles of material being sent for e-waste from the place
that is pretty much just junk material under the weather.
Think of this as a Dusenberg rescued from a barn though.
thanks for all the suggestions and observations.
Next thing to go over is a Sun 4/260 "mini" tower. Gads those were
heavy. Back is still aching from moving that.
Jim
On 10/19/2015 7:32 AM, Ethan Dicks wrote:
On Mon, Oct 19, 2015 at 3:42 AM, Pontus Pihlgren
<pontus at update.uu.se>
wrote:
Interesting. I thought Tthe DECserver 550 was
merely the big
brother in
the terminal server line. But it looks like it is essentially a
PDP-11/53 with 1.5MW of ram, you need new boot roms though. Pretty
nice.
Yep. It's essentially an S-box KDJ11 with different ROMs. I happen
to have a CPU board from one, but not the box itself.
One of these days, I plan to burn "real" PDP-11 ROMs and bring 2.11BSD
up on mine. That and my Pro380 are my only KDJ11 machines.
-ethan
12:03 p.m.
On Mon, Oct 19, 2015 at 11:57 AM, jwsmobile <jws at jwsss.com> wrote:
That is basically what I said. I don't have one that isn't part of a
DecServer and i need images, or someone with a non DecServer to provide
them.
I guess you restated what I said. if you have one, I'd appreciate copies.
The 23-261E5 / 23-262E5 firmware images for the M7554 11/53 are
available on Pete's DECROM archive.
http://www.dunnington.info/public/DECROMs/
12:24 p.m.
On 10/19/2015 12:03 PM, Glen Slick wrote:
On Mon, Oct 19, 2015 at 11:57 AM, jwsmobile <jws at
jwsss.com> wrote:
Thanks, Glen!
That is basically what I said. I don't have
one that isn't part of a
DecServer and i need images, or someone with a non DecServer to provide
them.
I guess you restated what I said. if you have one, I'd appreciate copies.
The 23-261E5 / 23-262E5 firmware images for the M7554 11/53 are
available on Pete's DECROM archive.
http://www.dunnington.info/public/DECROMs/
1:43 p.m.
On 19/10/2015 20:24, jwsmobile wrote:
On 10/19/2015 12:03 PM, Glen Slick wrote:
> The 23-261E5 / 23-262E5 firmware images for the
M7554 11/53 are
> available on Pete's DECROM archive.
>
> http://www.dunnington.info/public/DECROMs/
Thanks, Glen!
Glen beat me to it :-)
--
Pete
Pete Turnbull
12:39 p.m.
Well, you did ask for "thoughts in the conversion", so I gave you mine.
Sorry if you felt they were unhelpful. I just thought the "conversion"
was basically a no-work. Programming proms is something I have spent
more time than I can count on, and is so routine that I don't even think
about it.
Johnny
On 2015-10-19 20:57, jwsmobile wrote:
On 10/19/2015 10:03 AM, Johnny Billquist wrote:
Not sure what you expect a "conversion"
means. Creating new PROMs
imply finding actual proms, a prom programmer, the code to program
into the PROMs, and then just replace the proms on the card.
Only the last piece will actually require any modification of the
card, and I would expect them to be socketed anyway, so replacing
means just removing the old proms, and inserting the new ones.
That is basically what I said. I don't have one that isn't part of a
DecServer and i need images, or someone with a non DecServer to provide
them.
I guess you restated what I said. if you have one, I'd appreciate copies.
I didn't post the original link from the top of this thread, you might
want to read it. I'm just stating what someone did back in the 2001
time frame and posted a page about the conversion and info on his
experiences.
The note also mentioned that you might want/need
to install a pull-up.
But it would still be an extremely simple process. You just need the
right bits...
What I said.
Johnny
On 2015-10-19 18:28, jwsmobile wrote:
I would appreciate thoughts on the conversion of
the processor to normal
PDP11 eproms.
The page pointed to earlier has a mention of that too, but the poster
had access to another "real" KDJ and I am guessing copied that.
I don't have access to any version of the system with appropriate eproms
and would appreciate any pointers to the binaries needed.
As to the condition most of the material is the result of moving it from
where it was stored. It will be totally disassembled and tested before
being brought back up. There is about 5 or 6 large deep freeze (for
reference) sized piles of material being sent for e-waste from the place
that is pretty much just junk material under the weather.
Think of this as a Dusenberg rescued from a barn though.
thanks for all the suggestions and observations.
Next thing to go over is a Sun 4/260 "mini" tower. Gads those were
heavy. Back is still aching from moving that.
Jim
On 10/19/2015 7:32 AM, Ethan Dicks wrote:
On Mon, Oct 19, 2015 at 3:42 AM, Pontus Pihlgren
<pontus at update.uu.se>
wrote:
> Interesting. I thought Tthe DECserver 550 was merely the big
> brother in
> the terminal server line. But it looks like it is essentially a
> PDP-11/53 with 1.5MW of ram, you need new boot roms though. Pretty
> nice.
Yep. It's essentially an S-box KDJ11 with different ROMs. I happen
to have a CPU board from one, but not the box itself.
One of these days, I plan to burn "real" PDP-11 ROMs and bring 2.11BSD
up on mine. That and my Pro380 are my only KDJ11 machines.
-ethan
2:11 p.m.
On 10/19/2015 12:39 PM, Johnny Billquist wrote:
Well, you did ask for "thoughts in the
conversion", so I gave you
mine. Sorry if you felt they were unhelpful. I just thought the
"conversion" was basically a no-work. Programming proms is something I
have spent more time than I can count on, and is so routine that I
don't even think about it.
I didn't mean that in disrespect. The contents of what I posted was on
the page and I basically needed the binaries and needed some direction
as to which went where. I appreciate you taking time to reply, but am
coming from a lot less capability than you have. I do a lot of
computing and the like, but I've purposely not kept up with eprom
technology to the point that i can't reliably swear I can program them
right now.
There are only so many things one can keep up with and eproms were not
one that was cheap to follow, and I was more into EE type devices anyway.
I may need a favor by swapping you some of my eproms (I have a 12" x 12"
x 12" box of pulls) maybe to get you to make me a set for my board.
I've pulled out probably 500 and returned them to the original owner and
owe him more. but I do probably have a lot of the 27xx proms.
Do you think these are 27C or just straight 27 type eproms, and if so
what speeds? That is what I need to know too.
thanks
Jim
Johnny
On 2015-10-19 20:57, jwsmobile wrote:
On 10/19/2015 10:03 AM, Johnny Billquist wrote:
Not sure what you expect a "conversion"
means. Creating new PROMs
imply finding actual proms, a prom programmer, the code to program
into the PROMs, and then just replace the proms on the card.
Only the last piece will actually require any modification of the
card, and I would expect them to be socketed anyway, so replacing
means just removing the old proms, and inserting the new ones.
That is basically what I said. I don't have one that isn't part of a
DecServer and i need images, or someone with a non DecServer to provide
them.
I guess you restated what I said. if you have one, I'd appreciate
copies.
I didn't post the original link from the top of this thread, you might
want to read it. I'm just stating what someone did back in the 2001
time frame and posted a page about the conversion and info on his
experiences.
The note also mentioned that you might want/need
to install a pull-up.
But it would still be an extremely simple process. You just need the
right bits...
What I said.
Johnny
On 2015-10-19 18:28, jwsmobile wrote:
I would appreciate thoughts on the conversion of
the processor to
normal
PDP11 eproms.
The page pointed to earlier has a mention of that too, but the poster
had access to another "real" KDJ and I am guessing copied that.
I don't have access to any version of the system with appropriate
eproms
and would appreciate any pointers to the binaries needed.
As to the condition most of the material is the result of moving it
from
where it was stored. It will be totally disassembled and tested
before
being brought back up. There is about 5 or 6 large deep freeze (for
reference) sized piles of material being sent for e-waste from the
place
that is pretty much just junk material under the weather.
Think of this as a Dusenberg rescued from a barn though.
thanks for all the suggestions and observations.
Next thing to go over is a Sun 4/260 "mini" tower. Gads those were
heavy. Back is still aching from moving that.
Jim
On 10/19/2015 7:32 AM, Ethan Dicks wrote:
> On Mon, Oct 19, 2015 at 3:42 AM, Pontus Pihlgren
> <pontus at update.uu.se>
> wrote:
>> Interesting. I thought Tthe DECserver 550 was merely the big
>> brother in
>> the terminal server line. But it looks like it is essentially a
>> PDP-11/53 with 1.5MW of ram, you need new boot roms though. Pretty
>> nice.
> Yep. It's essentially an S-box KDJ11 with different ROMs. I happen
> to have a CPU board from one, but not the box itself.
>
> One of these days, I plan to burn "real" PDP-11 ROMs and bring
> 2.11BSD
> up on mine. That and my Pro380 are my only KDJ11 machines.
>
> -ethan
>
>
4:19 p.m.
On 2015-10-19 23:11, jwsmobile wrote:
On 10/19/2015 12:39 PM, Johnny Billquist wrote:
Well, EPROMs are getting sortof old fashioned nowadays.
Well, you did ask for "thoughts in the
conversion", so I gave you
mine. Sorry if you felt they were unhelpful. I just thought the
"conversion" was basically a no-work. Programming proms is something I
have spent more time than I can count on, and is so routine that I
don't even think about it.
I didn't mean that in disrespect. The contents of what I posted was on
the page and I basically needed the binaries and needed some direction
as to which went where. I appreciate you taking time to reply, but am
coming from a lot less capability than you have. I do a lot of
computing and the like, but I've purposely not kept up with eprom
technology to the point that i can't reliably swear I can program them
right now.
There are only so many things one can keep up with and eproms were not
one that was cheap to follow, and I was more into EE type devices anyway. I may need a favor by swapping you some of my eproms
(I have a 12" x 12"
x 12" box of pulls) maybe to get you to make me a set for my board.
Unfortunately all of my stuff in Sweden, while I nowadays live in
Switzerland. So I could only possibly help out next summer.
But I probably would have some 27256 around.
I've pulled out probably 500 and returned them to
the original owner and
owe him more. but I do probably have a lot of the 27xx proms.
Do you think these are 27C or just straight 27 type eproms, and if so
what speeds? That is what I need to know too.
I normally don't care about that. The difference is in how you program
them, and there are more variations than that. Fortunately my programmer
knows a whole bunch of them, and also can autodetect the different models.
But once they are programmed, the actual pins are the same, so speed is
the only possible issue. But I think most of them are 125ns, which is
fast enough anyway.
I replaced the firmware in some 11/93 boards a few years ago. But I
think I just reused the existing proms that time.
But I don't have any 11/53 boards, so I can't do that here.
Johnny
thanks
Jim
--
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
On 2015-10-19 20:57, jwsmobile wrote:
On 10/19/2015 10:03 AM, Johnny Billquist wrote:
Not sure what you expect a "conversion"
means. Creating new PROMs
imply finding actual proms, a prom programmer, the code to program
into the PROMs, and then just replace the proms on the card.
Only the last piece will actually require any modification of the
card, and I would expect them to be socketed anyway, so replacing
means just removing the old proms, and inserting the new ones.
That is basically what I said. I don't have one that isn't part of a
DecServer and i need images, or someone with a non DecServer to provide
them.
I guess you restated what I said. if you have one, I'd appreciate
copies.
I didn't post the original link from the top of this thread, you might
want to read it. I'm just stating what someone did back in the 2001
time frame and posted a page about the conversion and info on his
experiences.
The note also mentioned that you might want/need
to install a pull-up.
But it would still be an extremely simple process. You just need the
right bits...
What I said.
Johnny
On 2015-10-19 18:28, jwsmobile wrote:
> I would appreciate thoughts on the conversion of the processor to
> normal
> PDP11 eproms.
>
> The page pointed to earlier has a mention of that too, but the poster
> had access to another "real" KDJ and I am guessing copied that.
>
> I don't have access to any version of the system with appropriate
> eproms
> and would appreciate any pointers to the binaries needed.
>
> As to the condition most of the material is the result of moving it
> from
> where it was stored. It will be totally disassembled and tested
> before
> being brought back up. There is about 5 or 6 large deep freeze (for
> reference) sized piles of material being sent for e-waste from the
> place
> that is pretty much just junk material under the weather.
>
> Think of this as a Dusenberg rescued from a barn though.
>
> thanks for all the suggestions and observations.
>
> Next thing to go over is a Sun 4/260 "mini" tower. Gads those were
> heavy. Back is still aching from moving that.
>
> Jim
>
> On 10/19/2015 7:32 AM, Ethan Dicks wrote:
>> On Mon, Oct 19, 2015 at 3:42 AM, Pontus Pihlgren
>> <pontus at update.uu.se>
>> wrote:
>>> Interesting. I thought Tthe DECserver 550 was merely the big
>>> brother in
>>> the terminal server line. But it looks like it is essentially a
>>> PDP-11/53 with 1.5MW of ram, you need new boot roms though. Pretty
>>> nice.
>> Yep. It's essentially an S-box KDJ11 with different ROMs. I happen
>> to have a CPU board from one, but not the box itself.
>>
>> One of these days, I plan to burn "real" PDP-11 ROMs and bring
>> 2.11BSD
>> up on mine. That and my Pro380 are my only KDJ11 machines.
>>
>> -ethan
>>
>>
>
20 Oct
20 Oct
12:38 a.m.
Johnny Billquist wrote:
On 2015-10-19 23:11, jwsmobile wrote:
I can do a look later this day. I've done exatly this some years before,
and the KDJ11 that is working now as plain CPU isn't in a machine
currently so I have it handy.
As far as I remember I've used 27C256 Proms and the contents of the
previous ones are on Pete's archive since they where newer then the
images he had.
I've updated the memory from 512K to 1,5Mb too...
Regards,
Holm
--
Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe,
Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583
www.tsht.de, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741
On 10/19/2015 12:39 PM, Johnny Billquist wrote:
Well, EPROMs are getting sortof old fashioned nowadays.
Well, you did ask for "thoughts in the
conversion", so I gave you
mine. Sorry if you felt they were unhelpful. I just thought the
"conversion" was basically a no-work. Programming proms is something I
have spent more time than I can count on, and is so routine that I
don't even think about it.
I didn't mean that in disrespect. The contents of what I posted was on
the page and I basically needed the binaries and needed some direction
as to which went where. I appreciate you taking time to reply, but am
coming from a lot less capability than you have. I do a lot of
computing and the like, but I've purposely not kept up with eprom
technology to the point that i can't reliably swear I can program them
right now.
There are only so many things one can keep up with and eproms were not
one that was cheap to follow, and I was more into EE type devices anyway. I may need a favor by swapping you some of my
eproms (I have a 12" x 12"
x 12" box of pulls) maybe to get you to make me a set for my board.
Unfortunately all of my stuff in Sweden, while I nowadays live in
Switzerland. So I could only possibly help out next summer.
But I probably would have some 27256 around.
I've pulled out probably 500 and returned them
to the original owner and
owe him more. but I do probably have a lot of the 27xx proms.
Do you think these are 27C or just straight 27 type eproms, and if so
what speeds? That is what I need to know too.
I normally don't care about that. The difference is in how you program
them, and there are more variations than that. Fortunately my programmer
knows a whole bunch of them, and also can autodetect the different models.
But once they are programmed, the actual pins are the same, so speed is
the only possible issue. But I think most of them are 125ns, which is
fast enough anyway.
I replaced the firmware in some 11/93 boards a few years ago. But I
think I just reused the existing proms that time.
But I don't have any 11/53 boards, so I can't do that here.
Johnny
22 Oct
22 Oct
10:31 a.m.
Holm Tiffe wrote:
Johnny Billquist wrote:
Looked at my KDJ11 Board today (sorry for the delay). I have twp peaces
27128A on this board.
Regards,
Holm
--
Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe,
Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583
www.tsht.de, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741
On 2015-10-19 23:11, jwsmobile wrote:
I can do a look later this day. I've done exatly this some years before,
and the KDJ11 that is working now as plain CPU isn't in a machine
currently so I have it handy.
As far as I remember I've used 27C256 Proms and the contents of the
previous ones are on Pete's archive since they where newer then the
images he had.
I've updated the memory from 512K to 1,5Mb too...
Regards,
Holm
--
On 10/19/2015 12:39 PM, Johnny Billquist wrote:
Well, EPROMs are getting sortof old fashioned nowadays.
Well, you did ask for "thoughts in the
conversion", so I gave you
mine. Sorry if you felt they were unhelpful. I just thought the
"conversion" was basically a no-work. Programming proms is something I
have spent more time than I can count on, and is so routine that I
don't even think about it.
I didn't mean that in disrespect. The contents of what I posted was on
the page and I basically needed the binaries and needed some direction
as to which went where. I appreciate you taking time to reply, but am
coming from a lot less capability than you have. I do a lot of
computing and the like, but I've purposely not kept up with eprom
technology to the point that i can't reliably swear I can program them
right now.
There are only so many things one can keep up with and eproms were not
one that was cheap to follow, and I was more into EE type devices anyway. I may need a favor by swapping you some of my
eproms (I have a 12" x 12"
x 12" box of pulls) maybe to get you to make me a set for my board.
Unfortunately all of my stuff in Sweden, while I nowadays live in
Switzerland. So I could only possibly help out next summer.
But I probably would have some 27256 around.
I've pulled out probably 500 and returned them
to the original owner and
owe him more. but I do probably have a lot of the 27xx proms.
Do you think these are 27C or just straight 27 type eproms, and if so
what speeds? That is what I need to know too.
I normally don't care about that. The difference is in how you program
them, and there are more variations than that. Fortunately my programmer
knows a whole bunch of them, and also can autodetect the different models.
But once they are programmed, the actual pins are the same, so speed is
the only possible issue. But I think most of them are 125ns, which is
fast enough anyway.
I replaced the firmware in some 11/93 boards a few years ago. But I
think I just reused the existing proms that time.
But I don't have any 11/53 boards, so I can't do that here.
Johnny
19 Oct
19 Oct
11:57 a.m.
I have a decserver 550 CPU converted to a real KDJ. It's as simple as new ROMS and
one resistor. I also removed the s-box bracket to fit my chassis. Runs BSD 2.11 just fine
(RQDX3 disks)
Joe
On Oct 19, 2015, at 12:28 PM, jwsmobile <jws at
jwsss.com> wrote:
I would appreciate thoughts on the conversion of the processor to normal PDP11 eproms.
The page pointed to earlier has a mention of that too, but the poster had access to
another "real" KDJ and I am guessing copied that.
I don't have access to any version of the system with appropriate eproms and would
appreciate any pointers to the binaries needed.
As to the condition most of the material is the result of moving it from where it was
stored. It will be totally disassembled and tested before being brought back up. There
is about 5 or 6 large deep freeze (for reference) sized piles of material being sent for
e-waste from the place that is pretty much just junk material under the weather.
Think of this as a Dusenberg rescued from a barn though.
thanks for all the suggestions and observations.
Next thing to go over is a Sun 4/260 "mini" tower. Gads those were heavy.
Back is still aching from moving that.
Jim
On 10/19/2015 7:32 AM, Ethan Dicks wrote:
On Mon, Oct 19, 2015 at 3:42 AM, Pontus Pihlgren
<pontus at update.uu.se> wrote:
Interesting. I thought Tthe DECserver 550 was merely the big brother in
the terminal server line. But it looks like it is essentially a
PDP-11/53 with 1.5MW of ram, you need new boot roms though. Pretty nice.
Yep.
It's essentially an S-box KDJ11 with different ROMs. I happen
to have a CPU board from one, but not the box itself.
One of these days, I plan to burn "real" PDP-11 ROMs and bring 2.11BSD
up on mine. That and my Pro380 are my only KDJ11 machines.
-ethan
2:29 a.m.
Its a terminal concentrator. I have a load of those 8 and 16 line cards.
They would have fanned out to via splitter cables to back /front panels
with 9/25 way D connectors.
They look in a bit of a sorry state. I would not apply power or plug
into any other chassis.
Rod
On 19/10/2015 08:30, jwsmobile wrote:
These are the cards in the DecServer 550. Looks to be an expansion
chassis with 108 ports or so.
Thanks
Jim
Photos of the DecServer 550
https://drive.google.com/folderview?id=0B4AXJXpUCE-hQ2lsc2lqS3VHd0U&usp…
3350
days inactive
3353
days old
23 comments
10 participants
participants (10)
-
bqt＠update.uu.se -
ethan.dicks＠gmail.com -
glen.slick＠gmail.com -
holm＠freibergnet.de -
joe.lang.0000＠gmail.com -
jws＠jwsss.com -
paulkoning＠comcast.net -
pete＠dunnington.plus.com -
pontus＠Update.UU.SE -
rodsmallwood52＠btinternet.com