Rolm Computers: 1602, 1602A, 1602B, 1666, MSExx (was Data General Nova Star Trek)

[Christian Kennedy]

On 4/29/16 01:08, Erik Baigar wrote:
> 
> 
> On Thu, 28 Apr 2016, Christian Kennedy wrote:
> 
>> I was a staff engineer at ROLM MSC between '82 - '86.  By that time by
>> any reasonable measure MSC and telecomm were two utterly different
>> companies that happened to have common parentage; technology cross-over
> 
> [Another snip]
> 
> OK, so you are an insider to the Rolm MSC (=Mil-Spec-Computers?)
> division and in "your" years there, the design of the MSE series
> and probably beginning Hawk must have been accomplished?

Yes, MSC ::= MilSpec Computers

I was part of the Marvin team [1], an effort to built a B-level MLS
operating system that was capable of running AOS/VS code but which
internally was utterly unrelated to AOS/VS; it was the software effort
that matched the Hawk/32 hardware effort (software was downstairs on the
east side of the building; hardware was upstairs on the east and south
sides of the building.  While ROLM and DG had a close working
relationship, most ROLM implementations, both hardware (the 16xx and
Hawk, but not the odd S/140 and MV/8000 punches) and software (ARTS,
ARTS/32) were ROLM designs.

It was an interesting time.  I reported to Terry Dowling, who ROLM
recruited out of DG, and more or less everything we were doing was
pretty blue sky (in fact the charge code we used was for "Blue sky
product planning").  We learned to think about fault tolerance in
somewhat atypical ways (the node that's failed may not ever return
because someone just sunk it or, using Terry's favorite metaphor,
"planted a local sun on it"; under suitable gamma or neutron flux all
transistors become photo transistors, which has interesting consequences
for disk drives, etc) and the intersection of hardware and software was
fluid in a way that I hadn't seen since grad school (I ended up
specifying an I/O device that took advantage of an unused feature that
Steve Wallach had incorporated into the PTE format for the Eagle in
order to turn memory references into I/O requests that would be
transparently resolved in the physical memory of another machine.  There
was a sort of positive tension between the Hawk team, the Marvin team
and the architecture group that resulted in everyone learning a great
deal from each other ("Yes, I know that the PATU instruction only occurs
twice in the body of AOS/VS, but it's executed on every context switch
and as such it's probably not a really good idea to implement it by
having the microcode scrub each entry in the TLB").

In a curious twist of fate, I found myself working with member of the
Hark/32 team at TAEC in the mid-late 90's.  There was some curiosity
over the proliferation of little hawk statues, with some people thinking
we were stealing a single one from each other.


> OK, this makes sense to me as you in MSC certainly knew how to
> design sequencers and things like the connection tables from
> designing the processors and the MMUs. A very nice example from
> my point of view is the 3761 card for the Rolms Computers, which is
> a MIL1553 bus interface: This one essentially is a dedicated sequencer
> capable of autonomously routing data (and doing simple processing
> of it on the fly) by a command queue which resides in the hosts
> memory and is accessed in the background via DMA cycles. This
> obviously delivers outstanding realtime performance which is
> not only important in controlling aircraft but the same know how
> may have inspired the CBX.

The 1553 interface was a very clever piece of work, but not everything
we did was that smart.  At one point a disk interface was constructed
using an eight bit micro rather than discrete logic, and it was DOA
because the guys who designed it didn't understand that during boot it
was common to have code that looked something like:

doas 0,<device>
skpdn <device>
jmp .-1

The micro would be busy trying to make sense of the doas and be out to
lunch when the the machine asked for done status, resulting in it
returning garbage (or, more properly, the machine just reading whatever
happened to be floating on the nova I/O bus).

>> One of the more interesting was when the switch refused to
>> honor extension status changes and instead entertained itself by ringing
>> each extension *once* in ascending order, then repeating.
> 
> Very funny - but those days a reboot of the whole system
> takes just a fraction of a second - nowadays restarting a
> complex telephone system containing several servers may take
> several minutes which is even a bigger nuisance than the lost
> connection...

I can assure you, rebooting a confused VLCBX II took a lot longer than a
few seconds; that particular exercise resulted in us shutting down River
Oaks for the day ;)

Cheers,
Chris

[1] The original Marvin team -- Eddie Yea, Dave Yamada, Jim Woo and
myself -- were thought of by parts of management as "the bad attitude
team", so naturally we named the project after a certain paranoid and
depressed android -- which worked well until we discovered that
Marketing had been shopping the term to customers and wanted to know
"what it stood for".  In what has to be one of the finer examples of
bacronym engineering, we came up with "Multiprocessor Advanced Realtime
Virtually Interconnected Network" -- and they ate it up.  I probably
didn't help matters by including quotes from "Fear And Loathing in Las
Vegas" in the opening of each section in the architecture spec.

-- 
Christian Kennedy, Ph.D.
chris at mainecoon.com	AF6AP | DB00000692 | PG00029419
http://www.mainecoon.com	PGP KeyID 108DAB97
PGP fingerprint: 4E99 10B6 7253 B048 6685 6CBC 55E1 20A3 108D AB97
"Mr. McKittrick, after careful consideration…"