29 Oct
2018
29 Oct
'18
4:30 p.m.
AIX was ported in very cut down manner and used on the f960 and h960
routing cards used on the early T3 based NSFnet. F960 was FDDI and H960 was
HSSI. Come think of it, I think the v.25 and ether net cards also used
i960, just a smaller version.
--
Will
On Oct 29, 2018 12:13 PM, "alan--- via cctalk" <cctalk at classiccmp.org>
wrote:
I know i960 is a very different beast, but was there ever any high level
OSs that ran on it? Or was it pidgin-holed as a high speed embedded
processor for storage controllers and NICs?
I picked up a cache of i960 CPUs a couple years ago and they speak to me in
tongues every time I pass by the shelf.
-Alan
On 2018-10-29 12:56, Ken Seefried via cctalk wrote:
the i860 found at least a little niche on graphics
boards, so somehow
not a complete failure ;-)
I'd be mildly surprised if Intel ever made enough from selling i860s
as GPUs to cover the cost of developing and marketing them. At the
time, Intel was pushing them as their RISC processor, and put a lot
into the program. Going to take over the world and all that. Maybe
not a 'complete' failure...just mostly.
From: Chuck Guzis <cclist at sydex.com>
On 10/26/18 6:10 AM, Gordon Henderson via cctalk
wrote:
However it was a royal PITA to code for although a 32-bit CPU, it would
It wasn't fun for the whole 2 weeks. And the i860 is Yet Another
example of Intel claiming their compilers were going to be so smart
that all the architectural complexity/warts will never be noticed.
Wrong, and they didn't learn and said the same thing about Itanium.
The interrupt stall issue that Gordon pointed out was so bad they were
basically relegated to single-task software in the end.
KJ
read memory 64 bits at a time (actually 128 IIRC
to satisfy the cache),
with half that 64-bit word being an instruction for the integer unit and
half for the floating point unit, so you effectively had to build a
floating point pipeline by hand coded instructions, so 8 (I think)
instructions to load the pipeline, then each subsequent instruction
would feed another value into the pipe, then another 8 at the end to
empty it. Great for big matrix operations, rubbish for a single add of 2
FP numbers.
My impression of the i860 was that it might have been fun for about 2
weeks for which to code assembly, but after that, you'd really start
looking hard for an HLL to do the dirty work for you. While there's a
sense of accomplishment over looking at a page of painfully
hand-optimized code that manages to keep everything busy with no
"bubbles", you begin to wonder if there isn't a better way to spend your
life.
30 Oct
30 Oct
6:48 a.m.
William Donzelli via cctalk wrote:
AIX was ported in very cut down manner and used on the
f960 and h960
routing cards used on the early T3 based NSFnet. F960 was FDDI and H960 was
HSSI. Come think of it, I think the v.25 and ether net cards also used
i960, just a smaller version.
--
Will
So, what is this i960-based card for?? Could it be related to what you
say in your post?
https://imgur.com/NIvQPBv
https://imgur.com/hsF0jO2
https://imgur.com/7f6sxDj
https://imgur.com/w96cLhT
Carlos.
8:07 a.m.
New subject: behaviour of classic PDP-8 frontpanel
Is there anybody out with a working classic PDP-8?
For a long time we had the problem, that starting a program on our 8 by
pressing <LA> <START> keys, this program crashed. Examining the memory
contents showed, that typically one or two words short behind the starting
adress after such a crash had inadvertently content 0000.
For a long time I suspected a subtle memory problem. But now after
carfully having revised the memory timing I hopefully found the real
reason for this nasty misbehaviour:
if the machine is running and I press the <START> key, it stops and
there is also the chance, that one word in memory is nullified.
A look in the maintenance manual shows, that pressing <START> clears the
memory data register and others asynchronously. Naturally if this occours
in the moment, when a memory read is in progress, data from core has been
transfered to memory data register, which clears the word just have been
red, and before the memory timing chain was able to write this word back
to memory, then this word is cleared out.
Scoping the <START> signal coming from the front panel shows heavy
bouncing of this key: <START>ing a program produces in many cases more
than one <START> pulse. The first starting the program, the following in
some cases nullifying a memory location near the start address. The
problem showed only, if the second start pulse came just in the moment
between reading and rewriting the word in core. In the other cases
program just went on.
My workaround for this problem in the moment is a 22uF electrolytic capacitor
between the <START> signal line and ground to make a "brut force" debounce
of this switch.
Now my question to other classic-8 users: What does your machine do, if a
program is running and you press one of the front keys, which shouldn't be
pressed while a program is runnig: <START>, <DEP>, <EXAM>?
Logically it makes no sense to press these switches if the machine is
running.
On later machines (8/L, 8/E) these keys have no effect when <RUN> is on.
Maybe that at that time the keys were new and didn't bounce and the
designer simply said: you must not press these key while the machine is
runnig.
Or there is a kind of feedback to these keys which inhibits them if the
machine is runnig and which is defunct in our machine. But I didn't find
such a key-inhibit line in the maintenance manual.
Sadly in the manual I also didn't find a complete diagram of the
frontpanel. Neither in that one on bitsavers nor in our original
printed version.
May one of the classic-8 users here in this group make the experiment:
Start a program
an press <START> again?
Thanks in advance
Klemens
10:01 a.m.
New subject: behaviour of classic PDP-8 frontpanel
On Oct 30, 2018, at 11:07 AM, Klemens Krause via
cctalk <cctalk at classiccmp.org> wrote:
Is there anybody out with a working classic PDP-8?
For a long time we had the problem, that starting a program on our 8 by pressing
<LA> <START> keys, this program crashed. Examining the memory contents showed,
that typically one or two words short behind the starting adress after such a crash had
inadvertently content 0000.
For a long time I suspected a subtle memory problem. But now after carfully having
revised the memory timing I hopefully found the real reason for this nasty misbehaviour:
if the machine is running and I press the <START> key, it stops and
there is also the chance, that one word in memory is nullified.
A look in the maintenance manual shows, that pressing <START> clears the memory
data register and others asynchronously. Naturally if this occours in the moment, when a
memory read is in progress, data from core has been transfered to memory data register,
which clears the word just have been red, and before the memory timing chain was able to
write this word back to memory, then this word is cleared out.
Interesting. I know another machine that has a similar behavior, which was actually
considered a feature. That is the CDC 6000 series. Its peripheral processors do the
read-restore cycle of memory as part of the operation of the execution pipeline, rather
than with a dedicated data path. PPUs always run (there is no "halt"
operation). When you press the boot ("deadstart") button, that forces a
specific address into the program counter register. That happens at a pipeline state
between the instruction fetch and the memory restore cycle, so while the restore write is
done, it goes to the fixed address rather than to the address that was just read. The
result is that a PPU memory dump tells you where the PC pointed, if you are lucky enough
to find a zero in the code section of memory that doesn't belong there. Since PP
dumps only give you memory (no registers) this actually matters for debugging.
This feature was known as system programmer lore but not documented. Analyzing the block
diagrams carefully would show it, though, and a VHDL model makes it crystal clear.
paul
10:14 a.m.
New subject: behaviour of classic PDP-8 frontpanel
My Nicolet did the same thing it would load 0 into the intended start location ( on my
machine it was a jump to 0 ).
The front panel worked fine otherwise. It turned out to be some missing clocks because of
a bad 7474. Strange that a common problem on different machine created by completely
different issue but all writing 0 back to core.
Dwight
________________________________
From: cctalk <cctalk-bounces at classiccmp.org> on behalf of Paul Koning via cctalk
<cctalk at classiccmp.org>
Sent: Tuesday, October 30, 2018 10:01:29 AM
To: Klemens Krause; General Discussion: On-Topic and Off-Topic Posts
Subject: Re: behaviour of classic PDP-8 frontpanel
On Oct 30, 2018, at 11:07 AM, Klemens Krause via
cctalk <cctalk at classiccmp.org> wrote:
Is there anybody out with a working classic PDP-8?
For a long time we had the problem, that starting a program on our 8 by pressing
<LA> <START> keys, this program crashed. Examining the memory contents showed,
that typically one or two words short behind the starting adress after such a crash had
inadvertently content 0000.
For a long time I suspected a subtle memory problem. But now after carfully having
revised the memory timing I hopefully found the real reason for this nasty misbehaviour:
if the machine is running and I press the <START> key, it stops and
there is also the chance, that one word in memory is nullified.
A look in the maintenance manual shows, that pressing <START> clears the memory
data register and others asynchronously. Naturally if this occours in the moment, when a
memory read is in progress, data from core has been transfered to memory data register,
which clears the word just have been red, and before the memory timing chain was able to
write this word back to memory, then this word is cleared out.
Interesting. I know another machine that has a similar behavior, which was actually
considered a feature. That is the CDC 6000 series. Its peripheral processors do the
read-restore cycle of memory as part of the operation of the execution pipeline, rather
than with a dedicated data path. PPUs always run (there is no "halt"
operation). When you press the boot ("deadstart") button, that forces a
specific address into the program counter register. That happens at a pipeline state
between the instruction fetch and the memory restore cycle, so while the restore write is
done, it goes to the fixed address rather than to the address that was just read. The
result is that a PPU memory dump tells you where the PC pointed, if you are lucky enough
to find a zero in the code section of memory that doesn't belong there. Since PP
dumps only give you memory (no registers) this actually matters for debugging.
This feature was known as system programmer lore but not documented. Analyzing the block
diagrams carefully would show it, though, and a VHDL model makes it crystal clear.
paul
10:21 a.m.
New subject: behaviour of classic PDP-8 frontpanel
On Oct 30, 2018, at 1:14 PM, dwight <dkelvey at
hotmail.com> wrote:
My Nicolet did the same thing it would load 0 into the intended start location ( on my
machine it was a jump to 0 ).
The front panel worked fine otherwise. It turned out to be some missing clocks because of
a bad 7474. Strange that a common problem on different machine created by completely
different issue but all writing 0 back to core.
Not all that strange. Reading core clears it. So if the restore cycle is either
suppressed or diverted to the wrong address, you keep that zero at the location just
read.
paul
10:28 a.m.
New subject: behaviour of classic PDP-8 frontpanel
On Tue, Oct 30, 2018 at 1:21 PM Paul Koning via cctalk <
cctalk at classiccmp.org> wrote:
I believe the straight 8 is set up and ready for testing at the vcfed.org
museum, call someone there to mimic your tests.
On Oct 30, 2018, at 1:14 PM, dwight <dkelvey
at hotmail.com> wrote:
My Nicolet did the same thing it would load 0 into the intended start
location (
on my machine it was a jump to 0 ).
The front panel worked fine otherwise. It turned
out to be some missing
clocks because of a bad 7474. Strange that a common problem
on different
machine created by completely different issue but all writing 0 back to
core.
Not all that strange. Reading core clears it. So if the restore cycle is
either suppressed or diverted to the wrong address, you keep that zero at
the location just read.
paul
11:08 a.m.
New subject: behaviour of classic PDP-8 frontpanel
On Tue, Oct 30, 2018 at 8:07 AM Klemens Krause via cctalk <
cctalk at classiccmp.org> wrote:
Is there anybody out with a working classic PDP-8?
Now my question to other classic-8 users: What does your machine do, if a
program is running and you press one of the front keys, which shouldn't be
pressed while a program is runnig: <START>, <DEP>, <EXAM>?
Logically it makes no sense to press these switches if the machine is
running.
On our Straight-8 at the museum, hitting START appears to cause the running
program to hiccup (I assume it's re-STARTing but who knows from where). I
was unable to investigate whether memory occasionally gets stomped on
during this process (no time at the moment). DEP, EXAM or LOAD ADDRESS
causes program execution to stop and the specified action is (apparently)
taken, though who knows what it's depositing to or examining from :).
- Josh
1:07 p.m.
New subject: behaviour of classic PDP-8 frontpanel
On 2018-Oct-30, at 8:07 AM, Klemens Krause via cctalk wrote:
Is there anybody out with a working classic PDP-8?
For a long time we had the problem, that starting a program on our 8 by pressing
<LA> <START> keys, this program crashed. Examining the memory contents showed,
that typically one or two words short behind the starting adress after such a crash had
inadvertently content 0000.
For a long time I suspected a subtle memory problem. But now after carfully having
revised the memory timing I hopefully found the real reason for this nasty misbehaviour:
if the machine is running and I press the <START> key, it stops and
there is also the chance, that one word in memory is nullified.
A look in the maintenance manual shows, that pressing <START> clears the memory
data register and others asynchronously. Naturally if this occours in the moment, when a
memory read is in progress, data from core has been transfered to memory data register,
which clears the word just have been red, and before the memory timing chain was able to
write this word back to memory, then this word is cleared out.
Scoping the <START> signal coming from the front panel shows heavy bouncing of this
key: <START>ing a program produces in many cases more than one <START> pulse.
The first starting the program, the following in some cases nullifying a memory location
near the start address. The problem showed only, if the second start pulse came just in
the moment
between reading and rewriting the word in core. In the other cases
program just went on.
My workaround for this problem in the moment is a 22uF electrolytic capacitor
between the <START> signal line and ground to make a "brut force"
debounce of this switch.
. . .
If you haven't tried it already, a good exercising with contact cleaner (stay away
from the stuff with oil in it) or isoprop will often clear up excessive contact bounce on
old switches. Getting contact cleaner into the switch can sometimes be difficult though.
With mini-toggle switches (if that's what they are behind the flat levers) the toggle
can usually be pressed in a bit against the internal spring to open come clearance down
the throat.
For a proper design fix, if the switch has both NO and NC contacts, a solution might be to
build an SR flip-flop from two transistors and a few R and interposing that between the
switch and logic as a de-bounce circuit.
31 Oct
31 Oct
7:37 a.m.
New subject: behaviour of classic PDP-8 frontpanel
On Tue, 30 Oct 2018, Brent Hilpert via cctalk wrote:
If you haven't tried it already, a good exercising with contactr
cleaner (stay away from the stuff with oil in it) or isoprop will often
clear up excessive contact bounce on old switches. Getting contact
May be, but this would only solve one of the problems. In many cases
contact cleaner works some time an then problems come back, because in
the past 50 years the original silver platening of the contacts has gone
away.
For a proper design fix, if the switch has both NO and
NC contacts, a
solution might be to build an SR flip-flop from two transistors and a
few R and interposing that between the switch and logic as a de-bounce
circuit.
Yes this would solve one problem. But I don't want revise the logic of
such a historic machine.
And the other problem wouldn't be solved: the machine stops if any of
the keys <START> <DEP> <EXAM> <CONT> is pressed while the machine
is
runnig.
A look behind the panel shows:
<START> <STOP> <SINGLE STEP> <SINGLE INSTR> are single wired with
the
N.O. contacts of the switches. So they have open inputs with a
potential of -1.9V <START> or -3.9V <ALL OTHERS>. Activting one of
these keys makes contact N.O. to ground.
The other keys <CONT> <EXAM> <DEP> are connected to the middle of the
N.O - N.C switches. Inactivated N.C. is connected to -15V, bringing
this level to the inputs. Activated, the N.O. makes connection to
ground.
<PANEL LOCK> is simply a switch, which interrupts the common ground-
line of these switches.
The better solution would be a feed back line, which holds the former
ground line to 0V if the "RUN-FF" is reset and puts it to -3,9V or
-15V if "RUN-FF" is set. The first connect of the start key would
start the machine and set "RUN-FF", thus locking the switches by the
processor itself. Subsequent contact bounces would be ignored.
Inadvertent pressing one of the other controlswitches would be ignored
too.
Naturally <SINGLE INSTR> <SINGLE STEP> and <STOP> remain hard wired
to ground, to allow stopping a running machine.
But this improvement would need a siginficant rewiring of the front-
panel which I don't want to do for historical reasons.
Other writers in this thread wrote, that:
On our Straight-8 at the museum, hitting START appears
to cause the
running program to hiccup (I assume it's re-STARTing but who knows from
where). I was
Nice word "hiccup", :-) probably the same effect than at
our machine.
So this seems to be normal.
May be that was corrected in later machines with higher serial number?
Our machine has serial number #768
More behaviour, that I tested:
<DEP> stops the running machine and puts contents of SR in the actual
address that is in this moment in the MA-register.
<LA> stops the machine and loads SR in MAR.
<EXAM> stops the machine and shows content of current address in MAR.
<CONT> has no effect.
No one of theses switches ever cleared a memory word. Eventually they
are synchronised with the memory timing chain, whereas <START> works
asynchronously and clears most or all FFs.
Klemens
12:36 p.m.
On Oct 30, 2018, at 6:48 AM, Carlos E Murillo-Sanchez via cctalk <cctalk at
classiccmp.org> wrote:
So, what is this i960-based card for? Could it be related to what you say in your post?
https://imgur.com/NIvQPBv <https://imgur.com/NIvQPBv>
https://imgur.com/hsF0jO2 <https://imgur.com/hsF0jO2>
https://imgur.com/7f6sxDj <https://imgur.com/7f6sxDj>
https://imgur.com/w96cLhT <https://imgur.com/w96cLhT>
Just from the wording
on the label it seems like some sort of telecom card, but it could also be a development
board for the software that would run on telecom systems.
-- Chris
1 Nov
1 Nov
9:15 a.m.
So, what is this i960-based card for?
They were the routers. At the core nodes of the network, there would
be a big RS/6000s (very early POWER1 types) that would each do about
4-5 high speed interfaces (FDDI, HSSI, and 10base2). Each interface
was one of these cards, so each of the big RS/6000s would have about
4-5 of these cards.
IBM tried to commercialize the design, but it was doomed - the routing
engines were very fast, but the internet quickly outgrew the
architecture of the engines, and they apparently needed a complete
redesign to compete. IBM did release very few of these RS/6000s to the
public (I think RS/6000-320Hs with a fancy tag - machine type 6767?).
I have only seen one of these routers in the wild, but most of the
real NSFnet ones (I was decommissioning them, one time with a Sawzall
because of some live tangled cables).
Could it be related to what you
say in your post?
https://imgur.com/NIvQPBv
Possibly related, but that card is not one of the NSFnet ones.
--
Will
9:24 a.m.
On 11/01/2018 10:15 AM, William Donzelli via cctalk wrote:
I have only seen one of these routers in the wild
I worked at a company years ago that ran a pair of IBM RS/6000 (the
small beige desktop models, maybe a 43). They were running an IBM
Firewall software product that I don't remember the name of. I think it
ran on top of AIX 4.<something>.
--
Grant. . . .
unix || die
12:22 p.m.
6611 was the commercialized version. One early model was a standard 7012
desktop with the special cards. A later cost optimized version had a custom
PowerPC backplane.
There were some good pics of the nsfnet T3 racks I linked onto nekochan
forums but that site is gone. Wish people would migrate back to Usenet.
On Thu, Nov 1, 2018 at 9:15 AM William Donzelli via cctalk <
cctalk at classiccmp.org> wrote:
So, what is
this i960-based card for?
They were the routers. At the core nodes of the network, there would
be a big RS/6000s (very early POWER1 types) that would each do about
4-5 high speed interfaces (FDDI, HSSI, and 10base2). Each interface
was one of these cards, so each of the big RS/6000s would have about
4-5 of these cards.
IBM tried to commercialize the design, but it was doomed - the routing
engines were very fast, but the internet quickly outgrew the
architecture of the engines, and they apparently needed a complete
redesign to compete. IBM did release very few of these RS/6000s to the
public (I think RS/6000-320Hs with a fancy tag - machine type 6767?).
I have only seen one of these routers in the wild, but most of the
real NSFnet ones (I was decommissioning them, one time with a Sawzall
because of some live tangled cables).
Could it be related to what you
say in your post?
https://imgur.com/NIvQPBv
Possibly related, but that card is not one of the NSFnet ones.
--
Will
1:06 p.m.
On 11/1/18 12:22 PM, Kevin Bowling via cctalk wrote:
There were some good pics of the nsfnet T3 racks I
linked onto nekochan
forums but that site is gone. Wish people would migrate back to Usenet.
Community fragmentation and reliance on unarchived forums is a Bad Thing.
I wonder how much of value will be lost when Yahoo's unmigrated forums finally
collapse
or when G gets bored with all of the 'Usenet' groups they created and silently
dump them.
1:20 p.m.
New subject: Whither Google Groups - was Re: i860: Re: modern stuff
On 2018-11-01 5:06 p.m., Al Kossow via cctalk wrote:
On 11/1/18 12:22 PM, Kevin Bowling via cctalk wrote:
Groups is getting more and more buried in the UI. You have to really dig
to browse there from the home page now.
--T
There were some good pics of the nsfnet T3 racks
I linked onto nekochan
forums but that site is gone. Wish people would migrate back to Usenet.
Community fragmentation and reliance on unarchived forums is a Bad Thing.
I wonder how much of value will be lost when Yahoo's unmigrated forums finally
collapse
or when G gets bored with all of the 'Usenet' groups they created and silently
dump them.
2:57 p.m.
Right, thanks. 6611 is correct. I do not think the FDDI or HSSI cards
made it into those.
The RCS/RI twitter feed has some pictures of NSFnet racks and a F960
FDDI card. Those were from the GNJ node in Greensboro Junction, NC.
Were those the pictures?
https://twitter.com/RetroCompSocRI
--
Will
On Thu, Nov 1, 2018 at 3:22 PM Kevin Bowling <kevin.bowling at kev009.com> wrote:
6611 was the commercialized version. One early model was a standard 7012 desktop with
the special cards. A later cost optimized version had a custom PowerPC backplane.
There were some good pics of the nsfnet T3 racks I linked onto nekochan forums but that
site is gone. Wish people would migrate back to Usenet.
On Thu, Nov 1, 2018 at 9:15 AM William Donzelli via cctalk <cctalk at
classiccmp.org> wrote:
>
> > So, what is this i960-based card for?
>
> They were the routers. At the core nodes of the network, there would
> be a big RS/6000s (very early POWER1 types) that would each do about
> 4-5 high speed interfaces (FDDI, HSSI, and 10base2). Each interface
> was one of these cards, so each of the big RS/6000s would have about
> 4-5 of these cards.
>
> IBM tried to commercialize the design, but it was doomed - the routing
> engines were very fast, but the internet quickly outgrew the
> architecture of the engines, and they apparently needed a complete
> redesign to compete. IBM did release very few of these RS/6000s to the
> public (I think RS/6000-320Hs with a fancy tag - machine type 6767?).
> I have only seen one of these routers in the wild, but most of the
> real NSFnet ones (I was decommissioning them, one time with a Sawzall
> because of some live tangled cables).
>
> > Could it be related to what you
> > say in your post?
> >
> > https://imgur.com/NIvQPBv
>
> Possibly related, but that card is not one of the NSFnet ones.
>
> --
> Will
3:15 p.m.
Yes, they are. There are reference to those machines in the various
nsfnet written histories but not cross linkage to those great
pictures.
On Thu, Nov 1, 2018 at 2:57 PM William Donzelli <wdonzelli at gmail.com> wrote:
Right, thanks. 6611 is correct. I do not think the FDDI or HSSI cards
made it into those.
The RCS/RI twitter feed has some pictures of NSFnet racks and a F960
FDDI card. Those were from the GNJ node in Greensboro Junction, NC.
Were those the pictures?
https://twitter.com/RetroCompSocRI
--
Will
On Thu, Nov 1, 2018 at 3:22 PM Kevin Bowling <kevin.bowling at kev009.com> wrote:
>
> 6611 was the commercialized version. One early model was a standard 7012 desktop
with the special cards. A later cost optimized version had a custom PowerPC backplane.
>
> There were some good pics of the nsfnet T3 racks I linked onto nekochan forums but
that site is gone. Wish people would migrate back to Usenet.
>
> On Thu, Nov 1, 2018 at 9:15 AM William Donzelli via cctalk <cctalk at
classiccmp.org> wrote:
>>
>> > So, what is this i960-based card for?
>>
>> They were the routers. At the core nodes of the network, there would
>> be a big RS/6000s (very early POWER1 types) that would each do about
>> 4-5 high speed interfaces (FDDI, HSSI, and 10base2). Each interface
>> was one of these cards, so each of the big RS/6000s would have about
>> 4-5 of these cards.
>>
>> IBM tried to commercialize the design, but it was doomed - the routing
>> engines were very fast, but the internet quickly outgrew the
>> architecture of the engines, and they apparently needed a complete
>> redesign to compete. IBM did release very few of these RS/6000s to the
>> public (I think RS/6000-320Hs with a fancy tag - machine type 6767?).
>> I have only seen one of these routers in the wild, but most of the
>> real NSFnet ones (I was decommissioning them, one time with a Sawzall
>> because of some live tangled cables).
>>
>> > Could it be related to what you
>> > say in your post?
>> >
>> > https://imgur.com/NIvQPBv
>>
>> Possibly related, but that card is not one of the NSFnet ones.
>>
>> --
>> Will
3:19 p.m.
The machine type was 6611 and there where three model, the smallest was
based on a 7011 the mid size one was based on a 7012 and the largest was
based on a 7013.
The base card is an Artic 960 card which is just a processor card with
some memory that gets an application loaded on the fly.? The top
interface card has a lot to do with determining what the function of the
card sandwich is, there should be a X-Y type code on the back of the
card that would define the interface.? They where used for all kinds of
things like Synchronous communications, X25 and network accelerators.?
Some of the interfaces cards used in the 6611 where unique to it and
never made it to the "standard" RS/6000 line.? There was also a PCI
version of the Artic 960 but by the time it came along the 6611 was long
gone.
Paul.
On 2018-11-01 1:15 PM, William Donzelli via cctalk wrote:
So, what is
this i960-based card for?
They were the routers. At the core nodes of the network,
there would
be a big RS/6000s (very early POWER1 types) that would each do about
4-5 high speed interfaces (FDDI, HSSI, and 10base2). Each interface
was one of these cards, so each of the big RS/6000s would have about
4-5 of these cards.
IBM tried to commercialize the design, but it was doomed - the routing
engines were very fast, but the internet quickly outgrew the
architecture of the engines, and they apparently needed a complete
redesign to compete. IBM did release very few of these RS/6000s to the
public (I think RS/6000-320Hs with a fancy tag - machine type 6767?).
I have only seen one of these routers in the wild, but most of the
real NSFnet ones (I was decommissioning them, one time with a Sawzall
because of some live tangled cables).
Could it be related to what you
say in your post?
https://imgur.com/NIvQPBv
Possibly related, but that card is not one of the NSFnet
ones.
--
Will
3:41 p.m.
OK, I assumed the 6611s used the NSFnet type cards. Artic960s are
different animals - but probably very similar in idea.
My memory is hazy, but I think the NSFnet cards were referred to as Hawthornes.
Somewhere around here I have one of the really early 386 based routing
cards - a weird double height Microchannel card (the RS/6000s were
RPQ'd with extra tall chassis to accommodate them).
Anyway, I would like to get a 6611, but I do not think very many were
made at all.
--
Will
On Thu, Nov 1, 2018 at 6:19 PM Paul Berger via cctalk
<cctalk at classiccmp.org> wrote:
The machine type was 6611 and there where three model, the smallest was
based on a 7011 the mid size one was based on a 7012 and the largest was
based on a 7013.
The base card is an Artic 960 card which is just a processor card with
some memory that gets an application loaded on the fly. The top
interface card has a lot to do with determining what the function of the
card sandwich is, there should be a X-Y type code on the back of the
card that would define the interface. They where used for all kinds of
things like Synchronous communications, X25 and network accelerators.
Some of the interfaces cards used in the 6611 where unique to it and
never made it to the "standard" RS/6000 line. There was also a PCI
version of the Artic 960 but by the time it came along the 6611 was long
gone.
Paul.
On 2018-11-01 1:15 PM, William Donzelli via cctalk wrote:
So, what
is this i960-based card for?
They were the routers. At the core nodes of the
network, there would
be a big RS/6000s (very early POWER1 types) that would each do about
4-5 high speed interfaces (FDDI, HSSI, and 10base2). Each interface
was one of these cards, so each of the big RS/6000s would have about
4-5 of these cards.
IBM tried to commercialize the design, but it was doomed - the routing
engines were very fast, but the internet quickly outgrew the
architecture of the engines, and they apparently needed a complete
redesign to compete. IBM did release very few of these RS/6000s to the
public (I think RS/6000-320Hs with a fancy tag - machine type 6767?).
I have only seen one of these routers in the wild, but most of the
real NSFnet ones (I was decommissioning them, one time with a Sawzall
because of some live tangled cables).
Could it be related to what you
say in your post?
https://imgur.com/NIvQPBv
Possibly related, but that card is not one of the NSFnet
ones.
--
Will
3 Nov
3 Nov
2:03 a.m.
Do you have software or docs for any of this stuff? I run ps-2.kev009.com
On Thu, Nov 1, 2018 at 3:41 PM William Donzelli via cctalk <
cctalk at classiccmp.org> wrote:
OK, I assumed the 6611s used the NSFnet type cards.
Artic960s are
different animals - but probably very similar in idea.
My memory is hazy, but I think the NSFnet cards were referred to as
Hawthornes.
Somewhere around here I have one of the really early 386 based routing
cards - a weird double height Microchannel card (the RS/6000s were
RPQ'd with extra tall chassis to accommodate them).
Anyway, I would like to get a 6611, but I do not think very many were
made at all.
--
Will
On Thu, Nov 1, 2018 at 6:19 PM Paul Berger via cctalk
<cctalk at classiccmp.org> wrote:
The machine type was 6611 and there where three model, the smallest was
based on a 7011 the mid size one was based on a 7012 and the largest was
based on a 7013.
The base card is an Artic 960 card which is just a processor card with
some memory that gets an application loaded on the fly. The top
interface card has a lot to do with determining what the function of the
card sandwich is, there should be a X-Y type code on the back of the
card that would define the interface. They where used for all kinds of
things like Synchronous communications, X25 and network accelerators.
Some of the interfaces cards used in the 6611 where unique to it and
never made it to the "standard" RS/6000 line. There was also a PCI
version of the Artic 960 but by the time it came along the 6611 was long
gone.
Paul.
On 2018-11-01 1:15 PM, William Donzelli via cctalk wrote:
So, what
is this i960-based card for?
They were the routers. At the core nodes of the
network, there would
be a big RS/6000s (very early POWER1 types) that would each do about
4-5 high speed interfaces (FDDI, HSSI, and 10base2). Each interface
was one of these cards, so each of the big RS/6000s would have about
4-5 of these cards.
IBM tried to commercialize the design, but it was doomed - the routing
engines were very fast, but the internet quickly outgrew the
architecture of the engines, and they apparently needed a complete
redesign to compete. IBM did release very few of these RS/6000s to the
public (I think RS/6000-320Hs with a fancy tag - machine type 6767?).
I have only seen one of these routers in the wild, but most of the
real NSFnet ones (I was decommissioning them, one time with a Sawzall
because of some live tangled cables).
Could it be related to what you
say in your post?
https://imgur.com/NIvQPBv
Possibly related, but that card is not one of the NSFnet
ones.
--
Will
3:01 p.m.
I have quite few NSFnet backup tapes that need to go to Al at some
point. They likely have good stuff on them.
--
Will
On Sat, Nov 3, 2018 at 5:03 AM Kevin Bowling <kevin.bowling at kev009.com> wrote:
Do you have software or docs for any of this stuff? I run ps-2.kev009.com
On Thu, Nov 1, 2018 at 3:41 PM William Donzelli via cctalk <cctalk at
classiccmp.org> wrote:
>
> OK, I assumed the 6611s used the NSFnet type cards. Artic960s are
> different animals - but probably very similar in idea.
>
> My memory is hazy, but I think the NSFnet cards were referred to as Hawthornes.
>
> Somewhere around here I have one of the really early 386 based routing
> cards - a weird double height Microchannel card (the RS/6000s were
> RPQ'd with extra tall chassis to accommodate them).
>
> Anyway, I would like to get a 6611, but I do not think very many were
> made at all.
>
> --
> Will
> On Thu, Nov 1, 2018 at 6:19 PM Paul Berger via cctalk
> <cctalk at classiccmp.org> wrote:
> >
> > The machine type was 6611 and there where three model, the smallest was
> > based on a 7011 the mid size one was based on a 7012 and the largest was
> > based on a 7013.
> >
> > The base card is an Artic 960 card which is just a processor card with
> > some memory that gets an application loaded on the fly. The top
> > interface card has a lot to do with determining what the function of the
> > card sandwich is, there should be a X-Y type code on the back of the
> > card that would define the interface. They where used for all kinds of
> > things like Synchronous communications, X25 and network accelerators.
> > Some of the interfaces cards used in the 6611 where unique to it and
> > never made it to the "standard" RS/6000 line. There was also a PCI
> > version of the Artic 960 but by the time it came along the 6611 was long
> > gone.
> >
> > Paul.
> >
> >
> > On 2018-11-01 1:15 PM, William Donzelli via cctalk wrote:
> > >> So, what is this i960-based card for?
> > > They were the routers. At the core nodes of the network, there would
> > > be a big RS/6000s (very early POWER1 types) that would each do about
> > > 4-5 high speed interfaces (FDDI, HSSI, and 10base2). Each interface
> > > was one of these cards, so each of the big RS/6000s would have about
> > > 4-5 of these cards.
> > >
> > > IBM tried to commercialize the design, but it was doomed - the routing
> > > engines were very fast, but the internet quickly outgrew the
> > > architecture of the engines, and they apparently needed a complete
> > > redesign to compete. IBM did release very few of these RS/6000s to the
> > > public (I think RS/6000-320Hs with a fancy tag - machine type 6767?).
> > > I have only seen one of these routers in the wild, but most of the
> > > real NSFnet ones (I was decommissioning them, one time with a Sawzall
> > > because of some live tangled cables).
> > >
> > >> Could it be related to what you
> > >> say in your post?
> > >>
> > >> https://imgur.com/NIvQPBv
> > > Possibly related, but that card is not one of the NSFnet ones.
> > >
> > > --
> > > Will
> >
10:19 p.m.
That?s interesting stuff, get it done! :)
On Sat, Nov 3, 2018 at 3:01 PM William Donzelli <wdonzelli at gmail.com> wrote:
I have quite few NSFnet backup tapes that need to go
to Al at some
point. They likely have good stuff on them.
--
Will
On Sat, Nov 3, 2018 at 5:03 AM Kevin Bowling <kevin.bowling at kev009.com>
wrote:
Do you have software or docs for any of this stuff? I run
ps-2.kev009.com
On Thu, Nov 1, 2018 at 3:41 PM William Donzelli via cctalk <
cctalk at
classiccmp.org> wrote:
>
> OK, I assumed the 6611s used the NSFnet type cards. Artic960s are
> different animals - but probably very similar in idea.
>
> My memory is hazy, but I think the NSFnet cards were referred to as
Hawthornes.
>
> Somewhere around here I have one of the really early 386 based routing
> cards - a weird double height Microchannel card (the RS/6000s were
> RPQ'd with extra tall chassis to accommodate them).
>
> Anyway, I would like to get a 6611, but I do not think very many were
> made at all.
>
> --
> Will
> On Thu, Nov 1, 2018 at 6:19 PM Paul Berger via cctalk
> <cctalk at classiccmp.org> wrote:
> >
> > The machine type was 6611 and there where three model, the smallest
was
> > based on a 7011 the mid size one was
based on a 7012 and the largest
was
> > based on a 7013.
> >
> > The base card is an Artic 960 card which is just a processor card with
> > some memory that gets an application loaded on the fly. The top
> > interface card has a lot to do with determining what the function of
the
> > card sandwich is, there should be a X-Y
type code on the back of the
> > card that would define the interface. They where used for all kinds
of
> > things like Synchronous communications,
X25 and network accelerators.
> > Some of the interfaces cards used in the 6611 where unique to it and
> > never made it to the "standard" RS/6000 line. There was also a PCI
> > version of the Artic 960 but by the time it came along the 6611 was
long
> > gone.
> >
> > Paul.
> >
> >
> > On 2018-11-01 1:15 PM, William Donzelli via cctalk wrote:
> > >> So, what is this i960-based card for?
> > > They were the routers. At the core nodes of the network, there would
> > > be a big RS/6000s (very early POWER1 types) that would each do about
> > > 4-5 high speed interfaces (FDDI, HSSI, and 10base2). Each interface
> > > was one of these cards, so each of the big RS/6000s would have about
> > > 4-5 of these cards.
> > >
> > > IBM tried to commercialize the design, but it was doomed - the
routing
> > > engines were very fast, but the
internet quickly outgrew the
> > > architecture of the engines, and they apparently needed a complete
> > > redesign to compete. IBM did release very few of these RS/6000s to
the
> > > public (I think RS/6000-320Hs with
a fancy tag - machine type
6767?).
> > > I have only seen one of these
routers in the wild, but most of the
> > > real NSFnet ones (I was decommissioning them, one time with a
Sawzall
> > > because of some live tangled
cables).
> > >
> > >> Could it be related to what you
> > >> say in your post?
> > >>
> > >> https://imgur.com/NIvQPBv
> > > Possibly related, but that card is not one of the NSFnet ones.
> > >
> > > --
> > > Will
> >
4 Nov
4 Nov
7:42 a.m.
William Donzelli wrote:
After searching the web for a while, I finally discovered what this is:?
the key is that it is a "2-O" mca adapter, and it is a V.35
communications adapter.? But I also learned that IBM produced a series
of adapters hosting an i960 consisting of a processor card and a
daughter card; the daughter card would have the specifics for the kind
of interface that was implemented (rs232, rs422, X.25, etc).? These
adapters were called "ARTIC960 coprocessors".? They were first produced
for microchannel, later for PCI.? You could develop code for it in an
rs/6000 system, and then load on the adapter and run it:
http://ohlandl.ipv7.net/communications/aa6proggde.pdf
carlos.
So, what is
this i960-based card for?
They were the routers. At the core nodes of the network,
there would
be a big RS/6000s (very early POWER1 types) that would each do about
4-5 high speed interfaces (FDDI, HSSI, and 10base2). Each interface
was one of these cards, so each of the big RS/6000s would have about
4-5 of these cards.
IBM tried to commercialize the design, but it was doomed - the routing
engines were very fast, but the internet quickly outgrew the
architecture of the engines, and they apparently needed a complete
redesign to compete. IBM did release very few of these RS/6000s to the
public (I think RS/6000-320Hs with a fancy tag - machine type 6767?).
I have only seen one of these routers in the wild, but most of the
real NSFnet ones (I was decommissioning them, one time with a Sawzall
because of some live tangled cables).
Could it be related to what you
say in your post?
https://imgur.com/NIvQPBv
Possibly related, but that card is not one of the NSFnet
ones.
--
Will 
9:37 a.m.
Yes, a company I was working for OEMed what because IBM's X25Net
software and it was ported to their RTIC i960 cards from our own
homegrown i960 cards.
The IBM group we worked with was in La Gaude France but we heard the
RTIC cards were developed in Boca Raton, FL.
We ran VxWorks on them.
Todd
On 11/4/2018 10:42 AM, Carlos E Murillo-Sanchez via cctalk wrote:
William Donzelli wrote:
After searching the web for a while, I finally discovered what this
is:? the key is that it is a "2-O" mca adapter, and it is a V.35
communications adapter.? But I also learned that IBM produced a series
of adapters hosting an i960 consisting of a processor card and a
daughter card; the daughter card would have the specifics for the kind
of interface that was implemented (rs232, rs422, X.25, etc).? These
adapters were called "ARTIC960 coprocessors".? They were first
produced for microchannel, later for PCI.? You could develop code for
it in an rs/6000 system, and then load on the adapter and run it:
http://ohlandl.ipv7.net/communications/aa6proggde.pdf
carlos.
So, what
is this i960-based card for?
They were the routers. At the core nodes of the
network, there would
be a big RS/6000s (very early POWER1 types) that would each do about
4-5 high speed interfaces (FDDI, HSSI, and 10base2). Each interface
was one of these cards, so each of the big RS/6000s would have about
4-5 of these cards.
IBM tried to commercialize the design, but it was doomed - the routing
engines were very fast, but the internet quickly outgrew the
architecture of the engines, and they apparently needed a complete
redesign to compete. IBM did release very few of these RS/6000s to the
public (I think RS/6000-320Hs with a fancy tag - machine type 6767?).
I have only seen one of these routers in the wild, but most of the
real NSFnet ones (I was decommissioning them, one time with a Sawzall
because of some live tangled cables).
Could it be related to what you
say in your post?
https://imgur.com/NIvQPBv
Possibly related, but that card is not one of the NSFnet
ones.
--
Will 
9:46 a.m.
On Nov 4, 2018, at 9:37 AM, Todd Goodman via cctalk
<cctalk at classiccmp.org> wrote:
Yes, a company I was working for OEMed what because IBM's X25Net software and it was
ported to their RTIC i960 cards from our own homegrown i960 cards.
The IBM group we worked with was in La Gaude France but we heard the RTIC cards were
developed in Boca Raton, FL.
Yes, the RTIC cards were developed in Boca Raton. I had a number of friends that worked
in that group over the years. They were in a building off of the main site that was the
last to be closed down when IBM decided to close the Boca Raton site down.
TTFN - Guy
2010
days inactive
2016
days old
25 comments
16 participants
participants (16)
-
aek＠bitsavers.org -
bhilpert＠shaw.ca -
billdegnan＠gmail.com -
cctalk＠gtaylor.tnetconsulting.net -
ce.murillosanchez＠gmail.com -
cmhanson＠eschatologist.net -
derschjo＠gmail.com -
dkelvey＠hotmail.com -
ggs＠shiresoft.com -
kevin.bowling＠kev009.com -
krause＠informatik.uni-stuttgart.de -
paulkoning＠comcast.net -
phb.hfx＠gmail.com -
toby＠telegraphics.com.au -
tsg＠bonedaddy.net -
wdonzelli＠gmail.com