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.

--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org

Analog electronics still gives me shudders! Digital for the win!

On Sun, 25 Feb 2024, Bob Eager wrote:

> 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.
>
>

On 25 Feb 2024 13:34:04 GMT, Bob Eager <news0009@eager.cx> wrote:
>Not big iron by any means, but intersting I think. Particularly the
>postscript.

[snip]

>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 can see them being shocked.
--
Jim

Bob Eager <news0009@eager.cx> wrote in
news:l40tucF44cqU7@mid.individual.net:

> 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.
>

Bob,

Thank you so much for the detail of your post! I appreciate such things.

Bob Eager <news0009@eager.cx> writes:

[...]

> "This is the first time I have touched this panel for over 44 years".

Amazing story and beautifully told.

D <nospam@example.net> writes:
> This message is in MIME format. The first part should be readable text,
> while the remaining parts are likely unreadable without MIME-aware tools.
>
>--8323328-2120186974-1708872655=:19569
>Content-Type: text/plain; charset=UTF-8; format=flowed
>Content-Transfer-Encoding: QUOTED-PRINTABLE
>
>Analog electronics still gives me shudders! Digital for the win!

Top-posting and mime-encoded usenet posts give me the shudders!

On Mon, 26 Feb 2024 15:36:12 GMT, Scott Lurndal wrote:

> Top-posting and mime-encoded usenet posts give me the shudders!

Try repurposing lawyer jokes. E.g.

A: Skid marks in front of the hedgehog.
Q: What’s the difference between a dead hedgehog on the road, and a dead
top-poster on the road?