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. ch...@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…"