Rolm Computers: 1602, 1602A, 1602B, 1666, MSExx (was Data General Nova Star Trek)
Christian Kennedy
chris at mainecoon.com
Mon May 2 00:24:17 CDT 2016
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…"
More information about the cctech
mailing list