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

[Christian Kennedy]

On 5/1/16 04:10, Erik Baigar wrote:

> sorry, but there emerged more questions from my side  ;-)

It's a trip down memory lane ;)

> 
> On Fri, 29 Apr 2016, Christian Kennedy wrote:
> 
>> Hawk, but not the odd S/140 and MV/8000 punches) and software (ARTS,
>> ARTS/32) were ROLM designs.
> 
> I only know ARTS from ads being sold on eBay - this is some
> form od Ada development environment (or a complete OS?)? The
> acronym probably means something like "Ada Real Time System" (?).

Advanced Real Time System.  Memory resident with hard latency limits for
servicing interrupts; it had nothing to do with the Ada compiler.

> 
> Was this a cross compiler tool or did it run natively on the
> hardware? As there is a /32 variant, do you think a variant
> for the 16 bit machines like 16xx or MSE14 did survive some-
> where?

ARTS/32 was for Eagle architecture machines and actually made use of the
rings :P.  Prior to the Hawk there was a punch (basically a
militarization of DG's prints) of the MV/8000 of which something like
three were sold; it was about the size of a large modern refrigerator
and was sufficiently massive that it had large lifting rings on the top
of the cabinet; while sometime someone would fire up the one that lurked
in the hardware lab, 99.999% of ARTS/32 (and all of the Marvin)
development took place on commercial DG hardware -- MV/8000s for
ARTS/32, MV/10000s for Marvin (with MV/4000s used as target machines).

I have no idea if any of the software survived anywhere :(

It's funny that you mention the MSE14; it was the other punch done by
ROLM, basically a S140 stuffed into a 1/2 ATR chassis.  IIRC it had a
somewhat painful gestation, because mapping the 15x15" S/140 processor
onto multiple smaller cards created interesting timing problems.

The ADA compiler was developed in partnership with Rational; as part of
that deal ROLM was supposed to look at creating a militarized version of
the R1000.  The R1000 was freaking huge -- much taller than a MV/8000,
to the point that getting it into the machine room was a bit of a
challenge -- and it turned out it was markedly slower executing Ada code
than a MV/8000 running code produced by the ROLM compiler, so in the end
that project went more or less nowhere.


> 
>> 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.
> 
> Although I do not recognize the "PTE format", I guess the Eagle
> project is related to a widely sold US made aircraft, right? This
> one carried at least one Hawk/32  ;-)

PTE ::= Page Table Entry.

"Eagle" was DG's name for the MV architecture; ROLM's "Hawk" was a play
on "Eagle" ;)

> 
> Some of the Rolm stuff I have got is from the company which serviced
> the equipment of the ATTAS aircraft...
> 
>   http://www.dlr.de/dlr/desktopdefault.aspx/tabid-10644#gallery/1751
>  
> http://www.dlr.de/dlr/Portaldata/1/Resources/documents/ATTAS_Handout_2001.pdf

Huh.  Interesting :)

>> 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").
> 
> I guess you have not been happy with context switching and how
> the Rolm microcode implemented it. 

IIRC we caught the problem early enough that they were able to come up
with a hardware invalidation that did materially what the MV's did and
thus we didn't end up paying a terrible performance penalty on context
switching.


> Unfortunately, there is nothing
> on the internet related to the instruction set of the Hawk/32
> family but the hardware contained lot of big custom chips and
> therefor I guess it was far more powerful and complex than
> e.g. the Eclipse or earlier machines.

It's instruction set is identical to the MV/8000, but there's some
differences in how it treats "undefined" results and "undefined"
bitfields in a handful of instructions, enough to require tweaking the
diagnostics.


-- 
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…"