30 Apr
2016
30 Apr
'16
7:18 a.m.
Many thanks Chris for all the interesting recollections!
On Fri, 29 Apr 2016, Christian Kennedy wrote:
internally was utterly unrelated to AOS/VS; it was the
software effort
that matched the Hawk/32 hardware effort (software was downstairs on the
That sounds very interesting - although I do not know much about the
Hawk/32 it sounds to be a very interesting machine. I do not know
of anyone having one of these running, but I think some of them
should be still in service. And by accident I have got a tool to load
microcode onto the the Hawk/32 series: This tool is part of the
test facility (I have been told, that it was called "Rolm Mother"
in the factory) I got hands on and which is claimed having been
used in the original factory.
relationship, most ROLM implementations, both hardware
(the 16xx and
Hawk, but not the odd S/140 and MV/8000 punches) and software (ARTS,
ARTS/32) were ROLM designs.
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).
product planning"). We learned to think about
fault tolerance in
somewhat atypical ways
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?
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 ;-)
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!).
The 1553 interface was a very clever piece of work,
but not everything
we did was that smart.
It was extremely smart I must admit! I recently had two boards
communication using the BCUED diagnostics and it was awesome how
they sent messages, switched operation mode and changed roles
(master, terminal,...).
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.
There is an other similar problem with the boot code as implemented
in all 160x machines: Using the EPROM card and trying to boot from
it via the usual JMP .-1 located at 377 and a channel boot fails
as the boot code being executed in ROM places the JMP at
address 377, does the start command and than branches to 377.
But the EPROM PCB is so fast, that before the CPU "arrives" at 377
the JMP .-1 is already replaced and the code fails. So one has
to toggle the start command and the JMP in manually at 376 and 377
and launch it there...
"what it stood for". In what has to be one
of the finer examples of
bacronym engineering, we came up with "Multiprocessor Advanced Realtime
Virtually Interconnected Network" -- and they ate it up.
Very good choice of acronyms - fortunately the IT world has lot
of terms which can be arranged in many ways....
Thanks again,
Erik.