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

[Christian Kennedy]

On 4/30/16 07:18, Erik Baigar wrote:

> That sounds very interesting - although I do not know much about the 
> Hawk/32 it sounds to be a very interesting machine.

It was quite advanced at the time, thanks in no small part to the
efforts of Kamran Malik, Michael (Farbod) Raam and others.

> I do not know of anyone having one of these running, but I think some
> of them should be still in service.

They're still flying, on ship and in subs.  It's very difficult to
replace a mission computer in a weapons system, which explains why we're
only now in the process of changing out the 1970's 370-derived computers
in the E-3.

[snip]

> 
> But software prior to ARTS was just copies of the DG stuff as far as
> I can tell from the paper tapes I have got (mainly diagnostics).

All ROLM machines were supposed to be able to run DG software, including
diagnostics, but occasionally things went sideways, particularly with
the 16xx extensions and in places where the DG specification said that
certain bitfields were undefined but the diagnostics would expect them
to be zero.

[snip]

> Yeah for the later machines this may be true: E.g. the BITE of the 
> MSE14 is claimed to detect almost all problems in the CPU and I have 
> got seen a test report which shows that some poor moron randomly 
> soldered bridges onto the PCB board or cut wires and recorded whether
> the fault was detected. The result was, that more than 89 percent
> have been reported correctly -> This is very remarkable in my
> opinion. Does anyone know how this result relates to testing of
> modern CPUs?

My guess is that automated test coverage has come a long ways, but the
point of BITE was to do more than just verify the CPU but the Nova bus
and the cards sitting on it.  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, resulting in
it sometime being referred to not as "osav" but "neosav" -- the
never-ending one-second architectural verification.

> 
>> 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)
> 
> Hmm, in the list of peripherals for the Rolm IO bus I see a "nucelar
> event detector" which probably forces the processor into some routine
> verifying its correct operation after the "local sun" event.

Ah, event detect.  That was a morbid piece of marketingspeak if there
ever was one.  Large-geometry semiconductor devices (such as power
transistors in power supplies) are prone to catastrophic failure in the
presence of high neutron fluxes or gamma radiation (that whole
phototransistor thing again); 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).



> Apart
> from this the earlier Rolms (1602) had indeed bugs which (according
> to some ECN (=engineering change notes) could lead to freezing and/or
> branching to wrong memory addresses). One of my 1602s is a very
> strange one as it contains a memory and IO protection facility
> realizing some form of protection to prevent critical code from
> getting crazy.


> 
> This option consists of a special microcode realizing some form of
> kernel and user mode and an additional PCB in the CPU to detect
> access violations in core and IO - the whole thing was called APM
> (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, although Eddie did get briefly retasked to make a hack to ARTS in
order to appease the nuclear assurance folks, who basically lost their
collective minds when they realized the the nova I/O bus had no error
detection -- something that made them very unhappy with respect to the
machines deployed in GLCM/SLCM systems.

> 
>> order to turn memory references into I/O requests that would be 
>> transparently resolved in the physical memory of another machine.
> 
> What form of machine-machine communication was used in this case? Was
> this realized using the DG data channel transfers (MCA, would be very
> slow for a Hawk/32 I guess) or was it implemented in some newer
> hardware not depending on the DG IO bus?

It picked off the memory bus, not the I/O bus, and communicated via fiber.

> 
>> 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.
> 
> TEAC? The company we know from Audio devices and stuff like this?
> (Sorry for asking stupid questions!).

Toshiba America Electronic Components.  We did the MIPS-derived core in
the CPU2 chip of the Sony PS/2 -- the so-called "Emotion Engine".

[1553, snipped]

> 
>> doas 0,<device> skpdn <device> jmp .-1
> 
> Yes that is indeed a very common sequence of commands  ;-)
> 
>> The micro would be busy trying to make sense of the doas and be out
>> to lunch
> 
> ;-) That really is a design flaw. Together with two colleagues I 
> built a harddisk simulator for the Rolms and lucky as we are today we
> used a FPGA to realize the interfacing - so we could repair our bugs
> easily by modifying the firmware.

And your FPGAs are screaming fast in comparison to a 1983 micro -- and
to the 16xx as well ;)


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