On Friday, October 9th, 2026 at 19:59, [email protected] <[email protected]> wrote:
> I used to own a VT-125, this had an internal card
> cage with an LSI-11 computer board. I can't remember
> what I did with it.
I had one of those on my desk for a couple of weeks. I
think it ran CPM.
I was working for an engineering company at the time.
We had a big contract in the Middle East that required
us to put a computer in our local construction office
in that country, but had nothing about what it had to
be used for.
So we sent it over there.
The one thing that we set it up to do was to be able
to dial into our PDP 11/70 at the engineering company
to transfer reports back and forth. That turned out
to be useless because, as near as we could tell, that
country would drop the connection as soon as they
realized it wasn't a voice call. They must have been
listening to everything that was said on their telephone
system.
The first time we tried it in the morning, it would
stay connected for a minute or two before going down.
From then one, every time we tried it that day, it would
drop in seconds.
By the way, we may have had the fastest PDP 11/70
around running the RSTS/E operating system. One year,
(1982, I think) we did an expensive upgrade -- $15,000
for one megabyte of memory, $15,000 each for two RM05
disk drives, and $15,000 for a disk controller. The
problem is that the operating system could only use
something like 530,000 bytes directly. So we set it
to use the rest of the megabyte for disk caching. To
do so, you normally had to specify precisely which
files would be cached. The funny thing is that the
disk caching really didn't do much to improve
performance.
It turned out that when it cached a disk block, it
remained cached for a minimum of 30 seconds. Think
about how often you need to work with the same block
of data from the disk for 30 seconds. You could also
set it to cache all disk blocks, but they were still
cached for 30 seconds. If you needed another disk
block from the same file less than 30 seconds later,
it just did disk I/O for those.
It always appeared to me that if there was already a
block cached for that file, it would not cache any more
blocks from that file until the 30 seconds had elapsed
and the block was removed from memory. I didn't
understand the idea on that.
I patched the operating system to reduce the cache
time to something like two or three seconds and
enabled caching for all files.
Before that, the computer ran at about 25% to 35% of
capacity all day long -- most of the time, the CPU was
idle. After making those changes, the CPU time pretty
much ran at 100% of capacity all day long. The
resulting increase in capacity was clearly noticeable
to everyone.
It didn't cross my mind at the time, but the CPU
probably ran hotter since it was running at 100% of
capacity.
Also, one year in the mid 1980s, I went to a DECUS
(DEC User Society) convention in New Orleans. One of
the DEC employees showed me something on one their
older PDP 11's that they had at the convention. That
PDP 11 had real core memory. He started the computer,
found a large directory, and did a directory listing.
Back then, the listing went slow enough that you could
sit there and read every file name with no problems at
all.
While it was listing the directory, he reached over
and turned the machine off. So on the monitor, it
showed how far the computer had reached. After about
thirty seconds or so, he turned it back on. Since it
was core memory, it continued on from where it was
without having to reboot. In the directory listing, it
only lost the one character it had been processing when
he turned the computer off. So that particular file
name was just missing one character of the name.
They also had a thing in RSTS/E called I and D space.
I for Instruction space and D for data space. If you
used I and D space, any reference to memory for data
was in D space. Any reference for execution was in
I space. So the same numerical memory address pointed
to different places in real memory depending on whether
you were trying to execute it or to use it as data.
In other words, with the limited address space available,
you could potentially double the amount of space a
program could have. The address location 04000 (octal)
might be the location of a subroutine in I space and
the location of a string in D space.
This did mess up the MARK N instruction which was an
instruction placed into the stack in a subroutine call.
The purpose of the MARK N instruction was to simplify
cleaning up the stack at the end of a subroutine. The N
referred to the number of words used in the stack for
the subroutine call. Instead of restoring the stack and
executing a return instruction, you would execute the
MARK N instruction which was stored on the stack.
As near as I could tell, hardly anyone used the MARK N
instruction. If not for the processor manual, I might
never have figured out exactly how to use it.
At that DECUS, there was a birds of a feather discussion
about assembly language. Somebody asked the moderator
about the MARK N instruction and the moderator asked the
150 to 200 people in the room how many had ever used it.
I was apparently the only one there to raise my hand. I
don't know if I was the only one who used it or the
only one who would admit that I used it.
Here is an example of the MARK N instruction from a
terminal emulator I wrote in the mid 1980s so
that I could dial into other computers (aren't
backups great?):
.MACRO EXEC SUBNAM,ARGLST
MOV R5,-(SP) ; MOVE R5 TO STACK
C=0
.IRP PARAM,<ARGLST>
MOV PARAM,-(SP) ; MOVE ARGUMENT ONTO STACK
C=C+1
.ENDM
C=C+6400
MOV #C,-(SP) ; INSERT ARGUMENT COUNT
MOV SP,R5 ; MOVE STACK POINTER TO R5
JSR PC,SUBNAM ; GO TO ROUTINE
.ENDM
In this example, the C=C+6400 created a MARK N instruction
where N was the number of arguments in ARGLST. It was
placed on the stack and then the stack pointer went
into register 5. At the end of the subroutine, an "RTS R5"
would would clean up the stack and return.
I liked those old PDP 11's even more than the VAX computers!
VAX VMS had one thing that I would love to see available
in OpenBSD -- the use of versioning. When you edited a file,
it would create a new version of the file while leaving
the previous one in place. If I remember correctly, the
file name would include a ';' and a version number. For
example, "FOOBAR;76". When you edit FOOBAR, it would
find the latest version to edit to create the next
version, for example "FOOBAR;77". There was a purge
command to purge all but the latest N versions of the file.
Eric
signature.asc
Description: OpenPGP digital signature
