1 May
2016
1 May
'16
9:57 p.m.
On 4/30/16 07:18, Erik Baigar wrote:
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).
It picked off the memory bus, not the I/O bus, and communicated via fiber.
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]
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?"
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. 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? 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!). 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.