3 May
2016
3 May
'16
8:45 a.m.
Hi Chris,
thanks for the additional explanations.
;-) I think it is worth starting a separate thread here on the question
which early systems had a facility for memory and IO protection
facility. I still think, that 1975 is quite early for a Minicomputer
architecture.
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).
OK, that is helpful information - Stephen Merrony in the UK is
taking care of the MV series hardware/software/documentation and
he has some manuals on his page which enlightened me regarding
MV/Hawk32 instructions and usage:
http://www.stephenmerrony.co.uk/dg/doku.php
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.
What I have got is even smaller - called MSE14/Micro, it is 1/4 ATR
with a CPU on only two cards thightly packed together back-to-back
to ensure short connections and each full with discrete chips (AMD ALU,
sequencer, 32kW RAM and memory map; photographs show both sides of
the heavy CPU sandwich) -
http://www.baigar.de/TornadoComputerUnit/MSE14-CPU-Arithmetics-Memory.jpg
http://www.baigar.de/TornadoComputerUnit/MSE14-CPU-Microcode-Integer.jpg
it even has got a hardware multiplier doing 16*16->32 in one processor
cycle - so quite fast for those days. With the >20MHz, these are
running at, I can imagine that the "full size" MSE14 may have had
timing problems with the CPU distributed to several cards (and
many plugs for the signals have to pass).
"Eagle" was DG's name for the MV
architecture; ROLM's "Hawk" was a play
on "Eagle" ;)
Indeed - ;-)
which explains why
we're
only now in the process of changing out the 1970's 370-derived computers
in the E-3.
Hmm, I am not sure if this is a positive development. Special care
has to be taken to make the software robust and independent of
access to the internet. One does not want to run into trouble with
viruses etc. in such a context ;-)
In the case of the Hawk this was known
internally as the "one second architectural verification", but running
on the simulator it took approximately forever to finish,
Very funny - and understandable. Even in case of the MSE14 this BITE
implemtend in microcode takes several seconds and it is easy to
understand that it must have required a looooong time in the 1990ties
if simulated.
EventDetect (tm, no less) was basically a
PN diode that would conduct in the presence of radiation events and
non-destructively crowbar the power supply, after which the machine
would execute a normal power-fail auto-restart (the joys of core).
Hmm - here I am not sure. I just discovered, that I am proud owner
of PCBs called "Event Detect" with part number 7100A - so they really
existed, at least if mine are the right ones; They are IO boards
and therefore I doubt they short the power supply. At some time in
the future I will have a closer look to see what is on them.
[snip]
(Access
Protection Module or Mode or whatever (?)). This option is
not listed in the standard IO options and to my knowledge is a very
early form (dated before 1974) of such a feature ;-)
Way before my time. I assiduously avoided all contact with the 16XX
stuff, Toshiba America Electronic Components. We did the
MIPS-derived core in
the CPU2 chip of the Sony PS/2 -- the so-called "Emotion Engine".
From all your comments I am quite sure, that you had a
very
interesting business life so far - congratulations!
Many thanks again and best regards,
Erik.
On Sun, 1 May 2016, Christian Kennedy wrote:
>
>
> 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.p…
>
> 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?"
>