• Please review our updated Terms and Rules here

Simulating PDP-8 on a PDP-11?

DrCharles

Experienced Member
Joined
Sep 2, 2014
Messages
101
Location
West Plains, MO
I have an 11/23+ with 4 MB RAM, a pair of RL02's, a 3.5" floppy, 16 serial lines and TSX-Plus.
While thinking of interesting things to do with it, I wondered if there is any existing program that simulates a PDP-8?
It would be neat to have one of the terminals talking to a virtual PDP-8 with OS/8.
Is this impractical due to the speed, or lack thereof, of the 11/23+? Or has nobody attempted it? Or is it just plain nuts? :p
 
It should be practical; it is nuts (but that has never stopped any of us before has it) and it could be done fairly simply in MACRO-11.

But I'm on holiday...

Dave
 
It should be practical; it is nuts (but that has never stopped any of us before has it) and it could be done fairly simply in MACRO-11.

But I'm on holiday...

Dave

Absolutely - I once wrote one to run on a DG Nova (papertape and terminal only though) and I remember people mentioning different incarnations on a forum years ago. It wouldn’t be fast of course as each pdp8 instruction will take quite several pdp11 ones but it’s quite workable. Running OS/8 implies sorting out some device handlers too of course - perhaps to interface with your existing hardware - a bit more of a challenge. OS/8 isn’t interrupt based but for completeness .....? It can be as simple or complex as you choose.
 
I swear that I saw something on an old DECUS tape listing years ago which would allow you to do this, but it could only emulate the processor instructions, so no peripherals. It may have been more of a primitive JIT VM than an emulator though, or a sort-of cross compiler/interpreter which would let you load PDP8 paper tape.

It's obviously possible with enough memory but it'd be tremendously slow without some serious low level optimization, depending on what you want to use it for and how you want to run it (under an OS or with a raw bootloader).
 
I was thinking more of being able to sit at one of the PDP-11's terminals and have the experience of talking to a PDP-8... We could call that an Olsen test instead of Turing :)
That would imply an operating system (such as OS/8) since there'd be no way to enter RIM or other bootloaders.
 
How fast was a PDP–8 in terms of instruction per second? I have never written an emulator on a PDP-11 but on a AVR I have written a Apple II emulator which used about 10 to 20 AVR instruction to emulate a 6502 instruction. However the clock of a AVR is much higher so the result was slightly faster than a real Apple II. Is there a recommended document that would give an verview of what would be required to be emulated not only instructions but as well IO?
 
>>> That would imply an operating system (such as OS/8) since there'd be no way to enter RIM or other bootloaders.

Why not? You can emulate the IOT instructions themselves. You can convert the serial IOTs to talk to a DLV11/J and the disk IOTs to talk to something like an RQDX3 (but using fewer of the blocks to align with what your PDP-8 device driver expects).

You should be able to get the 'full experience'...

Dave
 
How fast was a PDP–8 in terms of instruction per second?
Later models were faster, for the most part, but as Wikipedia states, the original "straight-8" had a memory cycle time of 1.5 μs (the 8/e was 1.2 μs, as DrCharles notes.) Most of the main-group instructions are two-cycle (unless they perform an indirect reference, which requires another cycle,) while the OPR instructions are single-cycle. So the speed on the original model is somewhere in the range of ~222-666 KIPS, depending on the code, while on the 8/e it'd be ~277-833 KIPS.
 
Back in 1978 or so when the PDP-11/60 first came out it offered something new for the PDP-11
series, a writable RAM-based microprogrammable option, and there were some tools developed to
write and assemble microcode under RT-11. The WCS option was 1K of microwords IIRC.

Richie Lary of the PDP-8 world (his name appears a lot in the OS8 software sources) then was also
doing some microcode consulting on the PDP-11/60 project. As he indicates below in an interview
in 2015 for the Computer History Museum (portion extracted) he implemented an emulator for the
PDP-8 in 11/60 microcode and then others built it into a version of RSTS to provide a virtual time
shared PDP-8 that was, at the time, the fastest PDP-8 available.

So, not quite writing a PDP-8 emulator in PDP-11 code, but the user interface would be similar.
The main difference is (probably) a 10X performance speedup of microcode vs macrocode.

Don

Code:
Lary: Microcode words tend to be very wide and, although later people have actually succeeded
in doing this, [it tends] to be very difficult to do any kind of machine translation to write a
high-level language that converts into microcode. So it is all hand coding, which of course I was
great at, and the other thing was that microcode used to fit in a read-only memory, or at least
a very hard to modify memory. You could do updates to it, [however].. Which meant you only had
so much [memory] and this is where my skills at turning N words into N minus 1 came in handy.
So I became a microcoder on the PDP-11/60, helped write some of that code for floating point
and some other things.

