Bob Eager
2024-02-25 13:34:04 UTC
Not big iron by any means, but intersting I think. Particularly the
postscript.
I studied Electronics as an undergraduate. The degree programme wasn't
quite what I expected (it leaned more towards pure electronics than
electronic engineering), and I found it had rather too much physics in it,
and not enough emphasis on the practical stuff; I think the problem was
the inbuilt assumption that I'd have been playing with stuff (and
designing it) for quite a while before starting the degree.
Two things happened. One was that I soon became interested in all things
related to computers, and the second was that I found I could (sort of) do
digital electronics OK (much easier!). I learned a lot of stuff about
various systems, in particular our mainframe (see previous posts), which
ran VMs-within-VMs, effectively.
My final year project was unusual in that it was a joint one with another
student; he ended up doing the actual building part (including PCB
design), and I did the logic design and the software (hardware tests). The
project was to modify the CPU of a Honeywell DDP-516 minicomputer, which
was fitted with something called a memory lockout option (MLO). These
machines were used as IMPs in the early days of the ARPAnet.
I had realised that the MLO provided insufficient facilities and controls
to provide a proper virtual machine (as a hardware emulation). It did
provide something called restricted mode, which stopped certain
instructions (e.g. CPU halt) from being executed. The project was intended
to fix this. It was made easier on a practical level by the fact that this
was a set of wire wrapped backplanes containing multiple, rather small,
circuit boards. There were some spare, uncommitted board slots, which were
wired and used for this.
This is not the place to go into a lot of detail, but essentially the
modifications were:
- In restricted mode, some instructions were silently treated as a no-op
(NOP) instruction, rather than causing an interrupt to the operating
system. This meant that instruction emulation inside a virtual machine was
impossible. This was fixed by the addition of extra logic to cause an
interrupt in this situation.
- It was also not possible to emulate restricted mode inside a virtual
machine, because the instruction to enter restricted mode (ERM) was
treated as a no-op if already in restricted mode. This was fixed by the
addition of logic to force an interrupt.
- This wasn't strictly necessary but made life easier. When an interrupt
occurred, it wasn't possible to tell if the interrupt had come from
restricted mode, or from normal mode. A latch was added to preserve the
previous mode. There was an instruction to save machine flags, etc. on an
interrupt; it was, strangely, called 'input keys' (INK). It simply copied
the flags to the accumulator so that the operating system could store them
somewhere. INK was modified to save the state of the 'previous mode' latch
in an unused bit. Note that the 'output keys' instruction (OTK) was
naturally not modified, as all it could do would be to write back into the
latch!
I am pretty sure there was other stuff, too, but I can't remember right
now. And of course I wrote a set of hardware test programs.
Postscript
----------
Much later on (decades) I had a weird experience.
As part of a possible project, I was recently trying to get some good
photographs and physical details of the Honeywell DDP-516 control panel
(this sat on a desk, connected to the main cabinets via a thick cable). I
was after pictures, as well as accurate measurements, and the details of
how each switch operated (momentary, two state, three state, etc.) I was
able to locate some information online, together with some pictures I took
on the visit below. My photos are here:
http://www.ancientgeek.org.uk/Honeywell/DDP516_photos/
I noticed that the pictures were of an item held by the Science Museum in
London, so I decided to contact them. After a false start when no one got
back to me, after several months I was able to have a discussion with a
very helpful lady who arranged for me to have access to the panel.
Unfortunately it was actually on display, and because of that (and other
reasons) I was obliged to make my visit between 0700 and 1000 (i.e. before
Museum opening time) on the day arranged. We settled on 0745 as the
earliest feasible time for me, and I got up very early (it's about two
hours travel).
On arrival, I was admitted via a side door and went to sign in. We had to
traverse a lot of the main floor of the museum, which was quite
interesting as it was deserted apart from a couple of cleaners! I was then
taken down to a basement lab, where the panel awaited me on a bench.
Apparently, due to the proximity of another exhibit, there had been a few
problems extracting the panel from the display cabinet; a small member of
staff had to crawl in to get it!
At this point, I think I gave the conservator a bit of a shock. As I laid
my hand on the panel, I said something like "This is the first time I have
touched this panel for over 44 years". Yes, it was the same panel. I had
done some research, and discovered that when it left the my university,
the DDP-516 had been donated to a local school. Several years later, it
had been taken by the Science Museum, although they only retained the
panel.
I spent about an hour and a half examining and photographing the panel,
and taking measurements; mission accomplished. I then had coffee in the
Victoria and Albert café across the road, before entering the Museum again
as a member of the public. I spent some time touring the 'Information Age'
exhibition before returning home to sleep. The cabinet containing the
DDP-516 panel contained other artifacts from the start of the ARPANnet; a
Teletype, an IBM 360 panel, and a PDP-10 panel.
postscript.
I studied Electronics as an undergraduate. The degree programme wasn't
quite what I expected (it leaned more towards pure electronics than
electronic engineering), and I found it had rather too much physics in it,
and not enough emphasis on the practical stuff; I think the problem was
the inbuilt assumption that I'd have been playing with stuff (and
designing it) for quite a while before starting the degree.
Two things happened. One was that I soon became interested in all things
related to computers, and the second was that I found I could (sort of) do
digital electronics OK (much easier!). I learned a lot of stuff about
various systems, in particular our mainframe (see previous posts), which
ran VMs-within-VMs, effectively.
My final year project was unusual in that it was a joint one with another
student; he ended up doing the actual building part (including PCB
design), and I did the logic design and the software (hardware tests). The
project was to modify the CPU of a Honeywell DDP-516 minicomputer, which
was fitted with something called a memory lockout option (MLO). These
machines were used as IMPs in the early days of the ARPAnet.
I had realised that the MLO provided insufficient facilities and controls
to provide a proper virtual machine (as a hardware emulation). It did
provide something called restricted mode, which stopped certain
instructions (e.g. CPU halt) from being executed. The project was intended
to fix this. It was made easier on a practical level by the fact that this
was a set of wire wrapped backplanes containing multiple, rather small,
circuit boards. There were some spare, uncommitted board slots, which were
wired and used for this.
This is not the place to go into a lot of detail, but essentially the
modifications were:
- In restricted mode, some instructions were silently treated as a no-op
(NOP) instruction, rather than causing an interrupt to the operating
system. This meant that instruction emulation inside a virtual machine was
impossible. This was fixed by the addition of extra logic to cause an
interrupt in this situation.
- It was also not possible to emulate restricted mode inside a virtual
machine, because the instruction to enter restricted mode (ERM) was
treated as a no-op if already in restricted mode. This was fixed by the
addition of logic to force an interrupt.
- This wasn't strictly necessary but made life easier. When an interrupt
occurred, it wasn't possible to tell if the interrupt had come from
restricted mode, or from normal mode. A latch was added to preserve the
previous mode. There was an instruction to save machine flags, etc. on an
interrupt; it was, strangely, called 'input keys' (INK). It simply copied
the flags to the accumulator so that the operating system could store them
somewhere. INK was modified to save the state of the 'previous mode' latch
in an unused bit. Note that the 'output keys' instruction (OTK) was
naturally not modified, as all it could do would be to write back into the
latch!
I am pretty sure there was other stuff, too, but I can't remember right
now. And of course I wrote a set of hardware test programs.
Postscript
----------
Much later on (decades) I had a weird experience.
As part of a possible project, I was recently trying to get some good
photographs and physical details of the Honeywell DDP-516 control panel
(this sat on a desk, connected to the main cabinets via a thick cable). I
was after pictures, as well as accurate measurements, and the details of
how each switch operated (momentary, two state, three state, etc.) I was
able to locate some information online, together with some pictures I took
on the visit below. My photos are here:
http://www.ancientgeek.org.uk/Honeywell/DDP516_photos/
I noticed that the pictures were of an item held by the Science Museum in
London, so I decided to contact them. After a false start when no one got
back to me, after several months I was able to have a discussion with a
very helpful lady who arranged for me to have access to the panel.
Unfortunately it was actually on display, and because of that (and other
reasons) I was obliged to make my visit between 0700 and 1000 (i.e. before
Museum opening time) on the day arranged. We settled on 0745 as the
earliest feasible time for me, and I got up very early (it's about two
hours travel).
On arrival, I was admitted via a side door and went to sign in. We had to
traverse a lot of the main floor of the museum, which was quite
interesting as it was deserted apart from a couple of cleaners! I was then
taken down to a basement lab, where the panel awaited me on a bench.
Apparently, due to the proximity of another exhibit, there had been a few
problems extracting the panel from the display cabinet; a small member of
staff had to crawl in to get it!
At this point, I think I gave the conservator a bit of a shock. As I laid
my hand on the panel, I said something like "This is the first time I have
touched this panel for over 44 years". Yes, it was the same panel. I had
done some research, and discovered that when it left the my university,
the DDP-516 had been donated to a local school. Several years later, it
had been taken by the Science Museum, although they only retained the
panel.
I spent about an hour and a half examining and photographing the panel,
and taking measurements; mission accomplished. I then had coffee in the
Victoria and Albert café across the road, before entering the Museum again
as a member of the public. I spent some time touring the 'Information Age'
exhibition before returning home to sleep. The cabinet containing the
DDP-516 panel contained other artifacts from the start of the ARPANnet; a
Teletype, an IBM 360 panel, and a PDP-10 panel.
--
Using UNIX since v6 (1975)...
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
Using UNIX since v6 (1975)...
Use the BIG mirror service in the UK:
http://www.mirrorservice.org