And then as a hack, I wrote a PDP-8 emulator in microcode for the PDP-11/60. A friend of mine,
Mark Bramhall, who was doing RSTS, built a shell in RSTS that we could run PDP-8 code native
on this PDP-11 and it would run on PDP-8 speeds. Because the 11/60 was a pretty fast machine
and the PDP-8 guys who were left who were still doing PDP-8 development, they used that as
their development platform. They had a virtualized emulated PDP-8 that was time shared that
ran at PDP-8 speeds, and that they could access from their offices as a time sharing system
and run multiple jobs on and stuff like that. And they used it for the next 10 years to develop
PDP-8 software.
 
Richie Lary of the PDP-8 world

I am 'acquainted' with Richie - we both worked in CXO for years. Years ago he gave me a VT05 that he was storing under his deck.
When he left DEC and cleaned out his office, he threw a bunch of stuff in a bin, so I rummaged through it to salvage some things. One was a custom "logic analyzer" that he designed, circa 1985(?). Our CXO site was doing storage controllers, including the UDA50, KDA50, and HSC50, which all used a 2901 bit-slice architecture with dual sequencers (which I think Richie architected). Richie needed a logic analyzer, but the commercial choices didn't do what he wanted. So he designed his own, nicknamed 'MAD' (need to look up what the acronym stood for). It consists of two quad-height Q-bus cards plugged into an 11/23, with ribbon cables to the UUT. Some SW ran on the 11/23 under RT-11 - Harry Siegler wrote part of that support SW. It was used for lab debugging of the HSC50. Another key engineer on the HSC project was Tom Fava.
Anyway, I still have those two logic analyzer boards. Only a few were built - it wasn't a 'product', just used in our lab.

Pete
 
Don,

Thanks for pointing to that interview - it should be required reading for anyone with an interest in early DEC gear. I'm looking forward to Part 2.

I'm also curious to know if CHM (or anyone else) ever did an extensive interview with Tom Stockebrand, whose work included the tape drives for the TX-0, the LINC and DECtape.
 
Don,

Thanks for pointing to that interview - it should be required reading for anyone with an interest in early DEC gear. I'm looking forward to Part 2.

I'm also curious to know if CHM (or anyone else) ever did an extensive interview with Tom Stockebrand, whose work included the tape drives for the TX-0, the LINC and DECtape.

Here's a blurb on Tom, copied from here: http://www.decconnection.org/digitalstechnology.htm
Code:
One of my all-time favorite technologists arrived as a result of this... an amazing guy named
Tom Stockebrand. He was, if memory serves, actually a Chemical Engineer and was hired to
build our first "integrated circuit" known as a diode strait. It was meant to allow our modules
to derive logic power (-3 volts) with a single component instead of the handful of resistors 
and expensive diodes that were required at the time. Ken tells the story that the week the 
project finally delivered the first devices the price of diodes dropped to around 14 cents... 
making the diode straits our first "technology/financial failure"... the important thing is that 
Tom - the technologist - stayed on and created some of the most innovative products the 
company ever built!  You know some of them...the DECwriter(s), the VT-05, VT-50 and 52,
and on and on...)

I never met Tom while I was in Maynard/Tewksbury, but I did meet him on a business trip out
west when he had taken over running the DEC Albuquerque facility in New Mexico. He was never
one that liked the in-fighting between all the groups in Massachusetts, so he headed out west
to run that facility when he got the chance. The were producing the VT10x there at the time.
He also had an advanced development terminals/graphics group that he was running.

The main focus of our trip at the time was to go out to Stanford and visit with a researcher
at SLAC named Prof Forrest Baskett concerning a grad student of his that developing a new
kind of graphics terminal, and he thought it might be of interest to DEC. The grad student
was Andy Bechtolsheim and it was the SUN (Stanford University Network) model one terminal,
built around a new fangled chip called the MC68000 that was programmed to do 'BITBLT'
operations. This was about 1980 or 1981 as I recall. https://en.wikipedia.org/wiki/SUN_workstation

Don
 
Found this in the CV of someone on the net:

April 1978
Digital Equipment Corp., Albuquerque, New Mexico, c/o Tom Stockebrand.
Advised on the use of grey-scale and anti-aliasing to multiply effective screen resolution for a project developing a high performance graphics terminal.


Wasn't until 1980 that I met Tom in Albuquerque, and I'm sure we talked to him about his work on this project, as that is similar to what we in Tewksbury PDP-11 advanced development group were working on at the time. We were using OTS portrait mode monitors (Ball Bros IIRC) and were mainly working on the graphics processing subsystem.
 
Back
Top